Wait a minute. I mean, 20 seconds at least. Hold on... idea's almost here. Meanwhile, would you focus on the spinning circle I've included above and think happy thoughts?
OK, stop! Blog post loaded.
While we may think that the age of AJAX and the Flash/Silverlight preloader has ushered in a new era of more immersive and reactive user experiences, we still have light years to travel in how we manage expectations around wait times when content loads in a web browser.
And this post is a quick attempt to summarize some ways of thinking about wait times in the ideal user experience—and documenting those wait times in advance of development.
All the Browser's a Stage
The era of rich web experiences has raised our expectations of quality of delivered experience. However, as page weight has increased, we've brought the preloader into play to disguise the load time while the set is dressed for the next act in Firefox Theater.
Using a preloader or some form of "spinny" can be tantamount to artful misdirection, a magician's sleight of hand—and once a user sits through an epic wait once, they'll expect that they shouldn't have to ever again. (Didn't you cache the heaviest files?) They won't care about the reasons why it was easier to stream in the media then toss it after the session. They won't care about any development decisions, actually, except for the ones that govern how much dead air there is between an initiated action and the next screen or piece of content that they're seeking.
This is why the idea of the browser as a theater stage—and our act of viewing as the fourth wall to that browser stage—is a good way to plan and model how wait times may impact your user experience.
Javascript-driven lightboxed dialogs dampen our excitement just a tad, but they function psychologically like curtains closing and reopening at a theater. We know the furniture is being moved around on stage, so it's not a big deal... unless they're doing it so often that we never hear enough dialogue to move forward the story.
Theater shows that have multiple set-ups in a brief period of time establish maximum wait times between transitions. So why shouldn't you? This theatrical metaphor helps us create a useful principle for designers and developers alike:
As you plan the ideal user experience, understand at which points on your page there may be heavy wait times and ensure that the wait times elapsed during a session are no more than one-twentieth the ideal length of time expended during a target user's browsing session.
And while this may seem like a conservative or arbitrary number, if you add up all the various kinds of wait times that happen during a usual session you'll see that it isn't easy to achieve.If the user is going to spend a minute reading the front page of a news site or blog, 5 seconds is a fair wait time. If there's an immersive experience built in Flash that takes approximately 30 seconds to load, you'd better hope that a user will get a good uninterrupted 10 minutes out of the time and effort expended—and find the content meaningful enough to stick around. (And of course you'll intelligently stream in content past the primary website framework, so that you aren't waiting another 15-20 seconds for each section and piece of content beyond the main hero of the experience to show up.)
If you've properly planned your user experience against a target session length—i.e. 2 minutes spent average per session means success on the part of your team—then this simple rule can serve as a litmus test for success.
Don't Worry... It's Going to Be (Pretty) Good
When designing your preloader, did you plan for incorporating the proper story you're telling into the wait experience? This is all about reinforcing where your user is at in fulfilling their task as part of a larger narrative within your website.
There are plenty of great preloader examples where users are clearly told what is happening while the next aspect of the page is loading. Travel sites are the king of this behavior. There's a massive amount of work that happens before you're presented with a set of results from a gigantic, ever-changing database. So when you ask for tickets for a specific date, you receive the following prompt with your lengthy wait time: "Expedia is searching for flights on selected travel dates." Not: "Please wait" or "Fulfilling your query" or god forbid "Now loading."
Users rarely know what they're in for when they show up at your new website. Just smacking them with a preloader sans context could be a risk—unless you're trying to breed some deeper mystery. At the possible expense of a shut browser window, of course.
Fear, Metrics, and Loathing
You've got to look at the metrics as frequently as you can stand it, flagging any user behaviors where they bail at points where you've required a preloader due to a database query or refresh. If you've stitched a number of Javascript- or Flash/Silverlight-enabled interactions together into a long-form experience, this may require the embedding of "hooks" in your code so that you can track more granularly where users may bail.
Clients and designers alike look at this data with abject fear. I can't count the number of clients I've had who don't track this kind of data, and don't do qualitative testing to see how the wait times influence their user experience. I pray for the day that this isn't the case.
It's the Developer's Call.... So Let's Call the Developer!
"I take care of the wireframes and maybe the visual design, and then in development, we'll determine what areas of the site may require preloaders and factor them into the designs where appropriate."
Why leave major UX considerations until so late in the development process? Wait times and prompts are always usability factors, and should be part of any user experience deliberation in advance of a full build.
If you're working hand-in-hand with your developer while wireframing—which you really should be, no matter what the case—then you can negotiate what page contents will likely require preloading or wait times. This is especially critical when dictating what is a full page refresh rather than a swap of content on the page. This information can all be included in your documentation.
If you aren't planning for these kinds of user experience impacts, then you could be impacting the usability of your site in a negative way. Also, pinning yourself to ideal wait times per case—which can be difficult, as you can't control throughput and type of connection that a user has on the other end—gives the entire team a good baseline for how heavily graphics and code should be optimized to make the ideal UX a reality.
Guilty as Charged
I wouldn't be writing this piece if I hadn't made all of the mistakes above at one point or another. For many years, I was blinded more by what technology could accomplish as part of a really cool Flash website or slick AJAX presentation.
The flip side of those design decisions, however, were always issues with page weight and load times. And at the point that the page was cluttered with preloaders, it was too late to look back at the cascade of our design decisions and realize just how much our slick page presentations were impacted by heavy load times (even on a T1!).
If I could start over on some of those projects, I would have proposed some baseline metrics for page weight and load times. Setting those decisions at the start of a project would have contributed to some major design changes that would have made our projects easier to produce, faster to load, and still just as meaningful for our users.
I think the early Apple developers teach a good lesson: If you use the machines and connections that your users will use, you'll make a much better system.
Developing on a T1 line, I can imagine not caring in the slightest when page sizes zoom up.
I've only recently discovered that speed isn't the only issue. I'm using mobile internet, through which I've managed to download pages at 6 Mbps, but I'm limited to something like 32MB/day. A large site will load fast, but I've taken to disabling images and avoiding video.
The hardest part is to find out every limitation your users can have. The list is extensive.
Posted by: Michael Kozakewich | July 26, 2009 at 12:47 PM