Articles Comments

GUI Journal » GUI Design, Help, Process » GUI Design: 1…2…3…Help!

GUI Design: 1…2…3…Help!

In the 1980s when the advance of personal computers put software applications into the hands of administrative assistants, professionals, and students, “Help!” was quickly becoming the most common four-letter word in the English language. There was an obvious need for extensive and clear software manuals, because (for most of us) there was virtually no prior experience that would help us know how (or learn how) to navigate this new world at our fingertips. Desktops or bookcases near the computer usually contained multiple squatty, three-ring binders in thick cardboard sleeves with manuals for operating systems and desktop software. These were invaluable! But they were not always easy to understand and it was often difficult to find someone nearby who could help. These facts, along with the recognition that reading manuals was not always the first choice for most users, some software companies, WordPerfect® for example, even offered unlimited lifetime telephone support for their applications.

I have found a strong correlation over the years between outstanding applications and outstanding documentation.  In my experience, the best combination happens when the documentation begins before the programming does. A good documenter will help keep the development clear and consistent. The documenter should be provided with (and be involved in the development of) mock ups and functional specifications that everyone on the project is working toward. Documenting an application is the quickest way to find inconsistencies in layout, look, feel, flow, and terminology. Also, when the documentation seems convoluted or difficult to understand, that’s a big clue that the application is convoluted or overly complex and should be redesigned. Because you will want all of those problems fixed as soon as possible, documentation should begin as soon as possible, too.

Figure 1. Bad Right Alignment

The biggest challenge for help and documentation is how to effectively teach users about all the features and capabilities that they may need. Figure 1 shows a fictional example of a document similar to something many of us have seen in the past. It represents an attempt by a user to create a recital program that is aligned both on the left and on the right. Unfortunately, in this example, the right alignment was attempted by the use of spaces and dots. (The red line is inserted to emphasize the uneven line endings.) The problem could be either that the user had no idea there is a feature that can do this automatically, or the user has no idea what the feature is called, in which case it can be nearly impossible to find.

Figure 2. Right Alignment Using the Correct Feature

Figure 2 shows another example of the recital program, but it was done with the “dot leader” feature (as it is called in most word processors). The first time I wanted to use this feature I had to ask someone for help because I had no idea what it was called and therefore couldn’t find it in the index. We’ve all been in situations where we know so little, we don’t even know what to ask. Grand attempts have been made over the past 25 years to improve documentation and, thereby, improve the accessibility of an application and its features. Documentation of an application is as important as the application itself. At this point in the evolution of “Help!” there are three basic categories:

  1. Feature Documentation: Descriptions of the product and each of its features
  2. Task Documentation: Descriptions of how to accomplish a specific task
  3. Feedback: Analysis of application setup or usage with suggestions to be considered

 

CATEGORY 1: FEATURE DOCUMENTATION

Those old squatty three-ring binders were great with feature documentation. They usually had extensive indexes so that, as long as you knew what the feature was named, you could find it in the index and get instructions on how to use it. When disk space and memory increased enough that documentation could be electronic rather than printed, the documentation was mostly the same, just electronic. That made it more easily searchable, which was very cool, and at first no one really thought much past that…they were just happy not to have the expense of printing and shipping huge manuals anymore.

The next advance in feature documentation was the idea of “Context Sensitive” help. Instead of just hitting the help button and getting the entire manual in a window, you now were taken to the help for the specific area of the application where you were currently working. Somewhat nicer.

A few years ago I purchased a new version of Adobe® Photoshop®. When it launched for the first time I was presented with the welcome screen shown in Figure 3. It provided several options for learning about the new features. I quickly found some videos to watch. It was a quick and easy way to learn about features that were useful, but not necessarily tied to any particular task that I wanted to perform at the time—my reason for starting it up in the first place. When I am upgrading or installing a new product I generally do it when I don’t have pressing deadlines, so that is a good time to receive some generic training.

Figure 3. Adobe® Photoshop® Welcome Screen

CATEGORY 2: TASK DOCUMENTATION

Documentation that is task oriented was a huge step forward. Tasks are at the core of the way users think. They care about the outcome, not the process. A user can systematically go through all of the menu options and dialogs in an application in an attempt to learn what it can do, but a user is much more interested in accomplishing a task, not necessarily using a feature. Even if a feature is discovered that would be helpful, the user may not understand it well enough to realize how to use it for their task. A user that is new to an application will likely use the first feature discovered that seems like it can accomplish the task at hand, rather than doing an exhaustive search to find every possible feature in an attempt to determine the best way to accomplish the task. (That’s how a document like the phony recital program in Figure 1 ends up with a jagged right edge when users are doing their best to make it look straight.)

Fifteen or more years ago a “senior” programmer said to me (in all seriousness), “My code is self documenting.” I was incredulous. There is no way that a programmer can write code so well that it can be effectively maintained without documentation, just as there is no way that an application can be written so well that it can be effectively used without documentation. The problem with undocumented code is that one might be able to determine what the code is doing, but the more important information is why. The same is true for an application.

Various means have been (quite successfully) developed for making the leap from feature documentation to task documentation. Microsoft® has made the phrase, “What do you want to do today?” famous. Its applications began to encourage users to ask questions to find out how to accomplish a task, rather than just learning how to use a feature. About 15 years ago the web site askjeeves.com (now ask.com) promoted the concept of asking a question to get help on any subject. For this article I typed in the question, “How do I get all the left sides and right sides of the lines to be straight in a word processor?” and immediately found several links to detailed explanations of how to accomplish this using various means in various word processors. (Similar results are shown in most web search engines now.)

