Hacker News new | comments | show | ask | jobs | submit login
Why some apps use fake progress bars (2017) (theatlantic.com)
245 points by franciscop 44 days ago | hide | past | web | favorite | 194 comments

I had a report in Microsoft Access that took about five minutes to run - and the users hated it.

I had the application throw up a fake dialog with fake messages about "Collating data, Cross checking, Sorting" and other such nonsense.

The report now took eight minutes to run because I had to abuse the "On Timer" event for it to work.

The users were delighted with the improvement.

That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.

It's also one of the irritating things about "Material Design" websites, where responses to clicks are artificially delayed before speeding out with unnatural acceleration. "Nothing is happening. JUST KIDDING!" I'm not sure if that is to mask the slowness of mobile devices or if it's the cause of them. It's the animation spam[1] of the current generation of UIs.

* [1] "Let's make our website sparkle. It will be 'delightful'." http://dynamicdrive.com/dynamicindex3/snow.htm

That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.

Web browsers have progress bars.

I think your complaint is with "sites" that just serve a JS payload and then load "the real site" entirely from requests made by JS. Turns out if you generate and serve actual HTML, you get a progress bar for free!

I don't know why every thread about Web applications needs someone to tell me that technically HTML was just designed to be a document format. OK, great, now it isn't just that.

First someone states that the way web sites work now sucks. Then the next person states, ‘Well we used to build sites this way and then it doesn’t suck’. And then the next person comes in saying ‘well that just isn’t the way we build sites now’.

If that isn’t the way we build sites now, either change the way we build sites or accept that it sucks. But this is Hacker News so we’re supposed to think about different ways to build sites than what we do now.

It's just... what's the point of talking to anyone who will listen about how HTML was designed for hypertext? Yes, we all know that. Today the world's most-popular Web sites include YouTube and Facebook. We aren't going back.

This a (mostly) solved problem. With Server Side Rendering the html payload delivers what the client side is would have rendered. The client side js takes over rendering after it loads.

He did not say that. Generating the HTML for the initial page load server-side does not make HTML "just a document format". It improves loading and search-friendliness of your web site.

That’s true, but I can mention several online stores that do this. Even on a good network the site remains blank for seconds at times. If they at least served me a logo I’d know the site wasn’t dead!

> I can mention several online stores that do this

I would like to hear which ones they are, that I may try them.

I solved this in a react app I’m working on by overriding XMLHttpRequest.prototype.open to listen for the request lifecycle events and update a global “percent loaded” used to render a progress bar at the top of the page.

It’s far from perfect but is at least a good enough heuristic for the user to know when the page is loading a request.

Try to load an AMP page with JavaScript turned off. It can take many seconds, and there is no loading indicator.

> That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.

To be fair, depending on how the progress bar is implemented, it might not be a guarantee.

Clicks have a 200ms (IIRC) delay on Android to give a chance to recognize other gestures. There are hacks to get ride of it, though. It may have to do with that.

It's on desktop websites too, like YouTube (add to watchlist), and the delays are longer than 200 ms.

I remember reading long ago about how they did something similar at an airport(Dallas IIRC).

Basically, people complained about baggage claim taking too long, so they just moved the baggage claim area to the other side of the airport, so it took longer for passengers to reach it, by the time they did, their bags would already be there, so the complaints stopped.

It was actually a Houston airport; here's an article that talks more about it: http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting...

I feel like this really isn't deception but actually solving the problem which is that passengers didn't want to stand around.

In particular, people don't like to feel they are wasting time. Walking being a "necessary" step, doesn't feel like a waste of time.

It also distributes people through the airport to avoid localized crowding.

Years ago I discovered a bit of a trick for getting through customs in Jakarta in about 5 mins (I was travelling there a lot for work). However, what I always ended up with was standing around for about 15-20 minutes for my bags to be unloaded, as even the priority baggage was rather slow off the plane.

Seems like the passengers could have solved this themselves, by just walking in circles.

Or walking on the people movers and escalators going in the opposite direction!

Except they had to spend the same amount of time walking. If presented as a choice I'd usually choose standing.

Not me. Walking feels productive, standing is boring. Same with driving - my brain would rather feel like it’s making forward progress even if the route I take is longer.

I have a cell phone to eliminate the standing is boring problem. (Before that it would have been a book)

Even if you actually would make that choice doesn’t mean that you would be happier than if the airport implemented the other option and didn’t give you the choice. That may sound counterintuitive, but there’s no particular reason to think it’s contradictory.

Even right after getting off an airplane, where you had to sit in a cramped seat for hours on end? I’d much rather take the opportunity to stretch my legs.

It's not like they tore up all of the parking/loading/unloading areas. They just moved the baggage claim to the farthest point along which everyone had to walk anyways.

