User Experience Guidelines

The OS X user experience is streamlined, powerful, and elegant. To ensure that your app feels at home in OS X, keep the following guidelines in mind.

Avoid Burdening Users with App-Management Tasks

It’s worth emphasizing an obvious fact: Users view your app differently than you do. Nowhere is this difference more striking than in the performance of common app-management tasks, such as finding and opening documents, opening and closing windows, and managing document state. Although there are many ways that apps can make such tasks easier for users to perform, a more important question is, Why should users have to perform them at all?

Take this opportunity to step back and reconsider the division of labor between users and apps. For example, if your app is a single-window app that does not perform background tasks, do users really need to explicitly quit your app after they close the window? In fact, should users care whether your app is currently running if its window is either closed or on a different desktop? In OS X, users can turn off the open-app indicator lights in the Dock so that when they click a Dock icon, they don’t need to know whether the app is starting or simply bringing an open window into view. When this experience is combined with Resume, users don’t need to differentiate between the app opening experience and the window opening experience.

Changes in how users view the state and location of their content should prompt you to begin thinking about how your app presents the tasks that are related to these concepts. As you consider these issues, you should also follow the guidelines in this section to ensure that your app provides an experience that users appreciate.

As much as possible, restore the user’s previous state. Users should not have to remember which windows were open (and which were full screen) when they log in or start their computer. For the best user experience, opt into the Resume feature so that users can pick up where they left off in your app. To learn more about how to take to take advantage of Resume in your app, see “Resume” in Mac Technology Overview.

Support Auto Save and Versions, if appropriate. Users expect their content to be saved continuously and mostly without their intervention. If users can create documents in your app, be sure to opt in to Auto Save so that they can rely on these behaviors in your app. (To learn more about how these technologies should work in your app, see “Auto Save and Versions.”)

Consider using iCloud storage to help users access their content on all of their devices. For some tips on how to provide a great iCloud experience in your app, see “iCloud Storage.”

Decide whether users need to explicitly quit your app. In particular, if your app displays only a single window it's often appropriate to quit automatically when users close the window.

Avoid calling attention to file formats. It’s best when users don’t have to think about file formats (recall that users can turn off the display of filename extensions in Finder preferences). In addition, users tend to expect to be able to open other documents in your app and to share with others the documents they create in your app. Be sure to include a filename extension appropriate to the contents of the document. At the same time, take care to respect the user's filename extension preferences when displaying the names of files and documents within your app.

Focus on Solutions, Not Features

When people use your app, they do so with a goal in mind; people rarely use an app for the sole purpose of exploring its features. To help ensure that your app enables people to achieve their goal in the most efficient, easiest way possible, see to it that every feature is tightly integrated with the solution you provide.

Avoid feature cascade. It can be very tempting to add features that aren’t wholly relevant to the main focus of your app, but doing so can lead to a bloated interface that is slow, complex, and difficult to use. Always ask yourself if a proposed feature directly supports the user’s goal, and if it doesn’t, leave it out.

Heed the 80-20 rule. The 80-20 rule states that roughly 80% of users use only a handful of an app’s features, while only about 20% of users might use most or all of the features. Thinking of your user audience in this way encourages you to emphasize the features that enable the main task and helps you identify the features that power users are more likely to appreciate.

Embrace Modelessness

Users appreciate apps that allow them to be in control and they generally dislike apps that wrest control away from them too often. One of the most common ways that apps take control away from users is by overusing modes that require users to follow a specific path.

Occasionally, modality is unavoidable, such as when a serious condition arises that jeopardizes the user’s data or when the user initiates a task that must be completed before they can continue interacting with the app or their content. It’s also reasonable to use a mode that emulates a familiar real-life situation that is itself modal. For example, choosing different tools in a graphics app resembles the real-life choice of physical drawing tools. And sometimes, providing a mode is an effective way to help the user focus on a task and avoid distractions. (Note that a full-screen window is a type of modal experience, but it is one that remains active when users switch away from it.) As you design the user experience of your app, follow the guidelines in this section so that users don’t feel constrained by modality.

Think carefully about an app design that requires users to enter modes frequently. In general, you don’t want users to experience your app as a series of disjointed tasks. You also want to avoid chopping up the user’s workflow by requiring too-frequent transitions into and out of modes. As much as possible, reserve modes for small, self-contained tasks that users are likely to want to finish all at once.

Balance modelessness with the need for a distraction-free experience. Sometimes, users appreciate an isolated, self-contained environment in which to accomplish a task. Your challenge is to provide a mode that’s both discrete and full-featured. Users don't appreciate finding that they need to exit a mode to get information (or perform a subtask) that’s required to accomplish the modal task. As much as possible, allow users to perform tasks in a way that integrates with the rest of your app’s functionality, and use a mode only when it provides value.

Clearly indicate the current mode. If users can enter different modes in your app, make it easy for them to tell at a glance which mode they’re in. For example, a graphics app might use different pointer styles to indicate whether the user is currently in drawing, erasing, or selection mode. A segmented control can also show which mode the user is in; for example the View segmented control in the Finder toolbar indicates whether users are in icon, list, column, or Cover Flow view. And a popover offers a very strong visual indication of a self-contained task. (To learn more about using a popover in your app, see “Popovers.”)

Make modes easy to leave. Users should not feel that they’re trapped in a mode or that it takes effort to leave it. For example, you can enable a transient mode by using a popover, which can close automatically when users click outside of it. Be sure to save the user’s work, in case they leave a mode without meaning to.

Make Your App Easy to Use

An easy-to-use app offers a well-designed, intuitive interface that supports elegant solutions to complex problems. In addition, easy-to-use apps give users tools that are relevant in the current context, eliminating or disabling irrelevant tools.

