Let's say you have a button. When you click it a GET request is fired for some data (for this example assume that the data cannot be prefetched). Then a modal opens and displays that data in a pretty way.

For user experience, is it better to immediately open the modal but have the contents be blank until the data is loaded, upon which the data is painted


Is it better to wait for the data to come back and then immediately open the modal with all of its data already there.

In the former case the button click is more responsive but there is a "flash" from white to contents.

In the latter case the button click isn't as responsive but there is no flash and reflow of contents. Instead, everything is just there already.

The GET request usually only takes 10-30 milliseconds if that changes anything.

  • 2
    The first thing that comes to mind is: do you need a modal dialog? They have their place, but they shouldn't be your first choice. Commented Sep 22, 2020 at 21:09

5 Answers 5


The first option... but with more feedback.

You should have the modal appear immediately. This is important so that the user knows that their action has been successful (i.e. you don't want them to keep clicking because they think nothing is happening).

However, having a blank modal is not good. Because the user will be confused as to why it is empty (even if this is a brief duration). What you should do is initially show some sort of loading/progress indicator. This is important so that the user knows the application is still working and to expect the results shortly (once they have loaded).

As the GET request is (usually) quite short, you don't want to make this loading indicator too "in your face". However, it should be clear enough that it is also suitable for those rare occasions where that GET request takes longer than expected.

Additional note, it might be worth making the loading indicator static if it's only going to be visible for a short time.

Perhaps even just a simple bit of text: "Loading..." or "Fetching data...".

Have a play around and see what works best with your test data.

  • 1
    Second this. I work on an application with dozens of dialogs/modals (using Material theme). We put spinners in the title section of the modal and typically hide the model content until all loading is done. Commented Sep 22, 2020 at 10:39
  • 15
    Also, if there is buttons or other that could be loaded before the data (I am thinking a return/cancel button or such), I strongly suggest that they stay perfectly at the same position whether the data is loaded or not.
    – Puck
    Commented Sep 22, 2020 at 12:04
  • 2
    And if your CD allows it, you can use short animations to bridge the usual 20ms loading duration.
    – Falco
    Commented Sep 22, 2020 at 14:28
  • 1
    "Have a play around", I misread "Have to play sound" and jumped off my seat.
    – Wtower
    Commented Sep 24, 2020 at 12:49

Your app will have a more polished feel by intentionally avoiding the amount of elements quickly flashing or jumping around on the page. A loading indicator isn't needed if the data is returned in 1–3 100ths of a second. Even 10 times slower (0.1 seconds) still feels pretty instantaneous. Quickly showing and hiding elements like that is not necessary or helpful for the user, and only adds visual noise.

In this case, I'd suggest that you request the data immediately, and delay the modal opening for up to 0.1 seconds to try and give the data request some time to return before opening. This should be an effective compromise between limiting rapid UI changes and providing prompt feedback.

With optimal speeds, the request will return in 0.02 seconds (±0.01), and the modal can opened with the data fully rendered. With sub-optimal speeds, the modal opens after 0.1 seconds (which still feels instantaneous) showing a loading indicator. Once the call returns, the data is then rendered.

  • Considering it's a browser, it itself is susceptible to flashing and other delays in rendering even if content is available - e.g. from the local file/data URL. I wouldn't worry about 0.1 sec flashing. Commented Sep 22, 2020 at 9:44
  • 7
    This assumes a some what good internet connection. If you are rolling 3G or even 2G your requests could taken seconds. Or on a slow VPN that travels across the world. Or your API is having issues and doesn't send the response back so you timeout. Commented Sep 22, 2020 at 10:37
  • 1
    @theblindprophet I agree—of course there are factors outside of the developer's control that may still contribute to a long request time. In this case, showing the modal with a loading spinner (as suggested in the final paragraph) or placeholder is unfortunately the best option. My suggestion would provide a less distracting experience for the typical case (as indicated by the OP) where calls resolve very quickly. Commented Sep 22, 2020 at 13:36

If the global layout of the data is highly predictable, then the current trend would be to open the dialog immediately, and populate it with "mock" data, which is not data at all, just grey blocks where the data is going to be.

Apparently (just learned that), it has a name: skeleton screens.

This is used a lot by Facebook, Linkedin, Youtube, and more. An example from Linkedin (taken from the page linked above):

enter image description here

As soon as you have the data, you replace the skeleton with the actual data:


You'll note that in that one:

  • some of the text which is known in advance is already displayed at the skeleton stage
  • some of the skeleton (the bottom part) doesn't actually match the final layout

If your data is loaded quickly very consistently, this can be overkill and will indeed lead to a flash and possibly a relayout. But what happens on your dev box with local data or a high speed link to a nearby server, serving a bunch of highly-cached data may be very different from real-life experience, especially on mobile, or after your data has started to grow quite a bit to the point it actually takes a (short) while to return. You may want to measure this to decide how important this is.

In any case, a visual indication that something is happening is useful.

Also note that not everyone agrees with skeleton screens. This analysis points out that the users polled perceived the loading time to be longer with a skeleton screen, compared to a spinner or a blank page!

  • 2
    My gut "wariness" towards skeleton screens is the feeling that because a skeleton is – visually speaking – "almost there", when the data is displayed, the change will be less noticeable. Perhaps this contributes to the perceived longer load times of the analysis you linked? (I don't have any evidence to back this feeling up, but I have not gone looking for any).
    – TripeHound
    Commented Sep 22, 2020 at 13:46

The existing answers cover most points well; I'll expand the problem to consider whether or not the dialog's size will depend on the data returned (as well as mentioning a pet-peeve about meaningless spinners).

Statically-Sized Dialog

If the size (and final position) of the dialog is known/calculated at the point of clicking, and will not depend on the retrieved data, then musefan's answer of opening the dialog immediately is the best/simplest. You know you are going to open it; you know where and how big it will be: so open it immediately. As museman also suggests, include some form of "Loading..." message so the user knows that the real content will (should) follow shortly.

Exactly what the loading message says, and where it should appear is probably as much a matter of personal preference and/or existing styling as anything else. My starting point would probably depend on the "expected" response time of the data-retrieval request:

  • In a corporate environment, running over an internal network, where most of the time you expect "close to immediate" responses (roughly the 0.1 seconds or so mentioned in maxathousand's answer), then I'd probably go with a somewhat discrete "Loading..." message towards the top-left corner. Most of the time the users won't get a chance to see it, so you don't want it "in their face": you just need something for the (hopefully rare) times when the response is slower than normal.

  • If you are running over the public internet, where expected response times could easily be noticeable, then I'd probably favour a more centrally-placed message. Users are more often going to have a chance to see the message, so put it at the centre of their focus so they know "something's happening".

Dynamically-Sized Dialog

If the (final) size of the modal dialog is going to depend on the amount/nature of the data received, then a different approach is needed: ideally, you don't want a large, "about the right size dialog" to appear, only for it to change its size (and possibly position) a short while later.

You would still want an (almost) immediate feedback that the request has been started, but – because you don't yet know the size of the "real" dialog – you shouldn't use that to show the feedback. If you are going to "dim" the main page while the dialog is shown, then dimming it immediately is probably a good idea. Showing a spinner of some kind (but see my "pet peeve" below), or just a "Loading..." message in the middle of the screen would also be helpful.

In this case, the "extra complication" suggested by maxathousand probably is worth it: you don't want to distract the user with a spinner/message if it's replaced by the real dialog almost immediately. I'd consider the following steps:

  1. If used, dim the main page as soon as the button is clicked: immediate acknowledgement.

  2. Start the "tenth-of-a-second" timer: if the full response isn't available after a short pause, display a spinner and/or "Loading..." message.

  3. When the data is available, remove the spinner/message (if shown) and display the modal dialog with whatever size has been calculated from the data.

Pet Peeve: (Meaningless) Animated Spinners/Progress-bars

Musefan suggests "it might be worth making the loading indicator static" if "it's only going to be visible for a short time". Part of me would like to take this advice a step further: make it static unless there's positive, ongoing feedback from the server.

Originally, in desktop programs, a progress-bar would show how much of a task had been completed: if you were copying a number of files, the progress-bar might advance with every file copied. (Ideally, it would advance as a certain amount of data was copied, so a single large file wouldn't make it look like the process had stopped.) For "open-ended" tasks (e.g. downloading a file of unknown size), you might have to reset the progress-bar part way through (or use a different format, e.g. a spinner). However, in either case, the key thing that makes them useful is that their advancement is driven by "things happening" – they showed the user that the process was "still working".

However, many/most spinners in modern web-apps are not driven by progress in the task being performed: they are animated locally in JavaScript or as an animated GIF. However much it makes the user think something is still happening, most of them do not actually convey any information – you could unplug your network cable and the spinner will happily continue to spin!

Of course, given the ubiquity of spinners these days, even if most are meaningless, not having one is likely to make most users think "the internet has crashed". It's probably too late to only use them when true progress (or a "heartbeat") is available.

  • 2
    An important point many people fail to recognize with progress reporting is that even if one doesn't know how much work will need to be done, and a user likely won't know either, a report of how much work has been done may be useful for troubleshooting. If, for example, an action takes about 30 seconds to process 3,000 units (whatever they are), and stops, and if repeated attempts to perform the action stop after different numbers of units, that might suggest a bad network connection, but if every attempt stops after 3,000 units, that may be more indicative of a problem with...
    – supercat
    Commented Sep 22, 2020 at 21:50
  • 1
    ...some resource on the server which will cause the requested action to deterministically fail unless or until it is corrected.
    – supercat
    Commented Sep 22, 2020 at 21:50

Neither. A modal is the ultimate UX fail. As soon as you have one, there are no questions of what's better, only what's infinitessimally less awful.

  • That should probably a comment rather than an answer. But the modal itself is not the important point, the question is whether one navigates first, then loads, then displays, or loads first, then navigates to an already loaded screen/window/modal/tab/whatever.
    – jcaron
    Commented Sep 23, 2020 at 7:53
  • 3
    That's a bold statement without any arguments, can you update your answer please?
    – Martyn
    Commented Sep 23, 2020 at 9:47
  • The amount of user complaints that turn up all the time about modals should make it obvious. I don't have a saved sampling of them but I can try to dig some up.. Commented Sep 23, 2020 at 16:41
  • 2
    If a component is often used incorrectly that does not necessarily make the component itself bad. It just means that it is poorly understood, therefore we need to educate rather than blatantly say it is bad, that's not helpful.
    – Martyn
    Commented Sep 23, 2020 at 19:31
  • Blocking the user from taking any action at all until they make a decision is always hostile. "Educating" users that being hostile to them is "sometimes ok" is even more hostile. Commented Sep 23, 2020 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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