Thursday, September 29, 2005

Improving accessibility: portal interface use without a mouse

I tried hard during development to make our portal interface W3C accessible (sorry no guest logins at the moment). The current interface has been live for almost two years now. I had a fair head start in development by using Terence Ordona's Nested Div theme for uPortal. Even so, it wasn't that easy to get the design right but as a result CSS is now used extensively for layout. In development I ran the usual automated accessibility tests (Cynthia Says and WebXact [formerly Bobby] amongst others), validation tools and tried my best to implement the suggestions these tools made. I've tested it with the Lynx text browser (incidentally if you using Win2K you can get a nice Lynx installer from CSANT). I know the portal interface is not yet perfect but even so it works and I was quite pleased with it.

The other day a user told me that it was impossible to use the portal without a mouse. First this shocked me, especially after all the effort I had gone to in order to make sure it worked in a text browser. My initial knee jerk reaction was that "they must be wrong" but I gave it some thought and tried to use the portal without a mouse but in a "normal" browser mode (Images on, CSS on, JavaScript on). The user was right, it wasn't impossible but it was hard to see where the focus was when it was located on one of the portal control icons, so what to do. I noticed on the university front page that they were using the CSS focus pseudoclass, this means that whilst tabbing through the page, using a fully compliant CSS2 supporting browser [Not IE], it highlights each link in a different colour so that you always know where your focus is. The downside to this was the CSS focus pseudoclass is not implemented in IE.

I then found an article on making IE support the focus selector. I needed to tweak this solution slightly to improve performance. I only wanted the onfocus behaviour so I turned off the hover functionality and restricted the stylesheet scanned to a single file and that seems to have done the trick. You can now browse the portal without a mouse (assuming you are otherwise fully visually able).

Wednesday, September 21, 2005

Java related Search Plugins for Mozilla browsers

Here's some of my favourite Java programming related Search Plugins for Mozilla based browsers.

Codehound Java
Codehound JavaScript
Java Sun
Koders (All)
Koders (Java)
Koders (JavaScript)
Java Developers Almanac
Java Doc
Maven Repo Search

Search plugins are great, they are like bookmarking search engines and having immediate access to their search form. Mostly these are from MozDev's MyCroft but one or two aren't. My only criticism of the MyCroft site is that it isn't very easy to browse the categories but if you employ some Zen thinking you can always use the MyCroft search plugin to search for other plugins. There are nearly 4000 plugins to add to your search bar so you're bound to find something useful in there.

Wikipedia (EN)
Mycroft Advanced Search

Thursday, September 15, 2005

Desktop Applications using JavaScript engines

With all the recent interest in AJAX applications, all manner of JavaScript related technologies have the potential to take to the spotlight. Yahoo!'s Konfabulator and Apple's Dashboard are two such fascinating applications. They serve up small desktop applications called Widgets. A widget could be a clock, RSS feed, a search engine, a CPU monitor and other fun little desktop distractions (think XTeddy and XEyes from the Unix days of yore). As you might expect of a product originating from the Mac arena some widget designs are close to aesthetic perfection. Konfabulator and Dashboard offer the same sort of functionality and are both based on an underlying JavaScript engine but are implemented in slightly different ways. Konfabulator and Dashboard files use the .widget file extension, this is only an alias for the ZIP file format and this means that anybody can look at the source for any widget and learn from the masters. I want to sidestep the Dashboard versus Konfabulator debates if I may as despite all the arguments they are sufficiently different internally to both have unique merit.

This is what a Widget looks like: this example is a butchered DHTML version based on the Flip Clock Dashboard widget from Neometric Software. It looks best on browsers with good PNG support.

Apple's Dashboard

Apple Dashboard widgets are created from HTML, Images, JavaScript and CSS. The Dashboard server uses the same engine as the Safari browser. The engine called WebKit is open source and consists of WebCore and JavaScriptCore; an HTML/CSS renderer and JavaScript engine based on KDE's KHTML and KJS. Widgets use and Safari supports certain non-W3C standards such as the <canvas> element. A Dashboard specific JavaScript mechanism called the widget object is available that allows a widget to run system commands, access other desktop applications and obtain online content.

Yahoo!'s Konfabulator

Konfabulator widgets are composed of JavaScript, Images and driven by an XML document (written in a Konfabulator specific XML dialect). Unlike Dashboard, Konfabulator has been written to be both Mac and Windows compatible. Konfabulator utilises Mozilla SpiderMonkey (written in C) as its JavaScript engine, this is the same JavaScript engine used in the Mozilla and Firefox browsers. Konfabulator provides specialised extensions to JavaScript to enable system interaction and widgets call the same API irrespective of what platform they are on (only the server implementation actually differs).

Thinking about Clones...

