I immediately thought about TurboTax when i saw the title.
Why some apps use fake progress bars (2017)
191–200 of 200 posts
Re: Why some apps use fake progress bars (2017)
#192Earlier quoted context omitted.
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 mo…
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.
Re: Why some apps use fake progress bars (2017)
#193Similar 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:
http://www.dailymail.co.uk/sciencetech/article-3880250/The-c...
or, more generally, "placebo buttons":
Re: Why some apps use fake progress bars (2017)
#194I 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.
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?"
Re: Why some apps use fake progress bars (2017)
#195I 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.
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.
Re: Why some apps use fake progress bars (2017)
#196Earlier quoted context omitted.
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.
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...
Re: Why some apps use fake progress bars (2017)
#197Earlier quoted context omitted.
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.
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.
Re: Why some apps use fake progress bars (2017)
#198A 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.
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.
Re: Why some apps use fake progress bars (2017)
#199A 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.
Re: Why some apps use fake progress bars (2017)
#200Earlier quoted context omitted.
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.