« Sign Up for the ThinkFold Private Beta | Main | Flare Released Under GPL »

Artificially Delayed Splash Screens

Recently, Dave, Paul and I were laughing about how, when very new to developing, we would place artificial delays in our loading 'splash' screens (this was a long time ago, if you're worried :). The very idea of making the user wait for no reason seems absurd now, but it got me thinking about why we did it (ultimately our goal was the same as it is now - that our product be useful and valuable to the end user).

I think we did it because we wanted the user to think our app was big, powerful and did so much important stuff it couldn't possibly load in under 3 seconds. It's interesting that we associated a long waiting time with a better, more powerful app.

Now, I'm not proposing we all start forcing our users to wait 3 seconds before every page load, but there's definitely something to associating longer waiting times with more 'power' - and therefore smaller waiting times with small, simple actions.

Of course, the first time we request an action be performed we have no idea how long we will have to wait. But after just a few requests of an action (such as clicking a button) we'll begin to associate that action with a degree of waiting. After a while, we begin to make decisions about how we use software based on the time we expect to wait for the requests we can make. There are often many alternatives to achieve similar results (for example, I will often Ctrl+click links in a browser to open them in a new tab in the background as I know that action will take a few seconds to complete and I wish to stay reading the current page while waiting for it.).

Armed with this knowledge base of actions and their associated delays, we then begin to weigh the expected delay with the expected result in every decision we make.

Take Adobe Acrobat Reader for example, I rarely click PDF results in a Google search because I associate the “[PDF]” tag with an action that doesn't yield a result that justifies the expected delay. Now I can't possibly know how valuable the content of that PDF will be to me before I open the PDF, so why does my mind decide the delay doesn't justify the result? Perhaps it is because my mind compares the opening of a PDF in my browser to the opening of a normal, html web page. The request for the action is similar and the result is identical (text, images, form elements) - so why wouldn't it be disappointed with the result after such a considerable delay when compared with opening a web page?

With this in mind, the use of AJAX becomes very important. Requests for actions in web applications can be associated with small, simple actions (a simple AJAX request) and longer, more powerful actions (a page postback).

Consider every request in your web application. Does the delay reflect the result of the action? This works both ways; it should not be possible to invoke more powerful actions with significant results via a small, quick request. Say I wish to delete a task item, such a small action should not have a delay, but if I want to delete a task list of 500 tasks? From a technical point of view this action will not take any longer (as far as the client-side view is concerned) but to the user, this action is huge. So what do we do? Artificially delay the action's result so the action's delay reflects the power of the action?
One idea is to bloat the delay by prompting the user to confirm their action. This is certainly worth considering, but falls down as it doesn't reflect the size of action. If I attempt to delete a task list with a single task, I would consider this a small, quick action. If I attempt to delete a task list with 500 tasks, I expect a longer, more delayed action. It's this delay that allows my brain to build a knowledge base of actions and their associated delay so I know in future which actions can be performed with little thought or attention and which actions I need to think through before requesting.

The time delay between requesting an action and getting results back is an ideal, Real variable that we can use to quantify an action's 'size' in a user's mind.

Sure, I don't know how long an action will take before I request it, but it doesn't take long before I've built up that knowledge base and I can switch off or focus on other things while using the application - until I'm about to request an action that I know is big, then I'll give it all my attention before clicking that 'delete all tasks' button.

Post a comment


Contact Me

If you'd like to get in touch, contact me on +447944 353544 or matt@mattbrindley.com

products

Litmus

Litmus makes compatibility testing easier for web pages and email newsletters.

ThinkFold

Online outlining, for groups. Collaborate in realtime with colleagues!

Delicious Presentation Creator

20 slides from your Delicious feed, 20 seconds each.

Flare

A site-specific browser for 37Signals' Campfire chat app, bring Campfire to your desktop.

CSSVista

Edit your CSS code live in both Internet Explorer and Firefox simultaneously.