|
|
| Line 1: |
Line 1: |
| __NOTOC__
| | {{ Moved To Community | KDE_Visual_Design_Group/HIG/Animata }} |
| | |
| == Purpose ==
| |
| Following the ISO 9241-110 about 'Dialoge principles', any interface should meet the following generic axioms:
| |
| * suitability for task (the dialog should be suitable for the user’s task and skill level)
| |
| * suitability for learning (the dialog should support learning)
| |
| * suitability for individualization (the dialog should be able to be customized by users)
| |
| * conformity with user expectations (the dialog should be consistent with user’s expectations)
| |
| * self-descriptiveness (the dialog should make it clear what the user should do next)
| |
| * controllability (the user should be able to control the pace and sequence of the interaction)
| |
| * error tolerance (the dialog should be forgiving)
| |
| | |
| | |
| Of course, all principles are relevant for the development, but an important part of the usability engineering process is to prioritize them in relation to target users and use scenarios. For instance, if controllability is pushed it might have bearing on individualization.
| |
| In concordance to the 'hard' features of [[Projects/Usability/HIG/Destinata|destinatas]], those 'soft' requirements are a rather living aspect of software. It relates to user experience, to ease of use, and satisfaction, and is therefore called ''animata''.
| |
| | |
| == Guidelines ==
| |
| * Take animata into consideration, complementary to the [[Projects/Usability/HIG/Destinata|destinata]].
| |
| * Prioritize user's needs.
| |
| * Keep persona and scenario in mind.
| |
| | |
| == Example ==
| |
| KDE's file browser 'Dolphin' should be developed in respect to the following ordered list of requirements:
| |
| # Suitability: The dialog should suit user’s tasks and skills, and support without unnecessary strain by attributes of the dialog system. That is understood in terms of feature richness. If all the core requirements are fulfilled the dialog suits users’ needs. Unnecessary prompts or confirmations (‘Do you really want to exit?’) may cut back suitability. For example, commands on the shell are highly specialized and therefore suit perfectly the (limited) requirements.
| |
| # Self-descriptiveness: Each single step of processing has to be direct intelligible, and the user should always be informed about the scope of performance. Self-descriptiveness should therefore be highly related to familiarity. The use of common controls, standard short-cuts, or introductory text supports comprehension and facilitates self-descriptiveness. The CLI is one example for low self-descriptiveness – it cannot be learned without man pages.
| |
| #Controllability: The dialog should be managed by the user; he or she controls pace and sequence of the interaction. High controllability will be reached by unconstrained inputs, by avoiding wizards, or by means of a sophisticated undo feature – all these contrast robustness (see below). Because complex tasks are split into single, simple operations with usually more parametrization the controllability of the CLI is barely improvable compared to GUIs.
| |
| #Familiarity: The dialog has to be conform with user’s expectations out of his experience with previous work flow or user training. Originally, familiarity is meant as congruence with the handling in normal life. But software that becomes independent is often rated as familiar when it is conform with legacy products – big changes are not welcome. Unix commands haven’t changed in the last years, they are very familiar to experts. On the other hand, people used to operate GUIs might be confused and give low ratings to CLI’s familiarity.
| |
| #Robustness: The intended result should be reached without or with minimal correction in case of faulty entries. Constrained input, confirmation dialogs, elaborated exception handling lead to robust dialogs. Faulty input on the shell is neither checked nor handled by default leading to low values of robustness against user failures.
| |
| #Individualization: The dialog should be able to be adapted to individual needs or preferences of the users. Individualization is given by any means of configuration from switching features on/off, over modification of background, color or other design aspects to complex interaction pattern like scripts. The CLI provides parametrization not only on a functional level but to some extend as well for appearance and should hence be rated high.
| |
| #Learnability: The dialog itself should support learning; the user has be able to manipulate the system without reading extensive documentation. Learnability might be attributed to the presence of tool-tips, the configuration of some kind of novice vs. expert mode, or the preference of wizard style control over free interaction. Obviously, there is no inherent support to learn how to use CLI tools which leads to low values.
| |
| (All recommendations are based on empirical data, see http://user-prompt.com/quo-vadis-dolphin-the-relation-between-the-iso-9241-110-and-the-rating-of-features/)
| |
| [[Category:Usability]][[Category:Structure]][[Category:Task_Flow]]
| |
