Hacker News new | past | comments | ask | show | jobs | submit login
Gmail’s fake loading indicator (2020) (smitop.com)
194 points by pcr910303 78 days ago | hide | past | favorite | 188 comments



Progress bars are inherently difficult to create since you need to predict the future to provide an accurate status on progress.

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.


Huh... loading bars do not have to move evenly and smoothly. You reduce all your loading activity to a checklist, scale that to 100%, and update the progress bar with the number of checklists completed as soon as you are able

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


If you're just counting 'x of y things done' is that really a helpful measure of progress? Say the first 100 items on the list take 1ms except for the last item which takes 30s. your progress bar will be stuck at basically complete waiting for the last item to complete which doesn't feel like you're really communicating anything useful about progress.


It actually is, as with some time, you learn which phases take what amounts of time in a normal situation. This lets you judge pretty quickly how long loading should take - or if something goes wrong.

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


It would be for me.

Anything is better than a fake progress bar that turns into a static image as though it's frozen.


Progress bars measure progress, not time remaining. I don't understand all these other rules people have come up with about them, maybe we need to stop making it so complex


Depends on how you think of progress; as a function of total time or a function of total amount of elements on 'checklist'


There is a set amount of HTTP requests happening when you load gmail. When I just tried it out now, it seems to be about 200 before the page has fully loaded. Instead of doing all of what you wrote, figure out which request is the last one, and a couple of the ones in the middle and make the progressbar incrementally go up as the browser finishes the requests.

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.


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


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


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


Ok, so instead showing an actual loading indicator, you show a fake loading indicator and then put in additional complexity to detect loading timeouts.

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.


> Ok, so instead showing an actual loading indicator, you show a fake loading indicator

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.


> And is an "actual" progress bar any better for the user than the fake one?

Absolutely.


> When I just tried it out now, it seems to be about 200 before the page has fully loaded.

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.


> 2. would need to know # of assets to be downloaded by the user (since # of assets, not just file size, affects load time)

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


Sounds like a great idea! And in the future we would need to dedicate at least one discrete GPU exclusively to AI progress bars, right? Would drive sales. So seems legit, doesn't it? ;-)

But maybe, just maybe, AI isn't the right answer for everything. Especially loading indicators…


I get it, this is a hard problem to solve. BUT it is a terrible user experience to:

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.


> Blatant disrespect of your users is so 1995

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.


You're correct, but I was talking about the actual attitudes of coders, which were remarkably hostile towards users in the 90s.


100% a K.I.S.S. is their old non-javascripted Gmail interface that never needed a loading bar.


The entire page loads faster than most "AJAX" interactions on full-fat Gmail. Plus it doesn't use more memory than my first three Web-connected computers had combined, for a single tab.

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.


AMP scrolling was broken on iOS because of an iframe scrolling bug in Safari that, like any Safari bug, wasn't fixed for ages. I never experienced any issues on Firefox or Chrome on Android. https://medium.com/@dvoytenko/amp-ios-scrolling-redo-2-the-s...


The old interface is still there https://mail.google.com/mail/?ui=html and will be recommended if the client is underperforming during loading the new interface.

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.


I don't want my email web client to live refresh. I check a given inbox when I have the energy to respond.


And some people like a car with a manual transmission but in either case it has nothing to do with KISS when talking about an automatic car. KISS is about removing unnecessary complexity from a design not removing functionality from the design to simplify it.


Is there a reason meta refresh isn't good enough?


pretty sure KISS is about removing some functionality to simplify, like "don't be over-ambitious"


Why even show a (falsely) determinate progress bar over an indeterminate one then?

An indeterminate circular progress bar would distract the user just as much but with less lying.


Probably because in the normal case where it does finish loading relatively quickly, the progress bar causes the perception of faster loading.


If the "loading bar" moves everyone once in a while, it acts as a "did the page freeze" indicator. "Should I reload the page... oh, it just moved up a little."


K.I.S.S would be no loading bar at all. The least amount of work and also not baldface lying to users.


I agree, but want to add to this by saying there should still be some indicator that a background process is happening.

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.


> I agree, but want to add to this by saying there should still be some indicator that a background process is happening.

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.


ye totally agree with that. Spinner + some sort of semantic explanation. Like simply the text "loading gmail" or whatever. Tell the user what is happening.


