Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
    
What do these modules show and what interactions can be done with them? –  Mervin Johnsingh Nov 30 '12 at 22:33

3 Answers 3

up vote 12 down vote accepted

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.

share|improve this answer
    
I touched on this briefly, I don't want to keep loading modules while the user is interacting with the application because it causes it to become sluggish and less responsive. –  PhonicUK Nov 30 '12 at 14:32
    
@PhonicUK by that reasoning, it's better to be impossible to do something than to be able to do it sluggishly. If that is indeed true, then at least download the modules so that they can easily be loaded when needed. –  JohnGB Nov 30 '12 at 14:42
1  
@PhonicUK You may need to look at how this is being done in the architecture. However that discussion is outside the scope of this site. Feel free to come into the chat and discuss it there. –  JohnGB Nov 30 '12 at 15:09
1  
@JohnGB You might be referring to research on a fake travel web site.. They concluded 'waiting at an earlier stage is perceived as worse than waiting at a later stage.' –  user1757436 Nov 30 '12 at 19:29
1  
@PhonicUK There are mediating factors involved in this situation. If you want to understand all of the factors, consider reading this older review or this more recent explanation of perception of web response time. You probably do not have control over many of them but understanding them might help you decide which solution is best for your situation. –  user1757436 Nov 30 '12 at 19:31

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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