---

User Experience

One reason users choose the Macintosh over other platforms is that it provides a compelling user experience. This user experience is defined partly by the technologies and applications that are built-in to Mac OS X and partly by the applications you create. Your applications play a key role in delivering the experience users expect. This means that your applications need to support the features that help them blend into the Mac OS X ecosystem and create a seamless user experience.

In this section:

Technologies
System Applications

Technologies

The following sections describe technologies that form a key part of the Mac OS X user experience. If you are developing an application, you should consider adopting these technologies to make sure your application integrates cleanly into Mac OS X. Most of these technologies require little effort to support but provide big advantages in your software’s usability and in the likelihood of user adoption.

Aqua

Aqua defines the appearance and overall behavior of Mac OS X applications. Aqua applications incorporate color, depth, translucence, and complex textures into a visually appealing interface. The behavior of Aqua applications is consistent, providing users with familiar paradigms and expected responses to user-initiated actions.

Applications written using modern Mac OS X interfaces (such as those provided by Carbon and Cocoa) get much of the Aqua appearance automatically. However, there is more to Aqua than that. Interface designers must still follow the Aqua guidelines to position windows and controls in appropriate places. Designers must take into account features such as text, keyboard, and mouse usage and make sure their designs work appropriately for Aqua. The implementers of an interface must then write code to provide the user with appropriate feedback and to convey what is happening in an informative way.

Apple provides the Interface Builder application to assist developers with the proper layout of interfaces. However, you should also be sure to read Apple Human Interface Guidelines, which provides invaluable advice on how to create Aqua-compliant applications and on the best Mac OS X interface technologies to use.

Quick Look

Introduced in Mac OS X v10.5, Quick Look is a technology that enables client applications, such as Spotlight and the Finder, to display thumbnail images and full-size previews of documents. Mac OS X provides automatic support for many common content types, including HTML, RTF, plain text, TIFF, PNG, JPEG, PDF, and QuickTime movies. If your application defines custom document formats, you should provide a Quick Look generator for those formats. Generators are plug-ins that convert documents of the appropriate type from their native format to a format that Quick Look can display to users. Mac OS X makes extensive use of generators to give users quick previews of documents without having to open the corresponding applications.

For information about supporting Quick Look for your custom document types, see Quick Look Programming Guide and Quick Look Framework Reference.

Resolution-Independent User Interface

Resolution independence decouples the resolution of the user's screen from the units you use in your code’s drawing operations. While Mac OS X version 10.4 and earlier assumed a screen resolution of 72 dots per inch (dpi), most modern screens actually have resolutions that are 100 dpi or more. The result of this difference is that content rendered for a 72 dpi screen appears smaller on such screens—a problem that will only get worse as screen resolutions increase.

In Mac OS X v10.4, steps were taken to support content scaling for screen-based rendering. In particular, the notion of a scale factor was introduced to the system, although not heavily publicized. This scale factor was fixed at 1.0 by default but could be changed by developers using the Quartz Debug application. In addition, Carbon and Cocoa frameworks were updated to support scale factors and interfaces were introduced to return the current screen scale factor so that developers could begin testing their applications in a content-scaled world.

Although the Mac OS X frameworks handle many aspects related to resolution-independent drawing, there are still things you need to do in your drawing code to support resolution independence:

• Update the images and artwork in your user interface. As the pixel density of displays increases, you need to make sure your application's custom artwork can scale accordingly—that is, your art needs to be larger in terms of pixel dimensions to avoid looking pixellated at higher scale factors. This includes changing:

  • Application icons

  • Images that appear in buttons or other controls

  • Other custom images you use in your interface

• Update code that relies on precise pixel alignment to take the current scale factor into account. Both Cocoa and Carbon provide ways to access the current scale factor.

• Consider drawing lines, fills, and gradients programmatically instead of using prerendered images. Shapes drawn using Quartz and Cocoa always scale appropriately to the screen resolution.