There is already a Dashboard clone called dotWidget and although it looks quite similar to Dashboard the underlying mechanism uses VBScript rather than any kind of JavaScript engine. Now being a Java sort of person I couldn't help but speculate how one might go about producing a Widget type of application using Java technologies. I'm not a Swing or AWT programmer so an actual implementation is probably beyond me but nonetheless it is interesting to think about the possibilities.

Musing about a Java Konfabulator clone...

SpiderMonkey is not the only JavaScript engine that Mozilla have produced. The now defunct codename Xena project, sometimes called Javagator, attempted to create a 100% Java version of the Mozilla browser. Xena produced a couple of interesting subprojects including a newsreader Grendel and a fully equipped Java based JavaScript engine called Rhino. Rhino would be a particularly good choice for any XML handling application because it now includes the power of E4X which makes XML programming very easy. Rhino is very easily embedded in other Java applications and so it would be quite feasible to produce a Konfabulator clone based on Rhino.

Musing about a Java Dashboard clone...

Since Dashboard widgets utilize HTML and CSS, a HTML renderer of some sort would be needed. There are some interesting HTML renderers about including Flying Saucer XHTML renderer but this does not currently integrate the JavaScript engine that we would also require. So I would think that a more suitable approach would be to use a Java browser wrapper. Via Joshua Marinacci's The HTML Renderer Shootout articles (Part 1 and Part 2) I found two projects that might fit the bill, JRex and Blackwood Webclient, both based on the Mozilla browser codebase. Using either of these would essentially harness the power of Mozilla in the same way as Dashboard harnesses the power of Safari. There is also a possibility that a Mozilla based browser could even support the <canvas> element. Specialised system JavaScript objects could also be supported using something like JRex's JRexLiveConnectSession. So at least in principle it would seem that it would be possible to create a Dashboard clone using Java.


A Java, JavaScript engine based clone of Apple's Dashboard and/or Yahoo's Konfabulator is within the realms of possibility. I also got the distinct impression that widgets are not that different to their web counterparts such as JSR168 portlets. Indeed there are already some widgets for the web types of application such as the Flash based OpenLaslo and AJAX based Bindows. Given the growing popularity of toolkits like Direct Web Remoting (DWR) to produce AJAX applications and quality of the JavaScript engines available a resurgence of server side JavaScript might be on the cards...

More about this in my next entry... The Return of Server Side JavaScript (SSJS).

The Return of Server Side JavaScript (SSJS)

Remember Server Side JavaScript (SSJS)? (okay you are probably far too young) It came out of a time when the most popular browser was NCSA Mosaic, some people were still trying to use C libraries to create CGI scripts and when Java was in early beta. SSJS has not been widely integrated in application servers. With the recent trend in AJAX applications it looks like SSJS might be on the brink of a renaissance.

In the AJAX sphere there has been much interest in Direct Web Remoting (DWR) which allows JavaScript access to Java beans methods via servlet generated JavaScript files. But why stop there, why not have JavaScript talking to JavaScript? (there is a certain perverse logic in there somewhere). It turns out that there are already several like minded offerings where JavaScript has become the Server Side scripting language of choice.

Mozilla produced Rhino, a Java based JavaScript engine as part of the Xena project. Several server side application platforms have been produced based upon Rhino. You can use Rhino directly, see these interesting articles on using Rhino with web services (1, 2) and it also supports E4X. I must also mention Seppia which is an application that embeds Rhino that might also be interesting to look at. Now to the Server Side JavaScript applications, here are a few examples that caught my eye:

  • Rhinola (based on Rhino, well duh!) and seemingly Unix server oriented uses mod_gcj to run JavaScript files as server side scripts much in the manner that you would expect Perl or PHP scripts to run.
  • JSDB is a versatile JavaScript scripting toolkit environment with support for database access.
  • Whitebeam is an application server with the Rhino engine at its core. As you would expect from an application server it integrates support for accessing databases and with Rhino's built-in support for E4X is also a dab hand at anything XML based (such as web services).
  • OpenMocha is an application server based on Helma which uses the Rhino JavaScript engine to do server side scripting. To my eye this looked like a distinctly content management system (CMS) based application.

In conclusion, it looks like JavaScript is rearing it's head in more places than in client side browsers. We're seeing JavaScript in desktop applications and on the server side once more. With E4X it has actually become easier to use JavaScript for XML manipulation than it is in many other so called real programming languages. From where I am sitting it looks like the future of JavaScript will be a bright one.

Friday, September 09, 2005

My 1st webpages using E4X (ECMAScript for XML)