That’s a slightly different example then, because that actually does save time. Parallel vs. serial.

I think even the passengers' reaction might make sense here. Standing around at the baggage claim and observing that no baggage arrives makes you worry that there might be some serious error that will make things take a very long time.

I wish they would do it at Dallas. Most of the baggage carousels are ~100 feet from the gate. Many impatient people!

Visual confirmation that it isn't hung, I'd be happy too.

You're happy until 30 minutes later when the progress bar is still getting asymptotically closer to the end, and you come to suspect that the only thing that didn't crash was the progress bar.

>when the progress bar is still getting asymptotically closer to the end

That, my friend, is an impressive command of the English language.

Thank you for teaching me the word asymptotically! [0]


I think most people that have done a CS degree would at least know the word. My cs101 class talked about asymptotic notation.

Not CS but any study of limits in math, perhaps with differential equations. And it’s a useful term generally, much more likely to come up in conversation than “subtrahend” or “mantissa” but not nearly as much as “tangent.”

And that must be why I have yet to hear it, as I never took CS.

At least it didn't say "orthagonal". Don't know why, but that word pops up here way too often.

I am reminded of a webcomic, that i fail to locate at this moment, that reminded me of the practice of placing something next to a progress bar, like say during a Windows 95 install, to check if anything is actually happening.

This is the comic you're thinking of. http://www.commitstrip.com/en/2015/02/19/when-i-install-a-so... This was one of the comics that convinced me to add them to my RSS feed. I have not been disappointed since.

It's a blank page that says "Loading..." Is that the joke...?

edit: I started browsing around their site, and when I returned to that page via the back button, the actual comic was there.

I removed them from same recently because I felt I could no longer relate to the jokes, or some such.

That's so brilliant because it was true. (Nailed it, pixel perfect)

I do that whenever I have to wait on a progress bar. I zoom in with whatever accessibility options there are, then when a pixel is 3-5mm I put my mouse cursor at the end of the bar and wait.

I don't use the zoom, but yeah, parking the cursor right at the progress bar to see if it's advanced is useful if only to amuse myself. :)

Wow, I thought I was the only one.

To save time in the future, bear in mind any time you think you are the only person that does or notices something: you aren't. This is due to the fact that people are all running on the same physical architecture, with very similar cultural and social ecosystems, plus the law of large numbers. Note that this does not apply to edge cases such as people engaged in activities or domains with a very small number of participants...


Couldn't you have give also vague, but accurate information as well?

User's like to know what's going on, even if they maybe don't understand all the details, but at least they see things are happening and not just a (fake) progress bar. So they can connect more to what is happening and therefore be more understanding and patient instead of just being told to wait, with no further information, which nobody likes.

It would be nice - but the Microsoft Access framework didn't really give you a way to ask the query system "How far along are we?"

> Couldn't you have give also vague, but accurate information as well?

Could you give me an example of what you consider "vague, but accurate information?"

The article's discussion about the NYT election accuracy meter wiggling randomly (but within the error bars) is a textbook example of "vague but accurate" information, perhaps to a fault.

How do you visually represent "error bars" to someone who's not technical enough to have ever seen them? Not everyone takes college stats, math, and engineering.

Technically, wiggling within the error bars is a precise way of saying "the precise location is vague -- it's somewhere within this range", in that at any moment it is showing one precise, acceptable guess.

The most fascinating piece there was that as the error bars decreased, the range of the wiggling decreased as well.

Yeah, it doesn't convey the extend of the error bars instantaneously -- you need to stare at it over time -- but it does convey the idea of error bars.

I think the people upset about the error wiggle are either a) being pedantic that it's not visualized in the way they learned it should be visualized back in college; or b) they haven't accepted the idea that sometimes we don't have an exact precise black-and-white answer (we DO have ways to precisely quantify the degree of our uncertainty though).

All of this not to say it was the best execution... perhaps if they 'ghosted' previous needle positions like how old movie radars ghost a green blip as the thingie spins around, maybe it would have been a kind of hybrid approach where the error bars do kinda appear in the overlapping ghosting shadows but still change over time...

"reticulating splines"

I guess the lesson to be learnt here is that people are more understanding if you appear to be transparent but you don't have to ACTUALLY be transparent to get the affect.

Reminds me of the loading screen for The Sims (an obvious parody of the above mentioned tactic)

(You might want to mute it. The loading messages are at the bottom)


Reticulating splines actually comes from SimCity 2000 and they then used the idea in The Sims later


Actually, we used that phrase in a deceptive 'loading' progress box in PC/GEOS in 1989

Oh, interesting. I thought it came from Don't Starve but they must have been adopting this from SimCity.

Yes, it’s a relatively common SimCity reference, though I could swear I saw “Don’t Starve” say “Reticulating Pines”.