When scaling your images, be sure to cache the scaled versions of frequently-used images to increase drawing efficiency. For more information about resolution-independence and how to support it in your code, see Resolution Independence Guidelines.

Spotlight

Introduced in Mac OS X version 10.4, Spotlight provides advanced search capabilities for applications. The Spotlight server gathers metadata from documents and other relevant user files and incorporates that metadata into a searchable index. The Finder uses this metadata to provide users with more relevant information about their files. For example, in addition to listing the name of a JPEG file, the Finder can also list its width and height in pixels.

Application developers use Spotlight in two different ways. First, you can search for file attributes and content using the Spotlight search API. Second, if your application defines its own custom file formats, you should incorporate any appropriate metadata information in those formats and provide a Spotlight importer plug-in to return that metadata to Spotlight.

In Mac OS X v10.5 and later, several new features were added to make working with Spotlight easier. The File manager includes functions for swapping the contents of a file while preserving its original metadata; see the Files.h header file in the Core Services framework. Spotlight also defines functions for storing lineage information with a file so that you can track modifications to that file.

For more information on using Spotlight in your applications, see Spotlight Overview.

Bundles and Packages

A feature integral to Mac OS X software distribution is the bundle mechanism. Bundles encapsulate related resources in a hierarchical file structure but present those resources to the user as a single entity. Programmatic interfaces make it easy to find resources inside a bundle. These same interfaces form a significant part of the Mac OS X internationalization strategy.

Applications and frameworks are only two examples of bundles in Mac OS X. Plug-ins, screen savers, and preference panes are all implemented using the bundle mechanism as well. Developers can also use bundles for their document types to make it easier to store complex data.

Packages are another technology, similar to bundles, that make distributing software easier. A package—also referred to as an installation package—is a directory that contains files and directories in well-defined locations. The Finder displays packages as files. Double-clicking a package launches the Installer application, which then installs the contents of the package on the user’s system.

For an overview of bundles and how they are constructed, see Bundle Programming Guide. For information on how to package your software for distribution, see Software Delivery Guide.

Code Signing

In Mac OS X v10.5 and later, it is possible to associate a digital signature with your application using the codesign command-line tool. If you have a certificate that is authorized for signing, you can use that certificate to sign your application’s code file. Signing your application makes it possible for Mac OS X to verify the source of the application and ensure the application has not changed since it was shipped. If the application has been tampered with, Mac OS X detects the change and can alert the user to the problem. Signed applications also make it harder to circumvent parental controls and other protection features of the system.

For information on signing your application, see Code Signing Guide.

Internationalization and Localization

Localizing your application is necessary for success in many foreign markets. Users in other countries are much more likely to buy your software if the text and graphics reflect their own language and culture. Before you can localize an application, though, you must design it in a way that supports localization, a process called internationalization. Properly internationalizing an application makes it possible for your code to load localized content and display it correctly.

Internationalizing an application involves the following steps:

• Use Unicode strings for storing user-visible text.

• Extract user-visible text into “strings” resource files.

• Use nib files to store window and control layouts whenever possible.

• Use international or culture-neutral icons and graphics whenever possible.

• Use Cocoa or Core Text to handle text layout.

• Support localized file-system names (also known as “display names”).

• Use formatter objects in Core Foundation and Cocoa to format numbers, currencies, dates, and times based on the current locale.

For details on how to support localized versions of your software, see Internationalization Programming Topics. For information on Core Foundation formatters, see Data Formatting Guide for Core Foundation.

Software Configuration

Mac OS X programs commonly use property list files (also known as plist files) to store configuration data. A property list is a text or binary file used to manage a dictionary of key-value pairs. Applications use a special type of property list file, called an information property list (Info.plist) file, to communicate key attributes of the application to the system, such as the application’s name, unique identification string, and version information. Applications also use property list files to store user preferences or other custom configuration data. If your application stores custom configuration data, you should consider using property lists files as well.

