Accessibility

Flex Article

 

Designing for Flex – Part 7: Making your application fast


Table of Contents

Comments

Providing starting points

A common special case of eliminating work involves providing intelligent starting points. In the old days, most applications made no assumptions about what users would do with them when the application first opened. The first launch and every subsequent one was a blank slate, and it was up to users to repeatedly navigate to those sections of the application they frequently used. Good Flex applications are smarter than this, and start the user off right where he wants to be. (Sometimes this is referred to as "personalization," but I dislike that term. It sounds too much like the ever-present "Welcome, Rob!" message on the top of the home screen, as if that's supposed to make the application feel all warm and personal even though it stubbornly forgets everything I've done with it since I used it last.)

Second use starting points are often more straightforward to design and implement than first use ones. The most common approach is to follow a "last state" strategy; if the user returns to the application it should start out in the state that he left it in. This has a couple of benefits. First off, for many domains the thing the user was doing last is very likely where he'll want to pick up when he returns. Second, it mimics the behavior of physical objects, most of which remain in the state they were left in unless someone else modifies them. As discussed in Part 6: Guiding with motion, mimicking physical objects can help users understand interfaces intuitively, so last state behavior tends to make sense to users.

 iGoogle, Google's customizable homepage, employs a last state strategy. Every time a user returns to iGoogle it is in exactly the state she left it in; the same widgets in the same locations and configurations. This behavior feels very straightforward to users; so much so that most don't even notice the application is working behind the scenes to remember their actions.

Figure 7. iGoogle, Google's customizable homepage, employs a last state strategy. Every time a user returns to iGoogle it is in exactly the state she left it in; the same widgets in the same locations and configurations. This behavior feels very straightforward to users; so much so that most don't even notice the application is working behind the scenes to remember their actions.

Unfortunately last state strategies don't work well all the time. If I already purchased a product from an online store it's unlikely I want to go back to that product page the next time (though I may wish to return to my order to make corrections or check the shipping estimate). They also rarely work for first use starting points, since if the user has never used the application before it has no information on where he's been. Yet first impressions are lasting ones, so you still don't want to force the user to do a lot of navigation before locating the parts of your Flex app that interest him. What, then, can you do?

Instead of relying on past behavior, you must examine the context of the new user's arrival and see if you can infer anything from this context. For example, good calendaring applications don't plop the user down at January 1st, 1970; they start at "today," which they can easily determine by looking at the system's clock. Good mapping applications don't start out with a huge map of the United States. They zoom in on the city the user lives in since most likely his desired destination lies there. (Notice it's possible to get too personal. Most mapping applications shouldn't start out by showing the user his own house since he likely already knows the area around where he lives.) Good online stores recognize when a user has come from a search engine and use the search terms to immediately show relevant products.

checkmark Offer users sensible starting points by remembering the state they left your application in or by inferring an appropriate starting point from their context.

 Google infers the user's language based on the country his IP address originates from. Thus if a Japanese user accesses Google, he immediately receives the Japanese language version of the website without having to view an English website and figure out how to switch his locale.

Figure 8. Google infers the user's language based on the country his IP address originates from. Thus if a Japanese user accesses Google, he immediately receives the Japanese language version of the website without having to view an English website and figure out how to switch his locale.

Unfortunately, the current web environment is rather poor in context when a new user arrives with no pre-existing account. This will need to change for the experiences of the future to become reality, but in the meantime leverage the context you do have to tailor your users' starting points to fit their goals.