Designing applications is the most difficult aspect of creating a program. The job of the JavaScript developer is slightly more difficult as well, because the platform -- the Internet -- is a relatively new phenomenon, and developers are still trying to figure out what works and what doesn't.
Hopefully, when you looked at the object browser example, it didn't cause any reaction in you at all, aside from the normal confusion and curiosity associated with a new application. The purpose of the object browser is to teach JavaScript programmers about form objects, and not wow them with my deftness as a JavaScript developer. My goal in creating the application was to minimise the delay between the time when it is opened and the time when it is put to productive use.
Step back for a moment and pretend that you have not seen the example, and that you were writing the tutorial. Your purpose is to use HTML to teach JavaScript developers how to use form objects. How do you do it?
The first decision that I made (which was no grand revelation) was to provide both a description of the objects, and show them in use. Fair enough, but what next?
The primary consideration is the platform itself -- the Web browser and HyperText Markup Language. The Web has ushered in a new paradigm in information distribution and dissemination: non-linearity. When you read a book, you generally start on page one, and read the subsequent pages in order until you get to the end. With the Web, however, the process is different. Because a Web page can contain any number of different hypertext links on it, the user is free to branch off in any direction that catches his or her fancy. The human brain is non-linear by nature as well, and non-linearity is conducive to a better learning experience. For example, some readers may find that they absorb the information better by studying an object and then looking at the example, while others may prefer to go through all of the explanations before looking at the examples.
The next consideration is structure -- the human brain naturally appreciates structure and method. One of the reasons that people burn out on the Internet after the initial excitement is because of its lack of structure. The Web becomes an interactive TV, which often leaves users feeling empty, as if they've gained nothing from the experience. The conundrum is that you want to maximise the benefits of the Web's non-linearity while providing an underlying structure that is both logical and transparent.
The next consideration is the presentation of the application, or the User Interface (UI). I have a motto -- nothing makes things easier than simplicity. Makes sense, huh? Certainly we will all be guilty of violating that rule, but it's a good practice to follow.
There are many more considerations to take into account when designing JavaScript applications, as well as Web pages in general. One of the best resources on the Net is Jakob Nielson's homepage, www.useit.com. Jakob Nielson is a Sun Microsystems Distinguished Engineer who has spent a great deal of time studying usability issues. I can't recommend this site highly enough. He has also written a number of books, the most pertinent being Usability Inspection Methods (published by John Wiley and Sons). The following list is five of his top ten usability guidelines, and a short explanation of their meaning.
An application should provide feedback about what is happening with it.
The interface should parallel systems that the user is familiar with (ie. online ordering resembling a menu).
The user should control the application (not vice versa), and there should be many ways to accomplish the same task.
An application should not only maintain consistency internally, it should also recognise the standards of a platform (such as the cntl-O shortcut for opening a document).
To quote Mr Nielson, "Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility."
These are some of the considerations that I took into account when designing the interface. The previous and next buttons were used to provide structure; the pull-down menu and radio buttons provide non-linearity and system status feedback; the pop-up description boxes follow the example from the text and provide consistency; and finally, the design was created to be as inobtrusive as possible. While I don't believe that I 'got it right', I do believe that the application is easier to use because of these principles.
Enough already! On to the source code