Quoted from Jacob Nielsen's Response Times: The Three Important Limits: The basic advice regarding response times has been about the same for almost thirty years [Miller 1968; Card et al. 1991]:
- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect
Application of UI responsiveness guidelines to Netbeans
The classical performance test specification operate with following response times:
- 0.1 second - navigation and edit actions (e.g. folder expansion, paste in editor, navigation in editor), and painting of all menu bars must finish within this limit
- 1.0 second - all window and dialog openings must finish within this limit
- 10 seconds - all actions which are finished later than after 1 second and usually take less than 10 seconds must show some sort of busy indication (e.g. hour glass cursor or "please wait..." text); all actions taking longer than this limit are required to provide progress bar using Progress APIs
Features breaking the UI responsiveness guidelines will eventually end up with a PERFORMANCE issue filed against them (usually a P2), as specified in the Performance BugPriorityGuidelines.