When appropriate, use metaphors that represent concrete, familiar ideas. Appropriate metaphors allow people to apply their existing knowledge and experience to the usage of your app. (To learn more about the principle of metaphors, see “Metaphors.”) For example, OS X uses the familiar metaphor of a file folder to represent a container for storing documents. Be sure to use metaphors that fit the tasks in your app: If you have to distort a metaphor to make it apply to a task, you’re more likely to confuse people than to help them.

Make sure your app description clearly states what users need in order to use your app. This applies to any packaging you supply, too. Users need to know your app’s system requirements before they install it, so that they can begin using it right away. For example, the App Store description for Garage Band mentions operating system and processor requirements, among other things.

../art/ue_apprequirements.jpg

Use progressive disclosure to present the most common choices first. The technique of progressive disclosure consists of hiding additional information or more complex UI until the user needs or requests it. Using progressive disclosure can improve your app in two ways: It helps novice users understand your app without being overwhelmed with information or features they don’t need, while at the same time giving more experienced users access to the advanced features they want.

When appropriate, use panels to simplify the UI. An uncluttered user interface is essential, but the availability of certain key features and settings the user needs is equally so. A panel can be a good way to offer frequently needed controls and options that affect the current document or selection. For example, Keynote offers an inspector panel that gives users a convenient way to adjust objects in a slide.

../art/ue_inspectorpanel.jpg

Because panels remain open until users close them, it’s important to weigh their utility against the screen space they take up. To learn more about using panels in your app, see “Panels.”

As much as possible, arrange menus so that they reflect the hierarchy of objects in your app. For example, if your app helps users create computer animation, the app-specific menus might be Scenes, Characters, Backgrounds, and Projects. Because a user probably sees the project as a high-level entity that contains scenes, each of which contains backgrounds and characters, a natural ordering of these menus might be Projects, Scenes, Backgrounds, and Characters.

In general, place the menus that display commands to handle high-level, more universal objects toward one end of the menu bar and the menus that focus on the more specific entities toward the opposite end. When your app is used in countries that use left-to-right scripts, the high-level menus should appear on the left; in countries that use right-to-left scripts, the high-level menus should appear on the right. For more information about designing the menus in your app, see “UI Element Guidelines: Menus.”

Don’t use dynamic menu items merely to shorten app menus. A dynamic menu item (that is, a menu item that changes when the user presses a modifier key) can be a good way to provide a shortcut for sophisticated users, but it can be difficult for inexperienced users to discover. In general, it’s better to list all important commands in a menu, even if it makes the menu a bit longer.

Display an informative, actionable alert message when something goes wrong. An alert should clearly convey what happened, why it happened, and the options for proceeding. Describe a workaround if one is available and do whatever you can to prevent the user from losing any data. Avoid using an alert to deliver information that the user can’t act upon. For detailed guidelines on creating good alert messages, see “Alerts.”

Use display names in place of raw pathnames and filenames. In general, it does not help users to be exposed to the way apps handle files and data. It’s better to use the terms that users define for their content and to hide filesystem details unless users explicitly choose to see them. Be sure to pay attention to the user’s established language and filename extension preferences so that you can display their content as they expect.

Use Bonjour to automatically discover devices and network services on IP networks. Don’t make the user type in an IP address or configure a DNS server.

Allow Users to Go Full Screen (if Appropriate)

Full-screen windows make it easy for users to enter a distraction-free environment that helps them focus on a task. Follow the guidelines in this section to ensure that your app enables windows to go full screen when and how it’s appropriate. To learn more about how the full-screen window experience works in OS X, see “Full-Screen Windows Help Users Concentrate.”

Determine whether it makes sense for a window to go full screen. Full-screen windows help users to immerse themselves in a task, so they’re not as useful in apps that users don’t need to spend much time in, such as Contacts or Calculator. If your app enables brief utilitarian tasks, it probably doesn’t make sense to allow app windows to go full screen. In particular, if you’ve designed apps for iOS devices, don’t assume that your Mac app should automatically be full screen.

Bring into the full-screen window all the features users need to complete the task. Above all, you want to avoid forcing users to exit the full-screen window in order to complete the task. To help you avoid this situation, first evaluate why users might appreciate using your app in a full-screen window. For example, do they want a distraction-free way to consume media or a way to focus on performing a creative task? Then, identify all the tools required for the task and make them available within the full-screen window. If some of the tools are in an auxiliary window, be sure to designate this window as a full-screen auxiliary window, which means that it can be opened in the same space as the full-screen window (to do this, you specify the constant NSWindowCollectionBehaviorFullScreenAuxiliary). Or, consider making the tools available within the UI of the full-screen window instead of in an auxiliary window.

Show the toolbar if the full-screen task requires it. When a window goes full screen, it can display the toolbar or it can allow users to reveal the toolbar, along with the menu bar, by moving the pointer to the top edge of the screen. (A full-screen window never shows its title bar.) If the task that users want to accomplish relies on functionality that’s available in the toolbar, it makes sense to show it. For example, the full-screen Calendar window displays the toolbar because it contains controls that are essential to the task of viewing and managing the user’s schedule. On the other hand, a full-screen Preview window does not display the toolbar, because users are more likely to want to focus on reading the content, than on annotating or selecting it.

../art/fullscreenprieview.jpg

Avoid requiring users to interact with the Finder while they’re in a full-screen window. Opening a Finder window might cause the user to exit the full-screen window. Instead, provide other ways for users to bring content into the window, such as a source list or a customized Open dialog (to learn more about Open dialogs, see “The Open Dialog”).

Take advantage of the increased screen space, but don’t shift the focus away from the main task. In general, a window grows more in width than in height when users take it full screen. If appropriate, you can subtly adjust the proportions of the UI, so that the window fits better into the space and elevates the areas of the UI that are essential for performing the main task.

