Are you familiar with the Apple Human Interface Guidelines? It is a document which outlines how good OS X applications should look and behave in order to maintain the consistent look and feel of applications across the Mac platform (and the iPhone for the iPhone Human Interface Guidelines).
Personally, for any document of considerable length which I will undoubtedly spend a fair amount of time reading, I prefer to have a physical copy to read than simply read on-screen:
Although at a modestly-sized 394-pages long (those pages are printed double-sided), I would highly recommend that any Mac developer or designer for the Mac platform read the Guidelines, if not in their entirety because they are such a valuable resource when designing applications.
The Human Interface Guidelines are split into several parts:
- Application Design and Fundamentals: This section analyses what makes an effective interface which is both easy to use and attractive.
- The Macintosh Experience: This section explains the design and environment of OS X and presents the integrated technologies that can be used by applications.
- The Aqua Interface: This section is all about the Aqua Interface – the OS X user interface and behaviour of certain components such as windows and menus. It goes into considerable depth on a number of topics, such as icons, pointers and the controls provided by the Interface.
I am a strong advocate of consistency in applications across a platform, which is probably the biggest emphasis of the Human Interface Guidelines. This is so beneficial because in turn it leads to ease of use for users due to familiarity from other Mac applications. This is a massive plus, because it makes the application more intuitive and shallows the learning curve, which will make users more satisfied and provide them with a more painless, more enjoyable experience.
This main advantage, of course, stems other advantages from it, most of which are documented in the Introduction section:
- Users will be more at ease with your application because they have encountered similar workflows before, and so will learn how to use it faster and be able to accomplish tasks quicker.
- Documentation is easier because less has to be explained to the user.
- Application support is easier for the same reason.
- Users with disabilities will find it easier to use your application (there is a section about Universal Access in the Human Interface Design section).
At almost 400 pages long, the Guidelines are also very detailed, with information on some subjects which at first glance seem trivial. For example, the other day I was having a discussion about document icons (icons which show the user what application a document is associated with) on OS X and a contender’s suitability – and, low and behold, there is a detailed explanation about the role of Document Icons and how they should be designed, which I referred to:
Traditionally, a document icon looks like a piece of paper with its top-right corner folded down. As previously suggested, document icons should make it obvious which application they are associated with. Preview documents, for example, include a graphic of the media (the pictures) used in the application icon. For simplicity and to avoid confusing the document with the application itself, the viewing tool is not repeated in the document icon.
Document icons are presented as if they are hovering on the desktop, with the shadow behind the document. For more information, see “Icon Perspectives and Materials.”
When you want to put an identifying badge over a document icon, treat the badge as an integrated element within the document instead of putting it over the top of the base image and breaking out of the overall document shape.
There are also accompanying images to explain this.
Of course, there may be some debate about some of the items listed in the guidelines – and after all, as the name states, they are “guidelines” and not truly definitive. For example, in Updating Installed Applications in the section on Software Updates, the proposed method is as follows:
To provide a convenient application-update experience, follow these steps:
- When your application fully launches the first time after installation, start a separate thread that checks for updates.
- If a newer version is available, keep track of this fact in your application. Do not notify the user at this time.
- The next time your application launches, check the state of update availability you determined in step 2. If a newer version is available, immediately notify the user.
If a newer version is not available, start a separate thread to check for updates and keep track of the results in your application. Do not notify the user at this time.
Although I can see some of the advantages to this method, I am not in complete agreement – for example, what if the user rarely shuts down their computer and puts it to sleep? What if certain applications aren’t launched on a daily basis to check for/apply the updates? If the application is idle, why wait until the next application launch to perform an update when the user actually needs to use it? But although debatable, this depth of explanation also provides the consistency with other Mac software, and if adopted by applications, makes the whole user experience more seamless to the end user.
You can’t, of course, take everything the Guidelines state as gospel. All applications are different and there may be some cases where some of the proposed methods just don’t work, or don’t apply.
However, as guidelines on how to design great software for the Mac platform, I think the document is a very useful one. The level of detail that they go into is what makes the Human Interface Guidelines such a valuable resource – there really is an insistent emphasis on consistency and design so that the user is put first and helps to make the whole OS X experience more seamless and intuitive. And it is this collaborative effort and symbiosis by both Apple and Mac developers which make the platform a great experience.