I'm very excited about this (sad really!). The new versions of Mozilla 1.8 Beta1and Firefox 1.5 Beta 1 (Deer Park) support the ECMAScript for XML (E4X) Specification. For further information about E4X see Jon Udell's Introduction to E4X, Objectifying XML - E4X for Firefox 1.1, Wikipedia's E4X page, Brendan Eich's (Mozilla Chief Architect) E4X presentation and this W3Schools E4X tutorial.

I've yet to really dig into the specification in any depth but even this very simple example looks like it has the potential to change the nature of future AJAX applications.

This version works (but lacks proper web standards compliance):

<script type="text/javascript;e4x=1">

var x = <people>
<person gender="male">
<height measure="metric">176</height>
<person gender="male">
<height measure="metric">178</height>

document.write(x.person[0].@gender+"<br />");
document.write(x.person[0].name+"<br />");
document.write(x.person[0].hair+"<br />");
document.write(x.person[0].eyes+"<br />");
document.write(x.person[0].height+" ");
document.write(x.person[0].height.@measure+"<br />");

<h1>My First ECMAScript for XML (E4X) Page</h1>

and this version works AND is more standards compliant:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="">

<script type="text/javascript;e4x=1">

var xmlString = "<people>" +
"<person gender=\"male\">" +
"<name>Ant<\/name>" +
"<hair>Shaggy<\/hair>" +
"<eyes>Blue<\/eyes>" +
"<height measure=\"metric\">176<\/height>" +
"<\/person>" +
"<person gender=\"male\">" +
"<name>Paul<\/name>" +
"<hair>Spiky<\/hair>" +
"<eyes>Grey<\/eyes>" +
"<height measure=\"metric\">178<\/height>" +
"<\/person>" +

var x = new XML(xmlString);

document.write(x.person[0].@gender+"<br />");
document.write(x.person[0].name+"<br />");
document.write(x.person[0].hair+"<br />");
document.write(x.person[0].eyes+"<br />");
document.write(x.person[0].height+" ");
document.write(x.person[0].height.@measure+"<br />");

<h1>My First Standards Compliant ECMAScript for XML (E4X) Page</h1>

Both versions result in a screen containing something like this:

176 metric

My First ECMAScript for XML (E4X) Page

I advise you to try it yourself! Cool eh?

Tags :,

Sunday, September 04, 2005

CSS layout, CSS 2.1 tables and portals

Much as I appreciate the value of using CSS for layout, I am also aware of how much effort is currently needed (and how much resultant frustration) to convert a table layout web application to pure CSS layout that works in all modern browsers (don’t even talk to me about supporting Netscape 4!).

Recently a colleague of mine described creating CSS layouts for web applications as the holy grail. I’m not sure I’d have put it that strongly but I do take his point. To be fair for premeditated layouts it is relatively straight forward to create CSS layouts, good examples of these are Wiki, Forum and Blog software where you pretty much know in advance what the layout is going to be. CSS is good at static layouts but is generally pretty hard work for the average bod to create dynamic (fluid) web application layouts.

I recently discovered that WestCiv’s Layout Master WYSIWYG CSS layout creation software has just become freeware and it nice for the CSS novice to play with. That said Layout Master does not really help you in creating accessible CSS layouts as absolute positioning and fixed font sizes are generally frowned upon.

I have been recently working with the JSR168 software Apache Pluto and was quite disappointed that the simple portal application that comes with it uses tables for layout. I was disappointed because I otherwise consider this software to be at the cutting edge of technology and it should really be setting a better example as it is the official JSR168 reference implementation. Then again, what choice did it have if it was to work across browsers? In the article Getting your DIVs to behave like TABLEs I discovered my answer, with CSS 2.1 tables I can create table-like layouts easily.

The drawback of CSS 2.1 being that it requires a compliant browser which means Firefox or Opera but NOT Internet Explorer 6. However, I expect Internet Explorer 7 will support CSS 2.1 but I can’t try it out since I use Windows 2000 (grr). Although I should chalk this up as another victory for the far superior browser that is Firefox I suppose. Now I’m not being especially anti-Microsoft here I am simply stating that IE6 released in August 2001 with a single server pack update in 4 years cannot hope to compete with the Firefox browser that is current and constantly being improved. I didn’t make the move to Win2K until 2003 and probably won’t be in the queue to upgrade to Windows Vista until the dust has had plenty of time to settle. I’m not in a hurry to upgrade to IE7, which I understand from recent reviews is no better than Firefox. I'm sure there will soon be Firefox extensions to support any new Microsoft proprietary RSS formats. When I mentioned Microsoft Office 11 move to an underlying XML format my boss quipped that he expected that the XML would comprise of square brackets rather than angle brackets, I hope that he was joking and didn’t have insider knowledge...

Single Sign-On (Yale's CAS) for portlets using Apache Pluto portal driver

I've been contributing to the JASIG wiki again!

CASifying Apache Pluto portal driver