I have always wanted to write a series of articles on user interface design from the ground up, but I’ve never seem to have the time. Well, it’s time to take the time, and now that I have this beautiful little 2.8″ TFT Touch Shield that thus far I’ve been using to show how to render 3D graphics, I figured it was time we put it through its paces for what it was intended to be used for: as the input touch screen to control some cool little gadget.
So we have a blank canvas–and we toss in a button here, some text there, a cute icon below that–and we call it a day. Simple, right?
I want to discuss a more systematic way to think about user interface design, one which allows us to think about how to assemble our interface so that users find it easy to use, can engage in complex interactions with the user, and can be extended to provide a consistent visual language that can give your gadgets pizzaz.
First, let’s define what we actually mean by “easy to use.”
Waaaaay back in the dark days before there was an Internet, at the very beginning of computer-user interfaces, a division of Xerox was doing research in creating easy to use computers for the office place. Faced with a blank screen, they decided to model their interface after real-world physical things we encounter on a day to day basis. Apple used this as the basis for their own computer interface, and crafted human interface guidelines based on their recommendations and based on an established set of user interfaces.
This set of standard controls included radio buttons–so named because they resembled the behavior of old mechanical car radios, which could tune a radio station quickly but only one was active at a time.
They created check-boxes, borrowing visual language from filling in forms, where you can check off the appropriate boxes which match your choice.
We also got buttons, which were modeled after their electronic counterpart, pull down menus (which borrow their name from restaurant menus, where you have a list of things you can pick from), and text fields, which does not have a real good counterpart in the real world.
And the notion was that so long as you used these controls–and used them consistently, according to the detailed human interface guidelines provided by a company like Apple, then a user would know how to use your application.
What Apple did was create a set of affordances, things that, once we learned what they meant, we would remember how to use them.
Affordances are, in essence, the hints we have in the objects that surround us which give us an immediate idea how that object is supposed to be used. A teapot has a handle, and the shape of the handle tells us we should grab it if we want to pick up the teapot. A door has a knob or handle; the shape of the knob tells us to rotate it to open the door.
At a more fundamental level, however, an affordance is–in a very real sense–a visual language. We know if we see a circle with some text next to it, it’s a radio button–and if we tap on it, we’ll change its state and deactivate the state of the other related buttons.
But it doesn’t mean this is the only way we can represent picking one of a list of items. On the iPhone, one can use a picker view instead.
Some ‘Affordances’ may not even have a particular shape or color or size–but may be based solely on the position the thing occupies on the screen. For example, on the iPhone, the upper part of the screen generally has a button on the left or the right. The button itself is not marked out; we only know the button exists because we’ve become accustomed to the idea the word on the upper left and the uppper right of the screen is a button–and generally the button on the upper left backs us out a screen.
The point is not that we should use a particular design.
The point is that simplicity comes from consistency.
If we know “cancel” or “back” is in the upper-left, we know to always look to the upper left for a cancel or back button. Placing the cancel button in the lower right would be confusing if we got used to the cancel button being somewhere else.
And “language” can even extend to gestures or physical controls. For example, on the side of our phones we know there are two buttons: the top one turns the volume up, the bottom one turns the volume down. If the “volume up” button suddenly turned your phone off, you’d think something was broken.
We could, in theory, conceive of a user interface that consists of a screen full of information, a rotary knob that can be pressed, and a back button. If the back button takes you back a screen–it should always take you back a screen. If suddenly going back means twisting the knob sharply to the left–users will be confused. And they may think your system is broken.
In essence, our user interface is a language, like English, like Latin–but the “domain” of our language is rather limited. You’re not going to talk to your house thermostat about what’s for dinner–but in its domain (what temperature you want your house to be at), your thermostat provides a language: turn the knob to change the temperature. Flip the switch to turn on heat or air conditioning. Flip another switch to turn the system on or off. And a third switch for changing the fan settings.
And that interface is “easy to use”–because it is discoverable: you can find the switch–and you know when you see a switch how to flip it. You can see the knob–and the dial indicates the temperature in the room and the temperature you want it to be at. And it is consistent: when you flip the fan switch, the fan changes state: flipping the fan switch doesn’t order pizza from Domino’s or opens the garage door.
Now of course we’re talking about a small 2.8″ touch display. But the same principles apply. You don’t have to make your interface look like anything else–but you have to make your interface discoverable: does the user know what can be tapped on? Does the user have an idea when something is tapped what it will do? Does the user know what cannot be tapped on?
And it’s consistent: do things that look like they can be tapped on do something when they’re tapped? Do they do the same thing when they’re tapped–does a radio button always behave like a radio button and a check box like a check box? Do things that cannot be tapped do nothing when tapped–or are you hiding behavior where the user cannot discover it by being inconsistent?
Further, like any other language, our user interface language has nouns–that is, things we are acting on, and verbs–actions we are taking. More complex applications can even have adjectives: modifiers that describe the nouns of our language, and adverbs: modifiers that alter our verbs.
And when we “talk” to our computer, we are in essence using our interface to construct simple sentences to describe what we want to do. For example, in a drawing application, our “nouns” may be the lines, circles and blocks of text we’re manipulating, and our “verbs” are the ways we are modifying our objects.
Our language may look like this: “Please move that line” (picks the line) “over there” (drags the line to its new location). Or “please draw a new line” (picks the line drawing tool) “over here” (clicks and drags a new line on the screen).
Sometimes the object we’re acting on is implicit: the thermostat knob only changes the temperature. Sometimes the order in which we pick the noun (the object of our action) and the verb (the action we are taking) can be reversed: we may pick a tool which shrinks everything we touch in half.
And sometimes our language has contexts. For example, we may have a programmable thermostat; on the ‘main screen’ the knob controls temperature. But on another ‘screen’, the knob controls the time during the day when we want to raise or lower the temperature. This context can be thought of as a way to pick nouns on a limited screen (what temperature do you want for your house?), or it could be thought about as a “context” where we are having a conversation: in the kitchen, a ‘cup’ may mean something entirely different than a ‘cup’ on a football uniform.
As a side note, it is the failure to adhere to these two basic principles: discoverability and consistency–for example, consistency in how you construct complex sentences as you “talk” to your computer–which make some applications harder and harder to use.
In other words, you are not stupid. The designers who designed the application you are having a hard time failed to adhere to these basic principles, and they failed to adhere to some of the other principles outlined in the book Designing with the Mind in Mind, such as responsiveness–the fact that when the user interacts with a computer they expect the computer to respond quickly, even if the response is “stand by.”
And increasingly more and more “UI Designers” are being hired out of art school with no formal training in affordance theory or in the necessity for discoverability and consistency.
Its also worth talking about color. Color is a great way to augment a user interface–and certainly a colorful interface is an attractive one. But you need to consider color as part of your language–as a way to augment the information you are presenting, such as using color to represent adverbs to the nouns of your language.
But you need to be careful when using color. Partially because some people are color-blind. And partially because you may not get to use a beautiful color display when developing your language–so you need to have another way to specify your adjectives.
Where is your color God now?
All of this is a long-winded way to say we need to think of what we want our visual language to look like, and we need to consider how we pick the things we act on and how we act on them. That includes determining the appearance and behavior of our controls–with consistency being key–and the way we specify the things we are operating on and the things we can do to them.
And today we will start designing our visual language by taking inspiration from Star Trek.
Of course there are two immediate problems we face here. First, the original LCARS interface is copyright CBS Studios. And second, there is no real consistency between screens; the layout of the screens vary according to the artistic needs of the episodes rather than are designed according to the principles of discovery and consistency.
But we certainly can use the ideas here as a launching off point.
For our design we’ll use some of the shapes but then design a standard language for our visual interface that relies on these basic shapes to function.
First, we’ll start with a sloped inverted L shape. We’ll use this to divide the screen from a top part which contains a title and an optional ‘cancel’ button in the upper left, and the bottom half. If we have ‘nouns’ we intend to operate on, we can put them along the left column of the inverted L pattern; pressing one can either navigate to a new screen or update the content area as appropriate. Otherwise, we can hide the left part and simply have a bar.
We will also create basic button groups. The idea is that these are all buttons that are related to some piece of functionality. We group them by using rounded corners.
Finally we’ll use a grouping that contains a rectangular region on the left to indicate a group of radio buttons.
We’ll use this as the start of our visual language for buttons and radio buttons, as well as navigating between screens and picking the ‘nouns’ we’re operating on.
Now that we’ve sketched some ideas–and have a framework in which to use these ideas–next time we’ll start building the code, including our custom font and some changes to the Adafruit GFX library to reduce flicker when pressing a button.
The Hacking Den 