At the same time, don’t make the full screen version of your window so different from the standard version that users don’t recognize it. You want users to be able to stay focused on their task, even while they watch the window enlarge and perhaps alter a little in appearance. For example, the Photo Booth window gains decorative elements when it is full screen, but users never lose sight of themselves in the main viewing area. (Note that the red drapes that appear in full screen are also foreshadowed in the Photo Booth app icon, so users already associated them with the app.)

Don’t disable or override system-reserved gestures while a window is full screen. Even though your app is the current focus of the user’s attention, users should still be able to reveal Mission Control and move between other desktops and full-screen windows.

Respond appropriately when users switch away from your full-screen window. For example, a game should pause its action when users switch away from the full-screen experience so that they don’t miss important game events. Similarly, a slide show could pause when users switch away from it. In addition, be sure to let users decide when to take a window out of full screen. That is, don’t discontinue a full-screen window when users switch away from it.

In general, don’t prevent users from revealing the Dock. It’s important to preserve users’s access to the Dock even while they’re in a full-screen window, because they should always be able to open other apps and view stacks. An exception to this is in a game, in which the user might expect to be able to move the pointer to the bottom edge of the screen without revealing the Dock.

Handle Gestures Appropriately

A trackpad gives users another way to move the pointer and activate UI elements. OS X includes support for Multi-Touch gestures, which allow users to perform actions such as reveal Mission Control, switch to a different full-screen window or desktop, and return to the previous page in an app. Users expect to be able to use these familiar gestures throughout the system and the apps they download. Follow the guidelines in this section so that you can provide a great Multi-Touch gesture experience in your app.

Pay attention to the meaning of a gesture, not to the physical movements users make. In other words, instead of preparing to respond to a three-finger swipe, be prepared to respond to a "go to the previous page” gesture. Users can also change the physical movements that perform the system-supported actions, so your app should listen to the gesture the system reports.

As much as possible, respond to gestures in a way that’s consistent with other apps on the platform. For the most part, users expect gestures to work the same regardless of the app they’re currently using. For example, users should be able to use the “go back” gesture whether the app displays content in document pages, webpages, or images.

It’s especially important to avoid redefining the systemwide, inter-app gestures, such as reveal Mission Control and switch between desktops and spaces. (Note that users can change the precise gestures that perform these actions in Trackpad system preferences.) Even when users are playing a game that might use app-specific gestures in a custom way, they expect to be able to reveal Mission Control or switch to another desktop or full-screen window.

Handle gestures as responsively as possible. Gestures should heighten the user’s sense of direct manipulation and provide immediate, live feedback. To achieve this, aim to perform relatively inexpensive operations for the duration of the gesture.

Ensure that gestures apply to UI elements of the appropriate granularity. In general, gestures are most effective when they target a specific object or view in a window, because such views are usually the focus of the user’s attention. Start by identifying the most specific object or view the user is likely to manipulate and make it the target of a gesture. Make a higher level or containing object a gesture target only if it makes sense in your app.

OS X 10.8 supports a smart zoom gesture (that is, a two-finger double-tap on a trackpad). By providing a semantic layout of your content, NSScrollView can intelligently magnify the content that the user is most likely interested in. See NSScrollView Class Reference for more information.

Define custom gestures cautiously. A custom gesture can be difficult for users to discover and remember. And, if a custom gesture seems gratuitous or awkward to perform, users are likely to avoid using it. If you feel you must define a custom gesture, be sure to make it easy to perform and not too similar to the gestures users already know.

Avoid relying on the availability of a specific gesture as the only way to perform an action. You can’t be sure that all your users have a trackpad or want to use it. In addition, trackpad users can disable some gestures, or change their meaning, in Trackpad preferences.

Captivate with Gorgeous Graphics

High-quality graphics not only improve the appearance of your app, they also help convey information to users and enhance the overall experience of your app. OS X users are accustomed to beautiful, meaningful graphics and they look for the same level of quality in the apps they use.

Make sure your graphics look professionally designed. Don’t underestimate the impact that beautiful, high-quality graphics have on your users. More than ever, people see gorgeous, professionally produced graphics all around them, and most people can readily discern differences in quality. Low-quality graphics give people a bad impression and can negatively affect their perception an app’s overall quality. To help ensure that users are delighted with your app, make graphics a priority in your design and development process.

Make sure your graphics look great in full screen. If you allow users to take a window full screen, make sure you don’t just scale up your graphics to fit. As a rule of thumb, always start with artwork that is larger than you need and then scale it down. (For some guidelines on scaling artwork, see “Creating Great Icons for Any Resolution.”)

When appropriate, consider adding the appearance of real-world materials. In some cases, real-world textures, such as wood, leather, metal, or paper, can enhance the experience of an app and convey meaning to users. If this makes sense in your app, make sure that the texture you create:

For more guidelines related to using real-world appearances in your UI, see “Consider Adding Physicality and Realism.”

Make a great first impression with a beautiful app icon. Your app icon is the first experience users have with your app, and it can have a marked effect on their expectations. Think of your app icon as your calling card, and spend the resources necessary to ensure that it makes the right impression on users. For example, the Garage Band app icon is a beautiful rendering of a guitar.

../art/ue_greatappicon.jpg

For some specific guidance on creating a great app icon, see “Icon Design Guidelines.”

If they are needed, create control icons that are unambiguously expressive. OS X provides many built-in icons that apps can use in controls to represent standard actions, such as unlock an object or stop the current process. As much as possible, you should use the standard icons in your app because users already know what they mean (to learn more about the built-in icons, see “System-Provided Icons”). If you need to represent an action for which there is no standard icon, you must create a custom icon that clearly conveys its meaning to users. For detailed guidance on creating custom icons, see “Designing Toolbar Icons.”

