Recently I had to debate over the usage of a skeleton screen vs a splash screen for web pages or web apps, although I am not a fan of either solutions here are my thoughts on the topic.
Fist things first, if you can avoid any of the above this would be the way to go, if you are on the other hand forced to decide between them you will find that each has a place and a time when it should or shouldn't be used. Forget the trends or the classic "Apple does this in ...." because I heard it so many times and some use this as a sole argument. Let's look deeper into the subject, later you can decide which one to use.
First of all, why would you need such a screen?
If you have a heavy application, which needs to load some resources before the page is rendered, you will end up with a blank screen until the resources are loaded and the interface is rendered. Of course, on a high speed connection one or two seconds of white screen haven't kill anyone. Let's face it, you don't load a simple web-form, you have a heavy application and it is not so bad if the users have to wait 2 seconds. Maybe it is, as wishful thinking, wished to have instant loading and rendering, but if you are indeed a professional in this field you know that there is always a delay factor (or at least you should know). I have seen Expert, Senior and other "god-like" UX designers who have no clue about how the things are working and they expect wonders.
For the sake of clarity, let me enumerate some of them:
- the initial HTTP request,
- DNS response,
- SSL handshake,
- the server's response time in delivering the requested content,
- transferring the requested files,
- parsing on the client side (browser)
- and at the end comes the rendering.
As you can see there are quite a lot of processes happening behind the curtains and each requires its own time. Ok, we expect speed - if in the early 90's we were happy with the boot time of Pentium 233MMX, today we would get crazy waiting so long - is just that our expectations changed. The same goes for web, we expect to be ready in a millisecond, the bad news is that we can't have this and we still have to wait a bit.
Returning to our sheep, if your web app loads in 2 seconds over a high speed connection, what would you expect for a DSL? Maybe you are faced with 45 seconds?!?! How about 3G? Yes I know you have LTE but think about your clients and also about you when you have a blind spot for LTE coverage and you need to rely on low speed like 3G. So how do you feel about 1.5 minutes loading time over 3G?
First step it should be to see if there are options for reducing the payload, load less KB, load asynchronous and other techniques, maybe even use the client cache, serve gziped files straight from a server cache, and so on. But what if you need a lot of assets until you do the first rendering? Well, you are faced with the first problem: presenting a white screen and breaking one of the most basic rules - let your user know that the app is still loading or is doing something at least.
Enter the two options: Splash screen and Skeleton screen. Let's see how and where we can use these options.
The old and hated Splash screen
Well, it is old, it was used and over used and it is still used mostly when you start a software. It's sole role is to show you that something is happening and you have to wait a bit. Imagine you want to open an Office app and you would not have the splash screen. You would wait a bit and then you would try to open again and again. Everything becomes slower and after few minutes you are presented with 6-7 instances of the same software.
The smarter way would be to look if the HDD activity indicator LED is blinking. Why would you do that? Simply! Just because you search for a confirmation that the computer is doing something for you. Well, here is the Splash screen to rescue you. It will show you that the computer is starting now the software. I have this problem usually with the browsers (they do not show any splash screen) so I end up with 4-5 of them if I am in a hurry.
So ... how about using it for web!?!? In the past it was used under this name but with a wrong implementation. It was used more as a landing page, adding animations, having even interactions, later was used as a on-boarding tool, most of the times the progress bar had nothing to do with the actual progress and everything was shown after a standard time delay. No wonder that it became infamous. Unfortunately the new school of UX designers or so called UX designers (just because they have a passion and studied one year online somewhere, or just got somehow a job on this position) lack the basic concepts. And one of them is to look what you can improve, how can you use better, not only to what is trendy. Trendy is today, tomorrow is dead. Trendy was to do crazy shit on landing page but call it a splash screen. Trendy was to be web designer, now trendy is to be UX designer - same shit different name, although it is a huge difference between the two if they were correctly used. But that's another story.
So, then, what should a spalsh screen do?
In the first place should let the user know that the site is loading, maybe the progress, because we do not like to wait without knowing how much we have to wait. No more than this! In short I can say it should fulfill the following criteria:
-load first
-simple (low KB)
-not requiring heavy libraries
-real time - as soon the page is rendered it should disappear
-informative
-not blocking
-no any other interactions attached
-no important text for the user to read.
Why? It is simple, as long at it is real time the display time will vary from user to user and from network to network as well as the presence of items cached in the browser. So you don't want to have something important written there or to delay the access to the page by forcing an interaction element.
Advantages? Well the only real advantage is that it offers a perceived improved performance and informs the user. You need more?
The trendy Skeleton screen
I know, Apple does it! Well it is also not very new on the market but Apple does it, FB does it, Linked in does it .... almost exclusive on iPhone, haven't seen that too much in browser. If Apple does it, does not mean you need to do it! Right? Are you just copying what Apple does or you have a brain of your own?
As the name implies, you show a skeleton page until the rest is downloaded, and you fill it gradually with content loaded with lazy loading or whatever ... This means that you have to render already the layout. In the case of very complex apps with a myriad of possible layouts for each user this task alone will require a lot of time. If you have a single layout, hello FB and LinkedIn, then it is easier.
There are also two trends here: fake it and make it. Faking is just feeding a skeleton layout and later replacing it with the content, maybe adding a load bar as fake as it was used in splash screens some years ago. "Making it" it is the way to go, as long as there is no difference between the skeleton layout and the rendered layout (this would look odd, right?). Which criteria should such a solution fulfill?
- loading very quickly the layout
- replace elements as soon as they are ready, not waiting until the whole page is ready
- skeleton layout should be identical with rendered layout
Advantages? Well the only real advantage is that it offers a perceived improved performance. Of course I can say that it is also informative, as long as I see that half of page is not rendered I can presume it is still working on it.
Verdict
I would start by saying that it is each on its own, and there is no "one size fits all solution". From my point of view, I would use a Splash screen if my app will be more like a software, because I would like to point that out "hey, is a software not your blog, needs a bit of time to load all that heavy logic". On skeletons I am not so keen because a heavy and complex app has a big problem until it renders the layout, if is standard (hello again FB and LinkedIn) no problemo, but otherwise you would still end with the white screen until the skeleton is rendered. And another issue I have with skeletons is .... they look so ugly .... but Apple does it.
If you have a site which has just a tad of delay, you can do with a skeleton (as long as you do not fake it and make it from a technical point of view a splash screen), for these situation a real splash screen with real-time progress would be an overkill, and using a faked one would just waste your user time.
On the other hand if you offer a heavy app, which can do a ton of stuff and is not your google engine, than it makes sense to go on the splash, make it real, inform the user and hope that the waiting times can be lowered by refactoring your code.