Insert Alt Text
 Go Back | Home | Designer Resources | Print
Insert Alt Text

Web UI Standards for GE Services Central Web Enabled Applications

Author: Robert Dornbush
Last Mod: 04/30/2002 8:27 AM

Draft Version 1.1   top

Originally Published:  11/15/2001

Revision Chart

The following chart lists the revisions made to this document. Use this to describe the changes and additions to this document each time it is re-published (draft or final). The description should include as many details of the changes as possible, as well as the reviewers who requested the changes.

Date Author Description of Changes
11/15/2001 Robert Dornbush Draft Version 1.0 Published
11/16/2001 Robert Dornbush Edited Format / Added TOC
1.0 UI Design Considerations
1.1 User Centered Design and Information Architecture
1.2 The Three Models
1.3 Heuristic Evaluation Explained
1.4 GE Web UI Standards' 15 Heuristic Metrics
  A Note on Intuition vs. Idiom
2.0 HCI: Some Rules Pertaining to Human Factors
2.1 Forgiveness
2.2 Awareness of Human Limitations
2.3 User Control
2.4 Direct Manipulation of Objects
2.5 Consistency
2.6 Chunking of Information and Clarity of Presentation
2.7 Aesthetic Graphic Design
2.8 GUI Feedback
3.0 Standards of Consistent, Reusable Presentation Components
3.1 CSS Driven Websites & Java Based Architecture
3.2 Text Components
3.3 Labels
3.4 Text Entry Standards
3.5 Spin Edit Boxes
3.6 Button Standards
3.6.1 Command buttons
3.6.2 Menu & Dropdown List Buttons
3.6.3 Standard Navigation Components
3.6.4 Tabs
3.7 Radio Buttons
3.8 Check Boxes
3.9 Group Boxes & Panels
4.0 Form Standards
4.1 Headers and Captions
4.2 Fonts
4.3 Menus
4.3.1 Disabling Menu Items
4.4 Icons
4.4.1 Standard Icon Sizes & Colors
4.5 Roll-over Tool Help
4.6 Tab Order In Forms
5.0 Notes on User Acceptance Testing
6.0 Issues Summary
7.0 Bibliographical Notes
8.0 Sign Off

By Robert E. Dornbush, Jr.

GE Power Systems UI Analysis / Designer

1.0       UI Design Considerations: A discussion of the benefits of a User Centered Software Design methodology Starting with the “fundamental usability metrics” known as Heuristic Evaluation

A heuristic is a rule of thumb; a heuristic evaluation is performed by an architect or software development expert who analyzes an application or website and ranks it based on a standard list of usability heuristics1. The heuristic evaluation process was developed by Jakob Nielsen and is explained in his article “How To Conduct A Heuristic Evaluation. ” Nielsen pioneered the methodology of heuristic evaluation for software development and later refined it for the evaluation of website delivered technologies.  It is important to note that while many of today’s complex application technologies reside on a hard drive (often within a powerful UNIX server), the World Wide Web is THE delivery medium of choice for the vast majority of eBusiness applications. Whether via Internet, Extranet, or Intranet (over a WAN), almost all of today’s  Commercial applications are delivered and accessed via the web; therefore, when conducting usability testing on a given product, it is almost inevitable that one ends up doing an evaluation of the web enabled User Interface.

1.1       User Centered Design begins with Information Architecture

Information Architecture (IA) is the process of organizing data and designing the User experience for an application or web site by focusing on (1) the categorical organization & nesting of content elements (2) the logical flow of these content elements through functional devices and (3) the ease of application use & navigation for the end User. The IA process for a web site begins on the strategic level and continues through the design and implementation phases. Concepts, design elements and functionality issues must be developed and clearly documented in easy to communicate formats.

Quality standards for front-end architecture directly impact a business’ bottom line

Towards this end, Information Architecture and User Interface Design are key elements to the success of our Your e-business software. A fellow information architect who develops B2B sites for Lante notes “At my firm we're building marketplaces, and what really drives info arch and design more than anything else is identifying current workflow in a business system and either translating or retooling it for web-based applications.3” Another information architect writes in response “I totally agree. I worked on a B2B technology site and the IA was geared towards workflow. A project workspace was created to support the decision making process. The functionality was based on how well it would support the decision making process for purchase; decision making by several people or departments.4” As you take ownership of the User Experience of - and evangelize the implementation of usability standards for - all Your e-business products,  I must dramatically caution you against letting ‘transaction driving workflow’ and ‘engineering functionality’ be the only factors that influence the development of the User Interface to Your e-business products.  [They are, of course, important contributing factors to your UI development; however, it would be a myopic development process to design your UI solely around the functionality of the software].  I think we have all suffered through plenty of frustrating UI experiences on the web (both eCommerce and Customer Support related) to recognize the fact that User Experience hassles and counter-intuitive UI (designed obtusely around the esoteric structure of back-end functionality) directly translate into a negative impression of both the company who provides the website and the company who designed  the technology.  In other words the reputation of your e-business is directly dependent upon the user friendliness of the websites through which your software is deployed.

1.2       The Three Software Development Models

There are three models which apply to software development: The Implementation Model, The Manifest Model, & The Mental Model (see fig 1.1); each model describes the process as it is seen from a different subjective perspective. The Implementation Model is created by the software development (or programming) team and it reflects the way the engineers must build the product (based on intended functionality to be delivered).  The presentation architects create the Manifest Model, and it reflects the way the User will access the functionality, content, and navigation options within the product. The Mental Model is created in the User’s mind as she uses the product and it reflects the (metaphorical) way in which that User visualizes the product as some kind of specific tool  (when in actuality the product is just thousands of lines of code; all represented by 1s and 0s passing through the computer’s CPU).  The Implementation Model and the Mental Model are not very open to change.  The Manifest (or design) Model; (which has the capability for dramatic change) is the one model which a Good Usability Methodology can have the biggest impact on.  If The Manifest Model is properly influenced by the implementation of good usability standards, evaluation and testing; then, the other two models will evolve to reflect the improvements made via Information Architecture and User Interface Design in the Manifest Model.