The advantage of property list files is that they are easy to edit and modify from outside the runtime environment of your application. Mac OS X provides several tools for creating and modifying property list files. The Property List Editor application that comes with Xcode is the main application for editing the contents of property lists. Xcode also provides a custom interface for editing your application’s Info.plist file. (For information about information property lists files and the keys you put in them, see Runtime Configuration Guidelines.)

Inside your program, you can read and write property list files programmatically using facilities found in both Core Foundation and Cocoa. For more information on creating and using property lists programmatically, see Property List Programming Guide or Property List Programming Topics for Core Foundation.

Fast User Switching

Introduced in Mac OS X version 10.3, fast user switching lets multiple users share physical access to a single computer without logging out. Only one user at a time can access the computer using the keyboard, mouse, and display; however, one user’s session can continue to run while another user accesses the computer. The users can then trade access to the computer and toggle sessions back and forth without disturbing each other’s work.

When fast user switching is enabled, an application must be careful not to do anything that might affect another version of that application running in a different user’s session. In particular, your application should avoid using or creating any shared resources unless those resources are associated with a particular user session. As you design your application, make sure that any shared resources you use are protected appropriately. For more information on how to do this, see Multiple User Environments.

Spaces

Introduced in Mac OS X version 10.5, Spaces lets the user organize windows into groups and switch back and forth between groups to avoid cluttering up the desktop. Most application windows appear in only one space at a time, but there may be times when you need to share a window among multiple spaces. For example, if your application has a set of shared floating palettes, you might need those palettes to show up in every space containing your application’s document windows.

Cocoa provides support for sharing windows across spaces through the use of collection behavior attributes on the window. For information about setting these attributes, see NSWindow Class Reference.

Accessibility

Millions of people have some type of disability or special need. Federal regulations in the United States stipulate that computers used in government or educational settings must provide reasonable access for people with disabilities. Mac OS X includes built-in functionality to accommodate users with special needs. It also provides software developers with the functions they need to support accessibility in their own applications.

Applications that use Cocoa or modern Carbon interfaces receive significant support for accessibility automatically. For example, applications get the following support for free:

• Zoom features let users increase the size of onscreen elements.

• Sticky keys let users press keys sequentially instead of simultaneously for keyboard shortcuts.

• Mouse keys let users control the mouse with the numeric keypad.

• Full keyboard access mode lets users complete any action using the keyboard instead of the mouse.

• Speech recognition lets users speak commands rather than type them.

• Text-to-speech reads text to users with visual disabilities.

• VoiceOver provides spoken user interface features to assist visually impaired users.

If your application is designed to work with assistive devices (such as screen readers), you may need to provide additional support. Both Cocoa and Carbon integrate support for accessibility protocols in their frameworks; however, there may still be times when you need to provide additional descriptions or want to change descriptions associated with your windows and controls. In those situations, you can use the appropriate accessibility interfaces to change the settings.

For more information about accessibility, see Accessibility Overview.

AppleScript

Mac OS X employs AppleScript as the primary language for making applications scriptable. AppleScript is supported in all application environments as well as in the Classic compatibility environment. Thus, users can write scripts that link together the services of multiple scriptable applications across different environments.

When designing new applications, you should consider AppleScript support early in the process. The key to good AppleScript design is choosing an appropriate data model for your application. The design must not only serve the purposes of your application but should also make it easy for AppleScript implementers to manipulate your content. Once you settle on a model, you can implement the Apple event code needed to support scripting.

For information about AppleScript in Mac OS X, go to http://www.apple.com/applescript. For developer documentation explaining how to support AppleScript in your programs, see Reference Library > Scripting & Automation.

System Applications

Mac OS X provides many applications to help both developers and users implement their projects. A default Mac OS X installation includes an Applications directory containing many user and administrative tools that you can use in your development. In addition, there are two special applications that are relevant to running programs: the Finder and the Dock. Understanding the purpose of these applications can help when it comes to designing your own applications.

