Case Study: A Find Dialog Box

Now let's apply these ideas to a fairly typical example. Let's design a Find dialog box that searches for text strings in a file, similar to the Find command in Visual C++. The goal of the design is to eliminate as much unnecessary repetition as we can.

The first design is a simple dialog box, with an edit box to type the search text, a Find Next default button to find the next occurrence of the string, and a Cancel button to close the dialog box. The input focus is initially on the Find Next button, and the input focus moves from the Find Next button to the Cancel button to the edit box.

While this dialog box is completely functional, the user has to enter the complete search string every time he uses it. The dialog box has no recollection of any past usage. While the user will often completely change the text, it is likely that the user will want to search on the previous search string or a string similar to it. Let's eliminate the need to reenter the last entered text by saving it and automatically initializing the edit box to the last searched string.

Now if the user wants to search for the last string, all the user has to do is click the Find Next button or press the Enter key. What if the user wants to change the text? The user has to select the existing text, clear it, and then enter the new text. We can eliminate this unnecessary step by setting the input focus to the edit box by default and selecting the entire search string. While we're at it, let's also disable the Find Next button whenever the search string is empty to eliminate the need for an error message.

Now if the user wants to search for the last string, this dialog box requires the same effort as before—the user has to click the Find Next button or press the Enter key. However, if the user wants to search for a different string, the user just has to type the new string and press Enter.

Let's reconsider the first design attempt that didn't initialize the edit box to the last search string. Giving the Find Next button (or, as in most modal dialog boxes, the OK button) the initial input focus is a poor choice. Why? Because it is impossible for the user to use this dialog box by simply pressing the Enter key. By setting the initial focus to the control that the user is most likely to interact with first, you can eliminate an unnecessary step. Furthermore, since the default button can be pressed with the Enter key (by definition), there is simply no reason to give the default button the initial input focus.

TIP
Assign the initial input focus to the control that the user is most likely to interact with first.

This last design is functional and easy to use, and it would be suitable for a utility. However, for an application like Visual C++ or Microsoft Word that a user might use for several hours a day, there is still room for improvement. The problem is that while searching for the last word is easy, searching for any other previous input requires the user to completely reenter the string. The worst case is when the user alternates searching between two words. In that case, the user has to do a lot of typing.

The next improvement is to use a combo box with a history list of the recent searches. With the history list, the user can search for any recent search simply by dropping down the history list and making a selection. Of course, such a list is most effective when its contents are saved and restored between instances.

Is this as good as it gets? Well, there is room for one last improvement. What is the sort order of the history list? If the order is alphabetical or any order other than the most recently used order, it's possible that the user will have to do quite a bit of scrolling to find a previously entered item in the list. The user is far more likely to want to search for a recently entered string than one entered hours ago, so placing recently entered strings at the top of the list will make them easier to find and eliminate unnecessary scrolling. With this last refinement, this Find dialog box design is now similar to the Find dialog box in Visual C++. Note how small differences make a big difference in the usability of the dialog box.

To wrap up this case study, consider these few additional details:

  • Pay attention to how a dialog box is used when you assign tab order. For example, in Visual C++ 4.0, the Replace dialog box (shown below) tab order went from the Find What edit box to the Find What regular expression button (to the right of the edit box) to the Replace With edit box to the Replace With regular expression button. Although this tab order follows the dialog box layout, it doesn't follow how the user will use the dialog box. If the input focus is on the Find What edit box and the user presses the Tab key, it is almost certain that the user wants to enter the Replace With text, not select a regular expression. Visual C++ 5.0 fixed this problem by moving the regular expression buttons after the edit boxes in the tab order.
  • click to view at full size.

  • Consider using the toolbar for activities that the user performs often. For example, with Visual C++ you can set up the toolbar to have all of the Find dialog box capabilities. Using the toolbar eliminates having to display and close the dialog box. Since the toolbar is modeless, using the toolbar also allows the user to perform any other activity while searching for text whereas a modal dialog box does not. Furthermore, the toolbar version requires less effort than the modal dialog box, both physically and psychologically, as I discuss in Chapter 22, "Unnecessary Dialog Boxes Are Evil"
  • Visual C++ eliminates the need to type a search word altogether by searching for the word that the caret is in or for selected text. This approach is effective when the text the user wants to search for is likely to be displayed somewhere on the screen, which is less likely in most other programs. I think this feature could be improved by giving the user a way to bypass it when desired and default to the last search string instead.
  • Consider using keyboard shortcuts to eliminate having to use a dialog box. For example, repeating the last search is a likely action, so Visual C++ and most other programs provides a Find Next command with an F3 keyboard shortcut. Unfortunately, Microsoft Word provides a nonstandard Ctrl+PgDn keyboard shortcut that isn't displayed in the main menu, so it isn't obvious that the shortcut exists. However, Word does provide an interesting alternative with the Select Browse Object button with the Next Find and Previous Find buttons on the scroll bar. Note that the tooltip gives the shortcut key.

Do you always have to do all this work for every dialog box you do? Fortunately no. As I suggested previously, the depth of the functionality needed to eliminate unnecessary repetitive tasks should match how repetitive those tasks are. Simple utilities probably don't need such functionality since users typically don't do enough searching for the repetition to be a problem. Such functionality is warranted for user interface features that are constantly used.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net