The point of this discussion of three separate software models is: to underscore fact that, the easiest way to change the Users’ interpretation of the application’s intended meaning is to effectively express that meaning through the UI design rendered in each screen presentation.  No matter how well executed the back-end (or implementation) model is, the application will be a failure if the Users cannot understand how to navigate what they see on the monitor screen.

1.3       Heuristic Evaluation Work as a Method of Usability Validation

Heuristic Evaluation is the act of estimating the state of usability of a web-enabled application by applying well-known rules of thumb to the website’s UI and then deriving a score for the site based on how closely it fulfills the requirements of these rules.  Almost every usability problem can be traced to a violation of one or more heuristics5. Odds are that if a site is failing based on a flaw in usability, it is in violation of one or more of this Charter’s 15 Heuristics (rules).

A developer or architect responsible for coding of presentation layer elements should have a team of 3-5 UI experts review his prototype using the following 15 rules as a checklist for potential usability problems.  Each reviewer should evaluate the prototype independently, and their individual score sheets should then be combined into a master list for statistical evaluation and comparison purposes.  Presentation components that violate any of the rules should be graded on a severity scale of one to ten, with one being a minor violation and ten being a show stopper.

The results of the evaluation should be recorded in a spread sheet with the heuristics listed numerically across the top row and the components in violation listed (by name and numerical identifier) in the first vertical column on the left.  The ratings from the separate score sheets are combined into one master score sheet by averaging the grades from each evaluator on each item (i.e., if there are five evaluators add the five scores on each individual presentation component, and then divide the total by five) and then enter the average grade (x10) into the master score sheet. These numbers will give you percentages pointing out where the worst problems are.  Since it may not be possible to fix all of the usability problems, it is important to prioritize problems by severity (those receiving the highest failure percentage numbers).  A practical method for starting this practice is to number each screen/webpage in a given prototype.  The evaluators can enumerate heuristic violations on a page by page (rather than component by component) basis. Pages receiving a particularly high failure rating may require deconstruction and re-evaluation on a component by component basis in order to arrive at a clear definition of what needs to be fixed.

Research studies have repeatedly shown that Heuristic Evaluation identifies 86% of the potential usability errors that are later identified by subsequent User Acceptance Testing.

In a rapid development cycle where there is little time for formal UA Testing, Heuristic Evaluation serves as a money saving (and potentially product saving) method of “discount usability testing.”

1.4  GE Web UI Standards’ 15 Heuristic Metrics (a check list of usability rules)

Heuristics For User Interface Design

1) Visibility of system status

The system should always keep Users informed about what is going on, through appropriate feedback within reasonable time. Examples of GUI elements which provide this functionality include: incremental progress bar [being filled horizontally as task approaches completion], animated hourglass or stopwatch [indicating that the system is busy and the User should wait], any animated bitmap / gif which shows that the computer is working [and not ‘frozen’ or ‘locked up’].

2) Match between system and the real world

The system should speak the Users' language, with words, phrases and concepts familiar to the User, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order (commonly known as natural mapping).

3) User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. The application design should support undo and redo.

4) Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

5) Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place.

6) Recognition rather than recall

Make objects, actions, and options visible. The User should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

7) Flexibility and efficiency of use

Accelerators -- unseen by the novice User -- may often speed up the interaction for the expert User such that the system can cater to both inexperienced and experienced Users. Allow Users to tailor frequent actions.

8) Aesthetic and minimalist design

Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

9) Help Users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

10) Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the User's task, list concrete steps to be carried out, and not be too large. (the usability check list is continued with items 11-15 on the following page)

11) Being Clever is almost never a good idea,       …even if you ARE in the business of being clever:

Clever design is only good if it works right, and too often when we go out of our way to be clever, what seemed like a clever metaphor breaks down and results in an unusable interface.  See figs 1.2-1.3 : (Southwest Airlines Examples A&B)8, fig 1.4: (MagiCap Example C) [about which Microsoft Engineer & creator of Visual Basic Alan Cooper says “Never Bend your Interface to fit a metaphor” 9], and fig. 1.5 (PlanetOasis Example D) 7.

12) Does The Navigation Interface Follow The Magic 7 + 2 Items Mnemonic Rule?

This concept, often referred to as chunking, was discovered in the early days of Bell Labs research.  They found that human beings could keep roughly seven (plus or minus two) unrelated bits of information in their working memory at once.  For example: unrelated numerals.  This is the reason that U.S. phone numbers have seven digits.  Note how area codes are chunked separately from base phone numbers.  How, you may ask, does one apply this information to interface design? Try to cluster pieces of information near one another in groups, and provide whitespace around them to make them visually distinct.10 Try to keep horizontal navigation bars to seven items or less (nine items ,max). Although it is a hard factor to quantify, it is important to minimize the user’s memory load (i.e., limit the number of things you expect the user to memorize).

13) All Essential Information Should Be Kept Above The Fold

Design for a standard screen size (probably 800 by 600, unless you believe that a significant portion of your target audience is still working on a 14” monitor) and tryto keep all pertinent information visible within the browser Without Scrolling. A little scrolling is OK (and pretty standard operating procedure) BUT, a lot ofscrolling is bad – WAY BAD.

14) Make Sure All Web Pages Are “Scannable”

It is now widely accepted that Users of websites read those sites in a vastly different fashion than they would read traditional print media.  They scan (remember the ‘Evelyn Woods Speed Reading Course’?). Instead of immersing themselves in a sea of text and progressively trying to understand it all, website Users look quickly for keywords, hyperlinks, and other important eye-catching features in order to navigate to the next important page.  The best practice, therefore, is to keep all web delivered text media in (the visual equivalent of ) “sound bite” format.  A sound bite is a concise (1 to 3 word) expression of a more complex concept. If we apply this notion of “text bite” to the Global Nav bar, then the caveat becomes don’t use ‘Wall Street Journal Guides To Planning’ (as a Nav bar button) when ‘Planning Guides’ will do nicely; don’t use ‘Equity & Debt Capabilities’ when ‘Equity & Debt’ or ‘Investment Lending’ works better.   Keeping to this scannable text bite heuristic not only facilitates User navigation, it also aids in producing readable graphic design.  Lengthy navigation link titles simply will not fit on a button without double stacking the text and reducing it to a point size that is virtually unreadable.  This is not to say that entire paragraphs of text are against the rules. Paragraphs are sometimes inevitable, and are often useful as an introduction to a new category of information.  That being said, paragraphs must be kept as concise and scannable as possible.  Traditional “Brick and Mortar” business’ printed marketing brochures are created using multiple paragraphs of text that stretches out for many pages and emphasizes ‘feel good’ messages about a corporation or product.  This style of writing simply does not work on the web.  Use a front page newspaper article as your text model (in which essential information is metered out in concise, discreet packets; and any less important information is continued on page A14, if at all).