I don’t think I’ve ever seen another game than simcity give it a voiceover...

Ah! That's right! Thanks

"Doing things you don't want to know about"

Makes me think of the loading screen from Don't Starve


Fetching data

Processing query

Preparing for display

This, yes. Also, if you're processing discrete items in any measurable way (downloading kilobytes, ingesting database rows, querying servers...) that takes longer than one second flat, display that to users. "Processing record 1/1,000,000... Processing record 2/1,000,000..." gives a positive sense of progress. Even if you don't actually know the final total in advance, you should still display whatever you've got.

As a bonus, this can occasionally be useful for bug squashing. "I've been waiting for hours and it's only up to row 5681" when you know for a fact that there's <2000 rows is a lot more informative than "My report won't finish."

Most of those steps will go immediately, and one of them has the same problem the original issue had: it’ll sit on it for ages...

A few of the default Debian packages give feedback messages like "This could take a long time..."

Most of them used to take a long time, but hardware has caught up. SSH key generation, locale installation. Instead, it's a warning that briefly appears on modern systems, but is visible for quite a while on, say, a Raspberry Pi.

I designed and maintain a report-generating component and my system does the same thing. (Plus it is helpful as users can tell me where in the process it failed/hung) It doesn't matter how long each message sits on the screen, as long as it changes every so often. Animated, infinite progress bars also help if you don't/can't estimate ETA

A cycling animation only tells you that your computer/UI isn't dead, it doesn't tell you that the underlying task isn't frozen.

In the loading animation of windows 98 there was a horizontal bar of moving colors. And if it stopped animating, you can be 100% sure that the computer is frozen. I wonder if we can do similar with cycling animations.

Can it not say "$X items processed..." or have a spinner that updates it's frame at certain intervals? It doesn't have to be a percent, just proof of progress. I had no trouble adding an accurate "$X rows of csv processed" in a laravel (PHP) + VueJS app.

I know this won't work everywhere, but if you know how much time the task generally takes, your progress bar can just be a timer for that duration. Still more informative than fake messages.

In the same vein, at my work in the steel construction industry, when asked by internal and external customers how I'm going with their laser cut components I've taken to telling them: "Your job is important to us and has progressed in the queue".

I can't always give an accurate response because our scheduling is constantly being derailed by urgent tasks and the not-so-urgent tasks get complete in between.

People just want to know you haven't forgotten about them, throw in some light humour and a "I'll try to get it done before knock off tomorrow <wink wink>" and they tend to let me get back to working.

Sounds like a placebo button:


They add fake "close doors" buttons to the elevators, that arent connected to anything, but make people feel they have agency and it makes waiting for doors to close less frustrating.

This sounds like a Coding Horror story that is entirely made up. Using a timer made your code go from 5 to 8 minutes?

We had only 16 Megs of RAM. I think it had put chunks of the query process to virtual memory to deal with the 'on timer' stuff in the GUI process.

Ages ago I evaluated some reporting software. We were using Crystal Reports at the time. One thing that CR did better than the others was make pages available as they were generated. This made the software feel faster even though it was slower than one or two of the others[0] at the time.

[0] Can't remember which ones exactly.

For interactive applications, reponsiveness trumps raw throughput. It's what made operating systems like AmigaOS and BeOS so fast: they didn't actually crunch numbers faster, but they always stayed responsive and quickly reacted to user input under any load, that made them feel faster.

Just had a little PTSD flashback moment there at seeing the words "Crystal Reports"

Oh dear. That garbage came with Cold Fusion (before it became ColdFusion), IIRC.

Which is why browsers take so seriously the time to first paint despite the efforts by javascript frameworks to push it back.

Missed opportunity for "reticulating splines"

The tradition of "reticulating splines" started in Maxis games:


And now lots of other games and web sites do it too, even compiling Firefox:


The "Stage 5" evacuation completion detection timer in Austin Powers could have used a tad longer debouncing delay:


Erik Naggum reported that removing garbage collection messages from Emacs caused people to think it had been sped up: http://grokbase.com/t/perl/perl6-internals/00cmr2ak01/garbag...

Writing tables to disk...

Saving changes to template...

Rebuilding index...


A physical analog of this would be when an Houston airport reduced complaints by moving it's baggage claim to be farther away from gates. Would you call this deception?

Also: A friend runs a service that analyzes web page design based on tens of thousands of hours of human eye tracking studies. An analysis only takes a matter of milliseconds, but they found that their conversion rate went up if they artificially put in a delay. Again, I wouldn't call the delay a deception; but rather an accommodation of human perception where longer = harder, and thus more valuable.

In the same way most people can't reason about probability, most people also can't fathom how fast computers really are.

artificially put in a delay