Prepare for high resolution. In version 10.7, OS X extended its support for high resolution. To take advantage of this, you should adapt your app by using the appropriate APIs and provide higher-resolution versions of your artwork, among other things. To learn more about supporting high resolution in your app, see High Resolution Guidelines for OS X; for some guidance on scaling custom artwork, see “Creating Great Icons for Any Resolution.”

Be Responsive

Responsiveness is how users measure the performance of your software. Your app might use the best data-processing algorithms and performance-boosting techniques available, but if it does not instantly respond to the user, it will seem slow. During app development, pay attention to both the factors that influence the user’s perceptions and the actual, measurable performance metrics that your app generates.

Instantly acknowledge the user’s commands and input. Users expect to receive some type of feedback every time they interact with your app (for more on the principle of feedback, see “Feedback and Communication”). For example, buttons highlight when users click them and the pointer changes appropriately as users move it over different controls and areas. Similarly, if a command can’t be carried out, users want to know why it can’t and what they can do instead. The quicker you provide feedback for the user’s interactions, the more responsive your app appears.

Don’t wait until a long task completes before you display any results to users. If you display nothing until you have all the results, users might interpret this as sluggishness. Instead, display partial results as soon as possible after users initiate a long task so that they have something useful to view while the rest of the task completes.

Use a progress indicator to help users gauge how long a process will take to complete. Users don’t always need to know precisely how long a task will take, but it’s important to give them an estimate. For example, the Finder combines a progress indicator with optional explanatory text to show users about how long a copy operation will take.

../art/ue_progressindicated.jpg

To learn about the types of progress indicators you can use, see “Progress Indicators.”

Follow performance best practices. For example, avoid polling for information or events, load resources lazily, minimize drive accesses, and eliminate unnecessary I/O operations. To learn how to develop a performant Mac app, start by reading Performance Overview.

Use metrics and tools to tune the performance of your app throughout development. Be sure to use metrics, not assumptions, to quantify the performance of your app before you begin trying to improve it. For example, you can use Instruments (which is part of Xcode) to help you identify and address performance issues in your code. To learn more about Instruments, see Instruments User Guide.

Give Users Alternate Ways to Accomplish Tasks

Different people interact with apps in different ways, depending on personal preference and circumstance. Because you can’t predict exactly how users will use your app, it’s a good idea to offer a few different ways to perform each task.

Support accessibility. All apps should be accessible to people with disabilities and those who might use assistive devices to interact with their computer. As much as possible, make sure that every action users can take in your app can also be taken using VoiceOver or an assistive device. For more guidelines related to accessibility concerns, see “Reach as Many Users as Possible.”

Make app commands available in menus. The menu bar is the first place people tend to look for commands, especially when they’re new to an app. It’s a good idea to list all important commands in the appropriate app menus so that people can find them easily. It can be appropriate to omit infrequently used or power-user commands from your app’s menus (instead making them available in a contextual menu, for example), but you should be wary of doing this too often. Even experienced users can fail to find commands that are essentially hidden in this way. To learn more about providing menus in your app, see “UI Element Guidelines: Menus.”

Provide keyboard-only alternatives. Many people prefer using a keyboard to using a mouse or a trackpad. Others, such as VoiceOver users, need to use the keyboard. There are two main ways to support keyboard users:

Use Standard UI Elements Correctly

OS X provides a wide range of built-in UI elements, such as controls, menus, and dialogs. Using these elements in your app confers several important benefits:

To realize these benefits, it’s crucial that you use the built-in elements correctly. Follow these guidelines as you use Aqua UI elements in your app.

Don't assign new behaviors to built-in UI elements. It’s essential to use the system-provided elements according to the guidelines in this document. If you misuse standard elements, you make your UI unpredictable and hard for users to figure out.

In general, don’t create a custom UI element to replicate the behavior of a built-in element. Unless you’re designing a game or other completely custom experience, it’s not appropriate to replace familiar elements with custom ones. This is because when users see a custom control, they generally expect it to behave in a custom way. Outside of a game-like context, a custom control that behaves the same as a built-in control causes users to wonder why the control isn’t standard.

If you really need a new behavior, design a new element for it. Don’t try to stretch the behavior of an existing UI element. For some tips on how to create a custom UI element, see “Be Cautious When Extending the Interface.”

Help Users Be Productive Immediately

Users expect to be able to benefit from your app as soon as they install it. Meet this expectation by following these guidelines.

Don’t ask users to restart. After installation, your app should be ready for immediate use. If your app relies on a restart to work correctly, you should rethink its design.

Avoid requiring users to supply a lot of setup information before they can do anything else. Instead, let users get started right away and defer asking for setup or configuration information until it’s actually needed. Get as much information as possible from other sources, such as system preferences or Contacts, so that you can avoid asking users for information they’ve already supplied. When you must ask users for information, try to give users something in return for each piece of information they provide.

Establish intelligent default settings. Determine how most users are likely to use your app and set the default configuration accordingly. When you gauge the needs of your user audience accurately, it’s rarely necessary for users to adjust the default settings in your app’s preferences.

Make sure the functionality in your app is easily discoverable. When the usage of your app is obvious, users feel empowered and they can be successful right away. Although you should make help content available in case users need it, users should not feel that they must read a manual before they can begin using your app. (For guidelines on how to provide good help content, see “User Assistance.”)

Clarify and Communicate with Subtle Animation

Animation can be one of the best ways to provide feedback and to clarify the results of the user’s actions. For example, users understand exactly what the Duplicate command does because they can watch the document copy spring from the original.

../art/animation_example.jpg

Typically, animation is also one of the easiest parts of UI design to get wrong. Use the following guidelines to help you enhance your app with polished, useful animation.

