Designing a Great UI the Aqua Wayby Alan Graham
Question: What is the worst part of building an application?
- Sleep deprivation
- Lack of a personal life
- Questionable hygiene
- Running out of Jolt
- Building a user interface
- All of the above
Answer: All of the above.
However, most programmers will tell you they’d rather write algorithms all day with a dull crayon than even think of building a user interface (UI).
Let’s face it; building a good UI is hard work. It's possibly tougher than writing the code itself. But who can deny the importance of a good UI? The UI of your application is the actual representation of your code. Regardless of how well your application functions, a poorly designed UI will turn software reviewers rabid and send users running away screaming. You wouldn’t put a Ferrari engine in a Dodge Neon and expect racing enthusiasts to take it seriously.
Chicken or egg?
The first step before you even start programming should be planning and prototyping your application’s UI. Many developers begin coding before they’ve defined how the application and the UI work. You may say, “How can I design an interface until I complete my code?” My question to you is how can you really know what your application is capable of until you design your UI?
Designing the UI of a project will help you to define the scope of the application. It will often help to answer many questions and provided solutions you would not encounter until much later. Designing a UI at the start of a project can help to cut development time and lead to “eureka” discoveries, additional functionality, and new tools you may never have considered.
The good news
The good news is that Apple has provided the developer community with tools to help them build a successful UI. You can use Apple’s Human Interface Guidelines to ensure you are 100-percent Aqua compliant. They’ve also provided us with a number of development tools that include a handy little application called Interface Builder. In addition to excellent developer tools, the OS X system has been built to handle your font support, toolbar animation, and more to help cut down development time. Thanks to Apple, you don’t need to code these items to be Aqua compliant.
The bad news
The bad news is that Apple has provided us with their Human Interface Guidelines (AHIG). Now I am not knocking Apple. The AHIG is a well-developed document that covers practically every aspect of being compliant with Aqua. Want to know how many pixels between buttons? See Chapter 6. What is a drawer and when do you use it? Chapter 4.
The problem with the Human Interface Guidelines is that they are only guidelines. They can help you comply with the appearance of Aqua, but this isn’t a book on the art of good design. You could follow all the guidelines and still end up with a UI that drives end users to pull their hair out. This is excellent for the manufacturers of Rogaine, but not so good for your bottom line. I could write an entire series of articles on design, but by that time, we’d be up to OS XI. Instead, I am going to touch base on a few design topics and give you some food for thought.
Where do I start?
What tips do you have to add for designing user interfaces with Aqua?
Also in Designing for Aqua:
UI design is an art form. As with any art form, it is a topic that is highly subjective. There are thousands of experts with differing philosophies on what is the best way to perform function x, y, or z. There are thousands of studies that "prove" what works best. There are even universities that have entire programs in user interface design.
Apple itself has spent countless hours developing the Aqua experience. I’ve seen everything from praise to actual hate mail from UI designers. If that wasn’t confusing enough, the technology continues to change, challenging the way we think about interacting with our computers.
We went from the unimaginative command line to the GUI. The GUI started out as dimensionless and colorless line-art, which eventually expanded to colorful, dimensional metaphors. Today we are designing software that mimics the appearance of everyday objects. Drive icons look like real drives. The Calculator and Clock apps look and function like their real-world counterparts. Mac OS X and Aqua bring us a two-dimensional space with realistic 3D elements. Our real world is beginning to merge with the virtual world. Let’s take a moment to look at some design examples.
Glass half full
If we look at the QuickTime 5 interface, we see the philosophy of building an interface that mimics the functionality of a real-world device. We have a dimensional object with a brushed metal appearance. It has beautifully rendered buttons that resemble glass. The theory here is that applying real-world metaphors will allow users to take their real-world experiences and apply them to the application. Designers believe this makes the software less intimidating to new users and shortens the time required to go from novice to expert.
Glass half empty
The other school of thought says what we have here is a piece of software and not a real-world device. The user may not have a frame of reference to apply to this application. So the metaphor is not only lost on them, but could be confusing. In addition, the computer doesn’t always reflect the functionality of the object. Look at QuickTime 4, for example. You may not have a potentiometer on your mouse, so using a dial metaphor to control a variable setting (like volume) is not only confusing, but difficult to operate. Notice that QuickTime 5 has removed the dial and now uses a slider.
So which school of thought do you belong to?
Beauty vs. function
Some developers take design so seriously that their ideals are to produce a functional piece of art. The difficulty here is finding the right mix between function and beauty. How do you create an interface that satisfies your artistic sensibilities while not ostracizing the user?
An example of functional UI art (and one that will go down in history books) is Corel’s Bryce. This is by far the most stunning example of a functional yet artistic UI. A breathtaking program which is deceptively powerful with a short learning curve (compared to many 3D programs). However, your first impression is that you just stepped into a space simulator game. It is absolutely foreign in comparison to anything you have experienced before. Although I find Bryce easy to learn, how many people have been intimidated by their first Bryce experience?
For years Bryce has given us a glimpse into the future of UI design; a shining star among the drab toolbars and palettes of other applications. You’ll find elements in Aqua that were part of Bryce over four years ago. But is Bryce too far ahead of its time? There is something to be said for a gradual evolution of the UI. For example, I really like the fact that I can go through many of today’s leading photo-editing applications, and find a similar interface with similar tools and palettes. This really helps users to adapt to new applications faster. So the question to you is where will you draw the line between art and function? I believe the answer lies within who your end user will be.
I absolutely support the idea of pushing design forward, but you have to find the balance between functionality and art. Also, there is value in mimicking other successful applications and not taking a radical departure in design. For example, I really like the fact that I can go through several photo-editing applications and find a similar interface with similar tools. It helps me adapt to new applications faster.
There are also a number of trip wires to be wary of when designing your UI. I'm going to run through some of the more common mistakes right now.
Pages: 1, 2