Question: What is the worst part of building an application?
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.
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 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 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.
|
Also in Designing for Aqua: An Interview with Ivor St. John Clarke About Aquafying Office X |
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.
 |
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.
 |
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?
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.
|
Little details are a big deal, so take time to consider them. Some items seem trivial, but they can add up to a major issue that will turn a user away from your application. A good example of a small detail is when developers place buttons in illogical locations. An example would be this actual application.
When you initially launch this program, you fill out a number of configuration windows. On more than one occasion, I’ve hit the Cancel button accidentally because I move my mouse to where the Next button would logically be. I then have to go through the entire configuration again.
There is nothing worse than opening an application that presents you with a 8” x 8” toolbar and hundreds of microscopic icons waiting for you to peruse their help tags. Resist the desire to give everything a default place on the toolbar. When the user buys your application, it becomes their toolbar. Let the user customize the toolbar to fulfill their needs.
One thing that concerns me is an application that uses multiple windows to complete a single task. I can’t stand going through three or four steps (or menus/sub-menus) to complete a task that perhaps a palette (utility window) could handle.
Of course let’s not go palette crazy. You need a place to locate and keep all of your settings and tools, but there can be too much of a good thing. Palettes can consume an enormous amount of real estate. How many times have you started to perform a task and you end up running into a palette? There are many times you start something that you can’t complete because there is a palette in the way. Even if the application allows you to make a change behind a palette, you can’t see through it. If you have multiple palettes in your application, you need to have some creative solutions to handle them.
One of my favorite graphics applications has six palettes and one toolbar that I need constant access to, but they monopolize my screen space. One delightful way they managed this is by letting me hide all my palettes by pressing the Tab key. I can grab a tool or make settings and dismiss everything with one button. Consider a keyed "hide" option if your application has multiple palettes. Another possible solution I would like to see is giving users opacity control for palettes. It would be fantastic if I could set my palettes to be semi-transparent. Even better, when I click my mouse to perform a task, my palettes would ghost or vanish, allowing me to use my entire work space. No keystrokes.
Microsoft Word X has an intriguing way to handle palettes. They’ve taken items that normally might be considered separate palettes and combined them into one. Their size is managed by making them expand and grow as needed. I really like this feature. The only drawback to their solution is that the palette can actually expand right off your viewable screen.
Nothing is tastier than good feedback. I was recently testing an application that told me that it was running by displaying the word “Running.” Although a fantastic application, this simple static feedback leaves me a little wary. I like to see an application that uses some type of iconic representation to show me something is happening. Now don’t go placing huge garish icons that pulsate or blink mercilessly. Simple progress bars and small icons in motion add an element of action without annoying the user.
Not only do you need to be consistent with your apps internal functions, you need to be consistent with Aqua. I have seen a lot of applications that ignore Aqua guidelines. Consider these items when building your UI.
 |
Remember that at some point everyone is a novice with your application. Your goal is to build an interface that makes sense, decreases the learning curve, and increases productivity. Take a look at other successful applications that you admire when designing your application. What makes their UI so appealing? Be sure that you take your UI design as seriously as you take your code development. In the next column, we’ll actually fire up Interface Builder and begin building our first UI.
Alan Graham is the creator of the Best of Blogs book series and is a frequent writer on the O'Reilly Network.
Read more Designing for Aqua columns.
Return to the Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.