Avoid gratuitous animation. Animation that serves no purpose or is illogical quickly becomes tiresome and irritating to users. Be sure that the animation you add enhances the user’s understanding of your app’s functionality.

In general, avoid using animation as the focus of the user experience. Unless you’re developing a game in which animation plays a major role, you should use animation to subtly enhance the user experience. If you place too much focus on animation in your app, users are likely to become distracted from their task. The best animation helps users understand what’s going on, without drawing attention to itself.

Use animation to clarify the consequences of user actions. Showing users the results of an action before they commit to it helps them be sure of themselves and avoid mistakes. For example, items in the Dock move aside when users drag an object into the Dock area, showing where the new object will reside when they drop it.

Animate a window's transition to and from full screen. It’s a good idea to supply a smooth, high-quality animation to replace the default transition. Creating a custom animation is especially important if your window contains custom elements that might not be able to participate in the default transition. For example, if you display a secondary bar below the toolbar (such as a “favorites” bar), you need to make sure that this bar transitions along with the toolbar when the window goes full screen.

Use animation to enhance realism. If you create custom elements that look like real, physical objects, be sure to animate their movements so that they respond realistically, too. For example, if the user can spin an object in the UI, a large or heavy object should appear to slow down quicker than a small or lightweight object. For more guidelines related to adding realism to your UI, see “Consider Adding Physicality and Realism.”

Use animation when an object changes its properties. Showing an object’s transition from one state to another, instead of showing only the beginning and ending states, helps users understand what’s happening and gives them a greater sense of control over the process.

Use animation when an action occurs so quickly, users can't track it. When it’s important that users understand a connection or a process, animation can help them watch actions occur in a more human time frame. For example, when the user minimizes a window it doesn’t just disappear from the desktop and reappear in the Dock; instead, it moves fluidly from the desktop to the Dock so that users know exactly where it went.

Avoid animating everything. Although it’s tempting to think that more animation results in great clarification and better feedback, it’s not generally true. Most tasks and actions in an app are best performed quickly and with a minimum of fanfare.

Avoid animating routine actions supported by system-provided controls. Users understand how common UI elements work, and they don’t appreciate being forced to spend extra time watching unnecessary animation every time they click a button or switch tabs.

Consider Adding Physicality and Realism

Sometimes, suggesting or replicating the look and feel of the real world in your app can improve the user’s experience. The guidelines in this section can help you decide whether it’s appropriate to add realism to your app, and if it is, how to incorporate it successfully.

Determine whether depicting a real-world task helps users understand its virtual version. The key is to make sure that adding realism enhances both understanding and usability: Improving one at the expense of the other does not make your app better. For example, even though writing and posting letters is a real-world activity that most people understand, Mail does not expect users to fold a virtual note or affix a stamp to a virtual envelope.

Feel free to modify a real-world depiction if doing so enhances the user’s understanding. In other words, don’t feel that you must be scrupulously accurate in your rendering of realistic objects or experiences. Often, you can express your point better when you fine-tune or leave out some of the details of a real-world object or behavior.

Don’t sacrifice clarity for artistic expression. For example, it might make sense to show notes or photos pinned to a cork board, but it might be confusing to use a cork board background in an app that helps people create a floor plan for their home. If users need to stop and think about what your images are trying to communicate, you’ve decreased the usability of your app. (This concept is related to the principle of aesthetic integrity; to learn more about it, see “Aesthetic Integrity.”)

Aim for realistic motion, too. Sometimes, realistic movement can help people understand how something works even more than realistic imagery can. For example, OS X uses the rubber band effect to show users that they’ve scrolled to the end of a window’s content or come to the last full-screen window or desktop. Take the time to investigate the physics that dictates how the objects in your UI might move so that you can enhance the user’s understanding.

Consider enhancing physicality and realism in full-screen mode. In Photo Booth, for example, the depiction of red velvet drapes, woodgrain, and brass controls occurs only in full-screen mode. But it’s important to note that the addition of these peripheral elements does not distract users from their task, because the focus of the window remains on the main viewing area.

../art/photoboothtextures.jpg

Make Exploration Safe

Encourage people to explore your app by building in forgiveness—that is, making most actions easily reversible. People need to feel that they can try things without damaging the system or jeopardizing their data. Ideally, your app provides users with the capabilities they need while helping them avoid dangerous, irreversible actions.

Create safety nets so that users feel comfortable learning how to use your app. For example, support Undo as much as possible (for some guidelines on how to do this, see “The Edit Menu”). Also, consider allowing users to make changes to their content, but defer committing to the changes until a later time. For example, iPhoto allows users to perform all sorts of modifications to a photo without actually changing the photo file until they want to.

Warn users when they initiate a task that will cause an unexpected and irreversible loss of data. Such warnings are important, but they can become annoying—and users tend to ignore them—if they appear too often. Make sure you don’t warn users when data loss is an expected outcome of an action. For example, the Finder doesn’t display an alert when the user throws away a file because the user intends to delete the file. For more guidelines on how to use alerts in your app, see “Alerts.”

Provide plenty of informative feedback and communication throughout your app. Relevant, reliable feedback helps users feel confident that they have enough information to make the right choices.

In most cases, avoid constraining user actions. Unless you’re creating a children’s app in which it can be appropriate to restrict the user’s scope of action, you don’t want users to feel that your app is paternalistic. As much as possible, let users do what they want without unnecessary interference.

Earn Users' Trust with Reliability, Predictability, and Stability

A reliable, stable app behaves in predictable ways and maintains the integrity of the user’s data, while doing everything possible to prevent data loss or corruption. It also has a certain amount of maturity to it and can handle complex situations without crashing.