> This is unneeded complexity when instead, you can just display an animation to distract the user while the page loads.

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.


Or you know, set a maximum payload size to load the main page then load the rest of the needed content (when it is actually needed). Set a well known header on the contents and use that header (and the time it took to retrieve it) as a way to detemine the aprox time it would take to retrieve your well known payload size... I know I am over simplifying it but... Its Google and they hire some of the most brilliant minds in the wolrd and put them to do unit tests... I think many of them would be happy to be put up to a problem of this type


All difficult, but no need to reinvent the wheel - these could also be standard(ised) widgets/libraries/services; possibly build into the OS/browser.

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.


Helpful, built-in browser UI elements are being left to rot rather than improved, so I doubt that'll happen. See, for example, the HTTP auth login prompt. That could have been improved into something actually desirable to use for authentication on most sites, and saved god knows how many developer hours across the globe that go into making login screens & flows. Browsers should have started building in payment input screens a decade ago, for similar reasons. It'd give us better security, better compatibility, better accessibility, and save huge amounts of duplicated effort. Many millions of dollars saved across the economy, every year, with something like that.

But no.


>Progress bars are inherently difficult to create since you need to predict the future to provide an accurate status on progress.

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.


> If you need to load X KB in assets,

How do you know what you need to load in the first place? For sufficiently advanced applications this might be harder than you think.


How can you from JavaScript see how much of an asset has loaded?


Presumably this can be calculated server-side. So you could send the full size right away which the JS could use to calculate loading progress.


You mean we should invent something like the HTTP Content-Length header?


I remember Internet Explorer also doing this back in the day. When I was a kid I assumed it was showing correct progress, and I'd be patiently waiting for no payoff. Only much later I learned it meant nothing, it was just showing it wasn't dead.

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.


Remember how the original Mac used to plop down icons of all your system extensions one-by-one along the bottom of the screen, in the order that it loaded them, which helped you know how long it would take to boot, and figure out which one crashed your system?

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!


> Remember how the original Mac used to plop down icons of all your system extensions one-by-one along the bottom of the screen, in the order that it loaded them, which helped you know how long it would take to boot, and figure out which one crashed your system?

Iirc Haiku does that in its splash screen. KDE sort of did at some point in KDE 4.x.


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


KDE 4 also used this style of splash screen (with the icons fading into view): https://news.opensuse.org/wp-content/uploads/2008/02/kde4-sp...


Yeah, now I remember, I removed KDE 4 and its clocks [1] from my memory (it actually made me switch to Gnome and never went back)

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


What a clever solution! I like it because it still f gives an realistic indication of how long it will take!


Yeah, that's clever indeed.


Jenkins also does that (estimate progress based on last duration), but also shows estimated status equal to the previous one. If you know what it means, you know what state you're trying to fix or maintain, but it is quite confusing at first.


iOS does this when loading/switching apps. It takes a snapshot of the app as it was when closed, and then when you are loading that app as it was when you closed it it just shows the screenshot until the app state is reloaded.

The hope is that the app is fully loaded before you actually attempt to interact with what you see on the screen.


I think Windows does the same between desktop-compositor crashes and restarts. (When it doesn't get to bad, as than you just get a back screen with the mouse cursor until the compositor isn't restarted).

At least that was my perception as I used Win 10.


This defeats the point of a loading bar: it’s supposted to give an estimate of progress, not fill up at a rate entirely unrelated to actual loading!

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.


I understand that the ideal 1-to-1 progress bar is not worth making, if it's even possible, but they should at least be proportional to actual progress. I want a progress bar that goes up if and only if there are responses being received, and processing of those responses completes. Progress bars that continue to fill up even when everything is completely hung make my blood explode.


But why? Why is that important?


You know what's worse than being not having a perfectly accurate representation of something?

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.


So the user knows if they should stop waiting, reload/refresh/restart, or just hang tight.

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.


Because you want to know if there was an error during loading and it's not progressing anymore, instead of a forever-increasing loading bar that just makes you wait.


Animations are indeed great for that but that's not a progress indicator. Those are two distinct things.

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.


100%. Loading indicators are psychological placebos for the user.


Maybe on the web. But I feel on the web they are often not even there to mask load times but are just used as powerpoint-transition-like-effect. And also to prevent the user from seeing page-jumps when the page first loads.

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.