The Finder

The Finder has many functions in the operating system:

• It is the primary file browser. As such, it is the first tool users see, and one they use frequently to find applications and other files.

• It provides an interface for Spotlight—a powerful search tool for finding files not easily found by browsing.

• It provides a way to access servers and other remote volumes, including a user’s iDisk.

• It determines the application in which to open a document when a user double-clicks a document icon.

• It allows users to create file archives.

• It provides previews of images, movies, and sounds in its preview pane.

• It lets users burn content onto CDs and DVDs.

• It provides an AppleScript interface for manipulating files and the Finder user interface.

Keep the Finder in mind as you design your application’s interface. Understand that any new behaviors you introduce should follow patterns users have grown accustomed to in their use of the Finder. Although some of the functionality of the Finder, like file browsing, is replicated through the Carbon and Cocoa frameworks, the Finder may be where users feel most comfortable performing certain functions. Your application should interact with the Finder gracefully and should communicate changes to the Finder where appropriate. For example, you might want to embed content by allowing users to drag files from the Finder into a document window of your application.

Another way your application interacts with the Finder is through configuration data. The information property list of your bundled application communicates significant information about the application to the Finder. Information about your application’s identity and the types of documents it supports are all part of the information property list file.

For information about the Finder and its relationship to the file system, see File System Overview.

The Dock

Designed to help prevent onscreen clutter and aid in organizing work, the always available Dock displays an icon for each open application and minimized document. It also contains icons for commonly used applications and for the Trash. Applications can use the Dock to convey information about the application and its current state.

For guidelines on how to work with the Dock within your program, see Apple Human Interface Guidelines. For information on how to manipulate Dock tiles in a Carbon application, see Dock Tile Programming Guide and Application Manager Reference. To manipulate Dock tiles from a Cocoa application, use the methods of the NSApplication and NSWindow classes.

Dashboard

Introduced in Mac OS X v10.4, Dashboard provides a lightweight desktop environment for running widgets. Widgets are lightweight web applications that display information a user might use occasionally. You can write widgets to track stock quotes, view the current time, or access key features of a frequently used application. Widgets reside in the Dashboard layer, which is activated by the user and comes into the foreground in a manner similar to Exposé. Mac OS X comes with several standard widgets, including a calculator, clock, and iTunes controller.

For information about developing Dashboard widgets, see “Dashboard Widgets.”

Automator

Introduced in Mac OS X version 10.4, Automator lets you automate common workflows on your computer without writing any code. The workflows you create can take advantage of many features of Mac OS X and any standard applications for which predefined actions are available. Actions are building blocks that represent tangible tasks, such as opening a file, saving a file, applying a filter, and so on. The output from one action becomes the input to another and you assemble the actions graphically with the Automator application. Figure 5-1 shows the Automator main window and a workflow containing some actions.

In cases where actions are not available for the tasks you want, you can often create them yourself. Automator supports the creation of actions using Objective-C code or AppleScript. You can also create actions that are based on shell scripts, Perl, and Python.

In Mac OS X v10.5 and later, Automator supports the “Watch Me Do” feature, which lets you build an action by recording your interactions with Mac OS X and any open applications. You can use workflow variables as placeholders for dynamically changing values or pieces of text in your script. You can also integrate workflows into your applications using the classes of the Automator framework.

For more information about using Automator, see the Automator Help. For information on how to create new Automator actions, see Automator Programming Guide. For information about how to integrate workflows into your applications, see the classes in Automator Framework Reference.

Time Machine

Introduced in Mac OS X v10.5, Time Machine is an application that automatically and transparently backs up the user’s files to a designated storage system. Time Machine integrates with the Finder to provide an intuitive interface for locating lost or old versions of files quickly and easily. Time Machine also provides an interface that applications can use to exclude files that should not be backed up. For more information on using this interface, see “Time Machine Support.”

---