15) Keep Download and Response Times Low

Follow this ‘golden rule’ and you won’t loose customers by contributing to the “World Wide Wait.”  One tenth of a second (0.1) is about the limit for having the User feel that the system is responding instantaneously, meaning that no special feedback is required.  This would be the response time limit for any applets that allow the User to move, zoom, or otherwise manipulate screen elements in real time.  One second (1.0) is about the limit for the User’s flow of thought to remain uninterrupted, even though the User will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 bit less than 1.0 second, but the User does loose the feeling of operating directly on the data.  Getting a new page within a second means that the User has arrived at the page without undue delay.  Ten seconds is about the limit for keeping the User’s attention focused on the dialogue.  For longer delays, Users turn to other tasks (such as going out for a pizza) while waiting for the computer to finish.  Getting a new page within 10 seconds, while annoying, at least means that the User can stay focused on navigating the site.  Normally response times should be as fast as possible, but keep in mind that it is possible for the computer to react so fast that the User cannot keep up.  For example, a scrolling list may move so fast that the User cannot stop scrolling (or mouse down) in time for the desired element to remain visible within the available window 11 (I think we’ve all experienced this phenomena).

A note on Intuition vs. Idiom

IN the business of UI design we often demand an intuitive GUI presentation.  Rather than trusting to Users’ intuition (which is basically asking them to be psychic), rely on conventions that are easy to learn (offering affordance).  Once learned, these idiomatic conventions will easily be committed to memory.  Classic examples of idiom include proverbial statements such as: “a stitch in time saves nine” and “a penny saved is a penny earned.”  These sort of “easy to learn” conventions, if applied consistently to the navigation schema of a User interface, will result in a kind of fulcrum from which to leverage intuitiveness. If one can infer how to use a GUI widget just by looking at it, it is said to offer affordances (or ease of learning). For example, if one gets in a new model of car that one has never seen before, one will instantly surmise that the steering wheel is to be used for guiding the vehicle’s path down the road.  A wheel shaped object in front of the driver’s seat offers affordance that this control is used for steering; likewise, a question mark button on a GUI navigation. bar offers affordance that one can navigate to a help menu by clicking on the question mark.  We can foster intuitiveness by creating paradigms, which are easy to learn; and which, once learned, are rarely forgotten.

The Grammar of Web Navigation

Users have learned a “grammar” of web site navigation by spending time surfing other sites on the World Wide Web.  If we, as software designers, take advantage of these idiomatic navigation elements that Users have committed to memory (as a common “grammar” of web navigation), then Users will find it easy to learn how to use our web sites.  I have borrowed this concept of building upon an existing grammar of web navigation elements from the motion picture industry. Modern movie audiences understand a grammar of film editing and interpret it intuitively (after having learned it idiomatically).  If we storyboard a man getting in his car and leaving for work, we don’t have to include a close-up shot of the man turning the keys in the ignition of his car for the audience to understand that he must have started the car before he left for work.  This analogy translates to the re-use of commonly understood navigation elements and functionality widgets.  Users are accustomed to looking for global navigation elements (such as buttons and tabs) across the upper horizon of a web page.  They have learned to look for this structure regardless of the specific context of the given website.  Research has shown over the past few years that Users have grown to expect local navigation elements to appear in the left-hand margin; whereas, Users tend to intentionally overlook right hand navigation links and prominently placed banners which they assume to be advertisements (and thus a potential distraction from the content they are scanning for).

Section 2 –HCI: Some Rules Pertaining to Human Factors

2.1       Forgiveness

Users like to explore an application and learn by trial and error.  Such self-motivated learning can be extremely effective, but Users will be unaware of potential dangers.  Even with the most well designed User Interface, Users will make mistakes (both physical errors, such as accidentally pointing to the wrong command or typing in incorrect data) and comprehension mistakes (such as making a wrong decision about which link to select or which command to execute). It is your job as software developers to design the interface to accommodate User exploration and mistakes without pain or penalty (and to respond without an error message which accuses the User or makes the User feel stupid).  Your UI design should both minimize the opportunity for errors and handle errors gracefully.  Error messages should not imply that the User is at fault; instead, they should state the problem objectively (in plain language –no cryptic error code numbers) and offer possible solutions. 13Back-end code must offer contingency plans for the User changing her mind, for example: don’t automatically select something on rollOver OR mouseDown; instead provide the alternative of no selection should the User roll off of the button or link before releasing the mouse button (onMouseUp If cursor is off of the link Then nothing is selected).  Support Undo and Redo wherever possible. I think we’ve all been annoyed by the question “are you sure you want to delete that item?”, so much so that we have come to ignore it and hurry on to press “OK” to perform the delete.  This becomes such a habit that we ultimately delete something that we really didn’t want to trash.  That’s when a good undo feature would really come in handy.

2.2       Awareness of Human Limitations

The human body is an incredible machine which is, in many ways, more complex than most computer systems; however, human beings also experience unavoidable limitations in perception, memory, and reasoning. Be aware of human strengths and weaknesses, for example: don’t expect the User to memorize where he stored all of his data, that’s what search functionality is for.  Don’t overwrite the built-in browser functionality which allows the User to make changes to font size and color – this is an accessibility issue [ADA 508].  If your text and color formatting does not respond to browser controls, then you must provide alternative formatting functionality as a tool within your web-based application. All bitmap buttons such as icons or pictures should have alt text tags, this feedback helps both Users of older [graphics challenged] browsers and disabled Users who utilize read aloud ‘text reader’ devices. 14                