Off topic, but that's why I hate GUIs and animations hiding log output of the system when it's doing something important.

With a text console you can see exactly what was going on and in case of where it hung.


Reminds me of a story my old boss used to tell about how they dealt with complaints about long waits for elevators in one high-rise building: putting mirrors on the walls. With sufficient distraction (everyone likes looking at themself, or at least can't help it) the elevators were no longer "too slow"!


I read once how they kept elevator attendants long after they had any use as a placebo to help people get acclimated to automatic elevators.


Once one gets old enough, you'll just get up and pee whenever something is slow on the computer.


I've been known to get up and code whenever something was too slow on the toilet.


Or you can just drink too much coffee and la croix and have to pee all the time. :)


I sort of miss the 5 minute compile time coffee breaks.


Then at least be so kind to ensure the spinner stops if there is an error.

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.


The first time I've seen something similar was in IE5, I think. The loading indicator oscillates before connecting to the server. Once connected, it started progressing even without receiving any packet. It was easy to tell because win9x had a nice indicator when network packets were sent or received.

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.


> IE5, I think.

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.


  > 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. 
Which is why any open-loop activity indicator is called a "spinner", even if the actual graphic today does not spin.


I agree, UI stands for User Interface. If we the users can't trust it to display information accurately then it is a poor interface.


Honestly though: the idea of loading 20MiB of JS to read a 24KiB message is weird.

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 get it, traditional mail clients kinda suck, they feel bloated and janky.

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.


Thunderbird constantly lags for me when clicking emails, sometimes locking up for 10-15 seconds. It also has weird issues with how it displays that you have new messages. It will quite often show me I have unread messages that I've actually already read and I need to expand the account and click through every folder to get it to refresh and recognize that there really aren't any unread. I also have an email account on there that its said I have an unread message for the last 3 months, but when I click the arrow and expand the account, the unread bold (1) goes away, then comes back when I collapse the account. Its just permanently incorrectly stuck as unread for some reason.


I tried using Thunderbird a few times because that's what real tech people use. It's just not as good as Gmail in my browser.

I'll repent later.


I've used multiple email provider web mails (Gmail, ProtonMail, and my current provider fastmail). I have also used various clients over the years, haven't used thunderbird in a while but I still use mu4e in emacs as well as neomutt (terminal email client). In terms of feeling "smooth" the web clients have always been superior to the thunderbird, but it's been a couple years so maybe thunderbird has improved. Mu4e and neomutt are equal if not better than most web mail clients but since I always have a browser open I usually just have a web mail tab pinned. I wish I could use thunderbird, I've always liked its design, but it has a hard to describe quality which makes usage "clunky" feeling.