Reopen in the same state in which users left your app. Preserving user-modifiable settings, such as window dimension and location, enhances users’ perception of the stability of your app. OS X makes state-preservation easy to achieve when you enable Resume. To learn how to support Resume in your code, see “User Interface Preservation” in Mac App Programming Guide.

Make sure UI elements behave the way users expect them to. When UI elements work as expected, users are more likely to trust your app to do what it promises. In particular, it’s crucial to avoid altering the meaning of the standard UI elements that users are familiar with.

Provide status and feedback to show that your app is performing the specified task. Users need to be able to trust that your app is acting upon their commands and they appreciate knowing how long a process will take. One way to provide status feedback is by using a progress indicator; to learn how to use a progress indicator in your app, see “Progress Indicators.”

Make sure users receive predictable output from their content. If your app enables users to format data for printing, web publishing, or writing to film, DVD, or other formats, make sure there are no significant differences between what users see onscreen and what they receive in the final output.

Anticipate errors and help users avoid them when possible. A stable, reliable app minimizes the potential for error by, for example, validating user input before processing it. The more you can help users avoid triggering errors, the fewer problems you have to handle.

Adapt to Changes in the User's Environment

An adaptable program is one that adjusts appropriately to its surroundings; that is, it does not stop working when the current conditions change. One of the strengths of OS X is its ability to adapt to configuration changes quickly and easily. For example, if the user changes a computer’s network configuration in System Preferences, the changes are automatically picked up by apps such as Safari and Mail. Follow the guidelines in this section to ensure that your app is similarly adaptable.

Expect people to be mobile. First of all, be prepared for network configuration changes and make sure that users can benefit from your app when their network connection is slow or nonexistent. For example, be flexible when accessing the file system, in case network volumes go offline. If a network volume disappears, show users that it is unavailable and provide an option to save files to a different volume. (If you want to learn about using Bonjour to publish and discover services, see Bonjour Overview.)

Second, be conservative with your app’s power usage so that mobile users can use their computer as long as possible before recharging. For example, avoid polling for events and accessing the hard disk as much as possible. Also, make sure that your app is completely idle unless it is actively processing a user’s request. (To start learning how to optimize your app’s performance, see Performance Overview.)

Anticipate variations in display size, resolution, and number. OS X users can plug in and unplug displays at any time, and these displays might have different sizes and resolutions. Your app should respond gracefully when a display goes away or when a new display has a different size or resolution. Make sure your graphics look good at all resolutions and be prepared to adjust window locations and dimensions.

Be prepared for multiple users with different privileges. The OS X fast user switching feature allows multiple users to be logged in simultaneously and to switch quickly between accounts. To ensure that your app behaves appropriately when there are multiple users logged in or when the current user has limited privileges, keep the following things in mind:

Some users may be working under limited privileges and have limited access to some parts of the system. For example, only administrator users can write files in /Applications. In particular, users with limited privileges may not be able to:

Users on a computer can include both local and network users, so don’t assume that a user’s home directory is on a local volume. Be prepared for the possibility that you are accessing a network volume instead.

Named resources that might potentially be accessible to an app from multiple user sessions should incorporate the session ID into the name of the resource. This applies to cache files, shared memory, semaphores, and named pipes, among others.

Avoid depending on the availability of specific hardware. Hardware configurations can vary greatly based on the computer, country, and user. For example, not every Macintosh has the same graphics card or processor. Similarly, not all keyboards have the same set of keys. Hardware can also be added or removed at runtime. To detect available device configurations, you can use the I/O Kit interfaces that are described in Accessing Hardware From Applications.

Avoid making assumptions based on the current user’s locale. Be prepared to handle different date, time, and number formats. Also, don’t assume that the address format of the current user is the only address format in use. For example, in Contacts the user may store contacts with foreign addresses.

To make sure your user interface adapts gracefully to changes in locale (especially when users switch to right-to-left languages), use Cocoa Auto Layout as described in “Auto Layout.”

Design for Interoperability

An interoperable app communicates seamlessly with other apps and services so that users can open their content in different apps and exchange information with other users. Users appreciate interoperability because it means that they can focus on their content, without having to pay attention to details such as file formats and data-exchange protocols.

As much as possible, avoid using custom file formats. Instead, use standard file formats so that users can easily exchange documents with other users or open them in different apps. If you must use a custom file format, be sure to provide import and export capabilities so that users can exchange data with other apps and the system. If necessary, you should also include a Quick Look generator to convert your native document format into a format the Finder and Spotlight can display. (For more information about integrating well with the Finder and with Spotlight, see “The Finder” and “Spotlight.”)

Use the same file format on all platforms you support. Using the same format on all platforms ensures that users can use your app to view their content regardless of the device or platform they’re using.

Support filename extensions. A filename extension identifies the document’s type in a way that all platforms understand. Although OS X users can hide the display of filename extensions, you should support them so that apps on other platforms can recognize and open the files that your app creates.

Use the user defaults system to store preferences. When you use the user defaults system to manage your app’s configuration information, the data is generally stored in property list files. In your app, you use the shared NSUserDefaults object to access and modify this information (on the command line, you can use the defaults tool to examine the contents of the user defaults database).

Use standard protocols for data interchange. XML is the preferred format for exchanging data among apps and platforms because it is cross-platform and widely supported. OS X also supports numerous network protocols, as listed in “Core OS Layer”.

Use the Right Pointer for the Job

OS X provides several standard pointers that provide well-defined feedback to users. It’s important to use these pointers correctly because users already know what they mean.

Use standard pointers according to their intended purpose. OS X users are accustomed to the meaning of the pointers shown in Table 3-1. If you change the meaning of a standard pointer, users aren’t able to predict the results of their actions.

Table 3-1  Standard pointers in OS X

Pointer

Meaning

../art/cu_arrowcursor.gif

