It's Not Magic!
The audience stares at the man on stage in complete concentration, hoping to catch a glimpse of his strategy. The man waives a black top hat around, showing it’s form and empty contents to the interested spectators. Next, he places a red silk handkerchief in front of the hat. Shouting “Voila!,” the man drops the cloth and reaches into the hat. Amongst the “Oooos!” and “Ahhs!” of the audience, a white rabbit hops from inside the magician’s hat.
Context is Key
Magic tricks are exciting because we are challenged to figure out what just happened, and how it fooled us. We’re left to ponder and to discuss amongst each other the magician’s strategy and skill. This curiosity of what and how information is revealed is entertaining to us.
But, this guessing is not acceptable when designing mobile interfaces. On mobile devices especially, we want to eliminate the confusion. Our users are not stationary, or focused entirely on the screen. They’re everywhere and they want information quickly, easy to locate, easy to identify, and easy to manipulate.
Understanding Our Users with Norman's Model
The reason why magic works to confuse us is because it takes advantage of our cognitive processing capabilities.
Donald Norman tells us there are two fundamental principles of designing for people: provide a good conceptual model, and make things visible (Norman: 1988).
A conceptual model, known more today as a mental model, is a mental representation -- built from our prior experiences, interactions, and knowledge -- of how something works. It’s our representation of how we perceive the world.
The second principle, "make things visible," is based on the idea that after we have collected, filtered, and stored information, we must be able to retrieve it to solve problems and carry out tasks. Norman indicates that this principle is made up of smaller principles such as mapping, constraints, affordances, and feedback.
Mapping
Describes the relationship between two objects and how well we understand their connection. On mobile devices, we’re talking about display-control compatibility. On a mobile device, controls that resemble our cultural standards, are going to be well understood. For example, let’s relate volume with a control. If we want to increase the volume, we expect to push the volume button up. If we want to read more information in a paragraph, we can scroll down, click on a link, or tap on an arrow. Problems occur when designs create an unfamiliar relationship between two objects. On the iPhone, in order to take a screen shot, you must hold the power button at the same time as the home button. This sort of interaction is very confusing, and impossible to discover unless you read the manual (or otherwise look it up or are told), and are hard to remember.
When designing mobile interfaces, consider to:
- Use our knowledge of cultural metaphors. An "X" is understood as close. When selecting the X, we expect its page or window to close.
- Use proximity. Make sure the display and control you are using have a proxemic relationship. A indicator whose function is to expand or reveal more information must be close enough to the information it will affect.
Affordances
Used to describe that an object’s function can be understood based on it’s properties. For example, a handle on a door affords gripping and pulling. The properties of the door handle -- it’s relative height to our arm's reach, that the cylindrical shape fits within a our closed grasp -- make this very clear. If an object is designed well and it clearly communicates it’s affordance, we don’t need additional information attached to the design to indicate it’s use.
When designing mobile interfaces, consider that:
- We expect all buttons to do something and change a display's state.
- Physical buttons afford pushing, pulling, or turning.
- Screen buttons afford touching, selecting, and clicking.
- Depending on context, images, words, and graphics may afford selecting.
- If we cannot recognize that an object is supposed to reveal more information, then the user will ignore it, assume it is decoration (and therefore not functional) or not understand how to interact with it. "Affordanceless" interfaces, such as those where gestures are required but have no indicators at all, are a real concern in this area.
Feedback
Describes the immediate perceived result of an interaction. It confirms that action took place and presents us with more information. In a car, you step on the accelerator. That action has an immediate result. The feedback is that you experience the car moving faster. On mobile devices, when we click or select an object, we expect an immediate response. Feedback can be experienced in multiple ways: A button may change shape, size, orientation, color, or position. Or very often a combination of these. A notification or message may appear, or a new page might open up. Feedback can also appeal to other senses using haptics (vibration) or sounds.
When designing mobile interfaces:
- Be sure to design actions that result in immediate feedback. This will limit confusion and aggravation while making the user’s experience more satisfying.
- Create a change of state (color, shape, size, sound) that is measurably different from its initial state.
Use confirmations when user data could be at risk of being lost. See Control & Confirmation part.
Constraints
Restrictions on behavior can be both natural and cultural. They can be both positive and negative. Remember the toy with cut out spaces resembling geometric shapes? A child is to take a yellow plastic shape and fit it though the space in the red sphere that it matches. A cylinder fits into the circle cut out, the cube fits inside the square, but will not fit in the triangle slot, etc. The size and shape of the objects are constraints in making the correct fit. Those are examples of natural constraints (though still learned). Cultural constraints are applied to socially acceptable behaviors. For example, it’s not socially acceptable to steal from someone or throw your friend's phone out the window to get their attention.
When designing mobile interfaces use constraints:
- To reduce or prevent user error. When you accidentally press delete instead of save, you should be provided a constraining confirmation message that requires your action.
- Of the size of the viewport.
- To have unimportant buttons become inactive but visible.
Norman’s model of design is a framework that should be referred to when using patterns to revealing more information. For more of a complete understanding of his model, refer to his book, The Design of Everyday Things.
Designing For Information
A good way to start thinking about the entire topic of interactive design is that it is about displaying information. A discussion of detailed information architecture is beyond the scope of this book. Interaction design about presenting detailed information and results is however well within the scope of our discussion.
Displaying detailed information requires an understanding of the user, their context and goals and of the information available. In many cases, information should not be hidden behind a link or other action, and should be immediately available; how useful would the clock on your mobile be if it was behind a "current time" menu item?
If this seems extreme, consider many systems we encounter every day, and which are regularly griped about. Say, checking on an airplane flight. Once you sign on, most of these sites still require clicking on your itinerary and so forth to simply find out if the flight is on time. Yes, even if you only have one flight stored under your identity.
But much other information is of a second tier nature, and demands user input to be displayed. You must decide...
How to access the information: Access methods, like links, are discussed in the Widgets section under the Lateral Access and Drilldown chapters. The patterns in this chapter are almost entirely used for "drilldown" or getting further information, but explicit decisions must be made about the information architecture, and understood by the project team in order to make the right decision.
How to display the information: Display may be of two basically different types:
Display Full Page: Full pages are generally part of a process, and the user should ideally not have to go back to the previous page in order to view other information. Doing this repeatedly can be perceived as bouncing back and forth confusingly, as is sometimes called "pogo sticking." However, for processes where large amounts of content will be entered or consumed, it is the correct method.
Reveal in the Context: For quickly glanceable information, or to help the user decide how to proceed, information should be revealed quickly and easily within the context. A Pop-Up is a contextually-revealed item, because the
Sometimes, the simple facts of the information available will demand full-page presentation of information where the user's context and tasks may otherwise demand that it be displayed in context. Use access and display widgets carefully to provide access to the information, or reconsider if the information architecture can be redesigned to make this simpler.
Patterns for Revealing More Information
The most common method of revealing information, that of displaying an entirely other page, is not covered in these patterns. That is simply because there is very little to say about it. Linking widgets and the many display patterns, such as those listed under Display of Information cover these functions. In some cases, patterns listed other places offer alternative methods, and these will usually be cross-referenced within the pattern. For example, Windowshade is very similar to Fisheye List and the two may both be used for the same purpose when implementing the same product on different platforms.
The patterns detailed in this chapter are concerned with specialized methods of presenting more information, which have no other uses.
These patterns have been developed and refined based on how the human mind processes patterns, objects, and information:
Windowshade. This pattern should be used when a displayed element must be able to easily reveal a small or medium amount of additional information, without leaving the current context or page.
Pop-Up. This pattern should be used when a displayed element must be able to easily reveal a small or medium amount of additional information, while remaining associated with the current context or page.