Creating The Perfect User Interface

It’s an old axiom in design, and one that we get more familiar with every day: Simple design isn’t simple.

If we have a role model out there in the world of industrial design, it would be Apple’s Jony Ive. Ive spoke with Wired back in 2003 about designing the PowerMac G5, which features the iconic aluminum casing that has since been adopted by all of Apple’s computers except the regular Macbook.  He said:

“We wanted to get rid of anything other than what was absolutely essential, but you don’t see that effort. We kept going back to the beginning again and again. Do we need that part? Can we get it to perform the function of the other four parts?”

This is exactly the crux I found myself in yesterday when working on some concept designs for a major new project.  Unfortunately, I can’t talk much about the project itself, so I apologize in advance if I sound coy at times.  What I can tell you is that one part of this app includes the ability to access a variety of menus (the food kind).  The entire app is being designed using a horizontal aspect.  The issue I was dealing with was in deciding how best to make the menu navigable to users.

The Easy Part

At first this seems easy enough But then the pesky details get in the way.  In this case, the food items were listed in French, with English descriptions, and a need to also display the price.  Should all of this data be contained within a single cell from a group of cells that take up the whole of the screen? Or, should the descriptions appear one at a time to the right side whenever users select from a skinnier menu on the left that just shows the item names? I chose the first route, because it might not be readily apparent to many users that tapping on each food item would cause the description to appear.  Further, for the side menu to scroll correctly while also showing the information we need to stay at the top, this single screen would have three different panes.

After deciding that all item information should appear in the same cell, the next question arrived: How should long food names be handled?  There were three options here. One was to have item names simply cut off after a set number of characters, to be followed with a “…” ellipsis (shown in the first line below.) The next would be to resize the text to get smaller as words got longer, in order to fit it all within a set amount of space (shown in line two below.)  The third option was to allow for multiple lines within the cell (line three below.)

The answer in this case was blessedly obvious after trying each out. In some cases, we don’t like using multiple lines in cells, because it constrains the number of choices you can show on screen at any point in time. Indeed, it’s possible that items with very long descriptions might take up the entire screen at once.  However, the importance of the information, in this case, dictates how the items must be handled.

The Hard Part

In a different area on this same screen, I needed to create a way to sort various menu items.  Users needed to be able to easily switch which area of the menu they were viewing, from appetizers to entrées and desserts.  In all, we had at least five of these sections, with the possible addition of a drinks and kids’ menus.  We tried a number of options out.

Segmented Control

The first option was a segmented control. The benefit here is that there is a visible color difference between the selected tab and the rest of them, while still showing all of the options at once.  The issue here is that it didn’t particularly look good as part of the overall screen. It also was limited in the options it could offer, even while in the horizontal iPhone view.

Bordered Bar

Using a background bar with embedded “round rect” buttons definitely looked better. However, this limited the button real estate even more. Even these five buttons only fit on the screen when cheating slightly by having a few of the pixels on each side bleed off of the screen. The worst part, and the dealbreaker, was that the round rect buttons don’t offer a simple method of changing color, so it would be difficult to indicate which screen a user was currently viewing. To solve this, we’d need an additional title listed below.

A further issue with both of the above options is that they didn’t account for whether the menu was for breakfast, lunch or dinner; in several cases, we would need these different menu types to be accessible.  Either a second bar would have to be placed under the first, which would create touch errors for many users due to the close proximity, or a pre-screen would have to be created, where users selected their menu type before accessing this screen.

We have two key mantras when faced with a situation like this: 1) Keep it all on the screen without crowding the interface. 2) The less taps, the better.  This led us to the solution.

Drop Down Menus

It sounds simple, right? I agree. That’s how I knew that it was the right answer.  It really is as Jony Ive says: users never see the effort required to distill an idea down to its barest and purest form.

The drop downs will activate “pickers”, which are the spinning menus that often appear when filling out a form and choosing from a pool of selections, like what state the user lives in.  In this case, users can pick not just which portion of the menu they’d like to view, but also which meal menu they want that information to come from. This works out because the drop down menus, of course, continue to display the currently selected option.

Final Thoughts

The difference between an app well made and an app made quickly is the amount of thought put into the small parts of the UI, like what is shown above.  That’s what makes me proud of Megaton’s design process: every element is considered, reconsidered and considered again in constant pursuit of the most natural experience.  If we have done our job effectively, users should never make an incorrect action out of confusion or be left unable to figure out how to do something. Options should be clear and easy, even if the labor necessary to develop them is neither.

-Casey Ayers