After asking the question Will faster GUI always make one more efficient?, I understood that there is a lower limit to the amount of time lost due to the GUI not responding. My interpretation of the answer is that below 50-100 ms will have a neglectable effect. Now I am interested to know whether there are any studies on longer waiting times. I would be especially interested for in the ranges from 10 seconds up to 20 minutes, which were not covered by the study referred to by edeverett in his answer to the other question. I am interested in cases where the waiting time is happening on random so the users do not get used to it.
-
Can you give an example of where waiting time would be random? I work a lot with EDA tools, and they can have waits from a few seconds to several hours, but the times are hardly random.– James CrookJun 6, 2011 at 20:04
-
@James Crook. Opening Outlook on an ovetloaded Exchange server can take anything from seconds to half an hour. It certainly feels random, at least.– DavidJun 6, 2011 at 21:15
-
Great example. I'm on the same wavelength now.– James CrookJun 6, 2011 at 21:18
-
A bit off-topic but I never understood why anyone would run Outlook without cached mode enabled. It starts instantly and doesn't block user input while trying to establish its connections...– Oskar DuvebornAug 19, 2011 at 11:32
3 Answers
Related questions have mentioned http://www.useit.com/papers/responsetime.html which says users have to reorient themselves to the task if the waiting time is over 10 seconds. As I understand it the theoretical basis for the 10-second figure is that short-term memory decays in the 2 to 10 second range (or the user's attention wanders and pushes other things into working memory, depending on the psychological theory you subscribe to.) Once the user is back on task they use long-term memory and the information presented by the UI to figure out where they were.
I don't know what theoretical basis there would be for a threshhold in the 10 second to 20 minute range. I have heard two minutes suggested as a guideline where a different type of feedback is called for (e.g. notification instead of progress bar) but I think that was motivated by the idea that users would rather multi-task than wait that long.
Once I did a conversion from Lotus 123 to MS Access of some workflow database forms. The user were typically spending 6 hours on registering all the data in one particular work flow when using Lotus 123. After I had converted to MS Access, he used half hour on the same job! This was basically just converting everything bit by bit without restructuring anything. It did all in the same way and GUI look in the new version. It was just the difference in response time in the two systems that caused the big difference.
Depending on what you do I'd say that wait times are not a big problem but reminding the user once an action is complete can be very important.
Triggering a visual alarm after the action finishes could let the user react pretty fast after an event and improve performance.