A single, long load - or multiple short loads, which would provide a better experience?

Question

I have a very large, modular web application.

When it starts I can do things one of three ways:

1. A moderately long load time (about 60 seconds) to fetch all of the modules from the server (presented nicely with a progress indicator) before the user is shown the login screen. After the login screen the user never has to wait again.

2. A very short load time (3 seconds, no indicator) while only the essential core modules are loaded, the user is immediately shown the login screen, and modules are loaded on-demand as the user tries to access them for the first time (resulting in a loading screen of around 3-7 seconds per module)

3. A medium load time (around 20 seconds, with indicator) in which the essential core modules, and the 2/3 most frequently used modules are loaded), login screen is shown, and less frequently used modules are loaded on demand (again with a 3-7 second wait)

My first reaction is to let the user choose, but this actually seems like the sort of detail that most users won't care to change, or simply don't want to have to think about.

I can load modules at will, however during module loading the user interface becomes sluggish so I'm reluctant to keep loading modules in the background while the user is actively interacting with the application.

I'd love to hear which option you'd prefer as a user (and why), or even if there are other strategies that might deliver a better experience.

Answer 1

I can't recall the study, but it has been found that the perception of speed is heavily effected by the time to first action.

So my suggestion is a 4th option:

1. Load the bare minimum that is needed for your customers to see the app and decide what they want to do. Basically what you've described as option 2.
2. Automatically put the other modules into a loading queue (based on how frequently they are used), and start getting them one at a time.
3. If your customer tries to do something for which a module has not been loaded yet, show a loading image and place that module at the front of the loading queue.

That should give you the best balance between responsiveness and simplicity for your customers as they would no longer need to choose any option.

Answer 2

For me it seems like option 3 is worth trying in your case and that's why:

From a study The Cost of Interrupted Work: More Speed and Stress:

We performed an empirical study to investigate whether the context of interruptions makes a difference. We found that context does not make a difference but surprisingly, people completed interrupted tasks in less time with no difference in quality. Our data suggests that people compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort.

I think that delays caused by module loading during the work are like interruptions. For me it's always better to wait for app to start and do my work without (almost) any delays than to start faster and be interrupted occasionally by delays caused by loading modules, etc.

As far as I understand, your users will use your service from time to time (or, even, regularly), so they will be aware of a longer startup time but smooth experience afterwards.

And if you're developing a really UI-rich app, I think you may use some tricks, like loading several additional modules while user observing the screen after login, etc.

Answer 3

I think it's important to show the login screen as soon as possible (before any long loading happens):

• users that don't know that a login is required shouldn't have to wait 60 seconds, only to notice that they can't login (or don't want to)
• users that are unsure about their login data shouldn't have to wait 60 seconds to be able to try the login, only to notice that they forgot the correct password

So now it's the question whether to load all modules OR only the essential modules OR no modules after the successful login but before the users start using the app.

I think this depends on the kind of app:

• How long is a session? Are users logged in the whole day, or only for a few minutes? Pre-load more modules when a session is rather long (probably in the background, when the user idles), don't preload modules when the session is rather short.
• How many modules do users use? Is it typical that a user uses all modules in a session, or is it likely that the user is only interested in one or a few modules? When there is a typical set of modules almot every user uses in the same session, preload those "essential" modules. If many users only use the app for one or two modules, don't preload modules (so there wouldn't be "essential" modules at all)

Depending on the app, it might be possible to never preload modules that aren't configured by the user (if a first-time configuration would be required), or that were never used by the user after the first few sessions.

Maybe you could offer favorites? Let the users "star"/bookmark modules that they want to be linked prominently on their dashboard, so that they have quick access to them. Now you could preload all favorited modules per user.