Makes me wonder if online retailers for luxury/fashion items could increase sales by doing something similar.

Announce the latest fashion item via social media, but make the page take forever to load... maybe throw in a few fake 404s to a percentage of users saying the store's website is overloaded and encourage the user to refresh. Then when the page finally loads there's a limited supply left, and when they put the item in their cart there's a ticking timer because "X" other people are already shopping this item too. Maybe some other last-minute artificial constraints, like people can only check-out with AMEX.

So basically Ticketmaster for luxury goods, except you secretly always have enough in stock.

This really has nothing to do with luxury goods. This behavior occurs on a lot of e-commerce sites regardless of what they sell. Outside of established players these tactics are fairly common. At least TicketMaster has an excuse for the timer.

As far as I know a lot of travel and hotel websites actually work kind of like that.

Does anyone have more information on the Houston airport case? Because I can imagine how moving the baggage claim further from the gates could result in actual efficiency improvements if it's closer to the exit.

Travel is all about mass human psychology management anyway - why do you get a meal on flights? Because people who've eaten are more docile, on average.

I feel like this phrasing makes it sound way more dystopian than it actually is. People who are tired or hungry are quicker to snap and notice the little discomforts of the plane. It's not that they're more docile, is that they're more content because it's easier to relax.

In China I was part of a flight that got so delayed and had so many people complaining and shouting that they brought out free meals for everyone to calm them down.

> ... Houston airport reduced complaints by moving it's baggage claim to be farther away from gates. Would you call this deception?

nah man, that's just straight up Dark Patterns -- https://darkpatterns.org

Like when your 2nd-touch emails technically and legally have an Unsubscribe link, but it's the same color as the background. Or how installing the Yahoo search toolbar was an opt-out with each java update.

This article lumps a lot of techniques together that are fundamentally different. The ones that are actual deception are not benevolent, and the ones that are benevolent are not actually deception.

Deception is leading someone to believe something that isn't true.

If a deliberate delay is added to a UI to make it clear to the user that actual work is being done, this is not deception. You are leading the user to believe something that actually is true. The natural instantaneous UI is the deceptive one for a user who is led to believe that no actual work happened.

A fake progress bar that shows steady progress when the actual work is stuttering is not benevolent, unless you can be sure the operation will finish in a fixed amount of time approximately at the end of the progress bar. This kind of deception is irritating and not benevolent.

A fake progress bar like the way change.org petitions make it look like people are voting up the petition right now? That is deception, and regardless of the merits of the particular petition I don't think it's benevolent.

I think you've just redefined 'deception' as things you don't like.

How is it not deceptive to make a user wait longer than the task takes? (Perceived benefit aside)

How is it not benevolent to make the progress bar smooth even if the underlying process is not?

Most users don't and shouldn't need to understand a process that may not progress linearly.

The article is pretty clearly operating on a definition of 'deception' where it means showing the user something different than the underlying process.

Can you rephrase your questions so that it's clear what answer you're looking for? As written their answers appear to be verbatim what I wrote in the comment you're replying to.

> If a deliberate delay is added to a UI to make it clear to the user that actual work is being done, this is not deception.

It is deception. It's less obvious in case of a program, but imagine it when you're using some service in real life. You bring in a car for repairs, the mechanic says "right, I'm doing it now", goes to the other room and starts reading a newspaper. After some deliberate delay, fixes an obvious issue in a minute and comes back to you saying the job is done.

Still think that's not deceptive?

I think the difference is the amount of time. In your mechanic example, I have to wait probably a few minutes extra. Maybe total time goes from 15 to 25 minutes. 10 minutes is a significant time.

When dealing with computers however, the time goes from 100ms to 2 seconds. People generally don't mind.

Absolutely this. It's the time difference.

The mechanic could say "I'm very experienced with this kind of repair and was able to perform it quickly" in a lot less time than it would take to read a newspaper in the next room.

The computer can say, "We checked your taxes against 2,683 rules in 0.002 seconds" but the user would take as long to read this as it would take to insert an artificial delay.

But stepping back a bit for context, the only reason I'm pointing out the benevolence -- or at least harmlessness -- of this kind of artifice, is to also point out that the article lumps it in with real deception. This looks to me like an attempt to create a slippery slope toward excusing all kinds of deception.

It's not deceptive - there's no commitment or understanding that the only thing he's doing when out of sight is work on your car. (And they don't bill based on how long they're gone - they bill based on how long they actually work on the car, in theory.)

On a computer, however, users generally assume that results are being delivered as fast as possible, even though in reality there's usually other things eating cycles.

I think it depends. If the mechanic is attempting to mislead the customer by insinuating longer or more difficult work then it's deceptive. But if it's because customers refuse to believe that their car could be fixed so quickly and assume that no work had been done then I don't think so.

