This summer I am working on a project to design and build automated functional tests of some of IBM’s web interfaces that act as control panels for their servers. This appears to be a fairly straightforward task: figure out what the test should do, use the tools to write the test, and debug the test until it works properly. Oh if only life were so easy…. Due to some design choices in IBM’s hardware management console software, the process has been extended with an additional step: figure out what the test should do, modify the tools so they can do what they need to, use the modified tools to write the test, and then debug the test until it works properly. Rather than ranting on forever and ever, I figure a picture is worth a thousand words, so here it is, IBM’s HMC interface in all its glory:
Above is the welcome screen, which is innocent enough. Nothing major here to report that personally makes my life difficult. I just felt that it would be too one-sided if all I did was complain. Now, lets get on to the stuff that makes you wonder why was this done?
What we have here is my first example of non-standard widgets that cause me problems. If you look at the screenshot carefully, 
you might notice two places that seem perfectly normal at first but at closer inspection are just not quite right. Were you thinking about the check box in the table and the drop down combo box in the upper right corner? These widgets are actually images that are manipulated with fancy Javascript to appear as normal as possible. The tools we are using support standard widgets, things built with input tags, fancy JS is just a pain to test. Plus, imho, it makes the interface feel much more sluggish. Every time one of these widgets is manipulated there is a definite delay before any feedback is presented to the user.
Now, let’s get on to another example. In the images below, there is another example of a drop down combo box that is implemented purely with image tags and Javascript. What is worse about this particular example, is that upon changing the value of the combo box, the entire page reloads to fill in the new value. This is because the combo box options are implemented by hyperlinks that when clicked, redirect the browser to a new page that has the previously clicked link as the selected option.
Now its not that I am angry with the way this was designed or that I am overly critical of it, but it raises 
the question, are the standard widgets that we are provided by our programming APIs sufficient for most uses? On the internet, I would say that overwhelmingly the widgets that are built into the browser are fantastic for 95% of whats out there. I mean, realistically, how often do you see someone reinventing a textbox with some Javascript ninja magic. The answer: never. Why? Because the ones built into the browser are already good enough at what they do. Alright alright, some things just cannot be done with standard widgets in a web browser, things like date pickers and sliders, but why reinvent the wheel when it is not necessary? The only thing that I could think of for this particular case was that using homegrown widgets improved cross-browser compatibility in some way that I couldn’t imagine. If I find out the answer to this question, I’ll try to remember to put it up here.
But back to my basic question, are when are standard widgets not enough? I guess there are lots of times the more I think about it, but lots of times in a sea the size of an ocean is still a limited amount. Then that also raises the question, what does it take to consider a widget to be “standard”? All the major web browsers implement the widgets slightly differently, especially between different platforms. And take Java for instance, built into the language are two widget libraries, AWT and Swing, which I would argue are Java’s “standard” widgets. But there exists a popular add on library confusingly named the Standard Widget Toolkit (SWT), so what is a newcomer to think? I think Ill come back to this question later.
