Section II: User Interface Building Blocks
Chapter 8: Putting the Building Blocks Together
The preceding chapters have introduced the various building blocks provided by PenPoint - controls, menus, dialog and option sheets, etc.
With these building blocks in hand, we can step back and ask how they should be put together. Should a given function go on a menu, or an option sheet, a palette, or all three? Should all functions be put on menus? On option sheets?
This chapter gives principles and examples relevant to answering the basic·
question of how to present your application's functionality.
Topics include:
• Dual command path - controls and gestures.
• Layering of functionality to hide complexity.
• Allowing the user to configure the interface to your application.
• When to use menus, palettes, and option sheets.
• When to depart from the standard building blocks.
Basic Guidelines
This section mentions some basic guidelines for to keep in mind when thinking about how to present your application's functionality.
Dual Command Path - Controls and Gestures
This basic PenPoint principle, introduced in Chapter 3, bears mention again here.
To summarize the gesture guidelines:
• Throughout your design and development process, ask yourself how you can give your users the choice of using either visible controls - buttons, checklists, menus, palettes - or gestures.
• Use the core gestures whenever they are relevant to your application.
Always follow the standard PenPoint usage for the core gestures.
• Use the non-core gestures and the capital letters as accelerators for frequently-used operations. Use gesture accelerators judiciously - the point isn't to find a gesture accelerator for every command, but to use them where they really make the user's job easier.
Layering
This principle applies in designing any application, particularly those that present a rich set of functionality and will be used by a diverse set of people.
Don't overwhelm the user by presenting all of the commands at the same level.
Layer the interface to hide complexity. Present the most important commands prominently, and put the rest behind the surface, on menus or option sheets that the user must open to see.
Page 76 PenPoint User Interface Design Guide, Rev. 0.5,2/15/91
Putting the Building Blocks Together
User Configurability
Think of how you can help the user by allowing him or her to configure the face presented by your application.
There are many ways to do this - by providing "novice" and "expert" modes, by letting the user put favorite commands on customized palettes, etc.
One degree of flexibility you should always provide is to allow the user to hide any non-essential palette line, message line or other region, to make more room for the display of data.
Add the controls for showing and hiding the non-essential regions to the standard document Access sheet, as shown in Figure 56.
Expense Report • Access
Figure 56: Status Line Control on Access Sheet
In this example the application has added a Status Line choice to the Controls list.
PenPoint User Interface Design Guide, Reo. 0.5,2/15/91 Page 77
Where to Put It: Menu, Option Sheet, or Palette?
Now we come to an issue that is very basic, and yet difficult to give hard and fast guidelines for - how to divide your application's functionality between menus, option sheets, and visible control areas such as palette lines and custom control regions.
No single user interface mechanism is "beSt" - each has its strength and corresponding weakness.
As a reference point, the table below summarizes the main strengths and weaknesses of menus, option sheets, and palettes.
Mechanism
Menus
Option Sheets
Palettes
Strengths
Menus invite the user to explore by tapping.
Menus are easy and fast to invoke for a single operation.
Option sheets don't require the user to access each control by name. All the user need remember is to make the checkmark gesture over the object of interest.
Because they are modeless, option sheets allow the user to easily change several settings at once, or to keep the sheet up and use it repeatedly.
Palettes provide the most visual invitation, and the most efficient access, since all the controls are visible at once.
Palettes are typically compact, since they use small glyphs instead of longer textual labels.
Palettes don't obscure any of the document's work area, and never need to be dragged out of the way.
Weaknesses
Menus are inefficient for often used
commands, or for commands that are typica issued in groups, since they disappear automatically as soon as one command is issued.
Option sheets are take longer to display thal menus, and usually take up more screen rea estate than menus (although the user can resize the sheet to show only the desired control.
While option sheets are displayed, they obscure part of the screen, often requiring tl user to drag them out of the way.
Not appropriate for commands that can't be clearly expressed as a small glyph.
Not appropriate for less frequently-used commands.
Take up screen real-estate permanently.
On the following page are tWo useful questions to ask when considering how to present your application's commands and options to the user.
Page 78 PenPoint User Interface Design Guide, Rev. 05,2/15/91
Putting the Building Blocks Together
1. What are the most important, obvious objects that the user will see and deal with?
In general, you should provide an option sheet for each type of object in your application, unless there's a compelling reason not to.
Whatever the object is - a span of text, a figure in a graphics editor, a cell in a spreadsheet, an appointment entered into a calendar, - the user should be able to view and modify the object's options by drawing a chec1<mark over it.
For example, suppose your application presents a list of sales contacts. Each contact in the list has associated. information that the user can modify. You could call the command by a specialized name such as Edit Entry or Update Contact Information.
But that approach forces the user to learn and remember the specialized name you have chosen. By presenting the same command under the generic umbrella of Options, you lessen the learning curve. The user comes to yoUr application already knowing about option sheets and how to invoke them. There's no need to even think in terms of a new command. The user simply makes a checkmark on the entry in the list, and already he or she is successfully using the
application.
2. Is there a set of commands or modes that are fundamental to your application, that the user will be using very frequently? .
H the answer is "yes," it is probably best to present the commands in a palette that is always visible, so the user never has to worry about popping up a menu or option sheet, or dragging an option sheet out of the way.
The above two guidelines will suggest what you should put on option sheets and palettes - now what about menus?
When designing your menu line, there are two general approaches you can take.
One is to put all the important functionality on the menu line, so that the menu line, as the primary way of issuing commands, becomes indispensable.
The other is to put less functionality on the menu line and more on other input paths - gestures, palette lines, or option sheets. That way the user can turn off the menu line and continue using the application. In the notebook Table of Contents, for example, the user can turn off the menu line and browse through the notebook contents, turn to documents, turn tabs on and off for specific documents, move, copy or export documents, etc.
PenPoint User Interface Design Guide, Rev. 0.5,2/15/91 Page 79
When to Depart from the Standard Building Blocks
Don't depart gratuitously. There's not much added value in being different for differences sake, and there may be a cost, if it requires the user to learn new variations. For example scroll margin visuals.
But of course there are many situations in which it is appropriate to depart.
Guidelines and standards are not meant be rigidly applied, to produce a
monotonous scene. In the oft-quoted words of Ralph Waldo Emerson, "A foolish consistency is the hobgoblin of small minds."
The best reason to depart from the standard visuals is to emulate a real world object, such as a calculator, control panel, rolodex, telephone message slip, etc. In such cases by all means be realistic.
In fact, being "realistic" has all the benefits cited for consistency in interfaces -reducing learning time by taking advantage of the user's familiarity from other contexts. Only with realistic objects the consistency is with respect to things from other domains that the user is familiar with, instead of the domain of the
standard PenPoint user interface.
Issues
Page 80 PenPoint User Interface Design Guide, Rev. 0.5,2/15/91