How to Make Users Think Your App Loads Faster | Hacker News Reader

How to Make Users Think Your App Loads Faster

medium.com

58 pointsbabich34 comments

> You can disguise small delays in your progress bar by moving it instant and steady (fast in the beginning and slowing it down as it.

I think having a lying progress bar is worst than a loading spinner.

Research has shown that you should lie in the opposite way to get a better user reaction. If you artificially slow down the progress report in the beginning so that it can speed up near the end, the increasing speed works to counter the user's decreasing patience.

I argued this just the other day but couldn't find the source where I had read it. Do you happen to have a link for this research?

I don't think this paper is the source I remember. I seem to recall something from Microsoft Research. But, it reaches the same conclusion.

Article with easy summary and link to paper: http://johnnyholland.org/2008/11/the-effect-of-the-progress-...

Edit: here's a large collection of articles

https://github.com/Zhouzi/reactivedesign/blob/gh-pages/READM...

It doesn't counter decreasing patience, it sets expectation and then exceeds it instead of falling short.

What's with all the promotion of anti-patterns lately?

Medium's approach of loading blurry pictures first gives me even more so the feeling that the site is slow.

Exactly. Whereas I may completely ignore the image, now I feel I have to wait and decide whether this piece of information (the image) is useful.

On medium, it never is useful. Disable it via your content blocker.

I don't mind the blurry pictures at all. What bugs me is that they're eventually replaced with detailed pictures that don't add anything that the blurred pictures weren't providing already.

That process could probably be automated. Run a big collection of clip art through an image classifier to get keywords, and just load some image with relevant keywords. Good Wordpress plugin to write, if someone hasn't done it already.

So they load an entirely different image first? Why not just (re-)encode the image with interlacing[1] turned on?

[1]: https://en.wikipedia.org/wiki/Interlacing_(bitmaps)

Is Adam7[1] still useful with how fast internet speeds are today?

[1]: https://en.wikipedia.org/wiki/Adam7_algorithm

In some of the software (especially 1Password) I use I dislike animations to hide loading because I have a lurking suspicion that it is making me wait just to show a fancy animation, and is not doing anything useful.

> Because of that, people hate to see only a loading spinner with no indication of progress or time.

I hate to see the loading spinner at all. It gives you no indication if something is actually happening. (Actually, I feel much the same about progress bars that don't indicate what steps are being taken, as well.) These things will happily sit there spinning forever, possibly doing something, possibly just frozen. Who knows? I hate having to choose between being patient (and possibly a schmuck) or stopping something and trying to solve the problem.

These things give no indication of what went wrong, no starting point for where to look, and nothing useful to tell tech support if you call.

Caller: I clicked 'Update' and it shows me three pulsing dots. It's not doing anything. Tech: The process can take up to X minutes. Caller: It's been three hours. Tech: Sometimes it can take that long. Caller: ???

Versus

Caller: I clicked 'Update' and it's been on 'reticulating splines' for an hour. Tech: That's weird. That part of the process should only take a minute. Do X... does that work? Caller: That worked, thanks!

I'm sure lots and lots of UI research has determined that people don't want to see the guts of an application and want it to work by magic. But I find it completely asinine.

More common with progress bars on Windows, but I've seen on mobile once is the multiple phase load. These are especially useless and annoying.

Progress bar finally gets to 99% so you wait expecting to be able to use the thing. Now you get another progress bar. Right.

...

I'd far rather see what is happening (or what is supposed to be happening) as often that's enough to indicate if I can fix myself or need to seek support.

That grinds my gears as well. In some cases they show two progress bars, one for the current activity and another for the overall process; which I find acceptable.

Nothing can make your users think the app is loading faster other than making the app actually load faster. Loading blurred pictures first, or showing a false progress bar just makes the app feel more slow.

Pretty much all the usability testing that's ever been done would disagree with you. Do you have a good reason for feeling like your opinion is representative of broader demographics?

Do you have a good reason for thinking studies that clearly disagree with observed reality are actually correct?

Because I've heard similar results in the past, for example for OSes that show the GUI before they've stopped loading. Supposedly done to increase the perception of loading speed, and again they were supposedly supported by real studies. (MS WinXP for one.)

But considering that I've seen multiple non-power users discover the un-usability of their OS right after boot simply by trying to load something and finding the computer non-responsive, yes, I'd have to conclude that either this sort of study is 1) simply incorrect or 2) asked the wrong questions.