The user can activate the control or switch to the area.

../art/cu_contextualmenu.gif

A contextual menu is available for an item. Shown when the user presses the Control key while the pointer is over an object with a contextual menu.

../art/cu_alias.gif

The drag destination will have an alias for the original object (the original object will not moved).

../art/cu_poof.gif

The proxy object being dragged will go away, without deleting the original object, when the user releases the drag. Used only for proxy objects.

../art/cu_copy.gif

The drag destination will have a copy of the original object (the original object is not moved).

../art/cu_no_entry.gif

An invalid drag destination.

../art/cu_ibeamcursor.gif

Selection and insertion of text is available.

../art/cu_crosshair.jpg

Precise rectangular selection is available.

../art/cu_pointing_hand.gif

The content is a URL link.

../art/cu_open_hand.gif

The item can be manipulated within its containing view.

../art/cu_closedhand.gif

Pushing, sliding, or adjusting an object within a containing view is occurring.

../art/cu_move_left.gif

The object can only be moved or resized to the left.

../art/cu_move_right.gif

The object can only be moved or resized to the right.

../art/cu_move_left_and_right.gif

The object can be moved or resized to the left or the right.

../art/cu_move_up.gif

The object can only be moved or resized upward.

../art/cu_move_down.gif

The object can only be moved or resized downward.

../art/cu_moveupanddown.gif

The object can be moved or resized upward or downward.

The spinning wait cursor (shown below) is also standard, but it is displayed automatically by the window server when an app can't handle all of the events it receives. In general, if an app does not respond for about 2 to 4 seconds, the spinning wait cursor appears. If the app continues to be unresponsive, users often react by force-quitting it.

Spinning wait cursor

Create a custom pointer cautiously. Before you design a custom pointer for your app (especially a custom version of a standard pointer), be sure the new pointer actually improves the usability of your app and doesn’t confuse users. If you’ve determined that you need a custom pointer, follow these guidelines as you design it:

Reach as Many Users as Possible

As early as possible in the design process, start thinking about accessibility and worldwide compatibility so that the market for your app is as large as possible. It’s much easier to build in support for accessibility and internationalization from the beginning than it is to add support to a finished app.

Making an app usable by people with disabilities—that is, making it accessible—benefits you, too, because in many places accessible apps are the only apps that governments and some institutions can purchase.

OS X includes many assistive features, including VoiceOver, zoom, and full keyboard access mode. When your app is accessible, users can interact with it using the assistive device or feature of their choice. For example, in addition to speaking the UI to VoiceOver users, VoiceOver can also show the current focus and output to the user’s sighted colleagues.

../art/ue_voinaction.jpg

To learn about some of the user experience issues you should keep in mind, see “Accessibility.” To learn what programming steps you need to take to make your app accessible, start by reading Accessibility Overview for OS X.

It’s a good idea to prepare your app for localization by internationalizing it. Internationalization involves separating any user-visible text and images from your executable code. When you isolate this data into resource files, you make it easier to localize your app, which is the process of adapting an internationalized app for culturally distinct markets.

For details on how to internationalize your app and prepare for localization, see “Internationalization.”

Make Help Available, but Unobtrusive

Ideally, users can easily figure out how to use your app without ever needing to read the user guide. But sometimes users need a little help understanding how to use an advanced feature or how to perform a variation of the main task. The guidelines in this section help you provide app help that doesn’t get in the user’s way; for detailed guidance on how to compose help content, see “User Assistance.”

Provide help tags that describe how to use UI elements. Help tags can appear when the user allows the pointer to rest over a UI element for a few seconds. A help tag consists of a small view that displays a succinct description of what the UI element does. Although it’s best when the usage of your app’s UI is instantly apparent to users, help tags can be a good way to help novice users without annoying experienced users. Because a help tag’s message is short and directly linked to a specific UI element, a help tag is not the appropriate place to describe a higher-level task.

Provide a help book that describes how to accomplish tasks in your app. Users open an app's help book when they can’t figure out how to accomplish their goal. Although users might also refer to a help book to find out how to use a specific control, they’re more likely to be seeking help with a higher-level task. For this reason, your help book should be task-based, and for the most part, it should describe control usage in the context of accomplishing a task.

Make User Input Convenient

There are several ways in which users might have to enter information into your app, such as filling out a form, entering a password, or supplying an email address. Follow the guidelines in this section to make this experience as easy as possible for users.

When possible (and appropriate), automatically fill in text fields as users type. Users appreciate the convenience of having some information supplied for them, as long as it’s correct. If you can’t guarantee the accuracy of the information you provide, it’s better to leave text fields empty. If you supply text, be sure to indicate the fields you are filling in (perhaps by highlighting them), so that the user can easily distinguish the information your app provides from the information they provide. Note that a password field should always be empty.

Perform appropriate edit checks as users enter information. For example, if the only legitimate value for a field is a string of digits, the app should alert users as soon as they type a nondigit character. Verifying user input as your app receives it helps avoid errors caused by unexpected data. For a more complete discussion of when to check for errors and apply changes in text fields, see “Accepting and Applying User Input in a Dialog.”

Defer displaying a "required" icon next to a required field until users leave the context without handling it. Preemptively displaying an asterisk or a custom icon next to each required text field and selection control can make your UI appear cluttered and unappealing. Instead, assume that users will fill in all the required fields; if they forget one, display an asterisk or custom icon next to the forgotten field when they attempt to exit the current context. This strategy helps you maintain an attractive UI, while at the same time helping you avoid treating users as if they were children.

Preserve users’s privacy as they input a password. In this situation, each character the user types should appear as a bullet. If the user deletes a character with the Delete key, one bullet is deleted from the text field and the insertion point moves back one bullet, as if the bullet represented an actual character. Double-clicking bulleted text in a password field selects all the bullets in the text field. When the user leaves the text field (by pressing Tab, for example), the number of bullets in the text field should be modified so that the field doesn’t reflect the actual number of characters in the password.

