Microinteractions (2014)

Chapter 5. Loops and Modes

On January 4, 2004, a 400-pound, six-wheeled, solar-powered robot landed on Mars, in the massive impact crater Gusev. The robot was the $400-million-dollar Spirit rover that had taken over a year to build. As Passport to Knowledge reported, Spirit had just survived the six-month journey to the Red Planet and a perilous landing, including bouncing as high as a four-story building on first impact with the surface. The Jet Propulsion Laboratory (JPL) team that built and commanded the rover thought the worst was behind them. They were wrong.

Once the (literal) dust—red—had settled, Spirit began its mission of taking pictures and performing scientific experiments, rolling toward a nearby destination (“Sleepy Hollow”). But then on January 21, less than three weeks into the mission, something happened. NASA’s Deep Space Network lost contact with Spirit.

At first, the rover’s disappearance was blamed on a thunderstorm in Australia disrupting the network, but no, there was something wrong with Spirit itself. The next day, a transmission arrived from Spirit: a single beep that indicated the rover was still there, but that was all. This was seriously bad. If the problem was a critical hardware failure, the robot was dead and its mission was effectively over.

Trying a number of methods, JPL finally coaxed the rover to send diagnostic data, which it did on January 23. Much of the data was just repeated nonsense, but it did give them some insight into what was happening. The news wasn’t good: higher internal temperature than was expected, and lower battery voltage. Normally, the rover’s computer is only on five or six hours a day to save battery power and to prevent it from overheating, but the data showed the rover wasn’t going into sleep mode, and thus burning battery power and overheating. If this condition continued, the rover would destroy itself. As Mark Adler, one of the tactical mission managers, put it, “What we had on our hands was one sick rover. Spirit had insomnia, a fever, was getting weaker all the time, was babbling incoherently, and was largely unresponsive to commands.”

NOTE

Adler’s gripping first-person account can be read in full in “Spirit Sol 18 Anomaly,” by the Planetary Society Blog at this link.

Frantic, the command team sent Spirit a SHUTDWN_DMT_TIL (“shutdown dammit until”) command, which puts the rover to sleep. Spirit accepted the command and the JPL team breathed a sigh of relief. Just to make sure, they sent a beep to the rover; if Spirit was really asleep, it wouldn’t respond.

It did.

Spirit wasn’t responding to commands, and because the Earth was “setting” inside the crater, the JPL didn’t have another chance to try something else until the next day. Meanwhile, Spirit was overheating and running out of power. Time was running out.

The JPL team regrouped to figure out what exactly was happening. They came up with a working theory: that Spirit was in fault mode, meaning it was trying to reboot itself after encountering a problem that it couldn’t solve—basically just like all of us do with our gadgets when they become unresponsive. The problem was that Spirit seemed to be trapped in fault mode, rebooting itself over and over. It was encountering a problem while rebooting.

Later, it would be figured out the problem was with a software update that had happened while the rover was en route to Mars. During the update, a utility to delete the old software files was uploaded, but the upload failed and no one noticed—or else it was ignored. The result was that there was less file space available because it was being taken up by the older files. So when Spirit started running experiments and saving data, the file system overflowed. To try to fix it, Spirit rebooted itself. (This was what it was supposed to do.) The problem was that the reboot couldn’t complete due to insufficient available file space, which Spirit tried to fix by rebooting. And thus an infinite loop of reboots was entered.^[40^]

The command team didn’t know this at the time; they just guessed Spirit was repeatedly rebooting and had to figure out how to stop it before the rover was irreparably damaged. JPL suspected that, since the problem persisted through reboots, the issue was either the flash memory, the EEPROM, or a hardware fault. (If it had been hardware, the rover would be irreparable.) Fortunately, the rover engineers had anticipated problems with the flash memory and EEPROM, so they’d designed a way the rover could be booted without ever touching the flash memory: the radio that received commands from Earth could also execute a limited number of commands itself, one of which was telling the computer to reboot without using flash memory. The JPL team sent the command to the radio several times before it finally worked and the loop was broken. Relieved, JPL retrieved some data, and put Spirit into a long-overdue sleep.

