YUI – Yahoo! User Interface Library

What is YUI?

YUI is a set of javascript files containing useful UI code that are downloaded to the client in the normal "script src" fashion. The libraries build on themselves to provide ever richer UI tools.

The type of tools on offer include;

• Event registrations
• Dom support
• Drag n’ Drop
• Calendar
• Menu
• TreeView
• AutoComplete

My favourite is the Container that provides a very simple mechanism to include your own dialogs on a page, including psuedo modal windows.

My Staff Database

The project I wrote using YUI was essentially a very simple contact list with the following basic structure;

[Edit Box] [Find Button]

[Name of person] n [Contact details]n  [Photo]n

[Name of person] n+1 [Contact details]n+1  [Photo]n+1

etc

The Edit Box for searching for a persons name is implemented as an AutoComplete control, so as you type in the persons name it displays a list of ever more specific matches. When you find a match, you click the Find Button and the page is scrolled to the person in question and their name is animated to draw the users attention. The user can then see the thumbnail image of the person and can click on the image to see a larger picture. This invokes a photo-box dialog that displays the picture in a modal dialog without the user having to leave the main page.

Any problems using YUI?

YUI isn’t without its problems.

Documentation

When I started using YUI it was in a beta form so the help was a bit sparse and even though it has been improved I still needed to fish around inside the implementation libraries to understand what I needed to do.

Style

I’m sure Javascript must hold some kind of record for the number of ways to define a function block and I’m equally sure people will argue for weeks about which style is best to use. However, what I would expect from library code (of which I include the example code) is a consistant style. I’d just got used to one style in the ‘Module’ code to be faced with a different one for ‘AutoComplete’. Ok it’s a minor thing but it’s pretty irritating, if not tricky, to read a block of code with different coding styles within it.

Stylesheets and Javascript

Obviously a Javascript library needs Javascript to work, but it does need to placed into the ‘problem’ section since there are server side alternatives to many of the YUI features. I chose to degrade gracefully when there is no javascript by defaulting to a fairly standard HTML version of my page and getting Javascript to add complexity, that way if there is no Javascript then you only get the basic feature set. The slightly trickier problem is the use of Cascading Style-Sheets (CSS). For me, one of the great goals of CSS is that it should degrade gracefully. YUI relies on CSS to provide many of its features, some degrade more gracefully than others. For example, the auto-complete list is a hidden list, turn off stylesheet support and the list is created underneath the edit box. Ok it’s ugly but functionally it works fine. However the containers don’t really work. In my example the photo-box simply stays at the bottom of the screen and is pretty useless. More annoying is the use of colour. I wanted to write a colour fade (or animation) but this required me supplying the colours I wanted to use. Now I can’t really do this since the user (or other developer) maybe using a stylesheet that I’m not expecting. YUI provides some support for detecting the style of an element but this didn’t work as expected. When I asked for the background colour of a specific element it failed to properly traverse the CSS hierarchy and only provided the correct answer when the element was specifically configured in the stylesheet. That led me onto another annoying problem, my workaround was then to use an opacity fade but that kept doing odd things to the font. Eventually I discovered that you must ensure the text in an opacity fade has a background colour.

The other major problem with the CSS use is how accessable the page is. In my example I had to add extra buttons and events to cope with the keyboard user. Reading between the lines it looks like the YUI is doing more in this area but currently I feel you have to add too much of this code yourself.

Extending the YUI

Apart from the coding style issues I found extending the YUI relatively easy. The main problem is due to its main advantage, the coupling of the modules hides the complexity of the lower-level libraries but it can also means that you can break the code without really knowing why. In my example I have pictures of different sizes to display within my photo-box, so I extended the module to allow me to specificy the dimensions of the image. This worked fine for a while but suddenly the box refused to be moved by the user and would just stutter. Also if I created a dialog larger than the viewport it started to behave erratically. I’m still not sure what caused this, perhaps beta code, but after a re-write for the latest version it seems to work.

Summary

I think the YUI is well worth a look but I do get the feeling that the majority of the features are built for users with a monitor and a mouse. Then again there is nothing stopping you extending the library to better cope with other devices. So even though it isn’t perfect I’m certainly considering using it in future projects.