Only if he's billing me for more hours worked. He can both say that he's working on it right now and go to the break room to read a newspaper and be truthful. Lunch breaks and small breaks before/after lunch are a thing in some workplaces.

I would think that fake progress bars about "triple checking" your taxes would fall into that latter categorization.

Definitely, that one is bad. I don't care for you to show me what you did in an animation I just want to go to the next step. Stop wasting my time.

Though I did find some steps where it made you think it was checking stuff you could actually hit continue and it would work all the same but cut the animation short.

I wonder if they have focus groups and it works for the masses makes them feel happy or acfomplished, but for the long tail it's just frustrating.

Would be nice to disable such animations.

> Would be nice to disable such animations.

Indeed. If you have an Android phone you can try turning off all kinds of animations from the dev options. I always do that and my phone feels so much faster.

I learned that on my first programming job in 1996. They said the job was taking too long and I was printing periods every 100 transactions. I started printing periods every 50 transactions and they complemented me on how I sped up the program.

If that's not a psychology hack; I don't know what is.

Dr. Phil?

I'm sure Dr. Phil comes at a close second. ;P

Reminds me of the old IE bar (not sure if it still does this), but it would crawl towards 100%, getting slower and slower as it approached the end, when waiting for a page to respond. In reality IE had no idea how much "progress" had been made by the server, if any.

They also had those progress bars when you stopped or restarted some services in an old version of Windows. They had no idea how long it would take, so they just made a logarithmic progress bar that became slower and slower, but never finished.

That trick only works once. As soon as you see that progress bar pattern a couple of times, you realise that it is fake, and it is infuriating.

Progress bars need to be honest. If you don't have any clue how long it'll take, show a spinner instead.

I'd rather just see output of something tied to the actual process.

Basically an answer to the question, "Is this thing taking a long time because it's doing work - or because it's busted"

In software it's busted at least 20% of the time and I think that's being generous.

Chrome for Android does the same thing. If you start loading a page, then disconnect your phone through your router (with mobile data off), the progress bar will continue to move until your phone realizes that you no longer are connected to wifi.

Same as Explorer, the file browser. Once you know, it's useful as a timeout meter, i.e. it signals "how long before this device/network location is deemed unreadable".

Wouldn't an actual timeout timer be more useful, like when Ubuntu is booting/shutdowning it gives a "job is trying to complete" message and a 90s (say) timer before it ignores it and carries on.

Windows updates could use this, when it randomly decides to wait 30 minutes on startup despite not warning you and not giving a skip option.

Windows still does this when searching the hard drive.

The SMS sending bar on old phones used to just take four seconds to go across, then stop at 95% if it wasn't done yet.

The iPhone did this, and then when they added iMessage originally it would still use the same tactic even if you were sending say, a large video (in which case the software obviously should know how much has been uploaded so far). I guess their internal API for "send a message" was not properly updated to take into account multimedia.

The NYT example is interesting.

During the US presidential election I interpreted the needle’s fluctuations (on what was a simulation of an analog gauge–a skeuomorphism) to indicate some form of uncertainty in the data. This would not be deceptive (at least according to my own mental model of how such a gauge would operate in real life).

However, according to this article many interpreted the movement as the needle reflecting actual changes in data. In this interpretation (the gauge reading reflects at all times the actual data) this would be deceptive.

I realized that I haven’t seen one of those gauges in real life for a very long time. Have people in general (or, inversely, the NYT) forgotten how analog gauges are supposed to work?

> according to this article many interpreted the movement as the needle reflecting actual changes in data.

I said more in another comment elsewhere in the thread, but I think outside of stem fields, things often need to be precise and black-or-white... the idea of quantifying the degree of uncertainty ("error bars") is foreign. That's one of the ideas I would try to give the rest of the world.

I've never seen an analog gauge move like this. The pressure gauge on our heating doesn't do that, the speedometer on my car doesn't tremble, and neither do analog Volt meters as far as I recall.

The speedometer on your car is almost certainly a digital system driving a needle. Unless you have a 40 year old car or something. So you shouldn't expect that to indicate how analog meters work.

My friend has a car manufactured in 1982 and the speedometer is practically useless below 30mph because of how bad the tremble is. He can be driving at a fairly constant 25mph and the needle will fluctuate rapidly between 30mph and bottomed out. Given the fact that the gauge bottoms out at 10mph, that behavior is probably by design.

Interesting, I didn’t know that.

Unless you're in Scientology, the gauge is supposed to be an analogue of whatever the current value it's measuring is. If the data are noisy, the gauge may tremble a bit, but if the data are steady the gauge should be steady.