../art/ue_bulletsinpasswordfield.jpg

Use User-Centric Terminology

Almost all apps need to use some words to communicate with users, even if the only words are in button labels. It’s important to choose all of your app’s words carefully so that you can ensure that your communication with users is unambiguous and accurate.

In general, avoid jargon. Above all, you want to use the terminology your users are comfortable with. If your app targets sophisticated users who frequently use a set of specialized, technical terms, it makes sense to use these terms in your app. On the other hand, if your user audience consists of mostly novice or casual users, it’s better to use simpler, more generally understood terms.

Avoid developer terms. As a developer, you refer to UI elements and app processes in ways that most of your users don’t understand. Be sure to scrutinize the UI and replace any developer terms with appropriate user terms. For example, Table 3-2 lists several common developer terms, along with equivalent user terms you should use instead.

Table 3-2  Some developer terms and their user term equivalents

Developer term

Equivalent user term

Cursor

Pointer

Data browser

Scrolling list or multicolumn list

Dirty document

Document with unsaved changes; unsaved document

Focus ring

Highlighted area; area ready to accept user input

Control

Button, checkbox, slider, menu, etc.

Launch

Start

Mouse-up event

Click

Override

Take the place of; take precedence over

Reboot

Restart

String

Text

String length

Number of characters

Use proper Apple terminology. If you need to refer to standard parts of the UI or to system features, be sure to use the terms that Apple defines. For example, if you need to describe the use of a checkbox in your UI, tell the user to “select" the checkbox, not to "check,” “click,” or “turn on” the checkbox. Or, if you mention how to start your app by clicking your app icon in the Dock, be sure to capitalize “Dock.” You can learn more about Apple terminology by reading Apple Style Guide.

Be Cautious When Extending the Interface

OS X provides many UI elements that you can use to enable a wide range of actions in your app. Users are comfortable with these elements and they appreciate finding them in new apps, because they already know how to use them. In rare cases, however, your app might need to enable an action for which there is no Aqua element. If you need to design a custom UI element, follow the guidelines in this section.

Don’t assign new behaviors to standard UI elements. It’s better to create a custom element than to change the behavior of a familiar Aqua element. If UI elements behave differently in different situations, the interface becomes unpredictable and harder for users to figure out.

Don't create a custom UI element that looks or behaves like an Aqua UI element. If your custom element looks too much like an Aqua element users might not notice the difference, and they will be confused when it does not behave as they expect. Similarly, if your custom element behaves the same way an Aqua element behaves, users will wonder what, if anything, is different about the custom element.

Make sure your custom UI element enhances the usability of your app. A custom UI element should provide users with a unique benefit that is difficult to achieve in any other way. If a new UI element doesn’t help users, they’re likely to feel that they wasted the time they spent learning about it.

Avoid replicating a UI element from another platform. Users aren’t necessarily familiar with other platforms, so you can’t assume that they recognize nonAqua UI elements. It’s better to design a new UI element that coordinates with the design of your app and that supplies the precise behavior you need.

Brand Appropriately

A well-designed app incorporates branding in subtle, memorable ways. The guidelines in this section outline some strategies for adding branding that doesn’t overwhelm or annoy users.

Make sure branding is subordinate to the user’s content and the main task. People don’t use an app to learn more about a related product or company, so it’s best to keep branding elements unobtrusive. For example, consider using the relevant colors from the company logo throughout the UI, or using recognizable brand elements as the basis for custom toolbar icons.

As much as possible, make your app into a brand. Strive to create an app brand, rather than just displaying company branding in an app. One way to do this is to develop a subtle design language that you use consistently throughout your app. Allow this language to guide your use of color, shape, terminology, movement, and behavior so that users perceive your app as a coherent statement.

Create a memorable app icon. Your app icon is the place where branding elements can take center stage. If your app is associated with a well-known brand, or if your app represents a brand, incorporate its visual elements in your app icon. For additional guidelines on icon creation, see “Icon Design Guidelines.”

Provide Keyboard Shortcuts for Frequently Used Commands

Keyboard shortcuts are combinations of two or more keys that users can press to initiate certain actions. OS X reserves several keyboard shortcuts to support both general usability needs and accessibility needs. For example, Command-Space reveals the Spotlight search bar, and Command-Option-8 turns zoom on or off.

In addition to the system-reserved shortcuts, several keyboard shortcuts are so commonly used for specific actions that users expect them to be available in most apps. And, when users enable full keyboard access mode, other key combinations may be reserved by default.

Don’t override the system-reserved keyboard shortcuts. Users expect these shortcuts to work regardless of the app they’re currently using. You’ll find a list of these shortcuts (each marked with the ../art/ks_apple_icon_2x.png symbol) in Table A-2.

Avoid overriding the standard keyboard shortcuts users are familiar with. Users expect these shortcuts to mean the same thing in each app they use. The standard shortcuts are also listed in Table A-2 (they are not marked with the ../art/ks_apple_icon_2x.png symbol).

In rare cases, it can be acceptable to redefine a common keyboard shortcut. For example, if users spend the majority of their time in your app, it can make sense to redefine shortcuts that don’t apply to the tasks your app enables. Or, if most of your users have used your app on a different platform, you might not want to change the keyboard shortcuts they already know.

Don’t feel that you must create a shortcut for every command in your app. If you try to do this, you’ll probably end up with some shortcuts that are unintuitive, hard to remember, and physically difficult to perform. Instead, identify the most frequently used commands in your app and create logical shortcuts for them. Examine Table A-2 for characters and combinations that are not reserved by OS X or commonly used.