Luckily, this story has a happy ending, in that Spirit returned to full operation on February 5, 2004, and continued operating for years, even though its solar panels were designed only to last three months and even after getting stuck in a sand trap for two years. The last successful communication with Spirit was in March 22, 2010—nearly seven years longer than JPL expected—and NASA officially ended Spirit’s mission on May 25, 2011 after “a stressful Martian winter without much sunlight. With inadequate energy to run its survival heaters, the rover likely experienced colder internal temperatures last year than in any of its prior six years on Mars.” As of this writing (March 2013), Spirit’s twin rover, Opportunity, which arrived three weeks after Spirit, is still exploring the surface of Mars.

A mode, like Spirit’s fault mode, is a special part of an application in which the app operates differently than usual. Often, this means actions like pressing a key does something else when in a particular mode. A loop, like the reboot one Spirit was stuck in, is traditionally a command or series of commands that is repeated. (As we’ll see, it’s defined slightly differently for microinteractions.) As the near disaster with Spirit reveals, loops and modes can be tricky things, even for the conservative, thorough NASA.

Modes

A mode is a fork in the rules, and for microinteractions, modes should be used very, very sparingly. Most microinteractions should be mode-free, but sometimes they are necessary. The best reason to have a mode is when there is an infrequent action that would otherwise clutter the microinteraction’s main purpose. One common mode is a settings mode, wherein the user specifies something about the microinteraction. When you’re in settings mode, you’re not usually performing the major task, just modifying it. It’s separate from the rest of the interaction. Examples of this are in weather (see Figure 5-1) or stock market apps, when you select cities or stock ticker symbols to get data on them. You’re not performing the main action of the microinteraction; it’s a deviation in the rules that takes you away to do one subtask, then return.

Figure 5-1. An example of a mode from Apple’s Weather App for iOS.

The reason to avoid modes in general is that they can cause errors, especially if the mode is just an invisible state the screen is in. Turning on an edit mode, for example, makes a once-familiar screen something the user has to relearn. An action, such as clicking an item, could do drastically different tasks: selecting the item in default mode, deleting it in delete mode. The fewer modes—and in microinteractions, there should be no more than one, and zero if possible—the less chance of users being confused about what mode they are in, and the less they have to learn about how the microinteraction works.

If you must have a mode, a good practice for microinteractions is to make it its own screen whenever possible (or whenever there is even a screen). (This is the one exception to the “don’t make a screen for every rule” principle discussed in Chapter 3.) This will help reduce errors and frustration, because it will hopefully make it clearer to the user they are in a different mode, not just an unfamiliar state. A transition to the new mode—and back to the previous (default) mode—can be a useful cue here as well, indicating to the user they are going somewhere else to do something specific.

When a user goes to one mode and comes back to the previous mode, they expect the original mode to be in the same state as they left it, although perhaps any changes performed while in the other mode will be reflected in the default mode. For example, in a weather app, if I add another city in the Add a City mode, when I return to looking at weather data, I should see the new city there.

Spring-Loaded and One-off Modes

It’s annoying to have to switch to a different mode to perform one simple action. Two variations of modes that could be used in microinteractions in addition to (or in place of) traditional modes are spring-loaded modes and one-off modes. With either of these variations, the user can’t get trapped in an unknown mode.

Spring-loaded modes (sometimes called quasimodes^[41^]) are only active when a physical action such as pressing a key or holding down a mouse button is occurring. As soon as the action stops, so does the mode. The classic example is pressing the Shift key on your keyboard, which turns on caps lock mode, but only while pressing the Shift key. The Alt, Option, and Command keys also often turn on a spring-loaded mode.

The value of a spring-loaded mode is that the user seldom forgets that they are in a different mode, because they are doing something physical to make that mode possible, and it doesn’t require switching to a different screen. The drawback is that it doesn’t work well for actions that take some time to execute or require complex input.

For microinteractions, spring-loaded modes are best used sparingly, and probably mostly on devices and appliances. Pressing and holding a Start key can cause a reboot or reset, for example.

Spring-loaded modes can also be an invisible trigger that brings users to a microinteraction. Autofill in a search field is an example of this. Autofill only appears when there is text in the field, so it’s a type of spring-loaded mode.

