Design and Layout:Interaction:Feedback
From KDE-HIG_Wiki
Activity Feedback and Notifications
Activity feedback informs the user that there is activity happening in an application. It is especially relevant when the application currently is not focused. Typical types of activity feedback in KDE are:
- Flashing the task bar entry
- On-screen display (OSD)
- Changing the icon in the system tray (animated or still)
- Message box
- Info panel
- Audio feedback
Guidelines
Configurability
- Give the user flexibility to configure the notifications.
- Especially, give an option to
- Turn on/off the usage of the system tray globally in your application.
- Turn on/off audio notifications globally in your application.
- Provide all notification settings in the same place. That means if you provide system tray or OSD, move all notifications to the main configuration dialog. See Configuration Dialogs.
- In the notifications dialog, group the events along their context of use. This makes it easier for the user to configure them.
Progress Feedback
Progress Feedback informs the user about progress. Typically, there are three types of progress feedback in KDE:
- Mouse pointer feedback
- Progress bars
- Progress icon, e.g. in Konqueror
Guidelines
When to apply
- Provide progress feedback for response times > 1 second:
- A busy or wait cursor for response times up to 10 seconds when the application is focused.
- Additionally provide a progress bar or a progress icon for response times > 10 seconds.
Animated Transitions
When elements of the user interface appear, disappear or in another way transforms from one visual state to another, animate the transition. In KDE, typical transitions are:
- Fade in/out the appearance of elements in lists, tables or tree views (e.g. "New folder" in Konqueror or "New contact" in Kopete).
- Visualizing the minimization and maximization of a window.
Guidelines
When to apply
- Extend the usage of animated transitions in KDE and apply them to
- element appearance in all lists and tables,
- applications windows located in the system tray,
- dockers or dialogs if they can be activated via a visible ui widget. For example, animate the path from the toolbar button to the final position of a docker which is opened by that means)
Background Information: Acceptable Response Times
Research regarding acceptable response times in computer systems trace back to Miller in 1968 (Miller, 1968). According to Nielsen (Nielsen, 1994), the advice for response times is still based on these findings and the same for more than 30 years now.
| Maximum Response Time | Effect on User | UI Events |
| 0.1 second: | System is reacting immediately. | Mouse click, keypress, moving or mouse, moving of objects, resizing, etc. |
| 1.0 second: | User notices the delay, but flow of thought stays unaffected. | Application startup, displaying progress indicators, completing ordinary user commands (e.g. closing a window), completing background tasks (e.g. reformatting a table). |
| 10 seconds: | Maximum limit to keep the user's attention on the application. | Tasks that require more extensive processing, e.g. manipulation of large images, displaying a graph or anything else a typical user would expect to take time. |
Sources:
Nielsen, J. (1994). Usability Engineering. Morgan Kaufmann, San Francisco.
Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.
Implementation Suggestions
Try to avoid response time greater than 10 seconds by
- caching data whenever possible and plausible,
- showing the most important information first,
- preparing possible next steps which might be invoked by the user,
- prioritizing jobs according to the user's needs,
- allowing the user to perform other actions during extended or background operations.