Let me guess, you're using Gmail or another "web mail" on Thunderbird? Yeah there's a lot of artificial lag generated by Google or some bad process along the way. I get the same lag in Gmail, but they hide it behind CSS changes. In Thunderbird they actually show you the inherent lag (until it's ACTUALLY changed state). It's a Gmail thing though and most email connections are blazing fast.

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.


Calendar support is actually a desirable feature for me. I'm sad to find that there's nothing fully outlook-compatible in the open source world. Evolution gets very very close, but it still lacks support for viewing/changing some of the meeting data, and I believe background colour for meetings (which I miss a lot).


I think that the Apple way of separating calendar and mail is desirable honestly.

Calendar invitations are .ics files that any calendar client can consume, it’s a different remote protocol underneath too (caldav)


Ever tried Kontact?

I'm using it as daily driver and wouldn't switch to webmail nor Thunderbird or Evolution.


I think I tried it (for non-Exchange calendaring), but I didn't like it for some reason.

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.


To be fair Kontact (KMail) had its bad days. The whole Akonadi stuff underneath got a really bad reputation because of that. And that was for a reason, for sure!

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.


> Honestly though: the idea of loading 20MiB of JS to read a 24KiB message is weird.

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.


> What about downloading 70 MB of compressed binary code for Thunderbird?

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.


> You do it only once

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.


> I just checked and my second gmail login downloaded 500 KB before it became usable

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.


There is a basic HTML version of Gmail for slower connection speeds or folks wanting to use less data.

https://webapps.stackexchange.com/questions/151823/how-to-se...


500 KB is huge. That's so true.

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.


Is it true that you only need to download Thunderbird once? Don't you need to download new versions? Security updates?

https://www.mozilla.org/en-US/security/known-vulnerabilities...


re-read my comment


You can also firejail programs on Linux and so forth.


On one side, you download 70MB of thunderbird once and update it every once in a while without losing access to your emails while it's updating. On the other side, you have to download 25 MB of Gmail more frequently because cache is invalidated at a higher rate than thunderbird updates and you have to wait for your browser to download most of the page before you gain access to your emails.

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.


It's not just that the cache is invalidated, I also suspect Google changes the JS code fairly frequently enough that the browser needs to download a fresh copy (even if the cache it has is not that old and could otherwise have been reused). Compiled apps on the other hand are much more static.


Zawinski's Law of Software Envelopment states that "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

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


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

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.


I personally would prefer a one time 70 MB thunderbird download rather than a recurrent 20MiB download every time it loads.

I value my time more than I value my data, I guess.


It obviously doesn't transfer 20MB of anything. With a hot cache it needs about 300KB of traffic to load the initial thread list.


Browsers caches that kind of assets. So in practice you only only download it once every time it gets updated


Unless you only use web applications in private browser windows and/or clean your browser data every time you close the browser and/or have cache disabled (though this one's more by accident, since Firefox gives you the checkbox under network tab, but it doesn't work for just the site that you're developing locally, but seems to persist globally for all of the browser).

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.


Which is likely more than once a day given today's web-development practices (continuous integration and such).


To be fair you only have to download the 70 MB once (+ the occasional updates). Gmail instead pushes its JS over and over again. Every time I load Gmail it feels like it's starting from Square One all over again but even actually using it (opening, replying, etc) feels slow. Thankfully one of my several $WORK email accounts is 365 based so I just redirect my two other $WORK_RELATED Gmail accounts there. Big productivity boost that way since I get instant access to my emails without having to wait for the JS to load over the network.


It differs very greatly from traditional desktop mailers in that the search on gmail is fast (because it brings thousands of machines to bear on your request for an instant) and the search in desktop apps takes forever (because your little computer no matter how beefy does not have a million cores).


The reason search is slow on your computer is just that the app doesn't use the right kind of index, or maybe no index, for whatever reason. I can index hundreds of gigabytes of text on my laptop and have full text search take a couple milliseconds.

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.


IMAP does support server-side full-text search of bodies. (In mutt, this is invoked with the =b operator of the l command.) Amusingly enough, this works well with real mail servers like dovecot, but it seems to sometimes miss matches with gmail, because gmail's indexes aren't very good.


The more you know, thanks!


Have you actually tried search on Thunderbird?

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.


But then my search is not powered by the cloud!

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.


In apple mail, I can search all my mailboxes for all my accounts in one search and it's pretty much instantaneous. Most of my email accounts are hosted in gmail, but I generally use Apple Mail to access them (the only times I go into the web interface is for the account I use for submitting writing where I apply multiple tags to each message indicating publication/piece submitted/response type or to clean out the spam folder since I worry a little that if I delete messages from Apple Mail I might be inadvertently telling gmail that the spam wasn't actually spam).


I have a few GB of mail folders. I can search them more or less instantaneous, using Kontact (KMail).

Full-text indexing isn't dark magic at all.


I guess we have different requirements of scale. My gmail is over 300GB (one of the reasons I have a Google 1 subscription).


Ever considered to archive parts of it? I have difficulties to believe all of that is currently needed mail. (I know, it piles up over the years! :-))

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.


Thunderbird downloads once.

(Or at least, once per upstream update.)

If you stick with mutt, the binary is < 1 kB.


The web is a runtime platform and a distribution medium for the client software here. The "bad" part of it isn't web mail per se, but that the client gets downloaded every time. OTOH, you don't have to find the software itself on some site, download and install manually, then configure, and so on.

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


The funny thing is… if you are using gmail app on your phone, you don’t use webmail, because webmail is indeed too janky and bloated for phones, and native is just faster.


On a related note, this is one of the joys of using Fastmail: it's actually blazing fast, not just on desktop but also on mobile. It's probably the best web app I've ever used in terms of UX.


