[kde-guidelines] Styleguide: Animata

[Thomas Pfeiffer]

On Thursday 30 January 2014 10:42:15 Heiko Tietze wrote:
> Structure > Conceptual Model
> * Specify requirements considering destinata and animata of users.
> http://techbase.kde.org/Projects/Usability/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]]

Sorry for taking so long to reply, I admittedly only now remembered that this 
is still unanswered.

While the content of the example totally makes sense to me, I don't see how 
this is related to the animata/animus, since Björn wrote that "animata" meant 
people's _feelings_. If I thought about user's feelings, ISO 9241-110 wouldn't 
exactly be the first thing that comes to my mind...
Could you (Heiko or Björn) maybe explain your "animata" concept to me again?