Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
From 2009-08-20 OSXHIGuidelines

## The Always-On Environment


---
## Human Interface Design Principles

(from P39 to P47)

### Metaphors

### Reflect the User's Mental Model

* Familiarity
* Simplicity: thinking about the typical streamline of a task.
* Availability: avoid hiding key features and settings too deeply in submenus or making them accessible only from a contextual menu (which is not always able to be triggered)
 People should be able to find all the available features in your application. Don’t hide features by failing to make commands available in a menu. Menus present lists of commands so that people can see their choices rather than try to remember command names. Avoid providing accessto features only in toolbars or contextual menus. Because toolbars and contextual menus may be hidden, the commands they contain should always be available in menu bar menus as well.
* Discoverability: Encourage users to discover functionality by providing cues.  If an element is clickable, for example, it must appear that way. Avoid making controls invisible to inexperienced users.


### Explicit and Implied Actions
For implied actions to be apparent, the user must be able to recognize the objects involved, the manipulation to be performed, and the consequences of the action.

### Direct Manipulation

### User Control

Some applications attempt to assist the user by offering only those alternatives deemed good for the user or by protecting the user from having to make detailed decisions. (Windows is a very bad example)

The key is to provide users with the capabilities they need while helping them avoid dangerous, irreversible
actions. For example, in situations where the user might destroy data accidentally, you should always provide
a warning, but allow the user to proceed if they choose.


### Feedback and Communication

* 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.


### Consistency

* Name consistency
* Graphic consistency: Do icons mean the same thing every time they are used?


### WYSIWYG (What You See Is What You Get)
Use a preview function if necessary.

### Forgiveness

* 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.
* 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
Wiki

User Tools

Site Tools

Page Tools
