1

In one of the recent updates to Google Chrome, we have seen yet another method of dealing with page loading status with the introduction of the loading animation in the favicon area of the browser tab (by the way, the Firefox browser uses the side to side indeterminate loading state animation made notorious by LinkedIn).

enter image description here

As far as I can tell, this makes at least five or six different ways that you can indicate a loading status on a page, many of which occur simultaneously and makes the current state of the page content rather confusing for users.

So the ones that I have seen include:

  • Browser tab favicon area loading indicator seen in image above (is there a name for this?)
  • Mouse cursor loading indicator
    enter image description here

  • Page header loading progress indicator - example here

  • Modal/pop-up page loading progress indicator enter image description here

  • Call-to-action button progress indicator animation enter image description here

  • Bottom of the page loading indicator (e.g. when infinite scrolling is implemented) - example here

Assuming that there is a 'best practice' when it comes to dealing with page content status, is there a reason why there needs to be so many different ways of indicating to the user that the status of the page is not completed loaded? Doesn't this provide a very inconsistent user experience and add to the user frustration?

  • Good question, I too noticed it recently how Chrome squeezes the favicon to the centre of the loading spinner. I personally have always preferred to look at the progress bar like how it happens in safari. – Ren Oct 31 '19 at 12:20
  • Could you provide images for each of your bullet points, please? Some of them are not present in my Chrome, so I can't understand if you want to discuss the Chrome or the browsers as a whole? – Pavlo Grubyi Oct 31 '19 at 14:37
  • @PavloGrubyi seems to be some issues with the markup text so the formatting is a bit all over the place, but I have provided some examples. I think this is an issue with browsers as a whole, but if you can provide an explanation just for Chrome that would also be fine. – Michael Lai Oct 31 '19 at 22:21
1
+50

Well, I'm quite sure there's no "best practice", because it's very difficult to consider all possible scenarios (on a side note, you forgot skeletons).

First of all, you're mixing at least 2 layers: the browser(s) and the apps. You have to consider that many apps you see were built before Chrome launched this, so how would these apps guess what was coming?

So now we have at least 2 layers with redundant (and in a few edge cases, conflicting) information. I don't need any study to confirm it will add up to user friction by cognitive load, because that's like the definition of measuring cognitive load

Established eye movement and pupillary response indicators of cognitive load are:

pupillary diameter mean
pupillary diameter deviation
number of gaze fixations > 500 milliseconds
saccade speed
pupillary hippus

(just in case, multiple focal attention points increase one or more of the values above)

However, displaying information about the loading status of a page is certainly beneficial, as long as it's correctly used (see more info about it on When to user loaders and empty states).

So, we have this: - adding information about loading status is good. - Having redundant information adds to user friction

What should we do?

Well, browser's loading status isn't very good since they create uncertainty about what and WHEN is going to happen. But you have no control over that. Besides, browsers don't know if you're providing that information.

On the other hand, you must provide useful information to your users, and it is YOUR responsibility to do so, you cannot trust whether a user will see a small feature in the URL bar or not (personally, I did not notice that feature until you mentioned it).

Therefore, I believe that the correct answer is to provide the information that needs to be provided, with full control over it, so that users know what to expect and the time to wait for it.

The browser's native function should not interfere with the experience we need to create for our users. In the worst case, we will have a small cognitive load, which we can measure and eventually overcome

1

Page loading is a very complex process, so the first thing to take into account is that it's not owned by any "layer" (code, viewport, browser, OS, bandwidth, internet, server...), but it pertains to all. That means many layers can show loaders (web component, webpage, browser, OS...).

By Fitts's Law, the one indicator closer to the action should be the most effective. However, since the loading action happens from a multitude of places, that does not help (although Fitts's Law makes a case for the CTA and the cursor, it's of dubious visibility and probably missable) :(

So then, I'd go back to visibility. To me the best one would be the one that gives more visibility, so as the user does not have to "look for it".

That would make the "Page header loading progress indicator" a winner. It also offers the following advantages:

  • Be easily portable across browsers
  • Being at the bowser level allows for more control over the transaction (i.e. browsers choke less than pages)
  • It purports an easily identifiable pattern ("loading bar")
  • It can get levels of granularity: percentage, sections for different loaded components being loaded, speed control, etc.

Last, I'd say that, even though many times redundancy does not hurt, in this case I think it could, if all loaders are not synchronised, and confound the user on which one is most exactly tracking the loading. So I wonder if the most sensible solution would be a Browser API that can help the website pass detailed loading data (while still showing progress if the page fails to provide any).

1

Page loading status should indicate when something is in progress.

Depending on the complexity of the process, it can take from 0.000001 to several minutes (and maybe more or less)

Often the so-called lazy loading (which allows you to gradually download data from api, without loading all at once, only dividing them into smaller parts.

At the time of the surgery, the user should not be discouraged and should be provided with a stimulus(if it doesn't last long (max few seconds), a progress bar is not needed):

enter image description here


However, there may be a situation in which the process will be more advanced (computer scanning, defragmentation, removal of entire modules, overwriting, importing of entire databases etc. )

In this case - it is worth informing about the progress of the process, progress, and estimated time.(It will take 15 minutes, so you can relax, go shopping, start another task whatever)

enter image description here


Returning to the question about frustration: When the user has everything under control, he is not so frustrated.

According to Nielsen Heuristics:

Show system status Give the user full control

So let's inform and give a possible opportunity, for example:

  • Postponement of the operation
  • Stop operation

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.