You don't download that much for every message, there's caching.

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've only felt that with non-traditional mail clients. Traditional ones are fast, instant and work without any resource hogging.


I like Apple Mail way more than webmail clients. Thunderbird is okay, but I'd still choose it over a 20MB webjank.


The 20 MiB is cached


The case is often invalidated though, because these 20 MiB are often updated.


All progress bars are like this nowadays. At least for fast jobs (seconds to minute) where estimating time is hard, unreliable, and probably useless.

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.


Progress bars are like project managers. They try to provide realistic perspectives on what's going on, but at the end of the day they only have a vague understanding of what's happening and how much work is left.


Except they also add tons of overhead which also makes everything go slower, including that meeting to discuss why we go so slow.


Reminds of the time NPM (the CLI) was made slower by having an inefficient progressbar, disabling the progressbar made installations significantly faster.

https://github.com/npm/npm/issues/11283

So maybe progressbars are not always so different than project managers?


New insult for PMs: You're worse than NPM's progress bar!!


I had to code a loading bar indicator in a big online-only game few years ago and well, not really proud of the solution.

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.


In this case, I think I would have gone with a “shimmering” full loading bar when waiting to connect to the server.


Well yes, but that's the issue when working on a project with 800 people - my job was to make the loading bar work, the art direction didn't care that it would get stuck, and I can't override an artist and just make it shimmer.


I find this author's semi-outrage amusing. Oh, what a world of deception your virgin senses have yet to comprehend.

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%


The psychology of these versus, for example, an infinite spinner strikes me as interesting. The loading bar, even though it's fake, has an end and makes it feel like you're getting closer to the wait being over.

Works for me.


So is the progress bar on GitHub and many webpages. I think in most sites, users aren't interested in how much it's loaded but rather in the fact that it's loading at all (note that this doesn't apply to all progress bars).

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.


Youtube & Netflix do this the same way…actually a lot of JS/TS frontend frameworks nowadays have this 1px loading bar at the top which behaves the same way (speedup, slow down never reach 100%)


I think loading indicators fall into two categories:

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.


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

correct but what's the problem with determining it server-side


I got a project stopped at work when I revealed something similar to the product director. Our competitor had a live incrementing number of currently available positions which the product directer thought was real, I had to show him the code and that it reset each time we loaded the browser.

Saved alot of annoying conversations from that.


They basically borrowed this from the MacOS X booting progress bar, which is also 1000% fake.

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.


One thing I haven’t figured out is why Gmail’s performance is so bad in Firefox. It feels like it takes noticeably longer to load and to perform actions compared to Chrome. For example, if you take some action and immediately try to close the tab, you’ll get a pop-up warning about an action that may not be saved if you leave the page. That doesn’t happen on Chrome. But I find it hard to believe that this is some shortcoming of Firefox versus a fault of Google’s. Anyone know what’s going on?


Google obviously is not interested in non-Chrome browsers beyond making their apps essentially functional. If its more janky and slow then be it on your own head for not using their recommended browser or mobile app.


Gmail still provides a simple HTML page: https://support.google.com/mail/answer/15049


Note that the basic HTML version loads faster on slow connections but everything else is slower, because the big ball of javascript is there to hide latency. It has its niche, but on a decent connection the regular version is faster.


I had it as my default for a long time (i.e. it loaded the simple version when I go to gmail.com), but then I accidentally visited the complicated version and there doesn't seem to be any way to set the simple one as default anymore. I can still use the simple version by using the special link but nevertheless a bit bothersome.


I bookmarked the simple version and called it a day.


There's a _ton_ of those pseudo loading bars

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.


Since the main stalling point will be slow network connections, you may know how many steps you have to do, but not how long they will take.

So, I confess I assume you're second paragraph is sarcastic?


Good luck finding a single person who would complain if all pauses and accelerations of their loading bar were indicators of a network problem. That's exactly what people think progress bars are, rather than cartoons to distract you while you wait.


Anything that makes it look stuck will get a complaint. So will taking too long. Getting stuck and taking too long will get more complaints.


While not technically a precise loading indicator, this seems to be along the lines of giving a better user experience than anything else. Gmail has real dark patterns though. One of which is to load the emails first, and then after a short delay (even on a fast connection) load advertisement rows on top. So if you attempt to click one of the new emails on top, you're just as likely to hit an ad that just loaded in that space.

