[Notes2-team] Aqua Human Interface Guidelines
Brought to you by:
andersonrb
Menu
▾
▴
[Notes2-team] Aqua Human Interface Guidelines
|
From: Anderson <and...@po...> - 2003-06-22 03:20:59
|
E ae people!
Eis o guia da apple para interfaces. Na realidade s=E3o trechos, o guia m=
esmo
=E9 bem maior. Podemos afanar id=E9ias pro Notes.
quem entende mais de interface q os designer da apple?
And.
Aqua Human Interface Guidelines
Human Interface Design Principles
This section provides a theoretical base for the wealth of practical=20
information on implementing the Aqua interface elements presented in the=20
rest of this book.
You'll undoubtedly find that you can't design in accordance with all of=20
the principles all the time. In those situations, you'll have to make=20
decisions based on which principle or set of principles is most=20
important in the context of the task you're solving. User testing is=20
often an excellent way to decide between conflicting principles in a=20
particular context.
Metaphors
Take advantage of people's knowledge of the world by using metaphors to=20
convey concepts and features of your application. Use metaphors that=20
represent concrete, familiar ideas and make the metaphors obvious, so=20
users can apply a set of expectations to the computer environment. For=20
example, the Macintosh uses the metaphor of file folders for storing=20
documents; people can organize their hard disks in a way that's=20
analogous to the way they organize file cabinets.
Metaphors in the computer interface suggest a use for something, but=20
that use doesn't necessarily define or limit the implementation of the=20
metaphor. The Trash, for example, doesn't have to limit its contents to=20
the number of items an actual wastebasket could contain. Try to strike a=20
balance between the metaphor's suggested use and the computer's ability=20
to support and extend the metaphor.
See-and-Point
People interact with the interface by pointing at onscreen objects with=20
a device, typically a mouse. The Macintosh operating system works=20
according to two fundamental paradigms, both of which assume that users=20
can see what they're doing onscreen at all times and can point at what=20
they see. The paradigms are based on a general form of user action:=20
noun-then-verb.
In one paradigm, the user selects an object (the noun) and then chooses=20
the action to be performed on the object (the verb). All actions=20
available for a selected object are listed in the menus, so a user who=20
is unsure of what to do next can scan through them. Users can choose an=20
available action without having to remember a specific command.
In the second paradigm, the user directly manipulates an object (the=20
noun) and performs an action (the verb) with it. A common example is=20
dragging a document icon to a folder, for example. The user doesn't=20
choose a menu command, but it's clear what happens to an object when=20
it's placed on another one. For this paradigm to work, the user must=20
recognize what objects are for; the fact that the Trash looks like its=20
real-world counterpart makes the interface easier to use.
Direct Manipulation
Direct manipulation allows people to feel that they are controlling the=20
objects represented by the computer. According to this principle, an=20
onscreen object should remain visible while a user performs an action on=20
it, and the impact of the action should be immediately visible. For=20
example, a user moves a file by dragging its icon from one location to=20
another. With drag and drop, the most common example of direct=20
manipulation, users can drag selected text directly into another document=
.
Support direct manipulation when users expect it. Avoid forcing users to=20
use controls to manipulate data. For example, you should be able to send=20
a facsimile by dragging a document's icon to a fax machine icon in the=20
Dock, instead of having to open a utility program, choose a file, and=20
click a Fax button.
User Control
Allow the user, not the computer, to initiate and control actions. Some=20
applications attempt to take care of the user by offering only=20
alternatives judged good for the user or that protect the user from=20
having to make detailed decisions. This approach mistakenly puts the=20
computer, not the user, in control.
The key is to create a balance between providing users with the=20
capabilities they need to get their work done and helping them avoid=20
dangerous irreversible actions. For a situation in which a user may=20
destroy data accidentally, for example, you should always provide a=20
warning and still allow the user to proceed if desired.
Feedback and Communication
Keep users informed about what's happening with your product. Provide=20
feedback as they do tasks. When a user initiates an action, provide an=20
indication that your application has received the user's input and is=20
operating on it.
Users want to know that a command is being carried out or, if it can't=20
be carried out, they want to know why not and what they can do instead.=20
When used sparingly, animation is one of the best ways to show a user=20
that a requested action is being carried out. When a user clicks an icon=20
in the Dock, for example, the icon bounces to let the user know that the=20
application or document is in the process of opening. In Mac OS X, the=20
kernel environment detects when your application doesn't respond to=20
events for 2 seconds and automatically displays a busy cursor.
For operations that don't execute immediately, use a progress indicator=20
to provide useful information about how long the operation will take.=20
See "Progress Indicators"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGControls/chapter_7_section_14.html#//apple_ref/doc/uid/20000963/TPXREF=
106>.=20
Users don't need to know precisely how many seconds an operation will=20
take, but it helps to give an estimate. For example, the Mac OS uses=20
statements such as "about a minute remains." It can also be helpful to=20
communicate the total number of steps needed to complete a=20
task--"Copying 30 of 850 files," for example.
Provide direct, simple feedback that people can understand. In error=20
messages, for example, spell out exactly what situation caused the error=20
("There's not enough space on that disk to save the document") and=20
possible actions the user can take to rectify it ("Try saving the=20
document in another location"). For more information, see "Writing Good=20
Alert Messages"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGLanguage/chapter_13_section_4.html#//apple_ref/doc/uid/20000970/TPXREF=
23>.
Consistency
Consistency in the interface allows people to transfer their knowledge=20
and skills from one application to any other. Use the standard elements=20
of the Aqua interface to ensure consistency within your application and=20
to benefit from consistency across applications. Ask yourself the=20
following questions when thinking about consistency in your product.
Is your product consistent
* within itself?
* with earlier versions of your product?
* with Mac OS standards? For example, does your application use the
reserved and recommended keyboard equivalents? (See "Reserved and
Recommended Keyboard Equivalents"
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGUserInput/chapter_9_section_6.html#//apple_ref/doc/uid/20000965/=
CHDIGFBH>.)
* in its use of metaphors?
* with people's expectations?
Matching everyone's expectations is the most difficult kind of=20
consistency to achieve, since your product is likely used by an audience=20
with a wide range of expertise. You can address this problem by=20
carefully weighing the consistency issues in the context of your target=20
audience and their needs.
WYSIWYG (What You See Is What You Get)
In applications in which users can format data for printing, make sure=20
there are no significant differences between what the user sees onscreen=20
and what the user receives after printing. When the user makes changes=20
to a document, display the results immediately; the user shouldn't have=20
to wait for a printout or make mental calculations of how the document=20
will look when printed. Use a print preview function if necessary.
WYSIWYG is not about only printing; all data experienced by=20
users--movies, audio, and so on--should be faithfully represented in all=20
media.
People should be able to find all the available features in your=20
application. Don't hide features by using abstract commands. For=20
example, menus present lists of commands so people can see their choices=20
instead of having to remember command names.
Forgiveness
You can encourage people to explore your application by building in=20
forgiveness--that is, making most actions easily reversible. People need=20
to feel that they can try things without damaging the system; create=20
safety nets, such as the Undo and the Revert to Saved commands, so=20
people feel comfortable learning and using your product.
Always warn users before they initiate a task that will cause=20
irreversible loss of data. If alerts appear frequently, however, it may=20
mean that the product has some design flaws; when options are presented=20
clearly and feedback is timely, using an application should be=20
relatively error-free.
Perceived Stability
The Macintosh interface is designed to provide an understandable,=20
familiar, and predictable environment.
To give users a visual sense of stability, the interface defines many=20
consistent graphics elements, such as the menu bar, window controls, and=20
so on. Users encounter a familiar environment in which they know how=20
things behave and what to do with them.
To give users a conceptual sense of stability, the interface provides a=20
clear, finite set of objects and a clear, finite set of actions to=20
perform on those objects. For example, when a menu command doesn't apply=20
to a selected object or to the object in its current state, it is shown=20
dimmed (grayed out) rather than being omitted.
To help preserve the perception of stability, when a user sets up his or=20
her onscreen environment in a certain layout, it should stay that way=20
until the user changes it. Preserve user-modified settings such as=20
window dimensions and locations.
Aesthetic Integrity
Aesthetic integrity means that information is well organized and=20
consistent with principles of visual design. Your product should look=20
pleasant on screen even when viewed for a long time.
Keep graphics simple, and use them only when they truly enhance=20
usability. Don't overload the user with icons or put dozens of buttons=20
in windows or dialogs. Don't use arbitrary symbols to represent=20
concepts; they may confuse or distract users.
Match a graphic element with users' expectations of its behavior. Don't=20
change the meaning or behavior of standard items. For example, always=20
use checkboxes for multiple choices; don't use them sometimes for=20
exclusive choices.
Modelessness
As much as possible, allow people to do whatever they want at all times.=20
Avoid using modes that lock the user into one operation and don't allow=20
the user to work on anything else until that operation is completed.
Most acceptable uses of modes fall into one of the following categories:
* Short-term modes in which the user must constantly do something to
maintain the mode. Examples are holding down the mouse button to
scroll text or holding down the Shift key to extend a text selectio=
n.
* Alert modes, in which the user must rectify an unusual situation
before proceeding. Keep these modes to a minimum. See "Types of
Dialogs and When to Use Them"
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGDialogs/chapter_6_section_2.html#//apple_ref/doc/uid/20000962/CJ=
ECBHJE>
for more information.
Other modes are acceptable if they do one of the following:
* They emulate a familiar real-life situation that is itself modal.
For example, choosing different tools in a graphics application
resembles the real-life choice of physical drawing tools.
* They change only the attributes of something, not its behavior.
The boldface and underline modes of text entry are examples.
* They block most other normal operation of the system to emphasize
the modality. An example is a dialog that makes all menu commands
unavailable except Cut, Copy, and Paste.
If an application uses modes, there must be a clear visual indicator of=20
the current mode, and it should be very easy for users to get in and out=20
of the mode. For example, in many graphics applications, the pointer can=20
look like a pencil, a cross, a paintbrush, or an eraser, depending on=20
the function (the mode) the user selects.
Knowledge of Your Audience
Identifying and understanding your target audience are important first=20
steps when designing your product. The best way to make sure your=20
product meets the needs of your customers is by exposing your design to=20
their scrutiny. You can do this during every phase of the design process=20
to help reveal what works about your product as well as its flaws. The=20
improvements you make as a result of prototype testing can translate=20
into competitive advantages, increased sales, and enhanced customer=20
satisfaction.
It's useful to create scenarios that describe a typical day in the life=20
of a person you think uses the type of product you're designing. Think=20
about the different environments, tools, and constraints that your users=20
deal with. If possible, visit actual workplaces and study how people do=20
their jobs.
Analyze the steps necessary to complete each task you anticipate people=20
wanting to accomplish with your product. Look at how they perform=20
similar tasks without a computer. Then design your product to facilitate=20
those tasks. Don't replicate each step on the computer; your application=20
should make the whole process /easier/.
Throughout the design process, use people who fit your audience=20
description to test your prototypes. Listen to their feedback and try to=20
address their concerns. Develop your product with people and their=20
capabilities--not computers and their capabilities--in mind.
Text Display and Text Editing
Writing systems differ in the direction in which their characters and=20
lines flow, the size of the character set used, and whether certain=20
characters are context dependent. Mac OS 9 and earlier relied on=20
WorldScript and the Script Manager, which used a different character set=20
for each script system. Mac OS X supports Unicode, a single character=20
set for most writing systems in the world. Unicode is a cross-platform,=20
international standard for character encoding.
Text handling for Cocoa is entirely based on Unicode. For Carbon=20
developers, there is a new set of functions for manipulating Unicode=20
text. For more information about localization tools, fonts, and=20
international technologies, go to http://developer.apple.com/intl.
No matter what level of worldwide text support you provide, it's=20
important to avoid these common assumptions:
* Text isn't always left-aligned and read from left to right.
* Text isn't always read by a person; it might be spoken through a
text-to-speech converter.
* System and application fonts may change.
Layout Guidelines
This chapter provides basic suggestions for arranging controls in=20
dialogs and windows. These guidelines use many of the default control=20
sizes defined in Interface Builder; any exceptions are noted. To=20
simplify the process of resizing and repositioning existing dialogs and=20
windows, most values are based on a multiple of 2 pixels. All=20
user-visible text should use the standard fonts described in "Fonts"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGFonts/chapter_10_section_1.html#//apple_ref/doc/uid/20000966/TP6>.
The Control Manager (Carbon) and Application Kit (Cocoa) include smaller=20
versions of the most commonly used controls, for use in utility windows=20
when necessary. For utility window layout information, see "Using Small=20
Versions of Controls"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGLayout/chapter_8_section_5.html#//apple_ref/doc/uid/20000964/BGBBJHDI>=
.
Positioning Controls in Dialogs and Windows
Keep these guidelines in mind when designing dialogs and windows:
* In general, try for a more centered approach to dialog layout, as
opposed to the strongly left-biased approach of the traditional
Mac OS 9 dialog. Most of the sample layouts in this document
illustrate the center-biased approach.
* All spacing between dialog elements involves a multiple of 2
pixels--2, 4, 6, 8, and so on.
* Maintain a 20-pixel space between the left and right edge of the
window and any controls. Keep 20 pixels of space between the
bottom edge and any controls; this can include the shadow of any
push buttons in that area. Top spacing is determined by which
controls are placed closest to the top of the dialog. For example,
Figure 8-6
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGLayout/chapter_8_section_4.html#//apple_ref/doc/uid/20000964/BGB=
CEDJE>
uses a radio button as the topmost control, so the spacing is set
to 14 pixels. In contrast, Figure 8-7
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGLayout/chapter_8_section_4.html#//apple_ref/doc/uid/20000964/BIA=
FHIIG>
uses a tab control as the topmost element, so the spacing is set
to 12 pixels.
* For dialogs that contain a mix of controls, set 16 pixels of
vertical space between groups of controls. Vertical spacing
between controls is determined by the tallest control in the row.
* Groups of controls should be separated by 20 pixels of vertical
spacing and subgroups of controls within groups should be
separated by 16 pixels.
* The default button for dismissing a dialog should go in the
lower-right corner. If there's a Cancel button, it should be to
the left of the default button.
If there's a third button for dismissing the dialog, it should go
to the left of the Cancel button. If the third button could result
in data loss--Don't Save, for example--position it at least 12
pixels away from the "safe" buttons (Cancel and Save, for example).
A button that affects the contents of the dialog itself, such as
Reset, should have its left edge aligned with the main dialog text
or 12 pixels to the right of the help button (if there is one).
*Figure 8-1 Position of buttons at the bottom of a dialog*
* The minimum screen resolution a dialog needs to accommodate is 800
by 600. (Support for 640 by 480 is provided for games.)
* For most document windows that contain a single view (scrolling
text or tables, for example), do not specify any space between the
window edge and scroll bars (when using the Control Manager) or
the frame of the view (in Interface Builder).
Group Boxes
A *group box* is used to associate a set of related items--such as radio=20
buttons or pop-up menus--in a dialog.
As much as possible, /use additional space between controls to create=20
groups of controls, rather than group boxes./ Excessive use of group=20
boxes creates visual clutter; too many lines and edges can distract=20
users. Also use space or separator lines, rather than secondary group=20
boxes, for subgroupings. The following figures show examples of how to=20
successfully re-create dialogs using space rather than group boxes. When=20
space alone isn't enough to clearly divide areas, use a label and a=20
separator, as shown in the following "after" examples.
Within a group box, no control or label should be positioned within 16=20
pixels of the box's top, bottom, left, or right borders.
Group boxes can be untitled or titled. Titles can be static text, a=20
checkbox label, or text in a pop-up menu.
*Figure 8-2 Dialog redesigned without group boxes (first example)*
In the second "after" example, the group boxes have been replaced by=20
horizontal lines that serve as separators; the lines are 2 pixels to the=20
right of the label and base-aligned with the label text. Although the=20
overall look of the dialog is centered, the two labels, as well as the=20
lines, are right-aligned; flush-left controls would imply an=20
inappropriate hierarchy. The distance from the left edge of the pane to=20
the label text and from the end of the line to the right edge of the=20
pane should be equal.
*Figure 8-3 Dialog redesigned without group boxes (second example)*
In the "after" example, the labels are left-aligned, since they are next=20
to checkboxes, which are most commonly stacked vertically.
*Figure 8-4 Dialog redesigned without a group box (third example)]*
Sample Dialog Layouts
This section contains sample layouts illustrating how to position=20
various types of controls. Unless specified otherwise, all measurements=20
are in pixels.
*Figure 8-5 A standard alert with dimensions*
*Figure 8-6 Sample application preferences dialog*
*Figure 8-7 Sample dialogs with panes*
*Figure 8-8 Sample dialog with scrolling list*
Checklist
* Do you use standard Aqua controls provided by the system, instead
of inventing custom ones? Do you avoid assigning new behaviors to
existing interface elements?
* Does the application have the Mac OS X "feel," including window
minimization, live scrolling, live window dragging, and sheets?
* If a metaphor is being used, is it suitable for the application?
Does the metaphor match a "real" visual and behavioral representati=
on?
* Is the user always able to find an object or action on the screen?
In other words, does your interface follow the see-and-point
principle of design?
* Do document printouts exactly replicate what the user sees on the
screen? Do movies, sounds, and other types of data reproduce
faithfully regardless of what medium they're in? In other words,
is the application WYSIWYG?
* Is your application forgiving and explorable by supporting Undo?
Are there warnings about risky actions? Are users allowed to back
away gracefully from risky territory?
* If an operation can be interrupted, do you provide a Cancel or
Stop button? Can Escape or Command-period be used to cancel or
stop these operations?
* Does the application feel stable?
* Do you respect all of the accessibility features in Mac OS X, such
as keyboard navigation and focus?
* Have you made a clear, consistent distinction between basic and
advanced features?
* If your application has modes, is there a clear visual indication
of the current mode? Does the visual indication of the mode appear
near the object most affected by the mode? Are there enough
landmarks to remind the user what area of the application he or
she is in? For example, many graphics applications change the
pointer to an eraser in erase mode.
* Is each mode absolutely necessary? Do the modes within the
application properly track the user's own modes? Do users
consistently avoid the kind of errors caused by the program being
in a mode other than what the user wants or expects? Making a mode
visually apparent is no guarantee that the user will track it:
Test the application on users and find out what sorts of mistakes
they are making. If the errors are caused by modes, find ways to
communicate the modes more clearly, or eliminate them.
* Can the user save a document or quit an application at any time?
* Are the widest possible range of user activities available at any
time? The user should spend most of his or her time being able to
interact with the application--not waiting for it to complete a
process.
* Does your application always use the file's display name when the
filename is visible to users, except in expanded help tags?
* Is your application speech-enabled?
* Has all user-visible text been reviewed by a professional writer?
* Does all user-visible text use "curly" apostrophes and quotation
marks rather than straight ones (except for measurements or in
code examples)?
* Do windows, dialogs, and palettes look "clean" and free from clutte=
r?
* Does the user have control over the design of the workspace
(location and sizing of windows, toolbar customization), allowing
him or her to individualize it?
* Is the information in windows organized so the most important
information can be read first?
* Do you use white space and graphics to break up long pieces of text=
?
* Are the application, File, Edit, and Window menus present, with at
least the standard items?
* Does the application support Undo, Cut, Copy, and Paste, and are
these items in the Edit menu?
* Does your application menu contain About, Preferences, Hide, and Qu=
it?
* Do the unique menus of the application have appropriate names? Are
the names sufficiently different from the standard system menu
names? Can the user understand and remember their meaning?
* Are frequently used menu items available at the top level rather
than in a submenu or a dialog? If not, can the user change their
location?
* Are currently unavailable items dimmed (rather than being
omitted)? Are dimmed items unselectable? If all items in a menu
are unavailable, is the menu title dimmed? Can the user still pull
down the menu and see the dimmed names of the operations?
* Are toggled menu items unambiguously named?
* Are menu titles and items in caps/lowercase unless there is a
compelling reason to have a different style, such as an ALL CAPS
item in a Style menu?
* Do menu items have an ellipsis character (...) if more information
is required from the user before completing the command?
* Are the menu items truly menu items? Menu items should not be used
as text, section titles, or status indicators.
* In a hierarchical menu, does the title of the submenu have a
right-pointing triangle? Are submenus used only for lists of
related items?
* Can the user see all the commands, items, and submenu titles in a
menu without scrolling? Scrolling should be necessary only for
menus that users have added to or for menus that spill over
because the user has selected a large system font.
* Is the standard state of a window best suited to working on the
document (such as no wider than the page width), and not
necessarily as large as the full screen?
* Does your application sensibly open new windows in either the
standard or the user state?
* Can each resizable window be made as large as the smaller of
either the maximum document size or the maximum size of the
displays, including multiple monitor displays?
* Is the default position of a window contained on a single screen?
* Is each additional window opened below and to the right of its
predecessor?
* If a user drags a window from one monitor to another monitor, does
your application open subsequent windows on the second monitor?
* Do you use the lowercase letters "untitled," without additional
punctuation, in a new window title? Do you add a number to the
second and subsequent new windows, but not to the first? Do you
avoid using blank titles?
* Do document titles display or hide filename extensions appropriatel=
y?
* Do document windows with unsaved changes display a dot in the
close button?
* Before closing a window, do you check to see if the user has
changed its size or position? Do you save window positions, and
then reopen windows in the size and position in which the user
left them?
* Before reopening a window, do you make sure that the size and
position are reasonable for the user's current monitor or
monitors, which may not be the same as the monitor on which the
document was last open?
* When zooming from the user state to the standard state, do you
check if the size of the standard state would fit completely on
the screen without moving the upper-left corner? If so, is the
upper-left corner anchored? If not, is the window moved to an
appropriate default location?
* Do you appropriately display controls and selected items in
inactive windows?
* Does pressing the Tab key cycle through the available elements?
Does Shift-Tab cycle in the reverse direction?
* When appropriate, are buttons named with a verb that describes the
action that it performs, such as Erase, rather than OK?
* Do you provide a Cancel button wherever possible, especially in
progress dialogs? Does pressing Escape or Command-period indicate
Cancel? (Pressing Escape should never cause the user to lose
information.)
* If an operation can be halted midstream, with possible side
effects, is the button named Stop instead of Cancel?
* Do the Return and Enter keys map to the default button, which is
usually the button with the safest result or the most likely respon=
se?
* Do default buttons have color and pulse?
* Are buttons wide enough to accommodate their text names?
* Are buttons placed in functional and consistent locations, both
within your application and across all applications that you
develop? Is the action button placed in the lower-right corner
with the Cancel button to its left or above (for Western readers)?
* Are hidden filename extensions supported? Does the application
display a file's display name instead of its filename, and does
the Save dialog support filename extension hiding?
* Do Save dialogs place a default name in the Save As text field,
and is the name (but not its filename extension) selected?
* When a dialog refers to a document or an application, do you use
the name of the document or application in the message text?
* Has room been left to allow the dialog to grow during
localization? Most languages require more characters than English
to convey equivalent messages.
* Are the bounding rectangles of interface elements (for example,
radio buttons and checkboxes) the same size? When the alignment of
dialog elements is reversed, they should align on the opposite side=
.
* Does the application always provide some indication that an
activity is being carried out in response to a command?
* Does the application provide suitable feedback during task
processing? Does it somehow indicate the completion of a task?
Does it provide information about the duration of the task?
* Is an explanation offered if a particular action cannot be carried
out? Are alternatives offered?
* Do you make all changes clearly visible?
* Do you call the system alert sound when you want the user's
attention? Do you provide all feedback in visual as well as
auditory formats?
* Do you use the new standard alert functions for displaying alerts?
* Do you display your application icon in all dialogs? Do you also
show the caution icon in potentially data-damaging alerts?
* Does the alert have an informative title and text that not only
tell the user what is wrong, but also offer suggestions as to what
to do to correct it? The best alert messages answer the following
questions: What happened? Why did it happen? What can I do about it=
?
* Are all your alerts necessary? You can prevent many user errors
with good or preventative interface design. For example, if the
application cannot handle an 80-character filename, don't display
an 80-character field in which to enter it.
* If the user initiates an action by pressing the mouse button, does
the action take place only when the button is released (except for
drags)?
* Are there ways other than double-clicking to perform a given
action? Double-clicking should never be the only way to do
something; it should be a shortcut only.
* Can arrow keys be used in all text boxes (including in dialogs)?
Can the Shift key be used with the arrow keys to extend the
selection (including in dialogs)?
* If text is selected, does pressing an arrow key cause the
insertion point to go to the corresponding end of the range and
deselect it?
* Are discontinuous selections made with the Command key modifier
(for lists and arrays)? The Shift key is used for graphics
selections and continuous text extensions.
* Do you use Command-arrow key and Option-arrow key for moving the
insertion point in larger semantic units? (Note that when multiple
script systems are available, Command-Left Arrow and Command-Right
Arrow are intercepted by the system and used for changing the
keyboard layout.)
* Does the active font size in a menu have a checkmark next to it?
* Do you avoid making assumptions about font sizes? For example, the
system font may have a different size in other countries.
* Do your icons represent objects that users are familiar with and
that are universally recognizable?
* Do you use a common theme for icons associated with your applicatio=
n?
* Is the instructional suite written for the right audience?
* Do you provide HTML help viewable in Help Viewer and a Help
command in the Help menu?
* Does your documentation focus on real-world user tasks and
troubleshooting?
* When appropriate, do your dialogs have help buttons that open
relevant help text?
|
