macosx_human_interface
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
macosx_human_interface [2019/02/20 14:48] 203.9.78.18 |
macosx_human_interface [2019/02/26 07:51] (current) admin |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | From 2009-08-20 OSXHIGuidelines | ||
| + | |||
| ## The Always-On Environment | ## The Always-On Environment | ||
| + | |||
| + | --- | ||
| ## Human Interface Design Principles | ## Human Interface Design Principles | ||
| - | (from P39 to P) | + | (from P39 to P47) |
| ### Metaphors | ### Metaphors | ||
| Line 32: | Line 36: | ||
| ### Feedback and Communication | ### Feedback and Communication | ||
| - | Users want to know that a command is being carried out | + | * Users want to know that a command is being carried out. |
| + | |||
| + | * When a user initiates an action, always provide an indication that your application has received the user’s input and is operating on it (usually, use animation). Users want to know that a command is being carried out. If a command can’t be carried out, they want to know why it can’t and what can be done instead. | ||
| + | |||
| + | * Use animation to emphasize the relationship between elements. | ||
| + | |||
| + | * Use progress indicator to provide useful inormation during lenghy operations. | ||
| Line 48: | Line 58: | ||
| * making most actions easily reversible. (People need to feel that they can try things without damaging the system or jeopardizing their data. Create safety nets,such as the Undo and Revert to Saved commands) | * making most actions easily reversible. (People need to feel that they can try things without damaging the system or jeopardizing their data. Create safety nets,such as the Undo and Revert to Saved commands) | ||
| * Warn users when they initiate a task that will cause irreversible loss of data. If alerts appear frequently, however, it may mean that the product has some design flaws. When options are presented clearly and feedback is timely, using an application should be relatively error-free. | * Warn users when they initiate a task that will cause irreversible loss of data. If alerts appear frequently, however, it may mean that the product has some design flaws. When options are presented clearly and feedback is timely, using an application should be relatively error-free. | ||
| + | * Provide extensive feedback and communication at every stage so users feel that they have enough information to make the right choices. | ||
| + | |||
| + | ### Perceived Stability | ||
| + | |||
| + | * When a menu command doesn’t apply to a selected object or to the object in its current state, the command is dimmed rather than omitted. | ||
| + | * When a user sets up his or her onscreen environment to have a certain layout, the settings should stay that way until the user changes them. | ||
| + | * Providing status and feedback. (It also contributes to perceived stability by letting users know that the application is performing the specified task.) | ||
| + | * The preferences should be remembered. | ||
| + | |||
| + | ### Aesthetic Integrity | ||
| + | |||
| + | * Keep graphics simple, and use them only when they truly enhance usability | ||
| + | * The font size and type should be consistent within a window | ||
| + | * Control button size should be consistent. | ||
| + | |||
| + | ### Modelessness | ||
| + | |||
| + | * As much as possible, allow users to do whatever they want at all times. Avoid using modes that lock them into one operation and prevent them from working on anything else until that operation is completed. | ||
| + | * If an application uses modes, must be a clear visual indicator and should be | ||
| + | very easy for users to get into and out of. | ||
| + | * Most acceptable uses of modes fall into one of the following categories: | ||
| + | |||
| + | * Selection | ||
| + | * Alerts | ||
| + | * Tools (highlight, eraser, etc.) | ||
| + | |||
| + | --- | ||
| + | ## Preferences | ||
| + | |||
| + | (P75) | ||
| + | |||
| + | The purpose of preference is to reduce the complexity of the user interface by giving users the ability to customize what they see on the display screen and, to some extent, how the application performs. | ||
| + | |||
| + | A preference should be a setting that the user changes infrequently. If a user might change the attributes of a feature many times in a work session, use a menu item instead of preference. | ||
| + | |||
| + | |||
| + | |||
| + | --- | ||
| + | ## Dialog and Alert | ||
| + | |||
| + | (From P235 to P254) | ||
| + | |||
| + | ### Dialog | ||
| + | |||
| + | * A dialog appears to input information (search text) or choose object (save, open, etc). | ||
| + | * LS: dialog is used for a specific action, but not on global changes. | ||
| + | |||
| + | ### Alert | ||
| + | |||
| + | * An Alert appears asking user which action to take. | ||
| + | {{::alert_example.jpg?nolink&400|}} | ||
| + | |||
| + | --- | ||
| + | ## Naming of menu items | ||
macosx_human_interface.1550645322.txt.gz · Last modified: 2019/02/20 14:48 by 203.9.78.18