In the 1980s and 1990s WordPerfect® was highly successful with legal firms (and other entities) partly because it provided templates for getting started with a document that already closely resembled what you wanted to end up with. For example, if you wanted a legal brief that already had line numbering along the left, you simply chose the correct template; you weren’t required to learn where the line-numbering feature was or how to use it. If you wanted a calendar, there were many to choose from. The list of templates was long and rich. It was a quick way to get moving on a task.

CATEGORY 3: FEEDBACK (ANALYSIS & RECOMMENDATIONS)

Figure 4. Microsoft Office Assistant "Clippy"

This category is by far the least developed and has the most potential. Feedback can be either automatic or requested. The value of analysis and recommendations lies in the fact that most users don’t know what they don’t know. They often have no idea what the possibilities are within a given application and have no idea what questions to even ask.

Microsoft® did some amazing pioneering work in this category. The Office Assistant, a feature first included with Microsoft Office 97, was developed to basically watch what the user was doing at all times and offer helpful suggestions. It was a great idea (and still is). Unfortunately, it was poorly received, partly because the implementation felt intrusive and annoying. The Office Assistant could take on various forms, with the default in English being an animated paper clip named “Clippit,” nicknamed “Clippy” (see Figure 4). What was supposed to have been a trusted advisor ended up coming across as a precocious 15-year-old college freshman with the social skills of a pre-schooler. Users could only take the constant, “Whatcha doin’ now? Huh? Whatcha doin’ now? Are you gonna do this next?” for so long before they disabled it completely.

When the Office Assistant was finally discontinued by Microsoft with the release of Office XP, the statement was “Office XP is so easy to use that Clippy is no longer necessary.” I don’t buy it. I believe Microsoft was on the right track with the Office Assistant, but an overbearing implementation doomed the idea.

Figure 5. Adobe Update Bubble

I feel annoyed by applications that pop up a dialog telling me about the latest version at the time I launch the application. The reason I’m launching it is to get something done and I’m usually trying to meet a deadline, so don’t bother me right now. I am much more receptive at the time I am closing down an application. The subtle, less intrusive approach is common these days. Figure 5 is an example of an information bubble that appears temporarily on my task bar. It goes away after a few moments if I don’t interact with it, but the icon is still available when I am ready. When it comes to something like a word processor or drawing program I think I might like an “Analyze” button that I can select at will. I just finished doing a particular task, or I am in the middle of a task and I wonder what suggestions I might be able to get. This could be something akin to the “Hint” feature in a game.

Figure 6. Novell Cloud Security Service Recommended Actions

Novell® recently released a product called Novell Cloud Security Service®. The main panel is a dashboard with the current status of all the important areas of the application. One of the panels on the dashboard is entitled Recommended Actions (see Figure 6). By default this panel is at the upper left, but it can be dragged and left anywhere. It can also be minimized such that only the title bar remains, showing the number of recommendations. Clicking on a particular recommendation helps the user through the necessary steps to complete the action. In the beginning the recommendations center around setup: what should be done next to get the system operational. Once the setup is complete, the recommendations involve verifying defaults that are being used and adding features for robustness.

The Recommended Actions feature is a much more subtle implementation of Feedback. Users new to the application know where they can look to quickly determine what likely ought to happen next.

FUTURE

I still hope for a kinder, gentler “Clippy” someday. With the power that exists in software, this seems like a reasonable hope. I imagine something like the character Data from Star Trek: The Next Generation standing nearby, waiting patiently for me to acknowledge him. Then I can hear him saying, “Captain, I analyzed your document and determined that you were intending to have the middle column centered and the right column right-aligned. I therefore inserted a center tab and a right tab on each line and saved the new document for your review at your convenience. Of course the original is still intact in the case that I made an incorrect assumption.”

KEY DESIGN POINTS

  1. The Help system and documentation are as important as the application itself, so create them as early as possible and allow them to help direct development
  2. Task documentation is a minimum, not just feature documentation
  3. Analysis with hints or suggestions add a whole new level of polish, but they must not be intrusive

GUI Design

GUI Design Guidelines

Graphical User Interface

User Interface

Graphical User Interface Design

Graphical User Interface Design Guidelines

Written by

Carl Andersen currently works for NetIQ and Novell (divisions of Attachmate) as a Software Engineering Consultant and User Experience Architect. Carl has led teams and been the principal designer of multiple GUIs which have received analyst acclaim. He also consults on multiple other products within Novell and NetIQ.

Filed under: GUI Design, Help, Process · Tags: , , , , , , ,

2 Responses to "GUI Design: 1…2…3…Help!"

  1. Wendy Busath says:

    I agree that “Clippy” was one of the most annoying inventions of the 20th century. Although when it was late at night and I had to get my term paper turned in, I must admit I did turn to him a few times. I never could quite explain to him what I was trying to accomplish. Seemed nearly like talking to my husband! I think “Clippy” could be useful if the software to get what’s in the customer’s brain related to what “Clippy” knows was better.

    1. Carl says:

      Wendy, I think you nailed it with your last statement. It reminds me of a WordPerfect print ad from 30 years ago that showed a person’s thoughts going to the keyboard and onto the screen. Somehow we need to make that happen! Thanks.

Leave a Reply

*


× four = 12

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>