Apple: steal this design
Delivering good software is hard. In addition to the obvious challenges of engineering and design, good software requires effective management and marketing, clear writing, and a host of other skills. When you develop an application by yourself or with a friend, that means you have to be the engineer, the designer, and all those other people.
Apple eases this burden by telling developers, do what we do. For engineering, this means building upon the powerful libraries in OS X whenever possible, which reduces work and encourages consistency. Similarly, for design this means imitating the metaphors and terminology Apple has already introduced to solve design problems within its OS and applications.
Combined, these templates of engineering and design offer enormous benefits which often increase the more they’re used. Need a list? Use Cocoa’s NSTableView. But throw in Core Data and you’ll save even more work.
You can see this powerful borrowing at work in Macnification, a new scientific application positioned to be for microscopic images what Apple’s Aperture is for digital photographs. Macnification borrows from Apple’s design proudly with its smart folders, stacks, light tables, iTunes-like sidebar, overlay windows, and live filtering.
And why not borrow from the best? Why reinvent solutions to problems that Apple has already invested considerable effort in solving? By copying ideas from OS X and Apple’s suite of applications, developers save time and money while ensuring that the ideas they’re using are already tested and work.
This benefits users, too. If you’re looking at a collection of images, all closely related in time or nature, you benefit from a single refined metaphor—the stack—for regarding those images.
Sharing metaphors and design requires careful attention to detail. Unlike code libraries where sharing is strict, shared design is collaborative and subject to subtle divergences which unchecked can easily confuse. If Apple says stacks look and work this way but developers say they look and work that way, the difference erodes the benefit of shared design and ultimately compromises the user experience.
But when attention to detail is paid and metaphors are shared with exacting care, users certainly benefit. When you see that little numbered icon in the upper corner of an image, you think, hey, that’s a stack, and immediately you appreciate that you can click on it to expand it and interact it with it in other already familiar ways.
Just as important as shared metaphor are other simpler aspects of shared design. Take a look at this excellent dialog, for example:
There are many ways in which the design of this dialog might have been bungled, ways in which the user might have been confused by the options available while deleting a stack. But because the developers of Macnification were able to follow Apple’s lead in something as seemingly trivial as the design of a confirmation dialog, they created instead not only a design that’s clear, but a design that’s clear in a way users recognize.
As difficult as it is to lead by actions, to say “do as I do, not as I say”, Apple has done a great job at doing exactly that in OS X, and now on the iPhone.
It is significantly less wordy, and clearer.
I agree with the main point - design is important and you should use Apple’s tools so your design is consistent with the user’s expectations.
But what to do if you’re in an organization where (interface) design is not a high priority?
Patrick, what’s worked for me in the past has been to clarify the hidden costs of not making design a priority. If skipping design is perceived as a low- or no-cost alternative–”I skipped design and didn’t suffer at all for it!” or “Our users don’t care about that.”– it might simply be that the people making the decisions are genuinely unaware of the real costs involved. Once made aware of those costs, those decision makers can surprise with their new-found appreciation.
For instance, expensive customer support is directly and inversely related to the amount of time spent on design.
Strangely, this app may be aping Apple but they screwed up the words on that dialog — there are too many!
Address Book does it better: they should just say “Cancel”, “Delete”, and “Remove from Stack”. By drawing a distinction between “DELETE!!!!OMG!” and “remove” Apple can carry the shorthand throughout Address Book and the rest of the system — I’m removing this app from the dock, but I’m DELETING this file from my hard disk
-Wil
I don’t get it… isn’t this just like a really watered down version of Aperture?
I agree with Steven, why would one get an app for $399 that an app on $199 does better?
Though Macnification might offer valuable features that Aperture does not, including, crucially, the ability to read image formats particular to the field, I wasn’t arguing for the value or worth of the Macnification application per se, but instead wanted to comment on how deliberately it borrowed from Apple’s work.
The Macnification and Address Book confirmation dialogs have 3 buttons, and if done “right” (not sure if this is in Apple’s HIG), can be mapped to 3 different keys:
Return: the default button (button with blue background)
Spacebar: the button with blue outline
Escape: the other button.
Escape is usually associated with “Cancel” and hence the “Cancel” button should be the “other” button mentioned above.
Return can be tied to the default button (”Remove from Group”) and Spacebar can be tied to “Delete”.
Also, when apps follow the above “rules”, I have noticed that they are laid out in the following order (left-to-right): button with blue outline, Cancel (button associated with Escape), default button. See the confirmation dialog that appears in TextEdit when you attempt to close an unsaved document.
Thanks for your article John; UI design has taken an important place within the development process and the UI has seen many revisions. We took a lot of cues from Aperture since it is one of the best in its kind, and solves main interaction issues by well thought out metaphors.
Wil, I understand where you’re coming from (the dialog *is* wordy), but actually it has received a lot of thought. The comparison you make is not correct:
- The semantic difference between “remove” and “delete” is subtle to nonexistent. If Apple wishes to establish a dogmatic difference that is their choice but it is not intuitive at all. I’m not a native English speaker, but per the OS X Thesaurus:
9 (Gabriel removed two words) delete, erase, rub out, cross out, …
Our target users are for a large part International English speakers, so clarity is important here. That requires avoiding subleties, even if it increases word count.
- The whole use case is different from the Address Book scenario. In AB, you remove the item and AB asks if it needs to be removed from the library or from the group only.
The dialog in Macnification offers to remove all items from the library, after having removed the group itself. An equivalent of this dialog would have no use in AB, as this is never a desired action.
The button label “Remove from Stack” would be meaningless, as the stack itself is being removed anyway.
Again, the differences are subtle but vital, and there might be better solutions to the dialog, but the one Wil suggested is not viable.