 | | | Contents: | | |
| | Related content: | | |
| | Subscriptions: | | |
|
Client-side scripts for improved usability
Jodi Bollaert (Jodi.Bollaert@compuware.com)
Usability Specialist, Compuware Corporation
01 Sep 2002 It has been said that too much power can be dangerous. That saying is befitting when it comes to enhancing or creating Web widgets with client-side scripts. Web widgets, as you might recall from Part 1, are controls used in Web forms, dialogs, and wizards to elicit information from users. While scripts allow developers to create an infinite variety of Web widgets and behaviors, straying too far from users' expectations can lead to usability problems. Jodi Bollaert describes some common usability problems associated with client-side scripts and Web widgets, and suggest ways to avoid them. What is a client-side script?
Scripts generally come in two flavors -- client-side and server-side. As the names imply, client-side scripts execute on the client (the user's machine) and server-side scripts execute on a server. A client-side script is embedded in HTML documents within the <SCRIPT></SCRIPT> tags. Client-side scripts can be used to extend the capability of HTML Web widgets or create completely new widgets. Some of the popular client-side scripts used today include:
- JavaScript
- Java Applets
- DHTML (combination of CSS and Javascript)
- Flash (Actionscript)
- VBScript
Developers can usually create similar functionality with more than one type of script. The choice of which script to use may depend on developer expertise, target platforms, and target browser types and versions. (More on this below.) While this article won't tell you HOW to develop scripts, I will share some tips on how your scripts can enhance, rather than hinder, your site's usability. There is a wealth of information available about how to develop scripts on the Web and in books (see Resources). Advantages and disadvantages of client-side scripts
Developers might consider using client-side scripts for many reasons, and they might have some legitimate reasons not to use them. Advantages
Client-side scripts offer numerous advantages, including:
- Allow for more interactivity by immediately responding to users' actions
- Execute quickly because they don't require a trip to the server
- May improve the usability of Web sites for users whose browsers support scripts
- Can give developers more control over the look and behavior of their Web widgets (note that this can be an advantage or disadvantage)
- Can be substituted with alternatives (for example, HTML) if users' browsers do not support scripts
- Are reusable and obtainable from many free resources such as Hotscripts.com and Javascript.com (see Resources)
Disadvantages
Client-side scripts also create additional worries, including:
- Not all browsers support scripts, therefore, users might experience errors if no alternatives have been provided
- Different browsers and browser versions support scripts differently, thus more quality assurance testing is required
- More development time and effort might be required (if the scripts are not already available through other resources)
- Developers have more control over the look and behavior of their Web widgets; however, usability problems can arise if a Web widget looks like a standard control but behaves differently or vice-versa
General usability considerations
Before we look at specific examples of Web widgets that utilize client-side scripts, here are some general usability considerations to keep in mind:
- Research what scripts work best with the browsers your audience is likely to use. JavaScript is probably the most widely supported scripting language used today. It is compatible with the two most popular browsers -- Microsoft Internet Explorer (IE) and Netscape. Alternatives to JavaScript, like Microsoft's VBScript, will also work but usually only on Internet Explorer.
- If your audience includes PC and Mac users, be sure to test your scripts on browsers for both platforms. The Mac versions of some browsers do not support scripts as well as the PC versions.
- Test your scripts on at least the previous two versions of those browsers your audience will use. Many people are slow to update their browsers; therefore the latest scripts might not work for these individuals. At the time of this writing, statistics indicate that 57% of Internet users use IE 5.0 and 30% use IE 6.0 (see Resources). Companies like Netscape also provide information for developers on their Web site about known bugs.
- Web sites should still be readable and function properly without scripts. In this competitive marketplace, Web site owners can't afford to turn away members of their target audience who might have incompatible browsers. It is the developer's responsibility to build a site that works for the widest audience possible.
Designing usable Web widgets with client-side scripts
Expandable/collapsible menus
Expandable/collapsible menus, also known as tree navigation menus, are Web widgets that allow users to expand and shrink a list of navigation options. They are often designed to look like file folder menus found in PC and Macintosh applications. The Microsoft Developer Network (MSDN) Library site (see Figure 1) is an example of an expandable/collapsible navigation menu built with JavaScript.
Figure 1. MSDN expandable/collapsible menu
 These types of menus can improve the usability of a Web site's navigation scheme, especially sites with deep navigation structures like the MSDN Library. This dynamic menu allows users to only look at the details of sections that are of most interest. Viewing the entire structure of the MSDN Library at one time would probably be overwhelming and cumbersome to some users. To maximize the usability of an expandable/collapsible menu, consider these tips:
- Mimic the appearance and behavior of widgets with which users have had previous experience. Microsoft has made a notably good attempt with the MSDN Library. Knowing that most of their users are familiar with Windows Explorer, the developers made a conscious effort to duplicate its appearance and behavior as much as possible.
- Keep navigation labels short to avoid requiring users to expand a frame or horizontally scroll to view the complete label. As an alternative, truncate long navigation labels.
- Inform users when an action is not possible. At the MSDN site, for example, some users might think that files can be dragged and dropped as they can in Windows Explorer. On the Web site, however, this is not possible. The developers included a script to change the mouse cursor to a prohibitory symbol when a user tries to drag a folder in the menu to another location.
- Avoid designing menus with more than two or three levels. After a few levels, labels will shift too far to the right and beyond the viewable area.
- Clearly indicate when a navigation option is open and closed. Use graphical user interface (GUI) guidelines with which users are familiar. At the MSDN site, the plus sign (+) means closed; the minus sign (-) means open - making it look and behave like the menus in Windows Explorer.
Creating Flash widgets
Macromedia Flash is best known for its ability to make Web sites seemingly come alive -- bouncing logos, flying text, graphics, and photographs that fade in and out -- and more. Developers can also use Flash to create Web-based forms and a variety of Web widgets commonly found in these forms. The latest version -- Flash MX -- allows developers to create checkboxes, dropdown menus, radio buttons, and more. The client-side script used to create a Flash file is called Actionscript.
There are several reasons why someone might want to create Flash Web widgets rather than standard HTML widgets, including:
- Flash widgets can be custom-designed to go with the look and feel of a site.
- Users of Flash forms can receive feedback based on their input without waiting for a new page to load. Multipage HTML wizards can thus become one page that dynamically responds to users' input.
- Flash elements can be disabled based on a user's selection without reloading the page.
Flash, however, does not appear to be a silver bullet. While reading the rave reviews of Macromedia Flash in Macromedia Flash: A New Hope for Web Applications (see Resources), I came across a comparison of Volkswagen's Asia Pacific car building application (see Figure 2) with the United States/Canadian HTML version of the same application. Figure 2. Volkswagen Flash-based car building application
 Another example below (see Figure 3) illustrates the possible misuses of Flash. Here the developers have chosen to use scripted image buttons (instead of more standard radio buttons) to enable users to choose between a one-way and a round trip as part of a flight booking form. This approach presents at least three potential usability problems:
- Users might not understand what the image buttons represent.
- Users might not realize that these options are clickable since they are not designed to look like buttons.
- This design wastes a considerable amount of screen space.
Figure 3. Image buttons used instead of radio buttons
 The developers could have used the more intuitive, though perhaps less eye-catching, radio button widgets that come packaged with Flash MX. Consider these usability tips to create more effective Flash Web pages:
- Minimize the file size of Flash movies to reduce download time. Consider breaking up a large Flash movie into segments to reduce the initial download time and spread it out between segments.
- Keep users in control of the interface. It isn't always user-friendly to automatically transition users to new segments without allowing them to confirm a selection. Adding a command button like "Next" or "Go" to the interface will give users more control.
- If your Web page is made up entirely of Flash, users might experience erratic browser behavior when they click the browser 'Back' button. Some developers opt to remove the browser navigation buttons to prevent such problems from occurring. While this might solve one problem, it creates a new one -- users can't navigate! If you choose to hide the browser's navigation buttons, consider adding custom-made navigation buttons to the Flash interface.
- Carefully consider the cost of a typical Web widget design using Flash. Is the new look or behavior likely to enhance the usability of the site? What is the benefit to users?
- Design your Web pages so that content is still readable without Flash. If this is not possible, offer an alternative, HTML version of the site as well.
- Use a text-only browser such as Lynx to test that your content is still readable without Flash scripts.
Also, keep in mind that Flash might still require a plug-in. Users who do not use browsers that are pre-packaged with Flash will have to download the plug-in. Even browsers that come pre-built with Flash 5 (Internet Explorer 5+ and Netscape 6+) will have to upgrade to the Flash MX plug-in in order to view Flash MX files. Scripted image buttons
In application GUIs, buttons are used to execute actions. Examples include 'Submit' and 'Reset'. Using simple HTML, these buttons and their behaviors can be replicated on the Web. There are times, however, when developers want to do more with buttons. Using scripts, developers can create customized buttons that will execute a wide variety of actions and validation procedures such as 'Add', 'Delete', 'Check All', 'Clear All', and more. Scripted image buttons can be designed in a variety of shapes and sizes, with multiple states (normal, onrollover, onclick, etc.).
Usability tips
- Reserve buttons for executable events; use links for navigation.
- Recognize the added download time that will be required for image buttons. Use simple HTML buttons where possible.
- Follow standard GUI guidelines when creating custom buttons such as those described in the MSDN Library (see Figure 4) or the Java Look and Feel Design Guidelines (see Resources).
- Do not rely on images alone to convey a button's meaning. Include an explicit text label on or adjacent to the button. The text label, if not part of the image, will also be readable by text-only browsers.
Figure 4. Microsoft GUI guidelines for command buttons
 Client-side validation of text boxes
Developers often have a hard time deciding how to format text boxes when the user's entry can be in one of several formats. Figure 5 shows an example of the variety of ways users could enter a phone number in an open text box.
Figure 5. Phone entry variations
 One solution developers sometimes come up with is to create a pre-formatted text box to more clearly indicate how the data should be entered (see Figure 6). Figure 6. Formatted phone number text box
 While pre-formatted text boxes will make text entry requirements more clear, splitting one field into three fields can also make data entry more cumbersome. Also, because only the first field has a field label, users with screenreaders might be confused about what should be entered in the second and third fields. A more user-friendly solution is to develop a client-side script that could not only validate the data, but also could remove non-essential characters. Thus the question of how to format the text box is no longer an issue. Date pickers
Another nice Web widget that can be created with client-side scripts is the date picker (see Figure 7).
Figure 7. Expedia date picker
 The date picker at Expedia.com was created with Javascript. The advantage of using a date picker for users whose browsers support scripts is the ability to see what dates fall on which days of the week and allowing them to select a date with a mouse rather than text entry. On the other hand, for those users whose browsers don't support scripts, the developers were wise to also provide a text entry option. Pop-up windows
In a 26 July 2002 SIGIA-L post (see Resources), Jeff Lash points out that new windows can be opened with simple HTML using target=_blank; however, this method does not offer developers control over the size of the window or its placement. If you want to control the size/location of the new window, Jeff indicated that you have to use a Javascript link. This type of link will not work, however, in a text-only browser.
Regarding accessibility, Web application developer Ben Protas says in a posting to SIGIA-L, dated 30 July 2002: "My experience is that most screen readers do start reading the correct window when it opens; the problem is, the user then has no way of knowing how to get back to where he/she was before. The back button (in this case, most likely activated by a hot key or voice command) no longer works; the user has to stop and think about what happened and how to restore the state of the system to continue browsing." The World Wide Web Consortium has established guidelines for making Web sites accessible. These guidelines have been adopted by the U.S. Federal Government for all government web sites. The Web Content Accessibility Guidelines state: "10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user."
Usability tips
- If your target audience includes users with screenreaders or text-only browsers, follow the Web Content Accessibility Guidelines.
- Run your Web sites through accessibility testing software tools like IBM's Home Page Reader or Bobby from the Center for Applied Special Technology's (see Resources).
- Consider alternatives to pop-up windows such as displaying the pop-up content in the main window. Is that pop-up really necessary anyway? Also, a new alternative to pop-up windows is tabbed browsing now available in Opera and Mozilla browsers.
Scrollbars
Using DHTML, developers can create small text areas with graphic scrollbars within a larger Web page with browser scrollbars. This Web widget allows you to create scrollable blocks of text without requiring users to scroll the entire Web page (see Figure 8).
Figure 8. Omnium Scrollbar Widget
 But before you are swept away too quickly, ask yourself, why is a scrollbar necessary? Putting the content of a scrollbar in a regular HTML page poses much fewer problems for users. So what is the benefit? Before deciding to use scrollbars, consider these known usability issues:
- Scroll wheels on mice will not work as they do with browser scrollbars.
- Scrollbars might not degrade well on browsers that do not support scripts if no alternative is provided.
- Scrollbars might behave differently on Internet Explorer and Netscape. Thorough cross-browser testing is a must.
- Because space is limited in a scrollbar, users are forced to scroll to view all text.
- Some scrollbars will not resize gracefully when the browser window is resized.
Conclusion
This article describes a sampling of Web widgets that can be created or enhanced with scripts. A final point to consider is consistency. Consistency is a very big deal when it comes to usability. While client-side scripts can allow developers to create or enhance Web widgets, there are still standard GUI guidelines to consider and a need to develop internal guidelines specific to the Web site or application you may be building. Users should only have to learn once how a cascading navigation menu or a scripted submit button works. Creating an interaction design style guide as part of your project can help communicate these guidelines to all members of your team and help ensure consistency across your Web site.
Resources About the author
Jodi Bollaert is a Usability Specialist at Compuware Corporation in Farmington Hills, Michigan who frequently consults with clients on how to improve their Web sites and applications. Her previous articles have appeared on developerWorks, CNET and New Architect. You can contact Jodi at Jodi.Bollaert@compuware.com.
|
| 