2.3       User Control

One of the most important fundamentals of Human Computer Interaction is that the User should always be in control of the application, and not the other way around. This principle has several implications.  Applications should avoid modes that ‘lock out’ or severely restrict User input at any given time. If such restrictive modes must be used, they should be visually obvious (for example the pointer can change shape to indicate that the User must wait, or that User input is limited to a particular format at this time).  An interface should facilitate the User’s tasks (rather than either placing obstacles in the User’s path or calling attention to the interface itself -.i.e. “look at me, I am a gratuitous animation which serves no function whatsoever.” Users want to accomplish tasks, not bask in the glory of using computers.  They want to write letters, make decisions, manage resources, gather data and record it in documentation; they do not want to pause to contemplate how cool (or horrible) the scroll functionality, drop down lists, and flaming logos are.

2.4       Direct Manipulation of Objects

An Interface should give Users direct and intuitive ways to accomplish their tasks.  The object-action paradigm supports this principle. The User performs tasks by selecting an object (such as an icon, a window, or some text) and then selecting an action (such as move, close, or underline) for the selected object.  All of those examples represent good User control facility, but they are in a way somewhat indirect methods of object manipulation. Whenever appropriate it is preferable to give the User the alternative of direct control via some sort of interactive widget, for example: a slider control, which allows Users to manipulate graph data axis or audio volume, is a good interactive control widget.

2.5       Consistency

It is imperative that User Interface design be consistent in its navigation schema, its content labeling conventions, color-coding, widget shape & size, iconography, and presentation formatting. Consistency must be maintained not only within a particular form, but also across multiple varying types of forms (both submit forms and design or “look and feel” formats). The controls, labels, position, behavior and style should all set and follow consistent conventions (both internally to the application itself and externally to the standards and best practices of other web sites on the world wide web).

2.6       Chunking of Information and Clarity of Presentation

Frequently used components should be positioned where they will be seen first.  This will usually be the top horizon and left hand margin of a form.  Keep in mind that western cultures read left to right and top to bottom. Navigation bars across the horizon (which contain buttons or links to nested content categories) should be presented in groups of seven (remember the magic 7 +/-2 mnemonic rule from the list of heuristics).  This rule reflects the 7-9 items as the maximum number of unrelated items that the average person can remember, and it is also supported by graphic design style guidelines.  Any graphic designer will tell you that 9 label items is that maximum number that will fit across a horizontal nave bar at a readable font size.Once you increase the number (or try to include too many lengthy words, even with the numerical limit of links set to 7) you will be forced to reduce the font size to 7pt or smaller in order to make all the links fit across the horizon of the web page.  Eight point type is the smallest size that can be used without producing a read the fine print effect; therefore, good graphic design of navigation labeling calls for the same standard as the 7 +/-2 heuristic metric.

2.7       Aesthetic Graphic Design

Both aesthetic appeal and visual clarity can be substantially enhanced by attention to basic graphic design principles concerning spatial grouping, contrast, and three-dimensional representation (perspective, drop shadow, etc.). The best interfaces combine powerful yet accessible functionality with an aesthetically pleasing appearance.

2.8       GUI Feedback

The User should receive immediate and tangible feedback for actions within an application. For example: buttons should have a static state, a rollover state, and a selected state (highlighted). If the User of an application selects a data object with the mouse, the application should provide visual feedback that the object has been selected.  Graphical feedback is particularly effective, but textual and auditory feedback is also useful in certain instances.

Section 3 –Standards For Consistent, Reusable Presentation Layer Components

3.1       CSS driven web sites and Compatibility with Java based Architecture

Avoid using bitmap images as buttons in your User Interface design.  Buttons and /or hotlinks on a colored background should be managed by CSS / DTDs for a truly component driven web site design.  Rounded corner, bitmap buttons are a headache for both developers and users alike. Incorporation of too many bitmap graphic images means slow page download times for Users; and perhaps more important, overuse of bitmaps is unacceptable because it results in (JSP / XML generated) HTML having to be re-written, hand coded, or ‘tweaked’ on every page with a rounded button or tab.  The Java “iter” tag (for self generating of HTML widgets and text line items via XML messages from the JSPs) does not work with bitmap images.  Good-looking rectangular buttons can be rendered instead using JSP when the HTML template is driven by CSS / DTDs.  These handsome rectangular buttons can even be given roll-over (drop shadowed) and selected (darkened or highlighted) states [as in a JavaScript or DHTML dropdown] which are defined and driven by reference to the Cascading Style Sheets.

3.2       Text Components

Text fields do not include labels as a part of the control; however, you can add one using a static text field.  It is a good idea to make this descriptive label’s background color different from that of the editable text field it describes (or at least a shade darker within the same complimentary color range as the editable field’s background color).  This color coded labeling technique eliminates any User confusion between which text lines are editable and which are not.  Including a descriptive label helps identify the purpose of the text entry field and provides a means for indicating when the field is disabled (the label is then ‘grayed back’ of faded looking to indicate that the entry field is currently unavailable). When using a text field for input of a restricted set of possible values, for example, a field where only numbers are appropriate, consider validating user input immediately, either by ignoring inappropriate characters or by providing feedback that the input is invalid, or both. To prevent invalid input use pre-populated fields and dropdown lists wherever possible and practical.  Many transaction-based websites use dropdowns for date, state, and country selection: this is done to prevent the user from entering an invalid date, state abbreviation, or home address that would cause the transaction to fail (or worse, be shipped to the wrong address). It is not really practical to have a dropdown list with 50 choices representing all 50 states, but they do it anyway.  Perhaps some validation on the back-end prior to finalization of the transaction could prevent this clumsy interface device.  In the case of globalization, it is extremely impractical to have a dropdown of all of the world’s countries, but if you must do it, PLEASE put the countries which represent the bulk your customers near the top [in other words, don’t put the USA near the end of a long, alphabetically arranged, scrolling list]. You can use text fields to display information that is read only; that is, they are appropriate for text that cannot be directly edited by a user (but they should be consistently color coded as with the labels).  Read only fields allow the data to be selected but not edited.

3.3       Labels

One can use static text fields or labels to present read-only textual information; however, the application (back-end) can still alter read-only text, if appropriate, to reflect a change in state.  For example: one can use static text to display the current directory path (or breadcrumb trail), status information, page number, step number, date and time. One can also use static text fields to provide labels for other controls.  Using static text field as labels for other controls allows you to provide access-key activation for the control with which it is associated.  This is done by setting a key command property for the label. Again, consistent color coding (and even drop shadow / highlight framing the rectangular labels) helps the user to identify the label (and can elevate the label to the status of a functional button, if appropriate). It is appropriate to use static text fields to label buttons, tabs, and other way finding devices in your User Interface.  Sometimes a brief explanatory note below a dialog grouping will serve as a more concise instruction set than launching an on-line help application. There are many parallels between instructional signage on-screen and architectural signage in buildings, such as airports.  The object is to direct traffic smoothly to its desired destination (or desired information or task).

3.4       Text Entry Standards

An edit component is a rectangular control where users can enter or edit text (usually a larger rectangular text entry ‘box’ as opposed to the standard, single line, text entry ‘field’). It can be defined to support a single line or multiple lines of text.  The border of the text entry box should be framed with a standard application-like window frame (often with vertical scrolling enabled, to conserve screen real estate. The standard text box control provides basic input and editing support.  Editing support includes the insertion or deletion of characters and the options of text wrapping or envelope return.  Individual font or paragraph formatting properties are not supported; however, the User should have the option to choose and re-size a consistent font throughout the application (again, this is an ADA 508 compliance issue).  In the future we may add text formatting capabilities within text entry fields in order to encourage the creation of on-line documentation within GUI text entry boxes (rather than continuing to utilize the current LSOP of typing documents in MS Word, and then uploading those docs as attachments). A text box supports standard interactive techniques for navigation and contiguous selection. Horizontal scrolling is supported for single line text entry fields only when the width of the field is unlikely to be large enough to accommodate the length of the average text entry for that field.  Vertical scrolling is supported for multiple line text entry boxes.  Always remember to implement the rule from the heuristics list that ‘vertical scrolling is OK [in limited doses] and horizontal scrolling is bad, way bad.  Only use horizontal scrolling as a last resort when screen the available real estate is simply inadequate to present the required data view.  Please exhaust all possible presentation design alternatives before resorting to a horizontally scrolling data view. As another rule of thumb, always try to limit the number of characters accepted as input for a text box to whatever is appropriate for the data context.  You should also limit the width of the text box to the appropriate [# of] characters width [plus small margin for readability]. Try to follow the convention that text filed labels belong to the left of the text field; the label should be right justified against the entry field, and the entry filed should be left justified against the label.  In addition, text boxes defined for fixed length input should also support auto-exit; that is, as soon as the last character is typed into the field, the focus moves to the next control [with a blinking vertical line cursor in the appropriate subsequent field, if the next control is another text entry]. For example, you can define a five character auto-exit text box to facilitate the entry of zip code, or three two character auto-exit boxes to support the entry of date.  Bear in mind; however, that auto-exit boxes should be use sparingly, since the automatic focus shift behavior may be unexpected for the User. Auto-exit boxes should be limited to situations involving extensive data entry in between other actions such as submit or navigation selection.

3.5       Spin Edit Boxes

Spin edits are text boxes that accept a limited set of ordered input values.  A spin box is a combination of a text box and a pair of buttons (usually up and down arrows).  The buttons on the control allow the User to increment or decrement values (a number in the text box) interactively. The User can type a text value directly into the control, or use the buttons to change the value.  Dual alternative controls such as this are desirable as accelerators when different users have different requirements (such as expert vs. novice).  In the example of the spin box it is often helpful to have a default numeric entry that can then be changed by the User utilizing the arrow buttons. You can a single set of spin box buttons to edit a sequence of related text boxes (for example the time of day as expressed in hours, minutes, and seconds). In this example the buttons only affect the text box that currently has the input focus (again a blinking vertical cursor or text highlight).

3.6       Button Standards

Buttons are controls that initiate actions or change properties.  They can also be used for navigation purposes.  A button requires a colored background rectangle and a stroke or outline.  They can be dressed up with highlight, beveled edge, and / or drop shadow where appropriate.  This visual treatment is more appropriate for controls such as OK, Cancel, or Submit. Navigational buttons (such as those on a horizontal nav bar or left-hand nav links list) are best left simple (just a colored rectangular background) rather than beveled, etc.  Exceptions include navigation / functionality links in a multi-step process, such as: Continue, Next, etc.                        

3.6.1   Command Buttons

A command button is a control (commonly rectangular in shape) that includes a label (text, graphical icon, or sometimes both). Clicking a command button executes the command associated with the button. When the User presses the mouse button, the input focus moves to the button, and button state changes to the pressed or selected appearance (usually darkened, or drop shadowed, sometimes highlighted, depending upon which is more appropriate to the given color scheme).  If the user moves the pointer off the command button while the mouse button remains pressed, the button returns to its original state (this behavior is in accordance with the “Forgiveness” HCI rule noted earlier – in this case the User has changed her mind and decided that was NOT the selection she intended to make) [however, if the User moves the cursor back over the button while the mouse button is still pressed, then the button returns to its selected state]. The effect of choosing a button is immediate with respect to its context.  For example, in toolbars, clicking a button carries out the associated action. In a secondary window, such as a dialog box, activating a button may initiate a transaction within the window, or it may apply a transaction and close the window.  The command button’s label represents the action that the button initiates.  When using a textual label the text should follow the same capitalization conventions defined for menus.  If the control is unavailable (disabled), the label of the button appears unavailable (grayed back). Include an ellipsis (…) as a visual cue for buttons associated with commands that require additional information.  As with menu items, the use of an ellipsis indicates that further information is available / required (not simply that a window or dialog will appear at the press of the button).  Buttons necessitate the visual equivalent of ‘sound byte’ [text byte] labeling, and this convention follows on the heuristic requirement that all web pages be scannable.  If you are faced with a situation which demands a button label containing four or more lengthy words, then you must utilize roll-over help to explain the full name (when the actual characters of the lengthy name will not fit on the button). Command buttons can be used to open a secondary window and display additional options.  A command button with an ‘open nested content’ widget, such as an arrow or plus symbol, can be used to enlarge a secondary dialog.  This is sometimes known as an unfold button, and it is useful when further screen real estate must be allocated to show “advanced options.”  Another good use of the unfold button can be applied whenever further detailed functionality is available (but not required), for example: a small GUI representation of functionality that requires a larger window to manipulate and execute.  In the context of ePDM applications, consider a workflow, process flow, or object scale which could be represented by a ‘mini-diagram’, which the user would then have to click on to enlarge and manipulate / execute. A control button is not really a different type of button, but the use of a command button for a specific function.

3.6.2   Menu & Dropdown List Buttons

A menu button is a command button used to display navigation choices, often in the form of a drop down menu list. (or alternatively as a single navigational link to other related content nested under that category heading). The size, shape, location and functionality these types of buttons is defined in the Cascading Style Sheets, and this methodology is essential to developing a component (or template) driven presentation layer.  A menu button looks just like a standard common button; however, as a part of its label, it can include a drop down list of sub-category topics / tools nested within the main category heading. A menu button supports the same type of interaction as a drop-down menu.  The menu is displayed when the button is pressed.  The menu remains present until a sub-category item is selected or the User rolls off of the menu.  If the menu requires further interaction to make a selection (such as Search>enter keywords>Find ), then a ‘layer’ (utilizing DHTML / JavaScript commands) opens on mouse click of the menu button. Unlike the drop down list, the layer will remain visible until a command button within the layer (such as find or close) is clicked by the User.  This behavior is the similar to that of a dialog window in a desktop application.  

3.6.3   Standard Navigation Components

Global Navigation

is a specific grouping of menu buttons (or nav bar) located at the uppermost horizon of a web page which serve as controls allowing the User to access all of the top level hierarchical content categories and most frequently used feature functionality.  In the case of ePDM applications in a unified framework, the applications themselves are the global content categories.

Application Level Navigation

is a middle layer of menu buttons (just under the global nav) which allow the User to access all of the main tools / features within a previously selected global nav category.  For example, if the User selects Global Connector from the global nav bar then all of the major tools within the GC application would appear as buttons on the sub-global nav bar. A third drill-down deeper within the unified framework (ePDM>Global Connector>ITO, for example) should present the User with some form of local navigation choices. These choices may vary from sequential steps in a multi-step process to a selectable list of tools or content within the sub-category previously selected.

Local Level Navigation

This is the lowest level of navigation that any app will have. All designs should keep this hierarchy in mind. kh

3.6.4   Tabs

Tabs are frequently used components that can be extremely useful as navigational user interface controls in a multi-step process. They can also be useful in separating subsets in a complex master data set. An order entry process is a good example of problem situation where tabs provide a user-friendly solution to the subdivision of both the multi-step process and the complex master data set.  The hypothetical ordering process consists of unit identification, parts selection, cost calculation, shipping information, customer billing information, order submission / confirmation, and tracking. Seven tabs across the top of the submit form(s) horizon with appropriate labels such as: Unit Detail, Parts Requisition, Cost Sheet, Billing Info, Shipping Info, Submit Order, and Track Order would serve the dual purposes of grouping information into smaller chunks and guiding the user through the multi-step process. Each of those seven steps will be made up of many smaller sub-steps (entry fields, etc.), and breaking this complex master data set into smaller subsets will greatly benefit the user’s ability to enter the required data. The ordering process is primarily seen as a linear progression of seven steps, guiding the user through a complicated navigation exercise; in addition, the tabular interface allows the user to go back and check previous entries in a non-linear fashion without losing track of what step they were on or what state the order is in.  The tabs are not intended to replace the primary Global Navigation and Application Navigation buttons across the uppermost horizon of the web page; instead, the tabs provide an essential local navigation control immediately below the upper horizon of the web page. Tabs should be built using not gifs but tables and css.

3.7       Radio Buttons

A radio button (also known as an option button) represents a single selection from within a limited multiple choice set of mutually exclusive options.  The set of choices should always be grouped accordingly in sets of two or more options, of which only one can be selected at any given time.  If there are to be multiple sets of separate choice selections, then the groupings must be clearly defined with readable visual separation of groups (from each of which a separate, single selection can be made). Do not confuse the user by making it apparent that multiple selections can be made in a single group with radio buttons – that kind if interaction would require check boxes instead of radio buttons.  Option buttons include a textual label.  If you need graphic labels, then consider using another control [such as command buttons] instead.  Define the label to best represent the value or effect for that choice. You must also use the label (grayed back) to indicate when that particular choice is unavailable.  In addition to each choice having a label, the grouping needs a label as well (group box header), and the group’s label should be instructive [e.g.: select one of these to set the ‘blank’ property].

3.8       Check Boxes

Like radio buttons, check boxes support options that are either on or off; however, unlike radio buttons, check boxes are used for non-mutually exclusive choices (in situations where it is acceptable to select more than one of the options).  A check box appears as a square with an accompanying label.  The proper alignment is check box on the left, text label to the right (left justified against the check box, with an appropriate margin / space in between).

3.9       Group Boxes and Panels

A group box is a special component used to organize a set of controls.  A group box is a rectangular frame (usually with text label) that surrounds a set of controls indicating that this set of controls work together to set the value or property of a given user input (named by the label).  A menu header or title bar (which will be discussed in the next section 4.0>Forms), is another method of grouping user input into discreet chunks, and both methods are valid tools for creating groupings in web page User Interface design. A panel is a more generic container component that is used to group components. Several common uses for a panel include a toolbar, a navigation (or nav) bar, a status bar, and a system tray (of ‘currently in use’ items).

4.0       Form Standards

As software developers for GE Energy Services we are challenged by the fact that most of the applications we are developing are forms intensive, process driven, and transaction based: web-enabled applications. The usual challenge in designing a front-end architecture for web-enabled applications is organizing content and creating logical navigational access to that content hierarchy. In our business there is no content (or very little content that can be advertised to the user).  What we have instead, is a multitude of complex processes which need to be organized and inter-connected to give the User easy and logical access to the information (and tools) that they need.  The real challenge here (from a UI perspective) is how to keep the entire application from looking like “an excel spreadsheet” or “an ugly submit form”.  To achieve this goal all of our forms must share a common ‘look and feel’, and all forms should follow standard conventions with regard to size and layout of text entry fields, field labels, buttons widgets, etc.

4.1       Headers and Captions

All forms should have a header describing the activity to be performed by submitting the entered data.  Headers should be capitalized using the standard rules for titles: the first character in each significant word in the header is capitalized.  Long scrolling pages are to be avoided (by using tabs and other methods to break up steps in a multi-step process), but when a long (vertically) scrolling form is necessitated by the amount of data to be entered, break up the form into a series of related sub-steps or activities – each of which requires a header bar with the title of the respective activity set.  Header bars should be consistently color coded in the basic color scheme of the UI’s other buttons and navigational devices.  Captions can also be used above or below an activity group to explain what input is required.  Captions do not follow title capitalization; only the first letter of the first word, and any proper nouns (such as button names) in the caption need to be capitalized. If the form is the main application window, the form header should be a unique label that identifies the application window. This identification is especially important when the user is working with multiple windows (& tools, applications, or databases) open simultaneously.  It provides an identifying focus for both navigation and task you are (were when returning to a window opened earlier) here and you are (were) doing ________.  At a minimum the action should contain a name or label for the activity performed on that screen.

4.2       Fonts

Consistent use of fonts is essential to a unified presentation layer across all ePDM applications.  Sans serif fonts are preferred because they are easier to read on screen.  Bold fonts can be used in special cases to draw attention to a button or label.  Never use all caps as a font format (to draw attention) because it slows reading by 15-20% and violate the heuristic of making all web page content ‘scannable’.  The standard sans serif fonts to be used are Arial, Helvetica, Verdana, and Tahoma (add sans serif at the end of the family declaration).  These fonts can and should be specified in the Cascading Style Sheets, providing all three as alternatives (if the User’s desktop system has Arial it will be used, if not it will substitute Helvetica, by default, and if Helvetica is not available then it defaults to Verdana). There may be cases where Verdana is the preferred font for navigational buttons, and in that case the style sheet will define the font preference. Font sizes should be specified by pixels only. See this link.

4.3       Menus

Applications menus are one of the most important parts of its User Interface design.  Menus provide the User with access to the basic operations supported by the application.  Menus must be consistent in design and functionality across multiple integrated applications because menus themselves are a common element across applications (although the content of the menus changes as the user progresses through various tools and applications, the navigation and labeling conventions should be consistent).  Items in menus can vary dramatically in their intent or effect; therefore, naming and format of menu items is key in communicating the functionality of the given selection to the User.                         

4.3.1   Disabling Menu Items

Disabling menu items provides a consistent structure in menus and allows Users to build a mental image of a particular command’s location (a mnemonic device for remembering the navigation path for future access to that menu item).  The preferred method of disabling a menu item is to display its name ‘grayed back’ in the normal UI location.  When an Item is ‘grayed back’ or ‘grayed out’ Users understand that convention to mean that the item is currently unavailable.

4.4       Icons - download

Using graphic Icons in the place of text labeled buttons is a standard convention of User Interface design, but GUI developers must exercise special care in the design and implementation of Icons.  The first rule of thumb with regard to Icons is: “never bend your User Interface to fit a metaphor that users’ don’t comprehend”.  To understand this rule, consider the following scenario: a development decision has been made that all menu items on a certain navigation or toolbar are going to be Icons.  The menu labels include an assortment of verbs (action commands such as open, save, & print), nouns (such as file, help, document manager & order management) and adjectives/adverbs (such as scalable/scalability, reliable/reliability, & notes attached). At first you might think that creating these Icons will be a no-brainer because standard recognized symbols already exist for most of these labels: a floppy disk for save, a printer for print, a question mark for help, a folded piece of paper or lined rectangle for file/document, etc… – But then you try and sit down to illustrate a complex concept like document manager, order management, or reliability in an Icon and you’ll realize that we’re doomed to fail.  There is no way you will be able to come up with a universally recognized symbol for reliability (a smiling grandmother?, a faithful dog?, the value of a conservative money market fund?…good luck!).  The point is that if the Users can’t understand what the Icons mean, then the UI design is a failure.  Users who can’t figure out what to click on will not be able to navigate the application, and will either suffer a decline in productivity or refuse to use the software product. Roll over tool help can sometimes help get the UI designer out of this mess, but it is better to avoid the trap altogether whenever possible.

4.4.1 Standard Icon Sizes & Colors

There are three standard icon sizes.  The two most commonly used are 32 x 32 pixels (desktop shortcuts and application logo overlays on splash screen bitmaps) and 16 x 16 pixels (for hierarchical menu trees and system tray icons).  The third frequently used size is the 20 x 20 pixels Icon for toolbars. This third size is usually produced on an appropriate background that is designed to blend into the background it is superimposed over, thus making it ideal for toolbar icons.

4.5 Roll-over Tool Help

Commonly known in Windows 2000 as “Tool Tips,” roll-over tool help has become a standard UI convention which provides a text description of the function of a toolbar (or menu) button, and only comes up if the User first mouses over the given button, and then pauses for a second or two (probably wondering what that button is for). Text for roll-over tool help should be as concise as possible, containing no more than a few words (or one complete sentence at most).  More explanatory information can subsequently be displayed on the title bar or header of the page that the button brings up once selected.  The idea of tool help is to simply give the user a clue or reminder of what the selection does or where the button will navigate To. In addition, data result sets can benefit from this new functionality by placing full text descriptions in the title tag of a result while limiting the actual footprint to 15 or 20 characters.

4.6  Tab Order In Forms

The tab order defines how the User is intended to move through the form during the completion of a complex, multi-step process. The back-end should be able to accommodate the non-linear update of discreet chunks of user submitted data, because Users will sometimes want to revisit a previous step in the multi-step process in order to correct erroneous entries. This is an important example of the necessity of a temporary persistence layer where data can be staged before it is committed to the permanent database by the User’s click of the “submit” button. Session data is often collected for several steps before being committed in a “submit” or transaction closing step. (Please set the tabindex attribute of your form elements)

5.0 Notes on User Acceptance Testing,

which, after all, is designed to check and / or validate the usability of your applicationMost people’s first concept of a usability test is that it is something that would take place in conjunction with beta testing or quality assurance; BUT, At The End of The Development Cycle usability testing is virtually useless because it is Too Late to improve the product by implementing the findings of your tests. 15  I mean, let’s get serious here, what Software Developer in his right mind would send the development project Back To Square One for product redesign when the product is scheduled for release in a couple of weeks?  Nobody.  If he did, he would get fired; but if he didn’t, and the product failed based on shortcomings found in the usability testing, he’d get fired anyway (or the whole enterprise might go under). I hope that (not so cheery) example of why late usability testing is a big mistake underscores for you the necessity for testing early.  As far as testing often goes, the mere fact that there are four different types of tests (combined with the fact that some of them will be performed more than once on different task evaluations & different aspects of the product) should indicate to you that one or two neat & tidy tests, at say 25% and 50% through the development cycle, is probably NOT going to cut it. All that being said, there is no set formula (written in stone) to dictate when testing should be performed. Keep this in mind as you look over fig 2.1.

Fig. 2.1: When To Perform Formal Usability Testing During The Product Development Life Cycle16


As an prospective web site developer, hoping to take a proactive stance towards making your software products more User-friendly through a better understanding of User Centered Design, Information Architecture, and Usability; this document should have provided you with everything you need to know about usability. In fact, it probably includes everything you always wanted to know about usability, but were afraid to ask (and now you know why you were afraid to ask ;-).

If you should find yourself actually conducting usability tests on software applications (as test monitor), or if you need more reference information to accurately interpret the results of some web site usability tests, I highly recommend reading Jeffrey Rubin’s Handbook of Usability Testing: How to Plan, Design, and Conduct  Effective Tests (on which the ‘Formal Usability Testing’ section of this Charter is almost entirely based).  If you seek a deeper knowledge of Information Architecture [or how to design software with a front-end / User Experience Architecture perspective], I recommend attending my IA / Usability training class, and / or reading the Nielsen and Pearrow books referred to in the Bibliography of this Charter.

If you are even mildly interested in proactively supporting good usability practices in the Information Design of our Your e-business software products, I strongly suggest that you check out Jakob Nielsen’s website on which he publishes a weekly column “alertbox” as well as archiving his famous articles on “Heuristic Evaluation” and “Guerilla Usability.”

Nielsen is a User advocate and principle of the Nielsen Norman group, which he co-founded with Donald A. Norman (Former VP of Research at Apple Computer). Until 1998 he was a Sun Microsystems Distinguished Engineer and the company’s web usability guru.  Dr. Nielsen coined the term “discount usability engineering,” and has developed several usability techniques for fast and cheap improvements of User interfaces, including heuristic evaluation.  He holds 45 US patents, mainly on making the Internet easier to use.  He spends much of his time lecturing around the world on usability issues.  Through years of research and interaction with Users Jakob Nielsen has arrived at a series of principles that work in support of his findings: 1) that web Users want to find what they’re after quickly, and 2) if they don’t know what they’re after, they nevertheless want to browse quickly and access information that they come across (serendipitously) in a logical manner.

The concepts in this Charter are based squarely on Nielsen’s work, and the most effective “guerilla usability” technique you can employ is to follow Nielsen’s Heuristic Evaluation method.  You can always add a few new heuristics as needed to keep up with the curve of technological advancement.  So if you’re looking for the bulletized “Top Ten List” on usability, just go memorize “GE Web UI Standard’s 15 Heuristic Metrics” (a check list of usability rules).

Bibliographical Notes

1. Web Site Usability Handbook by Mark Pearrow, c2000 by Charles River Media, Inc.

2. see Nielsen’s website at for the

article “How To Conduct  A Heuristic Evaluation.”

3. Laura Boutwell 9/5/200 posting to the American Society for Information Science

&Technology –  SIGIA listserv regarding Information Architecture [in this case for B2B

Marketplaces].  Laura is an Information Architect for Lante, a B2B eMarket solutions


4. Winnie Chen 9/7/00 posting to the American Society for Information Science & Technology SIGIA listserv regarding Information Architecture [in response to Laura’s posting].  Winnie is, an e-Business savvy Information Architecture consultant.

5. Web Site Usability Handbook by Mark Pearrow, c2000 by Charles River Media, Inc.

6. Usability Inspection Methods by Jakob Nielsen and Robert L. Mack, c1994 by John Wiley & Sons.

7. see Nielsen’s website at for the

article “Heuristics For User Interface Design.”

8. Designing Web Usability by Jakob Nielsen, c2000 by New Riders Publishing,

Indianapolis, Indiana, USA.

9. About Face: The Essentials of User Interface Design by Alan Cooper, c1995 by IDG Books Worldwide, INC.

10. Web Site Usability Handbook by Mark Pearrow, c2000 by Charles River Media, Inc.

11. Designing Web Usability by Jakob Nielsen, c2000 by New Riders Publishing,

Indianapolis, Indiana, USA.

12. About Face: The Essentials of User Interface Design by Alan Cooper, c1995 by IDG Books Worldwide, INC.

13. Handbook of Usability Testing: How To Plan, Design, and Conduct Effective Tests, by

Jeffrey Rubin, c1994 by John Wiley & Sons, Inc.

14. see The World Wide Web Consortiums guidelines and policy links regarding ADA 508 at the W3C website:

15. & 16. Handbook of Usability Testing: How To Plan, Design, and Conduct Effective Tests, by Jeffrey Rubin, c1994 by John Wiley & Sons, Inc.