USABILITY FRAMEWORK
One
of the problems of working with usability from a design perspective is that
it is a broad and abstract concept that is hard to grasp. Therefore, we
decomposed usability at different levels. The details of this decomposition
can be found in Deliverable
2. The first level of the usability decomposition is what is called
usability attributes in the HCI field. Usability attributes are precise and
measurable components of the abstract concept that is usability. Below are
the usability attributes that most authors agree:
-
Learnability, which is composed of two complementary aspects: how quickly users
can learn to use the system for the first time and how easy it is to
remember how to operate the system after not having used it for some time.
-
Efficiency of use, which refers to how efficiently the user performs a task using the
system, that is, this attribute measures the efficiency of the software
system used by the user. Note that this attribute is not the same as the
classical quality attribute of efficiency, understood as system efficiency.
-
Reliability of use. Again, this parameter is not to be confused with system
reliability. It refers to the reliability of the user performing a task
using the system. Therefore, this attribute refers to the errors made by
the user when using the system, not the system errors.
-
Satisfaction is the most subjective attribute and refers precisely to the
user’s subjective view of the system.
However, we found that these usability attributes are
very far removed from software design, that is, the effect that these
attributes have on software architecture cannot be determined directly.
Therefore, the approach that we followed was to decompose these attributes
into intermediate levels of concepts that are increasingly closer to the
software solution. The first one of these concepts was the usability
properties. They represent particular usability issues that HCI
researchers have proposed to help developers to build usable systems. We compiled
these design heuristics and principles that different authors suggest for
developing more usable systems arrived at the following usability
properties for a software system:
-
Keeping the user informed. The system should inform users at all
times so that they know what is going on.
-
Error management. The system should provide a way to manage errors. This can be done
by error correction or error prevention.
-
Consistency. The system should be consistent in all aspects of interaction,
that is, in the interface and in the way we provide functionality.
-
Guidance.
We should provide informative, easy-to-use and relevant guidance and
support both in the application and in the user manual to help the user
understand and use the system.
-
Minimize cognitive load. Systems should minimize the cognitive load, e.g., humans have
cognitive limitations, and systems should bear these limitations in mind.
-
Explicit user control. Users should feel that they are in control of the interaction.
-
Natural mapping. The system should provide a clear relationship between what the
user wants to do and the mechanism for doing it.
-
Ease of navigation. Systems should be easy to navigate.
-
Accessibility. Systems should be accessible in every way that is required. This property includes internationalization,
multi-channeling and accessibility for disabled people.
Although this classification could contribute to
somehow structuring the field of design heuristics, an important problem
still remains to be addressed. Usability properties may be useful as
possible sources of requirements to be satisfied by a usable software
system. However, developers have no systematic way of incorporating them
into their developments. In other words, they need to know what particular
elements a software system has to include to satisfy a usability property.
Therefore, usability properties needed to be further elaborated if we want
developers use them to incorporate specific functionalities to improve the
usability of the software systems.
In this context we came up with the concept of architectural
sensitive usability mechanisms, to refer to specific usability features
that have an impact on the software architecture (as we will see in the
next section) and address particular usability properties. In other words,
we descended another level in our approximation of usability to
architectural design. A first approximation of those architectural
sensitive mechanisms are:
-
Feedback - Reuse
Information
-
Undo - Form/field validation
-
Cancel - User
profile
-
Wizard -
Shortcuts
-
Help -
History Logging
-
Commands aggregation - Action for multiple objects
-
Workflow Model - Provision of Views
To analyze the architectural implications of the
architecture-sensitive usability mechanisms, STATUS partners worked with different
practitioners (mainly junior developers) asking them to incorporate these
mechanisms into their developments, once they had made the design for the
system considering none of such mechanisms. If the practitioners modified
their designs to incorporate a specific mechanism, then the respective
mechanism can be considered to be architecture sensitive. The exact process
followed to study the relationship between the usability mechanisms and the
software architecture was described in Deliverable 3.4.
An example of the architectural implications of
one of the architecture-sensitive usability mechanisms (Undo) is shown in
the figure below. We also referred to the kind of solution described in
this figure as architectural
usability patterns. The reason is that the generalized architectural
solutions for each mechanism (like the one shown in the figure) represents
one possible way of incorporating such usability mechanisms into a software
design. So it might inspire developers in the inclusion of such mechanisms
into their designs.
|
