This paper investigate the role played by annotation along the development process of interactive systems. Empirical observations have demonstrated that development teams often make an extensive use of annotations, mainly as a communication support. Whilst the use of annotation is a fact (also supported by many prototyping environment, IDE and model editors), very few studies have investigated the use of the annotations for building interactive systems. In this paper, we propose a process to explain this co-evolution of annotations and artefacts along the development process of interactive systems. The ultimate goal is provide mechanisms that could help the development team to follow design decisions using annotations as a support.
Design is a problem-solving process whose objective is find a way to implement
requirements, respecting constraints, and ensure good quality. According to the ISO
standard 9241-210 (2008) [
User interface prototypes are the most common type of artifacts used to specify
design solutions for interactive systems. In early phases of the development process,
drawings are acceptable as prototypes to support ideation of the product but as the
process advances, drawings are replaced by interactive specifications and then by
executable prototypes. It is interesting to notice that prototypes are useful and necessary but
they are not sufficient to fully specify an interactive systems. On one hand, prototypes
are not self-explicative, which is illustrated by the fact that annotations have to be used
to explain for instance the use of icons in a design. On the other hand, prototypes cannot
directly inform other important aspects of the interactive system, for that other artefacts
such as task models [
Empirical observations have demonstrated that development teams often make an
extensive use of annotations as a communication support [
The first studies about annotations started with the identification of common practices
by university students on their paper textbooks [
In [
More and more prototyping and IDE environments at least some basic mechanisms
for annotating artifacts [
Very few studies have investigated how annotations could affect the development of
interactive systems in a UCD process. The study performed by Gutierrez et al. [
The work of Gutierrez et al. [
Thus, regarding the use of annotations, it is possible to identify two main roles: the
writer of the annotation and the readers. More generally, annotations is a mean to
convey a large variate of intentions to the reader. Naghash et al [
Whilst the development team are responsible for creating artefacts and make use of annotation to coordinate their activities, external member might use annotations to express opinions and comment on what is being developed. In the rest of this paper, we assume that annotations are suitable communication tools that must be available to the diverse stakeholder (readers/writers) that take part in the development process of interactive systems. 4
The Figure 1 represent the lifecycle of a design artefact within a UCD process. This process acknowledges that the creation artefacts are a starting point for the work. Nonetheless, it does not impose any artefact to be created, which might be dependent on project needs. After creation, the design team should be able to perform following tasks: • Edit the artefact, either for enriching it, for correcting it, or for making to match new requirements.
• Archive the artefact within a workspace for future use.
• Submit the artefact for evaluation, which leads to the creation of a new artefacts such as an “evaluation report”. The results of an evaluation have their own lifecycle within the design process and might lead to the creation/updating of other artefact (ex. new user interface design is created following recommendations of a usability evaluation). These outcomes are represented by the red arrow labelled “External influence”. • Dispose the artefact, when it is no longer useful.
Artefacts might pre-exist, for that, the process includes an “existing” state represented by the grey rectangle in Figure 1. Depending on the collaborative tools used by the design team, a distinction can be made between a local copy and a shared copy of the artefact. This duplication of artefacts require an effort of synchronization for the design team who have to manage the consistency between the local copies of each contributor with the shared copy. It is interesting to notice that annotations are, at some extension, a special case of artefact. Annotations depends on the artefact they are attached to, but they possess their own lifecycle which can be evolving independently from the design artefact. One particular aspect of the annotations in a UCD process is that annotations can be related to certain versions of the artefact but not each of its version (e.g. an annotation indicating to fix an error).
The life cycle of an annotation shown by Figure 2 starts with a decision. The creation might be motivated by a variety of reasons and influenced by external influences (e.g. in reaction of other annotations, of the content of an artefact). This creation can occurs when the artefact is being consulted, edited or evaluated. After its creation, the annotation is in a private state and only visible to its author. In this state, the annotation can be updated and reviewed anytime by its author. Depending on the annotation, its author can decide to publish it to make it visible to other members of the design team.
Published annotations are presented to the different actors of the design process who can argue with the information contained in the annotation (which can lead to the creation of an annotation as a response) or who can validate the annotation to ensure its relevance toward the artefact and to assess its content.
When validated by stakeholders, annotations are kept as a reference about activities taking place along the design process (e.g. information on the requirements, appreciation marks of the design, highlight of problems). These information can have an impact on other design artefacts which is represented by the red arrow. For instance, a problem on a prototype identified with an annotation can motivate and justify a decision to edit the prototype in order to fix it. After that, annotations can be managed by indicating that it has been processed.
If the annotation is not validated, the annotation will not have an impact on other artefacts or for future uses in its current state. Similarly to artefacts, annotations can be archived for keeping the annotation in its current state or disposed when it is no longer useful.
Annotations can also affect the evolution but are also be affected by the evolution of the artefact itself. Thus, while annotation have their own lifecycle, this lifecycle is interweaved by the life cycle of annotated artefacts.
An annotation is created or updated on an artefact in reaction to the content of the artefact as illustrated by the red arrow “Induce the creation of annotations” in the Figure 3. After the creation of the annotation, the annotation can be attached or detached to any artefact or fragment of artefact to include it to its target list represented with orange arrows. 6
In return, the annotation can have an impact on the artefacts it is attached to. Indeed, annotation can be used a medium of communication for discussing, for contributing to the elaboration of an artefact, to point out modifications to make on the artefact. The content annotations can be varied from the topic discussed, the intentions of the persons involved in the annotations, the precision of the information, and the quantity of information contained. Depending on this content, several type of impact can be identified: no modification required (e.g. for informative annotations), localized modification restricted to the artefact (e.g. correcting a typo, adding a precision) or global modification that can impact other artefacts (e.g. appearance of new requirements or adjustment of existing requirements). While annotations may have an impact on design artefacts, they are not always factual and can reflect opinions that should be nuanced and cross-referenced with others opinions or concrete facts prior to taking decisions. Thus, annotations can be used to motivate or support a decision regarding the artefact as illustrated by the red arrow “Induce or support a decision”.
Regarding the impacts of an annotation to the update of an artefact, their weight can depends on several factors. Indeed, annotations can point out problems directly, reflect an opinion or unverified data from different sources and thus, the information conveyed needs to be validated. This can be done by several means such as checking the person involved in the discussion, analyzing the relevance or the trustworthiness of the information. After the validation, another aspect can be taken into account that can influence the impact on targeted artefacts. Indeed, a decision process can be integrated prior to the editing of the artefact. This decision process can assess the cost of the editing and its planning if the editing has been adopted by the design team.
Another interaction between the artefact and the annotation is the mutual update they can trigger. When updating an artefact, the content of each annotations attached to the artefact may be questioned or the state of the annotation can be updated to match it with the new state of the artefact.
Annotations are a versatile tool for documenting the design by associating documents or by explaining. They can be used for communication, for planning tasks, for reviewing the design and by allowing stakeholders to highlight problems, to question the design or to give opinion.
This presented the connections between annotations and artefacts along the development process of interactive systems. This work is an attempt to promote annotations as a first class artefact that could be used for tracking design decisions along the development process of interactive.
Currently, we have implemented tools that allows to connect annotations to multiple artefacts. Our ultimate goal is to develop tools that could help the development tool to make a better use of annotations to communicate, trace design decisions and follow the evolution of artefacts along the development process. These tools are suitable for a demonstration and future work will encompass the evaluation of them with real users. In a long run, we expect that our tools would be able to collect design decisions along many projects. The analyses of design decisions and their association with the evolution of artefacts, might provide useful data for have a better understanding on the real practice of UCD process.