That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.
It's also one of the irritating things about "Material Design" websites, where responses to clicks are artificially delayed before speeding out with unnatural acceleration. "Nothing is happening. JUST KIDDING!" I'm not sure if that is to mask the slowness of mobile devices or if it's the cause of them. It's the animation spam[1] of the current generation of UIs.
That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.
Web browsers have progress bars.
I think your complaint is with "sites" that just serve a JS payload and then load "the real site" entirely from requests made by JS. Turns out if you generate and serve actual HTML, you get a progress bar for free!
I don't know why every thread about Web applications needs someone to tell me that technically HTML was just designed to be a document format. OK, great, now it isn't just that.
First someone states that the way web sites work now sucks. Then the next person states, ‘Well we used to build sites this way and then it doesn’t suck’. And then the next person comes in saying ‘well that just isn’t the way we build sites now’.
If that isn’t the way we build sites now, either change the way we build sites or accept that it sucks. But this is Hacker News so we’re supposed to think about different ways to build sites than what we do now.
It's just... what's the point of talking to anyone who will listen about how HTML was designed for hypertext? Yes, we all know that. Today the world's most-popular Web sites include YouTube and Facebook. We aren't going back.
This a (mostly) solved problem. With Server Side Rendering the html payload delivers what the client side is would have rendered. The client side js takes over rendering after it loads.
He did not say that. Generating the HTML for the initial page load server-side does not make HTML "just a document format". It improves loading and search-friendliness of your web site.
That’s true, but I can mention several online stores that do this. Even on a good network the site remains blank for seconds at times. If they at least served me a logo I’d know the site wasn’t dead!
I solved this in a react app I’m working on by overriding XMLHttpRequest.prototype.open to listen for the request lifecycle events and update a global “percent loaded” used to render a progress bar at the top of the page.
It’s far from perfect but is at least a good enough heuristic for the user to know when the page is loading a request.
> That is one thing I dislike about sites that show no loading bar. On a slow connection it's impossible to tell if the page is still loading or already failed.
To be fair, depending on how the progress bar is implemented, it might not be a guarantee.
Clicks have a 200ms (IIRC) delay on Android to give a chance to recognize other gestures. There are hacks to get ride of it, though. It may have to do with that.
I remember reading long ago about how they did something similar at an airport(Dallas IIRC).
Basically, people complained about baggage claim taking too long, so they just moved the baggage claim area to the other side of the airport, so it took longer for passengers to reach it, by the time they did, their bags would already be there, so the complaints stopped.
Years ago I discovered a bit of a trick for getting through customs in Jakarta in about 5 mins (I was travelling there a lot for work). However, what I always ended up with was standing around for about 15-20 minutes for my bags to be unloaded, as even the priority baggage was rather slow off the plane.
Not me. Walking feels productive, standing is boring. Same with driving - my brain would rather feel like it’s making forward progress even if the route I take is longer.
Even if you actually would make that choice doesn’t mean that you would be happier than if the airport implemented the other option and didn’t give you the choice. That may sound counterintuitive, but there’s no particular reason to think it’s contradictory.
Even right after getting off an airplane, where you had to sit in a cramped seat for hours on end? I’d much rather take the opportunity to stretch my legs.
It's not like they tore up all of the parking/loading/unloading areas. They just moved the baggage claim to the farthest point along which everyone had to walk anyways.
I think even the passengers' reaction might make sense here. Standing around at the baggage claim and observing that no baggage arrives makes you worry that there might be some serious error that will make things take a very long time.
You're happy until 30 minutes later when the progress bar is still getting asymptotically closer to the end, and you come to suspect that the only thing that didn't crash was the progress bar.
Not CS but any study of limits in math, perhaps with differential equations. And it’s a useful term generally, much more likely to come up in conversation than “subtrahend” or “mantissa” but not nearly as much as “tangent.”
I am reminded of a webcomic, that i fail to locate at this moment, that reminded me of the practice of placing something next to a progress bar, like say during a Windows 95 install, to check if anything is actually happening.
I do that whenever I have to wait on a progress bar. I zoom in with whatever accessibility options there are, then when a pixel is 3-5mm I put my mouse cursor at the end of the bar and wait.
To save time in the future, bear in mind any time you think you are the only person that does or notices something: you aren't. This is due to the fact that people are all running on the same physical architecture, with very similar cultural and social ecosystems, plus the law of large numbers. Note that this does not apply to edge cases such as people engaged in activities or domains with a very small number of participants...
Couldn't you have give also vague, but accurate information as well?
User's like to know what's going on, even if they maybe don't understand all the details, but at least they see things are happening and not just a (fake) progress bar. So they can connect more to what is happening and therefore be more understanding and patient instead of just being told to wait, with no further information, which nobody likes.
The article's discussion about the NYT election accuracy meter wiggling randomly (but within the error bars) is a textbook example of "vague but accurate" information, perhaps to a fault.
How do you visually represent "error bars" to someone who's not technical enough to have ever seen them? Not everyone takes college stats, math, and engineering.
Technically, wiggling within the error bars is a precise way of saying "the precise location is vague -- it's somewhere within this range", in that at any moment it is showing one precise, acceptable guess.
The most fascinating piece there was that as the error bars decreased, the range of the wiggling decreased as well.
Yeah, it doesn't convey the extend of the error bars instantaneously -- you need to stare at it over time -- but it does convey the idea of error bars.
I think the people upset about the error wiggle are either a) being pedantic that it's not visualized in the way they learned it should be visualized back in college; or b) they haven't accepted the idea that sometimes we don't have an exact precise black-and-white answer (we DO have ways to precisely quantify the degree of our uncertainty though).
All of this not to say it was the best execution... perhaps if they 'ghosted' previous needle positions like how old movie radars ghost a green blip as the thingie spins around, maybe it would have been a kind of hybrid approach where the error bars do kinda appear in the overlapping ghosting shadows but still change over time...
I guess the lesson to be learnt here is that people are more understanding if you appear to be transparent but you don't have to ACTUALLY be transparent to get the affect.
This, yes. Also, if you're processing discrete items in any measurable way (downloading kilobytes, ingesting database rows, querying servers...) that takes longer than one second flat, display that to users. "Processing record 1/1,000,000... Processing record 2/1,000,000..." gives a positive sense of progress. Even if you don't actually know the final total in advance, you should still display whatever you've got.
As a bonus, this can occasionally be useful for bug squashing. "I've been waiting for hours and it's only up to row 5681" when you know for a fact that there's <2000 rows is a lot more informative than "My report won't finish."
A few of the default Debian packages give feedback messages like "This could take a long time..."
Most of them used to take a long time, but hardware has caught up. SSH key generation, locale installation. Instead, it's a warning that briefly appears on modern systems, but is visible for quite a while on, say, a Raspberry Pi.
I designed and maintain a report-generating component and my system does the same thing. (Plus it is helpful as users can tell me where in the process it failed/hung) It doesn't matter how long each message sits on the screen, as long as it changes every so often. Animated, infinite progress bars also help if you don't/can't estimate ETA
In the loading animation of windows 98 there was a horizontal bar of moving colors. And if it stopped animating, you can be 100% sure that the computer is frozen. I wonder if we can do similar with cycling animations.
Can it not say "$X items processed..." or have a spinner that updates it's frame at certain intervals? It doesn't have to be a percent, just proof of progress. I had no trouble adding an accurate "$X rows of csv processed" in a laravel (PHP) + VueJS app.
I know this won't work everywhere, but if you know how much time the task generally takes, your progress bar can just be a timer for that duration. Still more informative than fake messages.
In the same vein, at my work in the steel construction industry, when asked by internal and external customers how I'm going with their laser cut components I've taken to telling them: "Your job is important to us and has progressed in the queue".
I can't always give an accurate response because our scheduling is constantly being derailed by urgent tasks and the not-so-urgent tasks get complete in between.
People just want to know you haven't forgotten about them, throw in some light humour and a "I'll try to get it done before knock off tomorrow <wink wink>" and they tend to let me get back to working.
They add fake "close doors" buttons to the elevators, that arent connected to anything, but make people feel they have agency and it makes waiting for doors to close less frustrating.
Ages ago I evaluated some reporting software. We were using Crystal Reports at the time. One thing that CR did better than the others was make pages available as they were generated. This made the software feel faster even though it was slower than one or two of the others[0] at the time.
For interactive applications, reponsiveness trumps raw throughput. It's what made operating systems like AmigaOS and BeOS so fast: they didn't actually crunch numbers faster, but they always stayed responsive and quickly reacted to user input under any load, that made them feel faster.
I had the application throw up a fake dialog with fake messages about "Collating data, Cross checking, Sorting" and other such nonsense.
The report now took eight minutes to run because I had to abuse the "On Timer" event for it to work.
The users were delighted with the improvement.