The same is mostly true with one-off modes. One-off modes are when a user initiates a mode that lasts for the duration of a single action, then the mode turns off. For example, double-tapping on text in iOS brings up its cut-and-paste features, which disappear after one command has been selected. Newer versions of Microsoft Office have a so-called “minibar” of formatting tools that appears only when a user highlights some text. And in OmniGraffle, after a single use, a selected tool (such as the line tool) reverts back to its default state (the pointer). One-off modes are most useful for rapid task switching (as in OmniGraffle) or for contextual use (as in Office and iOS).

One-off modes can also be helpful for gestural and voice microinteractions. For example, in some voice interfaces, such as on the Xbox with Kinect, a command word (in this case “Xbox” being it), could be the trigger, which initiates a one-off mode in which another command could be issued. “Lights! Dim!” or “TV! Off!” (A fictional version of this is in Star Trek: “Computer, Locate Commander Riker!”) Similarly, with gestural interfaces, one gesture such as a wave could trigger the microinteraction, putting it into one-off mode in which another gestural command could be issued. In both these cases, one-off modes prevent accidental triggering. In both these examples, the one-off mode would have to time out after a certain period of time, and for that, you need a loop.

Loops

A loop (in microinteraction parlance) is a cycle that repeats, usually for a set duration. The cycle can be microseconds, minutes, days, or even years. Loops are all about timing, determining the pace and the overall lifespan of the microinteraction. Although most microinteractions are generally short in duration, they or parts of them can repeat, and thus have a longer “life” than just a brief moment.

A loop is something indicated (directly or indirectly) via the rules. “Get data every 30 seconds” or “Run for three minutes, then stop” or “Send a reminder in 10 days” are all example indicators that a loop is involved.^[42^]

Styles of Loops

We’re concerned with four kinds of loops:

Count-Controlled (For) Loop

This repeats for a set number of times before ending. For example, check if there is network connectivity 10 times before giving an error message.

Condition-Controlled (While) Loop

This repeats while a certain set of conditions is met. If the conditions change or end, so does the loop. If there is a network connection, check for new Twitter messages every minute.

Collection-Controlled Loop

Similar to a Count-Controlled loop, this loop runs through everything in a set, then stops. Example: for each unread email, add one to the unread counter.

Infinite Loop

A loop that begins and never ends until there is an error or someone shuts it down. As with the story of the Spirit rover, these are generally to be avoided, but a microinteraction like turning on a light basically starts an infinite loop: the light doesn’t turn off again until the whole microinteraction is turned off or the light bulb burns out.

Additionally, there are two kinds of loops: open or closed. Microinteractions make use of both for different purposes. Open loops do not respond to feedback; they execute and end. (“Every day at 10pm, turn on a light.”) Closed loops have a feedback mechanism built in and are thus self-adjusting. For example, a closed loop could be one that, while the car is running, checks the engine noise level and adjusts the car stereo volume accordingly.

As with the algorithms we discussed in Chapter 2, defining the parameters of loops can contribute mightily to the user experience. Too few cycles in a loop can make the experience feel rushed or intrusive; too long a loop could make the experience sluggish and nonresponsive. Figure 5-2shows an example of a timing loop.

Figure 5-2. Moo starts a timing loop after an order has been placed, to show users how long they have to edit a recently placed order. (Courtesy Matt Donovan and Little Big Details.)

Loops can be used to make sure an action doesn’t go on too long or end a process or even the entire microinteraction. This could be done for security reasons, for instance when a banking site automatically logs you out after a few minutes of inactivity. This kind of automatic ending can be annoying, so use with care.

Figure 5-3. If a user clicks too many Add Friend buttons too quickly, Facebook gives the user a warning. (Courtesy Alfie Flores Nollora and Little Big Details.)

Loops can be used to recognize behavior as well. For example, if a user has paused at one part of the microinteraction for too long, the microinteraction could prompt them with help (Figure 5-4).

Figure 5-4. If a video has been buffering for too long, the TED site offers users the option to download it for later. (Courtesy Justin Dorfman and Little Big Details.)

