Object or UI Orientated?

Both libraries have implemented their own…style…for providing a more OO feel to the JavaScript code and to introduce some extra programming techniques, e.g. Namespaces. However, I believe that ATLAS goes quite a lot further. It allows you to register classes (including base classes), interfaces, enums etc. Although YUI has some of these features it feels very much more like YUI includes them to support the UI whereas ATLAS has included them to produce OO like code that happens to be used in the UI. A subtle but important difference, although if I can get the UI working without worrying about the code perhaps the Yahoo! way is better? If you’re a .net programmer now I’m sure you’d feel at home with the ATLAS client…code extensions(?).

UI Features

Both libraries have a very similar set of features but I’d say the YUI is more mature than the beta ATLAS counterparts. The YUI components just seem to work as you’d want. When I launch a panel in the YUI I get the full dialog experience with options for title bars, modal dialog, move controls, etc. Whereas for ATLAS I seem to get a square that I can move, but I’ve got to add the mouse pointer, the title, etc, etc. Another example is the Auto-complete edit box. The YUI and ATLAS variants do pretty much the same job, however the YUI includes a "selected" event, whereas I seem to have to code that myself for ATLAS. This means that I can quickly produce pretty slick UIs with YUI that do 90% of what I want. However, here’s the bind. When the YUI component doesn’t work as intended it takes quite a bit of fishing around to understand how the component works to sucessfully alter its behaviour. Whereas with ATLAS you learn that up-front and changes are easier because it works as you programmed it to. Ok, that’s a bit unfair, with the ATLAS control kit you can pretty easily wrap core features to become something more like what you need out of the box. However, I still come back to thinking that the YUI did almost everything I wanted without any need to customise it.

Summary

With my short time spent using both sets of libraries I’d have to say I’d probably invest my time in ATLAS. Mainly because it seems like the logical path to take when developing Microsoft based solutions, especially when you take into account ATLAS’ XAML like script, surely the tools will eventually all come together. However, at this very moment in time I would say that YUI wins hands down for its easy of use and feature set. I thought I’d struggled to get around animation bugs in the YUI, well I’d not seen the ATLAS implementation!

I’m sure over time both libraries will improve and it will probably just come down to the sort of coding you need to do. If you’re a Microsoft shop I’m sure ATLAS or Microsoft AJAX Client/Server/Control libaries will be for you.

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.

I was reading a collegues code review the other day and they raised the point that they didn’t understand what the new parameter in a call meant. The reason for this was the new code simply stated something like:

MyMethod(Name, Address, true)

Naming conventions means the first two arguments do a good job of conveying what they are supplying to the method. The problem with the third argument is it’s more of a statement rather than a hint to its (ahem) true meaning. The proposed solution was to swap this out for a enum; UpdateProcess.New | UpdateProcess.Edit Ok I can see how that might work, but the obvious point that seemed to have been missed is why not simply use a variable? If I rewrote the call using a variable for the Boolean wouldn’t this sort out the problem?

MyMethod(Name, Address, isNew)

Well to some extent it does, at least now the reader has some clue to the intent, however, if true==isNew what does false mean? What is the opposite of isNew? Ok you’ve read that the intent is to be new or edit, but you’ve had to discover that by some other means, the code doesn’t not convey that. You’d have to read a comment or drill down into MyMethod to understand that. This is where the (ahem..again) argument for a enum gains the upper hand. I’ll re-write it again.

MyMethod(Name, Address, UpdateProces.New)

Once again we can see what the caller wants to do a "new", whatever that is. But now the reader (assuming a decent editor) can hover over UpdateProcess and see what the alternatives are, in a binary case such as this then there are only two, previously represented by true/false. But now the reader has a chance of understanding the authors intent.

So what this long-winded blog entry is trying to say is, "do we need Boolean flags now?" I don’t think there is much need for them now, so I’ll shed a little tear for a faithful old friend and usher in more of those ugly type-space-hogging enums. I guess this is progress. R.I.P bool flag.