Reminds me when i was a kid and was writing some GUI shell like Windows 3.1 (it only looked like it, of course, it was really just DOS programs :-P). I used a 386 and WfW 3.11 and Windows took a long time to run. Mine launched instantly and it felt "cheap". So to make it look more serious i added a loop that created and deleted files with small random delays inbetween and a progress bar that filled :-P. This way i got both a progress bar and a slower startup with hard disk noises like the serious programs had :-) (FWIW I remember adding the random delays because if you had smartdrv with write caching it would just flyby but also because a smooth progress bar felt fake :-P).

Cool story. I had a similar experience as a kid, when I designed the most elaborate splash screen only to notice it was shown only for a split second before the main window came up.

I notice that with Minetest, which is essentially an open-source Minecraft clone. I can go from desktop to walking around ingame in about 3 seconds (and my system is not actually particularly powerful).

As a result, it's sort of become my short-work-break game and I keep on thinking that I would play a "real game", if I ever have the time for it.

So, for the example of Turbotax, specifically, a few years ago I owed a few thousand dollars in taxes (basically my withholdings were off). Seeing the calculator do its little "calculating your biggest refund..." song and dance and then announce I owned several grand was just kind of like a slap in the face. Guess they didn't consider that particular case too carefully. :)

If you’ve ever made a chatbot you have to do this. Add in a fake few seconds delay so it seems like it’s considering what you said in its reply. Replying instantly makes you feel like you’re being railroaded and ignored.

Bonus points if you trigger the "Human VonNotachatbot is currently typing..." indicator during the artificial delay period.

I recently contacted the sales chat of a company and they were typing too fast. The guy reached out by email later saying he was not a bot, but to this day, I'm not 100% sure.

This is a horribly researched article. Progress bars are not benevolent deception, they are deception by incorrect choice of UI elements.

