}}}
[[http://www.amazon.com/gp/product/1449394639/ref=as_li_tf_tl?ie=UTF8&tag=4ourthmobile-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=1449394639|{{attachment:wiki-banner-book.png|Click here to buy from Amazon.|align="right"}}]]
== Quiet Please ==
The lights in the theater dim. Voices die down. All eyes stare at the giant illuminated screen and silence overtakes the room. Projecting now, the movie begins. Starting from high above a city, the audience’s view mimics the flight of a bird. Slowly, as the view trickles down below the clouds, a row of houses appear. Dropping lower, the view focuses to one house in particular. We enter the house; it’s dark, old, and abandoned. Slower now, the camera leads us down the stairs to the basement.
The audience is coaxed into believing something isn’t quite right. Attention is focused on the closed closet door, now bringing an increase in fear and tension. Something terrible is about to happen; the audience waits. The camera leads the audience closer to the door. Closer. Closer. Closer. Not a sound to be heard now. Then it happens! The sound of Lady Gaga’s “Bad Romance” chimes loudly, breaking everyone’s concentration. Heads turn and eyes seek to identify the location of the sound and culprit. The patron embarrassingly finds her mobile phone and switches it off.
Yes, it’s annoying when someone forgets to turn off her phone. But hey, people make mistakes. Mistakes happen every day in our lives. Some mistakes go unnoticed, while others can be quite catastrophic. Some mistakes are caused by us, others by objects in our environment. But many mistakes can be prevented!
== That Was Easy ==
How could the mistake of the lady not turning off her phone have been prevented? If only she had an “Easy” button to push that would have allowed her to start over and turn off her phone prior to the movie beginning. Maybe through a distributed cognitive network, her friends could have reminded her. Or maybe the situation could have been resolved if her mobile device detected that she was in a movie theater, and incorporated constraint controls, such as automatically defaulting her device to vibrate.
Unfortunately, life doesn’t provide us with a personal “Easy” button to turn a complex sit- uation filled with chaos and mistakes into one of error-free simplicity. Relying on friends can be, well, unreliable. Having our device provide controls and constraints to limit our careless mistakes seems plausible and doable. Therefore, as designers we need to equip ourselves with a general understanding of why we make mistakes to begin with.
== Understanding Our Users ==
[[http://www.flickr.com/photos/shoobe01/6501514855/|{{attachment:ControlIntro-Pop.png|Figure 3-1. Pop ups and similar controls are key to Confirmation, Sign On, and many other types of interactions due to their modality. The user is required to make a choice, and this both focuses the user’s attention and prevents her from accidentally performing errors.}}]]
We must accept that we are human and we make mistakes because our body has unique limits. We are limited in our cognitive processing abilities which are constrained by capacity and duration. We have physical limits in our endurance and strength. We have ergonomic limits in our reach and rotation. We have perceptive limits in what certain electromagnetic and mechanical wavelengths we can detect and filter.
Mixed together with our limitations, we expend a lot of cognitive energy to process and interact with the enormous amounts of stimuli in our environment. Our attention on the task at hand will affect which environmental stimulus needs to be filtered, focused on, and stored. Think of the human mind as a leaky bucket that is constantly being filled. As more and more stimuli are collected through sensory memory, most will be lost due to filtering. Important stimuli will be processed and stored using our working and long-term memories.
Humans have also developed ways to reduce the mental load required to process information. According to Payette, this is possible because cognition is embodied, situated in an environment and distributed among agents, artifacts, and external structures (Payette 2008). We do not solely rely on our individual human limits to process information all the time. We can embed our knowledge of the world in objects that serve as episodic reminders to help us recall. We can distribute our cognitive load to multiple agents or devices. Consider a grocery list. We could try to store all that information in our heads and hope to recall it by the time we get to the store. But it is more effective to situate our cognition in a notebook where we can write down the entire list.
We then no longer need to recall each item. We just need to recall that the notebook con- tains the list. Further, we can distribute our cognitive load among others. Let’s say we are in a baking class that teaches only how to make cakes. Rather than have everyone remem- ber to buy all the ingredients, we can assign each person a specific ingredient to purchase. Can we reduce cognitive load and error even more? Yes. Let’s distribute all cognitive load onto technology. What if your refrigerator monitors your shopping habits and cooking behaviors, and can automatically sense which ingredients you need? Then it sends a grocery list order via SMS to your local supermarket. You mobile device can confirm your order was placed, the amount can be charged to your bank account, and you can be notified when your order is ready to be picked up!
== Control and Confirmation ==
Because not all devices are designed today to absorb all our cognitive load, as in the pre- ceding example, this chapter will provide methods that help distribute that load to create enriching situations while preventing user error. Throughout this chapter, cognitive frameworks are presented to help us understand how people process information. These frameworks apply when interactions require control and confirmation:
''Control''
This refers to respecting user data and input while protecting against human error, data loss, and unnecessary decision points. This is a key principle of mobile design.
''Confirmation''
When a necessary decision point is needed, an actionable choice is modally presented to the user to prevent human error. Before adding modal confirmations, consider the following:
* Is a decision point required here that needs confirmation from the user?
* Will having this confirmation eliminate risk of human error and loss of input data?
Do not use confirmations arbitrarily or excessively. They will increase user frustration by:
* Stopping the user’s goal from automatically happening by presenting a confirmation
* Forcing the user to read, understand, decide, and then act on the confirmation
* Increasing unnecessary mental load through the entire process
For example, let’s say a user’s goal is to enlarge an image on his mobile device by touching it. Would this particular situation require control and confirmation to prevent human error from occurring? And if so, can human error lead to a drastic consequence? In this example, the user’s risk for error is low. Security is not compromised, and loss of data is not imminent and likely to follow. Therefore, having a control or pop up modally appear with a confirmation message asking “Would you like to enlarge this image for viewing?” is not necessary. This will create user frustration.
Let’s examine another example. This time a user is at an ATM with a goal to withdraw money. The user’s risk for error is moderately high. Security can be compromised and money loss can occur. In this case, having a modal message appear to confirm the amount of money withdrawn may be viable and necessary.
== Patterns for Control and Confirmation ==
The patterns detailed in this chapter are concerned with specialized methods of preventing and protecting loss of input data. In some cases, patterns listed in other chapters will offer alternative methods, and these will usually be cross-referenced within the pattern. For example, [[Pop-Up]] may be referenced when creating patterns found in this chapter. See Figure 3-1 for some real-world examples.
''[[Confirmation]]''
When a decision point is reached within a process where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices.
''[[Sign On]]''
This pattern is used to confirm that only authorized individuals have access to a de- vice, site, service, or application on the device. Theory and principles of privacy and security will only be alluded to, and are not discussed. Please find appropriate refer- ences for these.
''[[Exit Guard]]''
This pattern is used when exiting a screen, process, or application could cause a cata- strophic loss of data, or a break in the session.
''[[Cancel Protection]]''
This pattern is used when entered data or subsidiary processes would be time-con- suming, difficult, or frustrating to reproduce if lost due to accidental user-selected destruction.
''[[Timeout]]''
High-security systems or those which are publicly accessed and are likely to be heav- ily shared (such as kiosks) must have a timer to exit the session and/or lock the sys- tem after a period of inactivity.
-------
= Discuss & Add =
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.
== Examples ==
If you want to add examples (and we occasionally do also) add them here.
== Make a new section ==
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.