Perceived performance and using asynchronous actions to make users happy
As an engineer I care about the perceived experience for my users and speed is a key part of the experience. A common practice is to build your programs to be as asynchronous as possible. This has always been the case in client UI development and is very much en vogue on the server (evented architectures using technology such as node.js as an example).
On the server you don’t want the program to wait and you want to be able to parallelize as much as possible. For users? Don’t make them wait or stare at a screen.
Of course, you often may be waiting for critical content that means you can’t act on the current path until it comes back but there is often a way to improve even those use cases. The key is “perceived performance”. Something can often take longer in actual time, but due to some other factor it can feel faster.
ASIDE: The type of spinner you use matters too! Facebook found that users blamed them for slowness when using a custom control and the platform when using a standard control!
That Felt Faster (because I was doing something)
One example is the notion of the self-checkout line (I work in retail ☺). Most people feel like their checkout is faster when they are going through self checkout, but often it isn’t the case at all. The customer feels more productive when doing a self-checkout vs. standing their watching someone else (often times not knowing what to do!)
How can we take that same effect to software experiences? We can asynchronously load data in the background and let the user keep doing something while they wait.
There are plenty of examples of this, and the classic case is: “Open URL in a new tab”
Nine times out of ten I open a URL in a new tab. Why? Sometimes I am in the middle of reading something and I am saying “I want to read that later” and this adds the reading to the stack. At other times I know that it will take some time to load the other item, so my desire is “I will keep poking around here until it is loaded thanks”.
There are other cases where you want to add something to the stack. For example, “add to reading list”, “add to playlist”, and “add reminder”.
A Blank Stare
I really despise watching paint dry, and I feel like I have to do that regularly when I tap on a link, see a blank white page, or a spinner, or notice that a @font-face hasn’t loaded! This tends to happen a lot when I am in an application that launches a web page in a WebView.
It goes beyond reading too. In the same spirit of the “Add to playlist” (or “play next”) I often find myself in an audio application (e.g. podcast app) wanting to tell the system “go ahead and start downloading this and when it is done jump over to it to start playing please”. Instead, I get frustrated when it jumps to the new item and I am listening to crickets as it downloads the new content. This is common when I am listening to something already downloaded (e.g. audible book) and want to start listening to a podcast that isn’t downloaded yet.
Maybe we want to be in a bubble
A fantastic example of the asynchronous loading taken to the next level is LinkBubble. As soon as I saw it I wanted all of my platforms to support this style. Let me fire off the new action (open a link), give me an indication to the progress (in the bubble), and let me jump to it when it is done.
This can even go beyond links, and could be a new interaction model, one that lets the user tell me when they are interested in some new data, but continue doing what they are doing until they can instantly act on it.
When I look at the interactions that I provide the user, I now try to let them be productive even when their primary action requires some time.