>Mask system hiccups to smooth out a user’s experience (like when a progress bar grows at a consistent rate, even if the process it’s visualizing is stuttering

This is malicious deception. The only one being benefited is the developer when the users incorrectly think your software is smooth but is in fact not. If the software hiccups, the users need to know this to better understand the system they are working with. Your users are left ignorant, which is malicious.

>The word “deception” has a negative connotation

That is because it is negative. A user exploring the UI of your software is much like a physicist researching the unknown laws of the universe. A physicist never benefits from ignorance, so don't find ways to make your users more ignorant about your system.

>Despite its complexity, this step was nearly instantaneous in the game’s first iteration. But the speed confused people. “Their reaction was, ‘Wow, was that it?’” Adar said. “That was sort of a bummer for us.”

That's why you should rarely listen to user feedback if you don't fully understand their experience. In this case the explanation is simple: users expect your system to be worse/slower than what it is, so when it exceeds their expectations, they are surprised and report this to you, but you've just set a new expectation that your software is faster than others out there, and then destroying it with an update.

>The security theater appeared to work

Already mentioned in this HN thread, but wrong term here.

>The needle only wandered within the margin of error of the forecast at any given moment, Aisch explained

Then put an error bar around the needle for crying out loud. Designers need to stop assuming their users are stupid---this is an annoying trend. If you're over the voting age, you can understand the concept of error bars. If the "needle jittered less and less", then the error bars are already known, so the designers actively chose the "lying" method to the truthful and more informative method.

>artificial static that Skype plays during quiet moments in a conversation to convince users the call hasn’t been dropped

This one is fine and can be grouped in the "skeuomorphism enhancements" category.

> This one is fine and can be grouped in the "skeuomorphism enhancements" category.

Actually, it's called comfort noise, and it's not just for skeumorphism's sake: https://en.wikipedia.org/wiki/Comfort_noise

TurboTax being the worst offender: they use a GIF to simulate step completion when the whole thing has already been completed to make you feel like “they're doing hard work”…

"The security theater appeared to work." (referring to a fake progress bar in a game)

That's not what security theater means.

Stupidity theater maybe?

This article was seriously one of the most depressing things I've ever read on HN.

Sorry about that, it was sad but still felt it was interesting enough so I shared it here.

Don Norman (The Design of Everyday Things) discussed this at the Business of Software Confence almost a decade ago: https://vimeo.com/96714148

He specifically talks about the case of benevolently deceptive progress bars vis-à-vis tax software @ 52:30.

Basically, UI/UX is theater, and just as Puck observed in A Midsummer Night’s Dream, humans come to theater because they want to be fooled.

So, good UX is the magician that is upfront about the fact that everything is a trick, but evil UX is the charlatan that hides the fact that a trick is being done in the first place (credit to Jaron Lanier).

<raises hand> Yep, I do this in most of my apps, especially where I have to pull data from a legacy system that give me NO feedback progress. Rather than handballing this 'quiet time' to my users, I tend to create timed progress bars that try and 'guesstimate' the timeframe based on historical transactions of the same size.

Or else I will randomly display various loading messages that are quirky but not relevant. Must admit I was highly inspired by the old SimCity loading messages, which seems to have further inspired the devs at Slack etc. with their creative loading messages.

Two mobile devices I worked on, at different companies, ended up with fake progress bars for boot-up. We engineers wanted individual bar segments for kernel load, filesystem mount, daemon startup and so on -- but wiring up the necessary instrumentation to the GUI would have been significant work, and management wasn't going to allow anything less than a show-stopper bug to delay code freeze.

So in the real world, time-to-market beats UI truthfulness.

Just show me the console log...

Change the font, write it sideways in a frame, viola - progress bar!

Deception is NEVER benevolent.

Don't lie to your users, people.

So I should never pretend that an operation that took 10 ms took 200ms so the users stop hammering the Save button over and over again because there's 'no way' it could have saved that quickly?

Why wouldn't you instead show a timestamp of the last save, giving confirmation that the save really went through?

Or a quick tooltip that flashes "Document saved" before disappearing?

Or disable the button for a second after saved?

Or show a cute little "save complete" icon?

Or autosave on change and disregard the save button entirely?

Or just give a save button because that’s what people expect and want?

Our software product eventually got auto-save after having required manually saving for a while. We got rid of the save button, and got tons of complaints.

The button went back up, with no functionality, because users liked that.

Finally got rid of the button and put some text that said 'saving...' -> 'auto-saved' in its place.

Should have put "Saving. Please do not remove the MEMORY CARD™ or turn off the power."

Why not an enable/disable edit button?

Typically, applications disable the save button when there are no changes that could be saved.

Our brains are funny things and there are lots of ways to hack them to make the world a more enjoyable place.

A related idea: https://signalvnoise.com/posts/1244-defining-the-problem-of-...

I would put these solutions into the same category: accommodating the way the brain works to create an overall more pleasant experience.

You may choose to call it deception, but you probably don't want to live in the world where no one does anything along these lines.

> overall more pleasant experience

It is far more pleasing to understand what is going on and be able to measure its progress then to be shown a series of arbitrary shapes and symbols that happen to push one's happy buttons.

Stop pandering to your users' mercurial, unpredictable, and manipulable feelings, and start using your software to teach their brains how it all works.

Plus, then I don't finish the interaction with, "well, what else have they deceived me on?"

Maybe for you but i dont think that is true for a majority of the population.

It's visual "proof" that the app itself isn't hung. I agree that you would have to be careful with the text, but progress bars do have some value.

No it's not. It doesn't prove anything, and there are ways you can prove it that don't deceive the user, like a status message at the end or a change of button text. The value of a progress bar is for the user to see the state of a background process, not to see whether it suceeded. Don't assume that all your users, or even a small proportion, think this.

I'm not suggesting deceiving users. I'm suggesting a spinner isn't much proof of the app not being hung. Some kind of updating status or progress is, assuming it's not complete bullshit. I can see cases where "slightly bullshit, but somewhat true" is better than just a spinner or unresponsive UI.

>Some kind of updating status or progress is, assuming it's not complete bullshit

This is where we agree. If the progress bar is bullshit (like the IE6 loading bar), then it means just as much to most users as a spinning beach ball, but slightly more insulting to the users' intelligence/experience.

I disagree. There's a difference between a progress bar that could just be a spinner or no progress bar at all because it's fake. And a progress bar that attempts to communicate real progress.

For me, a spinner doesn't say much, because it could just be something like an animated gif, while the app itself is hopelessly out to lunch. Knowing that at least one thread is working in a long running task is calming.

> (Of course, most designers won’t have the chance to ask their users whether or not they want to be tricked, so they have to make that call on their own.)

It’s a well-documented fact of user experience that asking users what they want is often the least accurate way to uncover that information.

In a similar vein, there's this website:


Although; in this case; I'd hesitate to call this a strict example of 'benevolent deception'. ;)

Almost nine thousand lines of Javascript to show a fake loading screen for a few seconds...

More than a few times, I've had an app where an "in progress" dialog would pop-up and disappear for an operation that could take anywhere from 0.1 seconds to a few seconds to complete. If it happens to complete quickly, you don't get to see the dialog text and it can be confusing if the operation succeeded or not. A solution is to force the dialog to be shown for a minimum of a couple of seconds. It's a weird trade-off between wasting the time of a user who understands what's going on and avoiding confusion for a user who doesn't understand the app so well.

Or you can delay showing the dialog for half a second, during which you gather progress data and estimate for how long the dialog would be shown. If it's less than a couple of seconds, don't show it at all.

Yep, that's another way. You still need to give some kind of feedback though if the dialog isn't shown otherwise it'll get perceived as lag. Also, say you wait 0.5 seconds until the dialog has to be shown but the operation takes 0.51 seconds: once the dialog appears you should still probably have it displayed for a minimum amount of time otherwise it looks like a glitch.

After 0.5 seconds you should have a good enough estimate to know that the operation will take 0.51 seconds, in which case you don't show the dialog at all. Of course estimations are sometimes wrong, but it shouldn't be a problem if you flash a dialog for 0.01 seconds once in a thousand times.

A related annoying thing is the spread of uncalibrated progress bars, that move front to back, then again loop around, giving no visual feed back of the quantum of time yet remaining.

That's what I thought this article would be about when I saw the title. Those are also a pet peeve of mine. If it doesn't track some real measure of progress, just show a spinning hourglass or something to indicate busyness.

> or help people get used to a new form of technology (like the artificial static that Skype plays during quiet moments in a conversation to convince users the call hasn’t been dropped)

Actually ever plain old telephones have intentionally imperfect speech transformers so you can hear your own echo and digital cellular phone networks do the same thing as Skype.

A funny counter observation is that because computer user interfaces have got progressively slower and slower (as it typically takes a "long" time to open documents or process something) people don't necessarily trust the right thing did happen if things actually go fast even if it's possible. So, in a perverse sense "slower is better" because people have accustomed to computers being slow.

Much like jerky, twitching, stuttering video playback used to be cool—to the extent of intentional frame drops introduced in things like music videos—because that looked "computerised". Game animations and video playback on DOS/Windows at the time were stuttering or had visible shear because waiting for vsync was apparently harder than in earlier hardware and everyone tried to avoid all that; yet it was fashionable in media that could've run smooth.

I’ve seen code with progress bars that didn’t hold up under maintenance (basically lying over time). As features were added, explicit progress percentages might not be updated so last month’s “30% complete” point might have 3 more steps in between this month.

In my humble experience the impact of this issue is multiplied on mobile; given the mobile context the user expectation is in amplified and the need for clear communication made more relevant. A simple “spinning wheel of death” is often not enough. However, I’m not bought in on the term ”benevolent deception”. Where I’m from we differentiate this by differentiating being honest with being earnest. “The importance of being earnest” (forgive the pun) is that the earnest person has your objectives/priority in mind regarding the outcome for the recipient. An honest persons is an indifferent to the outcome or result. The earnest person is looking out for you.

Similar to the trick of putting mirrors in and around elevators so that people can just "ape out" while they're waiting. Cracks me up when I see people doing it. Especially when it's me.

>Similar to the trick of putting mirrors in and around elevators so that people can just "ape out" while they're waiting.

Actually more similar to the "close door button" that doesn't actually do anything in a number of elevators:


or, more generally, "placebo buttons":


A example of this approach failing can be seen in Pokémon Go, where a Pokeball will shake to show a captured Pokémon trying to escape. The user is forced to sit through an obviously fake delay before they are rewarded for their efforts.

It seems to be an attempt to increase the tension but the execution is incredibly bad.

This is a mainstay from the original games, but it also serves a useful purpose - there's an RPC that's asking the server if the catch was successful. It does a pretty good job of hiding that latency.

I never got into Pokemon Go, but it was pretty effective in the original game in that all kinds of superstitions developed about what buttons to press at what times during the animation to increase the likelihood that a Pokemon would be caught.

Definitely not an RPC. The animation takes about 8 seconds, and if you force close the app during the animation you can reopen with the final state resolved.

I can see a case for artificial delays in some cases, so the user can comprehend everything relevant that is happening. But... trying to also use this time to employ tricks to give users "false confidence" in your software is taking a questionable turn.

So you're telling me that SimCity isn't really reticulating splines during loading?

I do this all the time with loading spinners...if it's "too fast" then psychologically it just feels like nothing happened...so instead I just setTimeout() for 3 seconds.

Have you considered how much accumulated lifetime is wasted by all those 3 seconds again and again?

How much time would be wasted by users trying again because they think that first time didn't work?

I don't think put a fake progress bar in shareware I wrote 25 years ago. And even then it was as a joke about other software's obviously fake progress bars.

> We combed through the source code powering TurboTax’s website, and soon confirmed my suspicion.

I am pretty sure just opening the network tab will show the loading gif.

> "[Intuit] regularly lobbies to keep the complicated U.S. tax code in place, and opposes proposals that would radically simplify it."


The Uber app shows a bogus map animation when its "locating 3 cars in your area"

By the title and "some" does it not mean, "all" apps use fake progress bars? The only apps that use legit progress bars were made in '94, the ones that have not had a superiour product come along because they were done right the first time.

One of my sites has a whole fake interstitial page, people love it

I immediately thought about TurboTax when i saw the title.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact