PleaseWait.js – Show your users a beautiful loading page while your app loads(pathgather.github.io) |
PleaseWait.js – Show your users a beautiful loading page while your app loads(pathgather.github.io) |
I would much more appreciate that dev time would be put into a framework that allows graceful enchancement by deferring loading more heavy components and to allow user to interact with the site ASAP.
Having a skeleton project for gulp (or any other system) that shows how to properly split big, non essential, components and lazy load them would go much further to ease developing big applications and smoothen UX.
EDIT: typos.
I agree and raise you the point that this is Chrome-only, and doesn't even bother to mention it. Half of the spinners fail to work in Firefox stable.
I know they didn't write the spinners, but the company seems targeted at teaching:
> Pathgather is an NYC-based startup building a platform that dramatically accelerates learning for enterprises
Platform lock-in on the Web is an odd thing to teach.
And I agree that a skeleton project to show proper modularization of different components would be great! Our blog just started an Angular series, so we'll try to write one on how we split up our large Angular enterprise app in this regard :)
I sure was guilty of big sites just as much as the next guy. It just saddens me that insted of promoting what we've learned it the past years and applying to current projects we're doomed to repeat bad UX from before.
Note, this isn't always easy to do. If you use on-the-fly gzip compression (which is how most people set their nginx or whatever up), you won't get a Content-Length, so you can't show progress.
For example, we have some heavy reports that take a few seconds to load, so we show a screen similar to this while we crunch the numbers.
My issue with whole-page takeover loaders is that they lose your control and spatial sense of the app. You can't, for example, page away if you decide the report is taking too long to load, or you went to the wrong section of the site when hunting around for a piece of information.
HTML 5 is the web remaking itself in the image of Flash.
HTML 5 is an attempt to turn the web browser into a replacement for the Flash Player. Punch the Monkey Flash ads are replaced with Punch the Monkey HTML 5 ads.
Javascript framework after framework comes and implements the Flash way of doing things in the browser.
And the irony is that Flex is still the best way of producing RIAs years after Adobe killed it.
A good intro can help to sell your site project to a customer (and help them selling it to their superiors), but no longtime user would protest if you took it away.
Single page apps are a way to fit in an interaction model that doesn't fit the idea of "one address, one page, one text" that was the idea behind the Web in the first place. So, yes, you give up some of the benefits of the Web (navigation with bookmarks, back button) or have to fight hard to get them back, while keeping others (mostly, platform independence and a built-in client-server architecture)
It's a loading screen. It's perhaps even a nice looking loading screen. Well, it's not ugly. It is missing a lot of functionality though. But it's less rage inducing than the spinning pin wheel so that's good I guess.
2015 would be a better year if we all agreed to stop using the word beautiful with respect to any and all things digital.
See https://www.npmjs.com/login, for example.
That said, I will agree that the use case is very small (page opening) and for most these days even showing this for more than 2 or 3 seconds might lead to some wrong assumptions and showing it for only a split second would be odd/no good/etc.
I expect splash screens and slightly longer load times from desktop apps... if I click on a link to something in my browser, not so much. TBH, if a page/app takes more than a second or two to load, I assume there's something wrong with it (or my net connection).
But speaking of that, please THINK of your users and despise loading times. Hate them with a passion. As they say, kill them with fire!
Do NOT make them prettier, it only makes it easy to think it's OK. It is not OK! Your app can load faster. Way faster. It's easier than you think. And even if it's not, it's worth it.
When you have done everything you can do to speed up the loading time, NOW you can think about loading screens.
Except, don't make it a loading screen. Fake it. Make it look like you loaded faster than you did:
- Let the fastest content load asynchronously with the slower content.
- Is caching for your entire app too hard? Start by caching the entry points from previous visits and show that (although beware of unsettling flashes/jumps in data!)
- If that's too hard, fake it with a screenshot from the last view the user saw (it's been done -- iOS apps).
Once you've done all the above, and exhausted every other idea that you can think of because you know your users better then I do...
... then, only then, you can think -- for maybe an hour or two -- about making the gap a nicer experience. But remember, it must be a NICE experience. BEAUTIFUL does not always equal NICE.
And until that gap is gone, never cross this item off your list!
[Disclaimer: To the creators of this module, I'm not saying your time has been wasted. I'm only talking to app owners, not to you! Thanks for thinking of how to make bad things better! ]
On a positive note, those animations would be great if they were GIFs - they're nice.
Of course it all depends how keen your users are to wait for the thing. If it is an online game and they clicked a link to play it then they may be happy to wait.
For most sites this would make me hit the back button if it didn't load in 5 seconds.
Wrong thinking! just make it load quicker!
My understanding is that he believed that no one could tell another person that something is beautiful. A person could only decide that for themselves.
And although I do think this library is supporting the case of being lazy and not optimizing your code and load times. I do think its beautiful.
Just my 2 ¢
Maybe you just don't like it as much as other people do. That just means your tastes differ, not that others are abusing language.
Also, being beautiful isn't an inherently valuable attribute. If your product is utterly useless, but good looking, then it's still utterly useless. Some form of user study about the utility of the aesthetic design would be a nice addition in these sorts of declarations.
I don't think the issue is with this project per se, but the trend in the presentation of these sorts of "show HN" posts.
The animations are pretty bog-standard, let's be honest. I'd stretch to calling them aesthetically pleasing, but there's no way I'd describe them as beautiful.
you look lovely today, btw.
you need help
At least Slack rotates through a few different sayings that tend to be goofy instead of creepy - and you can change them.
This stuff has been around for a long time, it's just cheekier now. Ever install a Windows app and the last setup page says, "Congratulations! You have successfully installed $APP." Congratulations? For what? You congratulate people for an achievement. Are you saying that it was an achievement on my part to successfully install your app? Was the more likely outcome that I would fail to install it? :-0
Hilarious.
Well, I think all these things are suspicious and maybe (I don't know) even bad in nature, but they have levels of badness, "you look lovely today, btw" is considerably worse than any form of birthday congratulations -- although I'm also suspicious of the second, which, here in Brazil, is a little more common thing to say than "happy birthday" (people just say "congratulations!").
Makes me cringe SO HARD every time. Why are we telling people they're amazing for existing? Haven't we identified the issue with much of today's youth is that their egos were often overinflated by their parents, teachers, etc, leading to problems of entitlement and whatever else that entails?
I'm not sure why you're confused -- is it because things aren't the way that you think they should be? To me, the explanation above is pretty concise and fits the situation neatly.
But on the NPM site I think it's different, it's a joke. It says "you look lovely today, btw". That's clearly mockery/irony. The help section is headed "you need help", for example.
For the majority of sites, I agree this may be overkill, but if you have a SPA that needs to load a good bit of data on the user's first use of your app (and verify authentication), this can (hopefully) be useful.
In cases like that, indicating to the user that something is happening makes for a better experience than not doing anything, or in the worst case (which certainly shouldn't happen these days) blocking the user's browser.
I agree. If you need this, go back and look at what you're loading. Do you really need all that CSS? Does that Javascript really need to be executed? Do you need it just to get started? Do you really need 15 tracking cookies and a Flash bug?
This can likely be extended to only be utilized on part of a widget. If it's something like an ajax call you can easily add an option to cancel the request e.g. underneath a spinner.
For your report example in particular the service could be developed in such a way that the processing occurs independently of the user session. You can mix this in with an additional request which returns the actual progress of what has been calculated in the report such that whenever a user browses to that page, they can see just how much time there is to go before their report is generated.
It'll get good and comforting soon enough..
Also, the intended use of PleaseWait.js doesn't have to be used to stall while client side resources are brought down. This concept could easily be used for long running, server side processing.
Edit: I misspoke when I said "a good bit of data" in my original response. I simply meant any API calls to your backend.
There's so many tools right now to find out exactly what your page or app is using and how to minimize what you're serving. Sure, it takes some effort, but your users will thank you in the end.
Do we have "How to be passionate about beautiful UI in 7 days, for dummies" yet?
Given that they're done in the background, the browser won't indicate them being made outside of dev tools. If they're asynchronous, again ideally they will take place as quickly as possible. This is unfortunately not something that can be relied upon.
This probably comes off as looking the gift horse in the mouth but at some point it does come off as excessive, like when I get bum rushed to be helped the second I look at a product in a department store.
Sure. Maybe it's literally always a Bad Thing to show a loading screen. But plenty of apps have made that choice, for some reason or other. Maybe the developers are incompetent, or maybe they have a combination of technical and resource constraints that make this the best choice for them. It doesn't matter. At least this loading page can improve users' experiences with apps that have, for whatever reason, made the choice to go this route.
If you look at web applications, Google's music app ("My Music" in Google Play) uses a load screen (complete with progress bar) because it's seriously bloated, while Amazon's Cloudplayer just loads and does its thing (which is, playing music).
Needing a load screen is a sign that your app is not, or aims at not being, a Web app anymore - in the sense that you'd also want to loosen the other restrictions - give it its own window, possibly have local file storage or FS caching, etc.; In that case, something like TideSDK ( http://www.tidesdk.org/ ) may come in handy to deliver a desktop app to power users that is based on the same codebase. And, maybe you'd still want a web app that is functional and lean. (As an example for two apps with non-identical possibilities, Google's My Music allows you to change song metadata on desktop browsers but not in the Android app - yet another sign that My Music is meant as a desktop-y app).
In many cases it can be a sign of hubris or lazyness that you cannot get rid of the bloat. Be real and think whether your users actually enjoy waiting that time, since they'll be doing it more often, on machines with less resources and/or slower connection, than yours.