If your goal is to trick non-users into thinking your startup time is short, you might be able to do this pretty easily. But the second time someone uses the system instead of watching a video of it, they see through it.

And this isn't the abnormal case - this is essentially 100% of users in 95% of use cases. When you start an OS or an App you're waiting to do something. You notice when you can stop watching it load and actually do something.

Come back when the effect works the 5th, let alone 50th time.

I think Facebook's trick doesn't help much on making the app look faster, but, it makes it look like the slowness is the device's fault rather then the app's.

And Instagram is actually making the app faster! The user can do the exact same tasks in a shorter period of time, because those are arranged in a smart way.

Pretty good post though, thanks!

Users don't care whose fault it, they care that experience is bad.

Guys, you all may not be fooled into thinking that the load speed is faster from any of the tricks mentioned in the article, but most users are not like you guys. They're not developers, they don't think like you do.

I've had many tech support calls that amounted to telling people to wait until their earlier clicks had taken effect.

The users clearly initially thought the system was loaded and were shocked to find 30-second delays in their input being registered.

I think it's pretty rude to assume that users are so stupid, just because they don't code, that they can't notice being tricked.

> Dummy Content and Placeholders

We've started doing something similar with our front-end apps, but it's not placeholders. Our router is set up to store page markup (indexed by DOM node ID) at the end of every page request. So for the dashboard, we'd save something to localstorage with the key "APPNAME.domstate.dashboard":

    { '#nav': $nav.html(),
      '#header': $header.html(),
      '#main': $main.html()
      ...
    }

We compile HTML templates for every root page (in this case dashboard). On every new page load, the template is set up to look for the domstate in localstorage before it downloads any JS and bootstraps the application.

Since the HTML files are aggressively cached by the browser, and since the localstorage injection happens first, we can re-render the last version of that page for the user before the new data is re-populated. It works pretty well, but the drawback is you may see content flicker when it updates.

I recall that iOS did/does some tricks similar, especially when it came to sending texts (sms). The sending bar shows the same animation even if the text sends very quickly and would delay if it took longer than normally expected.

I recall reading too that iOS effectively screenshots the app as you exit it and displays the screenshot while it kicks it back into memory on re-open. It looks like it's loaded instantly but isn't actually interactive until it fully comes back

I don't believe this is where I originally read it but does mention it http://www.geek.com/apple/how-ios-tricks-you-into-thinking-i...

Another one: reduce your animation duration in production. That 500ms value from that tutorial was set so you can see it better. In production < 100ms?

Or even better: in production, 0ms.

I agree, but people judge things on appearance.

"Trick them with a clever pacifier"

I'd be more interested in reading about how to make my app start faster so the user can interact with it sooner. Data may need to load in the background, for example, but giving the user a quick start is better.

You should do both. Actually speeding up the experience is great, and today even popular apps often reload data unnecessarily and generally work suboptimally in the presence of a slow or flaky connection. But there's only so much you can do - if the user's connection is bad enough, eventually they're going to have to wait. So you do what you can to make the experience more bearable.

Didn't iOS used to show a screenshot of the last state of an app when resumed, so it looks like it's resumed instantly? This is clever because often a user will not interact straight away, and the app can load on top of the screenshot with no noticeable difference.

Sorry for the double post.

>The load screen shouldn’t highlight much. It doesn’t need to be eye-catching. Facebook’s gray placeholder is a good example. It uses template elements when loading content and makes the user familiar with the overall structure of the content being loaded.

I really find Facebook's placeholders distracting. The subsequent content that loads is usually laid out differently (albeit in the same rough format) as the placeholders.

Reply on news.ycombinator.com