Medium is not even the worst, it’s quick and I’ve never seen that progress bar. Blogger/Blogspot is my most frustrating online experience when I have to read text: it’s very slow to load even on a fast connection and shows fullscreen spinning cogs, breaks Safari Reader on desktop and mobile, overrides gestures and makes me lose track.
Really, you don’t need Javascript to load a page of text.
Agreed. To me, the gears make it feel that the page is taking longer to load. It's especially rubbish because the page that loads is normally just text and static images, not some complicated webapp. Should have been fast to begin with.
Because the team who developped these stupid templates dont care about users, that's a fact. Or why would they do that ? they just want to kill their plateform and move on. that's the only explanation.
My thought exactly. If your site is taking so long to load that you feel the need for a progress bar, it's time to trim the fat.
Youtube videos already have their own bar, why is the rest of the page so bloated that it needs bar? All the thumbnails? Maybe it's time to stop loading so many by default. Too many widgets for comments, ratings, favorites, etc.? Again, time to cut down on all the widgets.
I don't think so. As more sites move away from full page refreshes toward just changing the DOM (using Angular, Backbone, Turbolinks, etc.), I think we're going to see way more of these.
The problem is that you can never rely on a load being fast. If you trim the fat on the app side and get a pageload down to 100ms, it might load almost-instantly for you on a 100Mbit/s connection.
But it still won't for someone on a 768Kbit/s DSL connection. In that case, you can't just let them sit there for a second or two with no feedback. A loading indicator is necessary for those instances.
I agree that sites should trim the fat and make pages load as quickly as possible so that a loading bar isn't really necessary. But you have a) instances where you're not in control of load times, like when you're relying on an external API (like Facebook, for example) to return data, and b) even if your app is blazing fast, you're still subject to slow connections that necessitate a loading bar.
I think in cases where you are loading significant external data that may take several seconds a loading bar is appropriate; see for example the loading bar on a Youtube video. Perfectly legitimate. Or a loading indicator on a gallery of thumbnails. Appropriate uses.
But the page itself should not necessitate a page wide loading bar. That's a design flaw. Your page is bloated. Even a 768Kbit DSL should be able to load the page itself rapidly. If you're beyond that just for the basic page itself then you've failed in your job as a designer/developer, IMHO.
And I've designed web apps that never actually send you to a different page (just update the DOM), and in my experience they are extremely fast. Even making many API calls retrieving tons of records to a very modest server. That design is not in and of itself a reason to have load bars.
Agreed. The whole point of a client-side update mechanism is to do something better than a loading bar. And that thing should be (1) immediate and (2) particular to what the user did.
It's like there's a Law of Conservation of Bloat: browsers are hugely fast; computers are hugely fast; even broadband is getting to the point of usability (in North America) -- how can software tumors metastasize? Where is there an opportunity to slow things down and make them shittier?
>Wirth's law is a computing adage made popular by Niklaus Wirth in 1995.[1][2] It states that "software is getting slower more rapidly than hardware becomes faster." - Wikipedia
There's also a related "law": “What Andy giveth, Bill taketh away.”
> "software is getting slower more rapidly than hardware becomes faster."
I used to think this was true. For me, the perceived inflection point where perceived speed of software started improving was somewhere around 2008. This may be because I switched to a mac in 2006 and the releases around that era had a big performance focus.
How much patience did people have back in the 90s when broadband and computers were slower? (Hell, it sometimes took 30 minutes just to dial into AOL without getting a busy signal.) Now that computers and broadband are faster, do you think people have just as much patience as before or less?
I'd imagine that, until broadband becomes truly instant, you will have a need to ensure users that the page is still loading. A user's patience will never grow. It will only shrink. The least we can do is buy ourselves precious seconds by using a progress bar. It is the difference between "Your call is important to us, please hold" and "You are now 5th in line to be answered. Please hold." The illusion of progress goes a long way in fooling the user's brain into having just a smidge more patience.
Well, OK, but that's orthogonal to the question of: what is causing this bloat, and why is that considered sacrosanct, as opposed to the user's time and energy? Reasonable people can disagree as to where that line is drawn, of course, but with sheerest garbage like Medium, where the putative goal is to give people something to read, it looks to me like they're driving a process for the sake of driving a process, and deserve to be mocked for it.
I like using this for ajax file uploads. For example, in a photo gallery with thumbnails already occupying the client area then it's a convenient place to indicate upload progress from a drag + drop without placing a temp element in the grid or overlaying some other element with progress info. I'm not sure how well it solves the problem (usually I'm just interested in general file progress and not a specific percentage) but it does give a good indication of progress in a convenient location.
