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.

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!

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.

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.

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.

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.

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.

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.

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.”

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.

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...

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.

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...

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."

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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 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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.