Gmail’s fake loading indicator (2020)
smitop.com
smitop.com
Let's just consider what would factor into an accurate status bar. Gmail would need to know in advance:
1. the total payload size (which is different for everyone since some might have locally cached assets and everyones inbox size is different)
2. would need to know # of assets to be downloaded by the user (since # of assets, not just file size, affects load time)
3. how fast your computer will render the webpage (different processors, browsers, versions, etc all affect load time)
4. how fast is your internet connection and pack loss (more pack loss on mobile networks, etc)
5. is there any blocking content on the page that will affect delaying "first paint". (Why things like Lighthouse exists)
And many more factors.
This is unneeded complexity when instead, you can just display an animation to distract the user while the page loads.
This is 100% a K.I.S.S.
An indeterminate circular progress bar would distract the user just as much but with less lying.
This is typically how games handle it, since the loading is split into "components"/"groups" anyways, so each "group" acts as a checkpoint, maybe around 20% of the total loading time. If you're loading assets, you could just animate the progress between loading those assets, within the group as well, otherwise just animating the bar moving between the groups.
Tada, you have a progress bar that actually bars progress, and it's still simple.
but is it simpler than an animation? And is an "actual" progress bar any better for the user than the fake one?
In the best case, no, because the progress bar disappears so quickly you hardly notice it.
But in the worst case scenario, yes, it's useful to see that your connection dropped, rather than finding it out after waiting for something that is not even actually waiting.
Gmail handles failed connections separately from the loading bar animation code. If network connection fails during the initial page you get an error page instead of a hung loader. If loading fails during use of the page you get an offline indicator. If you have network but it's performing horribly you'll get a suggestion to use the basic static interface.
None of that logic is dependent on how the progress bar is moved.
How is this simpler than just showing a real loading indicator and let the user react to timeouts?
The user has more knowledge about their internet connection than gmail, so they will likely have better knowledge how long the page usually takes to load.
Yes, this is the part that is simplified
> and then put in additional complexity to detect loading timeouts.
No, there is no "additional complexity" to put in. Even if the page had no loading bar at all these functions are needed, exactly as implemented, to let the user know if their mailbox is having trouble synchronizing while the tab remains open.
These functions however don't tell loaded percentage (as it's a continuously synchronizing page) they just tell connectivity status. The additional complexity would be special functions to tell initial page loaded percentage just to move the loading bar exactly instead of falsely.
> The user has more knowledge about their internet connection than gmail, so they will likely have better knowledge how long the page usually takes to load.
Not sure what this part was in response to but I'd say it makes a great argument as to why the loading splash screen shouldn't actually try to estimate how much of the initial loading has passed.
Absolutely.
Gmail was ready long before that. Most of those requests are just pre-loading the immediately visible email threads in the background.
Disclaimer: not associated with Google, but have reverse-engineered the Gmail XHR-format for (non black-hat) web-extension purposes.
If any(one) is in a position to provide that, it's goog.
I think it would also be neat to have standardised conventions for progress bars, that possibly encode more complex information e.g. uncertainty, which bar sections are io/net bound etc. Again, low level standardisation would help.
But no.
No. You just need to display the progress.
If you need to load X KB in assets, and you have loaded Y KB in assets, that's all you need.
You don't have to add time estimations. You could, but you don't have to.
How do you know what you need to load in the first place? For sufficiently advanced applications this might be harder than you think.
Progress bars are typically where AI would excell. After a while, the algo looks like this:
- “I know that at 34/93 items, there are generally 3 seconds left.”
- “I know that in 5% of situation, instead of going smoothly at 64/93, it takes 7 minutes more”
- “So I’ll show a progress bar that goes smoothly.”
It would be great because it would benefit from other people’s install/loading experience, and we could stop trying to make it smooth as a developer by typing “x3 weight for files, x7 weight for dependencies…”.
Please don’t download TensorFlow as a JS dependency, though ;)
But maybe, just maybe, AI isn't the right answer for everything. Especially loading indicators…
This is effectively done via a "spinner".
While a loading bar would be better than a spinner in most cases, that is only the case if the loading bar is actually indicative of progress. If a dev team doesn't (or can't) produce a semi-accurate loading bar, then just throw a spinner up and call it a day.
But it is still nice to have a spinner to let the user know that something is happening in the background that you can't see. Just displaying a blank screen or a fancy envelope icon can confuse users and cause them to refresh the page or click the back button in a panic to get to what they are expecting (a screen of their inbox).
Progress bars are ideal. But they need to actually work if you have them. But table stakes for modern software is at least a spinner to inform the user that something is happening in the background.
This is effectively done via a "spinner".
If spinners actually indicated that, it would be useful.
Unfortunately, most spinners in web apps - like this one - are simply static animations replayed by the browser, without any actual involvement by the app's code. All they indicate is that the browser didn't freeze - something I usually already know if I have another tab open.
They don't give me any information about the actual application: The browser will happily keep the animation running even if the app's JavaScript is already brain-dead or if the app has long lost all connectivity.
The bars themselves only have a couple of important fields... total items and items completed. I'm not understanding all this other complexity you are specifying
Anything is better than a fake progress bar that turns into a static image as though it's frozen.
> Say the first 100 items on the list take 1ms except for the last item which takes 30s.
Yes, in your worst-case scenario, this would be the case - but when would that scenario occur. If each state of the progress bar represents a different operation (as in the gmail scenario), you can structure the different states in such a wy that this doesn't happen.
If different states represent different slices of same operation (e.g. copying files), it's not really likely that ine slice of the same operation always takes a disproportionate amount of time, compared to the other slices.
I wouldn't call it having JS a simple matter of KISS though, features like live refresh seem to be core to an email portal not an over complication.
Only way Gmail's tolerable.
Their worst version isn't full-fat Gmail, though, but their lite mobile version. They've done something idiotic with touch & scrolling on there that causes "stop the scroll" touches to register as taps on elements, making it damn near unusable. You fling-to-scroll, tap-and-hold to stop, but it takes the tap-and-hold as a touch on whatever's under your finger. Also triggers tap-events it when you're making multiple scrolling swipes. I dunno what it is about Google and fucking up mobile web interfaces for no reason. AMP pages also had inexplicable make-scrolling-shitty code in them, which was part of why I hated them. Why put in more work to make mobile suck? It makes no sense.
a) not even have an estimate of how long something will take.
b) not know if your damn process has frozen due to an error.
c) not know what actions are actually happening.
>unneeded complexity when instead, you can just display an animation to distract the user while the page loads
Blatant disrespect of your users is so 1995. If respecting your users is seen as simply adding complexity then you have failed to respect the mantra of "delight your customers." Or, more likely, your incentives are misaligned due to predatory business models.
I think that's more apt for 2021, the era of fake loading bars, lying to the user, hiding functionality, sacrificing performance for labor costs and harvesting private information.
Back in the 90s, UIs were more likely to give you statistics you might or might not care about instead of vacuous animations, and they were fast as hell.
But that's exactly it - a distraction. It doesn't give any information to the user, not even if the page is actually loading. This thing will happily keep on spinning even if there is a network outage.
I'm not sure about GMail's case, but I recall Mac OS X (back when it was called that) used to do something like this. Since showing a correct progress bar doesn't make it look so nice (it might be stuck at 90% for longer than it took to get there) and might be difficult to estimate, they instead wrote the last boot time into a file and on the next boot would render a smooth progress bar that would follow the timer. In my experience it made for a reasonable estimation of the boot time and I thought it was a clever solution.
And how all the k001 k1dz had lots and lots of extensions?
Well there was actually a special extension that made you even k001er: you could paste as many and whatever icons you desired into its resource fork, and it would plop them down one by one during the boot, delaying a bit between each.
Sure it took a little longer to boot, but it made you such a bad-ass!
Iirc Haiku does that in its splash screen. KDE sort of did at some point in KDE 4.x.
I would swear it was KDE 3.x in its splash screen.
https://cdn.pling.com/img//hive/content-pre1/14801-1.png
The icons at the bottom would start in grey scale and be colored as KDE was loading.
[1] basically the initial 4.0 release (which was a rewrite from scratch for the UI/Desktop component) was not usable at all as a daily driver, lots of crashes and missing features. The only thing that worked well from the start were the clock widgets, and they were showcased a lot in screenshot. I think it even reached some kind of meme status by KDE 4.1. But I cannot find any blog post / rant from the time, my search-fu is not that good.
The hope is that the app is fully loaded before you actually attempt to interact with what you see on the screen.
At least that was my perception as I used Win 10.
I'd say it's actually fulfilling the real point of a loading bar: to keep the user pacified through some period of waiting that you couldn't engineer away.
But as an anecdote of where a progress bar was more than just cosmetic: Couple of years ago I attempted to upgrade to a new MacOS on my Macbook and the install ran into some error but gave no indication whatsoever. So the only info I had was that the progress bar hadn't moved at all in 5 hours. I waited another couple of hours before I switched it off and tried again. Without the progress bar I probably would've waited another day. I mean my macbook was still bricked but at least I could compare it to screenshots online of people getting stuck at the same point, allowing us all to blame Apple :)
That's quite a specific scenario but anytime it's difficult to debug what's actually happening, I wouldn't say progress bars are just cosmetic.
With a text console you can see exactly what was going on and in case of where it hung.
If a progress bar or loading animation does not stop when something goes wrong, the it is conveying zero information and shouldn't be there.
Being told that something is working when it has crashed and you'll only notice it after a long, unknown time because the damn output is lying to you.
The one is just to distract the user for some time. The other is to signal that something's going on, and indicate the progress of that (background) task.
A distracting animation is only good to hide some latency. In cases where progress will be made eventually for sure and in a predicable amount of time.
If there is a task you can't be sure about when or even if it completes an animation is not the right tool. There you need a proper progress indicator.
I've seen enough spinners tgat will happily keep going if there is a network outage.
I think this is the difference between "communicating that there is still processing being done, even if I can't give a progress estimate" and - as you say - "keeping the user pacified". First one is helping the user, second one is really just a "not my problem anymore" asshole move.
It seemed very strange since the beginning: "It is not right... it is progressing but I see no packets incoming...". The progress indicator then progresses slower and slower until it reaches half the bar exactly when timeout is reached and a popup with an error message is shown.
It was very frustrating because I could no longer trust the browser. Now, if I want to know if there is progress or not, I have to look at the network indicator which could be disturbed by other network activity. At the time, connections failing were not all that rare and being able to quickly retry to load the page was an important time saver because you didn't had to wait for the timeout.
I once saw my father, who was not well versed, waiting for a page that simply would not load, but instead of retrying he just kept waiting until the indicator slowly slowed down to reach half the bar and only then tell him that the timeout was reached. I approached and said: "It is not loading, try again.", he said: "It is progressing!", I said: "I don't think it is progressing... I think they are lying to us.". We then went back to Netscape Navigator.
This is bad UI. No matter what experts or even tests say. A lie is a lie and is not something a system should do to the user. The correct way to do this is to use an indicator that oscillates or runs around. I think they were invented for exactly that case.
> The correct way to do this is to use an indicator that oscillates
> or runs around. I think they were invented for exactly that case.
At least as far back as IE4 IIRC. I'm not sure about earlier, as while I was around for them being in circulation I never used 1/2/3 extensively.
> Once connected, it started progressing even without receiving any packet
And could climb up to about 80% before the first packet was received.
It was an intentional con to pacify the user and it worked: I've know people convinced that IE was faster than other browsers because when they access a script that connects quickly but takes ages to send out the first byte of response IE initially looks like it is doing something sooner than [insert competitor here] that truthfully showed no progress until data started arriving. It meant that even if MS wanted to change the behaviour to be more truthful in later versions they would have an issue: the same people would make a noise about the new version being slower than the old.
It adds a layer of interpretation to some user problem reports too: “it nearly completed, but then just displayed an error” could mean one of a wider range of things than otherwise.
Like: I get it, traditional mail clients kinda suck, they feel bloated and janky. But the more I think of it, the more I think that webmail was a mistake, especially webmail as heavy as GMail has become.
What about downloading 70 MB of compressed binary code for Thunderbird?
> Like: I get it, traditional mail clients kinda suck, they feel bloated and janky. But the more I think of it, the more I think that webmail was a mistake, especially webmail as heavy as GMail has become.
I don't see how does it differ from traditional e-mail clients, except that you don't have to install, configure and allow unlimited access to your computer.
I value my time more than I value my data, I guess.
Of course, that's not the use case of most people, but that's also one that shouldn't be dismissed entirely - for people who don't trust the modern web in any capacity, local system software is indeed a better choice.
The quick filter finds messages in seconds in a folder with > 10000 mails. Not instantaneous, but not forever.
The global search is instantaneous because Thunderbird indexes the mails.
Not having to rely on the Internet to find your stuff is a feature, not a bug.
Snark aside, I sometimes feel like we reinvent the wheel using new technologies just because we like the new hotness.
I see the OS battles take place and my only thought is..at work, I want an OS that: Boots and then gets the hell out of my way so I can do my work. I don't want it to try and sell me things or re-arrange things or have to spend time tinkering or fixing it.
Now in my free time, sure! I set up a computer with pass thorough GPU so I can game in Windows while running Linux. It was fun and a learning experience.
The problem is mail servers. They usually don't support search this way, so the client has to download or cache each message to do the search. Gmail gets around this by having their own protocol and the indexes ready.
Full-text indexing isn't dark magic at all.
Also most of it will be likely some bloat form HTML mail and attachments (especially with their inefficient encodings).
My point was: Handling full-text search indices over even dozens of GB of plain text isn't anything a mediocre computer couldn't handle nowadays.
You do it only once, do not risk having to do it when being on a metered or spotty connection because your cache is not warm or the webmail got yet another update, which can happen at any time. You can apply Thunderbird updates when you are on a good connection.
You can access your mails offline, you don't re-download them each time you open them. It's faster, even on a good connection.
> configure
The configuration part for most providers is essentially typing one's email address and password, so there is not much to say.
> allow unlimited access to your computer
That is why I am reluctant to run non-free software, but Thunderbird is free, I can reasonably trust it. Especially the version packaged by my OS vendor. I agree a better isolation for native desktop apps may be desirable though.
I just checked and my second gmail login downloaded 500 KB before it became usable. Browser allows for caching of downloaded code.
> do not risk having to do it when being on a metered or spotty connection because your cache is not warm or the webmail got yet another update, which can happen at any time. You can apply Thunderbird updates when you are on a good connection.
I agree with your point. I think that it's possible to implement a separate update for web apps with explicit request, but it's rarely done and unusual for web.
> You can access your mails offline, you don't re-download them each time you open them. It's faster, even on a good connection.
Web browser allows for local storage and offline work which could be utilized for those features. You can enable offline mode in Gmail. I just checked, it works.
Sure, but tomorrow? This afternoon?
500 KB is 1-2 seconds on the connection I'm currently using (not at home right know). It's 4-5 seconds on the train to get there… in the sections were connectivity is available. 500 KB is huge. That's 1% of my previous monthly mobile data plan.
I think we should revisit our idea of what amount of data is fine to do anything on the web today. Data transfer is not free, it needs infrastructure and electricity.
500 KB should be the amount of data to download for getting the full web application with cold caches, tops. Can you imagine the number of instructions you can fit in 500 KB of code, especially high level? I can't.
> Web browser allows for local storage and offline work which could be utilized for those features. You can enable offline mode in Gmail. I just checked, it works.
I guess, but I don't trust this. And as a web developer, I am well aware that local storage is limited in size and there is no way my gigabytes of mails are going to fit.
https://webapps.stackexchange.com/questions/151823/how-to-se...
Compare to the mutt package, a fully features mail client, weighting in at ~1.8 MiB — without the need for an additional gigantic runtime.
I'm not saying mutt is an alternative to GMail for most people. But just to give some feeling for the size relations here.
https://www.mozilla.org/en-US/security/known-vulnerabilities...
Don't get me wrong, I use webmail all the time with protonmail, Gmail, outlook and purelymail, because it abstracts installation and updates, but your argument doesn't seem to be valid.
Most people are using Google's client in some form (Chromium), so they do pretty much have unlimited access to your computer, unless you use Firefox or Safari. Most people are logged into the browser itself, so it's even worse. With Thunderbird you aren't linking every single thing you do online to your email account.
(Or at least, once per upstream update.)
If you stick with mutt, the binary is < 1 kB.
https://en.wikipedia.org/wiki/Jamie_Zawinski#Notable_quotes
>Some have interpreted this as commenting on the phenomenon of software bloating with popular features. Zawinski himself has stated:
https://twitter.com/jwz/status/1331287160738070528
>My point was not about copycats, it was about platformization. Apps that you "live in" all day have pressure to become everything and do everything. An app for editing text becomes an IDE, then an OS. An app for displaying hypertext documents becomes a mail reader, then an OS.
So it follows that most programs that can read email are enormous ("expand" being the operative term, with Emacs and Thunderbird being the archetypal examples)!
App stores try to solve this, but they suck in other ways (e.g. security -- at least the web has a security model. Native apps just expect some kind of ill-defined and unrealistic "trust" in the app's author).
It's strange to compare content to an application, I see this more often and it looks logical for a second because of the matching units but it's like calling a car heavy because the gasoline only weighs 50kg... what?
I'm actually not sure about this, Thunderbird to me seems like it's pretty good: https://www.thunderbird.net/en-US/
The only bloat that i can think of is the calendar functionality that i simply don't care about, but that's easy enough to get out of the way. Maybe one could also have gripes with the account administration section, though that's not necessarily touched in the daily usage.
Apart from that, it does everything i need, in the simplest way possible and is as boring as it is usable. Contrasted with lots of the modern day software, i'd instead put it into the category of "workhorse" software, where LibreOffice, GIMP, KeePass, Notepad++, SourceTree/Git Cola and others live - dependable pieces of software that do what i need without many breaking changes and all that many bells and whistles. The kind that you install and forget about, maybe updating them once every few years if at all needed.
Calendar invitations are .ics files that any calendar client can consume, it’s a different remote protocol underneath too (caldav)
I'm using it as daily driver and wouldn't switch to webmail nor Thunderbird or Evolution.
As far as Evolution goes, I don't see myself moving away from it for now. I can't afford to have reminders not showing up, or have my calendar not syncing for half a business day because something has gone wrong. Evolution is the only program that I've tried that gets both of these right, and I've tried many, many applications both native and Electron-based.
Don't get me wrong, I'd switch in a heartbeat if I discovered a superior solution. But as-is, the few issues are found, aren't enough of a motivation to switch. A few cosmetic/UX glitches and nice-to-have missing features (highlighting background entries with their category's colour, busy/free/out-of-office setting on meetings) are tolerable when the alternatives are so, SO much worse.
But those issues are solved today (and since a long time by now).
I don't know whether Kontact could be considered substantially better than Evolution. But it works fine and has a lot of features not found elsewhere. It's also quite focused on power-users I would say. For example you have configurable one-keystroke commands for all important functionality (and being a KDE application you can configure shortcuts for actually every action if you like to). It handles big inboxes in different accounts (being capable of showing an unified inbox if desired) and independently of that multiple identities. The calendar and mail components handle Exchange idiosyncrasies. The GPG stuff just works.
For people looking for a true Outlook alternative on Linux it's at least one of the things worth trying. That's why I've mentioned it.
I'll repent later.
Here's a test to run on Gmail web client: Mark an email unread or do anything that changes state. Now click the email, as to read it, and then close your browser. It will not let you because it's still "lagging" in the background for you. It's dreadful.
Better fake a progress bar than add dozens of time estimation code for no real value, as long as errors are managed.
The only thing you should try to manage is to detect when things are stuck for real and stop the fake animation / manage the situation. But even this is hard.
But all of this is just exploiting a psychological gimmick which make you feel than an animation with a predictable end feels to end faster than, say, some spinner.
https://github.com/npm/npm/issues/11283
So maybe progressbars are not always so different than project managers?
It was basically that 0-90% of the bar showed the actual loading process of the game's assets, then the last 10% would load in only if the server was ready to let you in, which obviously we had no control over and no way to realistically estimate it.
So when servers weren't under load, the load bar was realistic, you were waiting for the assets to load, then once you got to 90% it would just lerp over one second to 100% for smoothness and load you in, but if the servers were under load you'd get to 90% and nothing would happen whatosever.
The deceptive loading bar has a loooong history through a solid two decades of early MacOS and Windows.
I honestly think the early status bars are the subconscious inspriation for the software estimation joke about the first 90% of code takes the first 90% of budget, the last 10& take the other 90%
Works for me.
Implementing a fake progress bar can be done once and it works everywhere, but a controlled progress bar that's accurate needs to be connected to some actual progress data, and this is engineering work for questionable results.
1. full page
2. unobtrusive
Those 1px progress bars are unobtrusive because you can partially render data you've already received while still conveying that more data is loading.
To make a JS progress bar correctly show precent of data loaded over a network you would need to first know the total data size. That's why JS progress bars are always auto-incrementing and don't represent actual loading progress.
correct but what's the problem with determining it server-side
Saved alot of annoying conversations from that.
Still, this progress animation does serve a purpose. Normally it is prompt, but if you see it at all it means that Gmail is behind the scenes trying to make your account work correctly. So in that sense it serves as a kind of binary indicator.
I wish so hard people would make real loading bars. Ones that _actually_ give you an indication of progress, that don't stall forever on 5% and then jump to 100% instantaneously, or rest on 100% for half a minute before actually proceeding.
Idk, it can't be that hard, right? You know what your software is doing; let each part of the process report how far along it is, and together with rough knowledge how much time each part takes proportionally, you can calculate a very useful progress bar.
So, I confess I assume you're second paragraph is sarcastic?
Probably creates a ton of false clicks for whoever is paying for that advert.
I know it's a minor issue because rendering an accurate progress bar is a hard problem, but in my view this is just another example of how behavioralism leads to a generalized erosion of trust in the interfaces and technologies people use. It may be true that, in an A/B test, users who see the fake progress bar are happier or more patient. But at some point, people are going to realize they're being lied to, and they're going to wonder what else you're lying to them about.
This is why I think the stories of "[$App] listens to your conversations" / "[$App] charges you extra when your phone battery is low" etc. remain so persistent, even when there's sometimes little or no evidence to back them up. If designers have decided that a little psychological manipulation is okay, why wouldn't they be manipulating us elsewhere too?
https://www.thunderbird.net/en-US/
For really important mails I use ProtonMail.
I switched to Thunderbird at the same time I switched to Linux; after some tweaking, I was mostly happy with it.
Then, in some major version, it started frequently freezing up for thirty seconds at a time. Authoring emails in it became impossible. I could not downgrade it because it was version-locked with some system libraries (libnss OSLT). I could not debug it because that was blocked by a bug filed on Bugzilla ten years ago with no fixes or workarounds.
Then, in another major version, they killed XUL extensions.
I still hope to stop depending on Google services some day, but at that point I would probably switch to or write some webmail with a similar-enough UI to Gmail.
I switched from Gmail to fastmail last week, after planning to do so "one day" for a few years. Using a mixture of the web client and Thunderbird, just like I did when using Gmail. No regrets so far, I recommend taking to leap!
No, it's still there even in the most recent version. (Maybe I just have too much mail?)
Unless something has changed in the past 3-4 years.
So in short, you can use Thunderbird as a client with your @gmail.com address, so you still have the same spam filter and search, but a lighter and faster UI.
* Project management and software development methodologies are bullshit! Let's all follow the "Just get shit done" process!
* Loading icons shouldn't lie!
* Unlimited plans should be unlimited! If your business model can't scale with everyone backing up 10Petabytes of manga, don't offer it to me!
If you inspected source, it just had a little exp function with different constants depending on how far in the future it was.
As a user why would I even care about a real loading bar here?
I just care whether the page loads or not.
https://www.youtube.com/watch?v=gnzaS18XuJ4
>Brad Myers
>This video reports on early research about progress bars. It was previously published as: Brad A. Myers. Percent-Done Progress Indicators in Practice and Experiments, Videotape shown at SIGCHI '85. San Francisco, CA. Apr. 14-18, 1985. SIGGRAPH Video Review, Issue 19, no. 6.
>[...] This Buddha, used in some programs at the University of Toronto, shows that patience is in order.
>[...] A further improvement improvement is to use something I have called a "Percent Done Progress Indicator". This combines all the advantages that I have listed before. In addition to showing that works is being done and progress is being made, it also indicates approximately how long it will be before the job is finished.
>The earliest reported use of progress indicators was apparently by Robert Spence in 1976, with something like this clock face.
>I used progress indicators in a file transfer program in 1978, and integrated them into the PERQ POS operating system in 1980 as shows here. When the hand reaches the bottom of the screen here, the program will be compete.
>[...] For those program that cannot calculate how long they will run, it is still a good idea to show that they are executing using a technique called "Random Progress". In the PERQ POS operating system, as progress is made, the busy bee flies around the screen.
>And in the Sapphire window manager, the pattern in the progress bar continuous changes. We have already seen this used in earlier example such as this one from Xerox.
>IT IS GENERALLY A GOOD IDEA TO USE TECHNIQUES LIKE THIS THAT WILL NOT BE CONFUSED WITH PERCENT DONE PROGRESS.
(Brad didn't actually shout that, but it's an important point so I capitalized for the benefit of Google and their GMail users! ;) )
>[...] The experiment suggests that percent done progress indicators can have a positive effect on user's attitudes towards the computer system.
>Intuitively, this is because they can decrease the user's anxiety while waiting for jobs to finish, and therefore increase their satisfaction with the system.
>Progress indicators also give the user enough information so that they can estimate when jobs will be finished, so that other activities can be scheduled appropriately.
>Obviously, progress indicators are not a solution to slow execution times, but they do make the waiting more tolerable.
>The benefits of progress indicators are therefore sufficient to warrant including them in many future computer systems.
Who Made That Progress Bar?
https://www.nytimes.com/2014/03/09/magazine/who-made-that-pr...
>“People wait for all sorts of things every day, sometimes more happily than others,” wrote the interface designer Bob Stahl in a 1986 article for Computerworld. “The problem is how the user feels about waiting.” At the time, machines were often slow and unreliable, and users didn’t always know when their programs crashed. A “progress bar” might mitigate frustration, Stahl suggested, by signaling that bits were flipping with a purpose somewhere deep inside the C.P.U.
>The push to make computers more user-friendly gained momentum in the early 1980s. At a 1985 conference on the nascent field of computer-human interactions, a graduate student named Brad A. Myers presented a paper on the importance of what he called “percent-done progress indicators.” “I had the sense that they were useful and important, and not used as much as they should have been,” Myers says today. (He’s now on the faculty at Carnegie Mellon University.) He told his colleagues that progress bars made computer users less anxious and more efficient, and could even help them to “relax effectively” at work.
>To prove his point, Myers asked 48 fellow students to run searches on a computer database, with and without a progress bar for guidance. (He used a capsule that filled from left to right — like a giant thermometer from a charity drive, tipped on its side.) Then he had them rate their experience. Eighty-six percent said they liked the bars. “People didn’t mind so much if it was inaccurate,” Myers says. “They still preferred the progress bar to not having anything at all.”
>Since the ‘80s, other kinds of progress bars — audio, tactile — have been suggested, but the horizontal form prevails. There have been some refinements: Bars now strobe in color, or show an animated ribbing that slides back against the grain. These effects can fool the brain and make a bar appear to move more quickly, says Chris Harrison, another Carnegie Mellon scientist. Because people hate to see a progress bar reach a standstill, some inch forever forward even while a task is stalling out. For Harrison, these tricks raise a funny question: “Do users really want the truth, or do they want the more relaxed, more comfortable experience?”
>There’s a deeper question still: Is a progress bar a tool to make us more efficient or a sop that helps us pass the time? Its ancestor, the pen-and-paper “progress chart,” showed up in the early 20th century and was hailed at the time as a major innovation. It “refers all facts to the irreducible and final element of human life — time,” wrote Walter Polakov, an early pioneer in project management (and dedicated Marxist), in 1923. “Because it is true to the human dimension, it is both human and humane; hence it obliterates conflicts between men and management, promotes the fullest exercise of man’s creative forces and places work in its proper relation to life.”