One of the things that make this problem special on a mobile device is that the necessary information for showing a reasonable progress indication may not be available on the device. A related issue is that it may be more difficult to predict the duration, e.g. when data is transported using a wireless connection with varying bandwidth. Also, obtaining the necessary information for showing progress – and partly also the process of showing it – may require more overhead on a mobile device than on a PC. As it usually is impossible, difficult or inconvenient to use other applications than the one performing the long-lasting operation on the device, long-lasting operations will probably make mobile users more impatient than a PC user. This increases the need for good feedback solutions.
The issues just presented above may make it difficult to use the established mechanisms for showing progress for long-lasting operations. Sometimes it may be a trade-off between giving information and not delaying the long-lasting operation even more. Balancing this trade-off is probably the main problem when trying to find an optimal solution for user feedback during long-lasting operations.
When faced with a problem like the current where there are no optimal solutions, a possible approach is to try to eliminate the problem instead of solving it. In this case it means trying to avoid or bypass the long-lasting operation. There are of course lots of situations where this is not possible, because an operation requires transferring large amounts of data or very much computation. Still, trying to find smart implementations may speed up the application. When there is a need to transfer large amounts of data, a smart caching solution both pre-fetching data that the user may start working with before it is asked for, and continuing to transfer data while the user works with it – even with reduced performance – may be a much better solution than waiting for the user. If there is a need for a very demanding computation involving modest amounts of data, doing the computation on a server computer instead of on the device may enhance performance significantly. This is of course only possible if the application is on-line.
Given that it indeed is not avoidable that the user has to wait, information may be given on three levels:
The normal way of doing this is providing a wait cursor, preferably supplied with a message saying “please wait…”.
This is normally done with a counter and/or a slider/gauge that shows the percentage of time spent. If it in addition is possible to estimate in actual time values the time left, this is a benefit for the user.
Informing the user about what is happing (in addition to indicating progress) may be done as a scrolling text that the user can browse back in, just a small list showing the latest events, or as single text changing as events happen, as illustrated in fig. 1. Independent of how the information is shown, it should be presented in a way that is comprehensible by the user – i.e. related to user concepts and user tasks.
Published October 10, 2008
Problem area:Difficult to understand
Main problem area:Design at large
Fig. 1. Informing the user what is happening