Probably creates a ton of false clicks for whoever is paying for that advert.


If you don't care for the ads in Gmail they are easy to nerf: don't use the "Multiple Inboxes" view, or if you like it keep using it but disable the "Promotions" and "Social" tabs.


Anecdotally I've noticed that nearly all progress bars on major apps/sites are fake these days. Instagram and Facebook also have "progress indicators" (usually used for uploads) that just show asymptotic progress regardless of whether anything is happening.

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?


Tricks like this are self-perpetuating because it teaches users that progress bars are UI meant to model a duration. This is of course impossible to calculate without a crystal ball, as other posters have pointed out. But since it's what users expect, web developers must create an animation that meets user expectation.


Progress bars are hard. You could try to come up with something that guesses the user's connection speed from the first few bytes, somehow checks what's already in the cache and you will still have an inaccurate progress bar. Probably even one that isn't fullly filled up before the page is ready.


gmails application architecture has most decidedly not scaled to the bigger application it is today. once a rare gem of a just in time loading app, now it's just so so so so so so slow. unloved & destitute.


They all are.


Surprised this isn’t higher. Loading bars are universally faked on the web.


My favorite was writing.com - I don't know if it's still like this, but there was a period where they put a javascript loading spinner on the page by hiding the already-on-the-page content, let it spin for a moment, then showed the content.


There are a lot of sites that have fake delays to load information to make it seem like they're doing more work than they actually are.


After switching to Thunderbird I can never go back to Gmail.

https://www.thunderbird.net/en-US/

For really important mails I use ProtonMail.


Perhaps odd, but I've had the opposite experience.

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.


To be fair though, the freeze was probably caused by a xul extension.

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!


> To be fair though, the freeze was probably caused by a xul extension.

No, it's still there even in the most recent version. (Maybe I just have too much mail?)


Thunderbird has been PITA due to its major updates that breaks existing add-on's which I tend to use.


I used to use Thunderbird. But Gmail's spam filtering capability combined with their search are something I missed.

Unless something has changed in the past 3-4 years.


To make things a bit clearer: Thunderbird is a email client, but doesn't actually hosts emails. Gmail is both a email client, and you can host your email with them. But that doesn't mean you have to use Gmail "The Client" to access Gmail "The Emails".

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.


I feel like this is the case for soo mamy loading bars. Especially with games. Loading bar zips to 99% and then you wait for a few minutes. Yea right. I guess it is really hard not to make it frustrating.


Deceiving the user into thinking it's a tool for them while actually being a way to manipulate them. For Google that's extraordinarily on-brand.


It's so weird the cycles of idealism that permeate through our industry with every new generation of tech nerds.

* 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!


The big selling point of GMail originally was the amount of space you got. Earlier versions of the login page advertised this by having a bit of javascript that showed an increasing number showing you how the quota was increasing.

If you inspected source, it just had a little exp function with different constants depending on how far in the future it was.


"This defeats the point of a loading bar: it’s supposed to give an estimate of progress"... A loading animation is supposed to placate an eager user and deliver a more pleasant UX (by not making us wonder if something is wrong).


I've always assumed progress bars are either fake or meaningless, unless I know otherwise. Meaningless ones are like the file transfer ones which don't take into account the overhead of small files vs large files.


Love it when the estimated to be 20 minute file copy job turns into a 4 hour one when you are fighting with deadlines.


Often longing for the old days of Flash websites with byte per byte precise loading bars that as slow as they were back then they actually meant something.


It’s not worth the extra complexity for something that loads that fast.

As a user why would I even care about a real loading bar here?

I just care whether the page loads or not.


Of course there is an xkcd for the long history of terrible loading-progress bars: https://xkcd.com/612/


A loading spinner would convey the exact same information without being misleading.


I knew that Google is evil, but that's whole another level.


Wait until you hear about Every Progress Bar Ever.


Welcome to the real world


more importantly, why does it take so long to load my email...


not that easy, almost everybody does or used to do this.


They should add a "dislike" button for this, me thinks 8o)


Percent Done Progress Indicators 1985

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


Pure gold, thanks.


Yeah, their spam filter is also fake. You "report as spam", at least on Android. So it's up to Google to decide if it's actually spam.




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

Search: