Chapter 2: Changing the HTML Mindset (Part 2)
2.2 Creating a Flow
Flow as defined by Mihaly Csikszentmihalyi, identifies the state in which one ceases to think, but merely do, becoming so involved in and focused on an activity that everything else falls away. One can achieve flow reading a book, playing chess, running a marathon, painting a picture, or any other scenario where concentration is complete and consuming. This concept translates to software design as a state of total engagement in the workflow, thinking about the task, the creation, the content, NOT the software. Flow is a difficult state to achieve in anything, not just software. If an application is too rudimentary, the user may become bored, too difficult and she may become frustrated. Our goal as designers is to help users achieve flow, and do our best not to interrupt once it’s flowing.
As I sit here and write this in Microsoft Word, I focus on the words in my head, which fluidly translate to my fingertips. In these moments of flow, I’m not thinking about Microsoft Word, but rather my thoughts and my phrasing. When a squiggly red correction line suddenly appears or an autofill suggestion pops up, I find myself thinking about the software instead of my task. Both of these tools are useful to me, so I’m willing to put up with them instead of turning them off, but they are indeed flow breakers.
Rich internet applications absolutely empower designers to create that state of flow. When users can drag an item into their shopping cart (which uses a familiar metaphor of physical-world shopping), instead of hunting for a “Checkout” button, more thought is given to the task (shopping) than to the process (clicking a button). As you design, keep these principles in mind to foster flow in your applications:
2.2.1 Keep tools at hand
A good way to break flow is to send your user hunting for a tool. Sometimes it’s a button or function that the user knows is there, somewhere, but can’t find it. “Of course I can delete this email, but where is the button?” Other times it’s a deeper question of whether or not the tool exists and what it’s called, let alone where to find it. “I wonder if I can resize this picture? Where would I find a tool like that?” Providing these kinds of tools and information close by can shorten the hunt. The best kinds of designs, RIA and otherwise, support direct and local action wherever possible.
In the physical world, if you want to know more about the figurine on your aunt’s coffee table, you walk over to it, take a closer look, possibly pick it up (careful now!) and look at details like finish, manufacturer, artists’ name, etc. The same is true in RIAs. Tools and other contextual information can be revealed upon closer inspection, or upon interaction with the item. I call these localized tools. Luckily this is a great idea that’s catching on, and there are a hundreds examples of this on the internet, including inline editing, rollover buttons, auto-fill, tooltips, rating widgets, and on and on.
Localizing tools and information helps focus the user’s attention, resulting in more awareness of animations and other changes to the UI in that area. It also maintains a level of comfort for the user, knowing that necessary information and tools are always at the ready. This is the theory behind some other conventions from the desktop world, like right-click. As I will talk about in Chapter 3, right click menus have pitfalls on the web, but the sentiment of localizing tools is still an effective approach.
Obviously there’s a limit to the number of tools you can crowd into a small space. But before you shunt them off to a toolbar menu somewhere, prioritize the tools, and decide which ones are important enough to keep close by. And the other tools… if they’re not important enough to keep close by, are they important enough to keep? If the goal is clarifying the UI, the answer may be ‘no’.
2.2.2 Offer contextual help
A close cousin of localized tools is contextual help. Providing Help in applications is almost always under-considered and half-baked. Nine times out of ten “Help” for an application comes in the form of a tiny button in the corner that ushers you off to an HTML page that hasn’t been updated in a year. Not very flow-friendly. In really great applications, help is considered at the beginning, middle and end of a project and keeps itself in the context of the application. Providing help within the user’s field of attention supports flow.
RIAs offer some really neat and innovative ways to incorporate contextual help. One of these is tutorial help. This kind of help provides basic instruction about using the application, and often makes a distinction between first time use of an app and subsequent use. One example of this is a tutorial overlay, which is becoming popular. This is a somewhat transparent image placed over an application that includes high-level notes on button functions and basic tasks. This may be activated by the absence of a cookie (meaning the user has never viewed the application before) or may include a “Don’t show this again” type of checkbox for manual removal. I’ve also seen a surge in tutorial animations that appear on first time use. These can be very effective tools.
Another very popular form of contextual help is the tooltip, which is basically a block of informative text that is visible on mouse hover. Tooltips can be short and sweet, such as displaying a button’s name or function, or can contain lots of explanatory text or details about an item. This kind of interaction is really nice because it allows for a clean interface that relies on icons and other abstractions, while still revealing information for those who seek it out.
Inline messaging is a fairly new interaction type for the web that’s gaining ground. These are little contextual clues to the completion of a task, such as character-counters on fields with character limits, simultaneous feedback on form fields such as password, auto-suggestion and auto-fill, and status messages such as “your email has been sent”. I often see poorly executed examples of inline messaging, but I’m still really happy that people are going to the effort.
The usual design rules apply here of course, that messaging is clear, well-written, and supports flow. A caveat to the design of inline messaging is that you must also design a way to return to a neutral state. This can be accomplished manually, via a close button, or automatically by querying the back end for a status change that will prompt the interface to change back to neutral. Whether the message is related to status or an error, it will become irritating if it’s visible beyond its usefulness.
Aside from these types of contextual help, there are lots of other little helper fairies tucked into nooks and crannies of applications ready to do your bidding. Mini-calendar widgets are sent from heaven – how did we ever survive without them? Progress bars let the user know how much longer they must wait. Display of “number of steps” in a task informs the user where they are in the workflow. Adding user aids in context will keep your users happy and focused.
2.2.3 Error messages suck
Error messages and other dialogs break the flow every time. I know from experience that the reason users are often confronted with cryptic error messages is that designers tend to design for rainbows and sunshine. We envision what our application will look like in a perfect world, full of data and intermediate users and warm fuzzy feelings. But since developers by contrast always prepare for doomsday, it falls to them to create messages and dialogs for the failures they encounter while coding. It’s a little bit harder, although critical, that designers step back and design for the less optimal use case.
As the old adage goes, an ounce of prevention is worth a pound of cure, so at this point I will talk about some of the causes of error messaging in RIAs. With the emphasis on states in RIAs, messaging can get even more confusing. There may be many areas in your application with which users can interact. If an error message comes up, is it clear which area is causing the issue? I have often employed tabsliders to group information, and struggle with this frequently. The user can either have the ability to change focus to another tabslider (and risk later seeing an error message for data in a tabslider that is not open), or the contents of the tabslider must be validated (and the application is locked down) before the user moves on. Neither is really the optimal case. It is no small task for the engineers to create all of the scenarios in which the application is locked down until an error is corrected.
And at what point does the application query the back end to validate and check for an error? A familiar example of this is a traditional HTML form, in which fields are not validated until the “submit” button at the bottom is clicked. At that point the user gets a message that the format is wrong on the phone number, or they forgot to fill in the “city” field. Now we are seeing more real-time checking on forms, as in the password example above, but this results in a very chatty application and can be a very processor-intensive route to take.
Since RIAs are constantly loading data, images, etc., we also have to design for timeouts or failure to load. On some applications these take the form of a modal dialog (Video failed to load: click OK), but this seems unnecessary. Sometimes an error message can come in the form of an icon, as seen on HTML images that don’t load, or inline text.
Since some error/confirm messaging is unavoidable, there are a few techniques to ensure that they aren’t quite as jarring for the user. If you choose to incorporate modal dialogs, reserve them mainly for error messages, and go easy on confirmations. Modal confirmations should be reserved for somewhat high-stakes actions (Are you sure you’d like to shut down the electrical grid for Northern California? Yes/No) Write the explanations to clearly identify both the problem and the solution (and if this is not a strong skill of yours, hire someone suited for this), and be aware that although you’ve named buttons and functions in your application, the user may not be familiar with your vocabulary. Present clear options on your buttons using verbs instead of affirmative/negative words. I would rather see four or five words on a button that explain exactly what it does, than to see yes/no buttons and have to read the explanatory paragraph three times just to be sure I understand the action I’m about to take.
A problem with modal dialogs is that they often cover up the area in question. The new thing lately is to make them draggable. This feels like a bit of a band-aid solution to me, but if you go this route be sure that the window cannot be dragged off the screen. And on a visual note, be sure that the interface clearly reflects a modal state. The most popular way to handle this is to give the background application a slightly opaque cover which mutes the appearance and allows the dialog to stand out. Adding this cover will also illustrate which actions may still be accessible, such as global navigation or logout.
A new take on the modal dialog box is what I call transitional dialog, which is prevalent on Facebook among other applications. A dialog box appears with a confirmation message, but then fades away after a few seconds. I like this approach because, although it does break the flow, it doesn’t force you to interact. Avoid placing buttons on these dialogs or the user may feel like he’s in a game of whack-a-mole.
Inline messaging is probably the best answer for a variety of situations, because it suggests making a change without forcing it. It can be a way to lead your horse to water without making him drink. The right messages in a friendly tone can encourage learning and prevent the appearance of true error messages. Again, they require more conversation between the application and the backend, and you will need to design a way for the user to return to neutral state, but these are well suited for the kind of low-level explanation that is often needed in applications.
Lastly, I want to say here that I think there is great opportunity for innovation in the area of error messaging and dialogs. Just because they’ve taken the form of a little window for the past 20 years doesn’t mean that’s the ideal situation. I could envision dialogs of the future incorporating animations, or actually pointing to the error in question. Use your imagination (and then find a developer willing to go on a lark with you).
2.2.4 Fun! Fun! Fun!
I’ve saved the best for last: enhance flow by making your application fun! C’mon, who doesn’t like fun?? Fun software may sound like a contradiction in terms, but I think there’s an opportunity to make any application fun, event if it’s check-balancing software. As a matter of fact, check-balancing software could probably benefit the most from the addition of fun to keep people engaged, learning and satisfied.
Before I proceed, I have to make a couple of clarifications. First, I see a difference between “fun” and “clever”. Clever can sometimes come off as sarcastic or ironic, and clever wants you to know that it’s a little bit smarter than you. Clever gets very old, very fast. Fun, on the other hand is universal, multi-generational, pure. Fun is a good feeling and fosters loyalty. Secondly, fun should never stand in the way of usability (or then it’s not fun, right?) and should still be respectful of the tasks that need to be accomplished. Never lose sight of basic design tenets while enriching your UI with a little fun.
That said, the obvious place to seek inspiration about fun interfaces is games. Gaming inspires a variety of feelings that, for some reason or another, humans think are fun. Some of these feelings, like “adrenaline surge” and “blood-lust”, we’ll leave to the design crew of Grand Theft Auto. I will cover a few of the more innocent qualities found in gaming, such as competition, sense of accomplishment, surprise and wonder.
Sometimes competition can be fun, tapping into a users’ competitive streak or desire to be on top. Certainly social networking sites such as Facebook and Linked In foster competition among their users in the collection of friends or contacts, with the number collected in prominent display. Linked In goes even further these days by incorporating a “Best Answer” feature in its forums. If someone selects your answer as the best answer, you are then declared an “Expert” on that topic. Way to fire up the alpha dog.
Another closely related feeling is a sense of accomplishment (which is basically competition with yourself, achieving a personal best). On a holistic level, this can be fostered by a UI that allows users to become intermediates or experts quickly. You can also encourage this sense of accomplishment by providing steps for your users to complete, or levels to attain. Again, Linked In has a good example of this with their “Profile Completeness” meter that is designed to motivate you to collect more recommendations and contacts. Ebay has its “Power Seller” demarcation (with many levels therein), which I’m sure is fosters a sense of pride in sellers.
Surprise and wonder are two attributes that rarely have positive connotations when in the context of software. My definition includes discovery, exploration, and finding something unexpected yet delightful. Tread carefully here of course, but try to include a sense of lightness and humor where possible. Surprises in the form of Easter Eggs, or hidden interactions, can be a fun way for users to spend a little extra time with the software. I’ve seen sites where mousing over the company logo animates it in a fun way. Sometimes a seemingly random connection can be surprising and funny: Adium, an Instant Messaging software for the Mac, is personified inexplicably by a duck, which quacks when there are new messages. It very cute and funny, and I can also turn it off when the joke’s worn off.
Another way to incorporate surprise and wonder is to give the interface anthropomorphic or physical-world properties, or to add a little flair to animations. I’m not entirely sure why, but giving objects weight, momentum, and other physical-world properties makes the interface feel fun and inspires people to gawk. And anything that goes “boing” is sure to be a hit. I mentioned earlier the cute little dog-like shudder on the Mac login screen when an error is detected. The “genie” effect when a window is docked is also very cute and engaging.
Lastly, fun is a mood that can be expressed by your software’s visual look and feel. This look can range from friendly to downright silly. Big buttons and friendly colors create a sense of fun, as do unusual shapes. It may be difficult to advocate for a fun interface when being stared down by corporate, buttoned-up style guides, but a fun and friendly interface can enhance users’ comfort with the software and possibly even inspire loyalty.
2.3 Summary
RIA, non-linear thinking does not come naturally to most, in fact sometimes it can make your head hurt. Understanding the conditions that are necessary for good “rich” design, both in the way you think about your design and the environment you offer to your users is essential to capturing the fluid feel of RIAs. Now that we have knocked down the barriers to RIA thinking and built up methods to encourage flow, we can turn to the next obstacle, this one wily and formidable; the browser.
