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!
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 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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”…
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.
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?
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.
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?"
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.
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.
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.
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.
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.
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.
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.