Sometimes just the repeating (an open loop) is enough. But the most powerful loops are those that take place over long durations and/or are closed loops that adapt over time to behavioral feedback. These are long loops.

Long Loops

“Something in design has gone wrong when objects don’t mature in a way that makes them more desirable.”

—Deyan Sudjic

Let’s talk about hammers for a moment. Hammers, like most tools, are very good for a few discrete activities—just like microinteractions. In the case of hammers, this is pounding or removing nails, as well as occasionally smashing something. But microinteractions aren’t hammers. They can have memory. They can use data. They can loop, sometimes endlessly. When designing microinteractions, you can use what I’m calling long loops and focus not only on doing an individual task, but also on a longer timescale. What can be done to make the microinteraction better the second time it’s used? The tenth? The ten thousandth? Figures 5-5 and 5-6 are examples of microinteractions that have undergone looped modifications.

Figure 5-5. The songs in the “Added” column on Spotify fade over time. (Courtesy Jorge Nohara and Little Big Details.)

Figure 5-6. YouTube indicates recently made searches in purple. (Courtesy Davide Dettori and Little Big Details.)

Loops can deliver what design strategist and CEO of design consultancy Adaptive Path Brandon Schauer calls The Long Wow. The Long Wow is about delivering new experiences or features over time instead of all at once, and by doing so building customer loyalty (see Figures 5-7 and 5-8). For the purpose of microinteractions, The Long Wow is about adapting the microinteraction over time so that it feels customized or even brand-new. This requires a long loop, perhaps one that lasts the duration of the device the microinteraction is contained in or even beyond, if behavioral data can be stored remotely or transferred to a new device.

Figure 5-7. Threadless sends users an email when items in their cart are about to sell out. (Courtesy Little Big Details.)

Figure 5-8. Remember Me is the great broken loop of the Internet. What even happens when you check the box? Does it automatically log you in? (Unlikely.) Most times, it doesn’t even remember you checked the box, leaving it unchecked. (Courtesy Jack Moffett.)

One use of these long loops is to extend the microinteraction far beyond a single instance of use. A weekly reminder of items placed on a wish list is one example, or the “Remember Me” checkbox that no website seems to remember is another. When a user returns to the microinteraction, ideally there is some memory of previous use. A user who likes to play her music loud may have different volume settings than someone who doesn’t.

Figure 5-9. ThinkGeek allows users to temporarily unsubscribe while the holidays are ongoing. (Courtesy Kayle Armstrong and Little Big Details.)

Progressive disclosure or reduction

Another use of long loops is progressive disclosure over long periods of time. As users become used to a product, they don’t need as much handholding, and instead can be treated as a more skilled user. For example, shortcuts could be added to a microinteraction after it’s been used a few times, or more advanced features added.

Another option is progressive reduction, where the microinteraction becomes simpler over time, as the user becomes skilled and doesn’t need items such as labels for guidance (see Figure 5-10 for an example). However, care must be taken; if the user doesn’t engage with the product for a while, the microinteraction might have to become more robust and obvious again. The benefit to users is a cleaner interface, one that rewards and makes use of a user’s familiarity with a product.

Figure 5-10. An example of progressive reduction from LayerVault. The signpost button’s default is a large icon with a label. As the user becomes proficient, the label disappears. And eventually for experienced users, the button is de-emphasized altogether. (Courtesy LayerVault.)

As the near-disastrous story of the Spirit rover on Mars reminds us, loops and modes can be tricky to implement and maintain. However, their use can make a microinteraction cleaner (by moving infrequent actions like settings to a mode) and richer, by having the microinteraction adapt to use over time.

This completes the structure of microinteractions. Now it’s time to put everything together that we’ve learned.

Summary

Only have a mode when there is an infrequent action that might otherwise clutter the microinteraction.

If you must have a mode, make it its own screen when possible.

For rapid actions, consider using a spring-loaded or one-off mode instead of a traditional mode.

Use loops to extend the life of a microinteraction.

Carefully consider the parameters of loops to ensure the best user experience.

Use long loops to give the microinteraction memory or to progressively disclose or reduce aspects of the microinteraction over time.