=Paper=
{{Paper
|id=Vol-2503/paper2_7
|storemode=property
|title=An Attempt to Fathom the Role of Annotations in User-Centered Design Process
|pdfUrl=https://ceur-ws.org/Vol-2503/paper2_7.pdf
|volume=Vol-2503
|authors=Jean Luc Hak,Olivier Nicolas,Philippe Palanque,Marco Winckler
|dblpUrl=https://dblp.org/rec/conf/eics/HakNPW19
}}
==An Attempt to Fathom the Role of Annotations in User-Centered Design Process==
https://ceur-ws.org/Vol-2503/paper2_7.pdf
An Attempt to Fathom the Role of Annotations in User-
Centered Design Process
Jean Luc Hak1,2, Olivier Nicolas2, Philippe Palanque1, and Marco Winckler 1,3
1 Institut de Recherche en Informatique de Toulouse, France
2 Softeam, Toulouse, France
3 Université Nice Sophia Antipolis, France
{jean-luc.hak, olivier.nicolas}@softeam.fr,
winckler@{irit.fr, unice.fr}, palanque@irit.fr
Abstract. This paper investigate the role played by annotation along the devel-
opment process of interactive systems. Empirical observations have demon-
strated 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 sys-
tems. In this paper, we propose a process to explain this co-evolution of annota-
tions and artefacts along the development process of interactive systems. The ul-
timate goal is provide mechanisms that could help the development team to fol-
low design decisions using annotations as a support.
Keywords: Annotations, interactive system, design process.
1 Introduction
Design is a problem-solving process whose objective is find a way to implement re-
quirements, respecting constraints, and ensure good quality. According to the ISO
standard 9241-210 (2008) [1], the design process of an interactive systems is iterative:
design solutions are created, tested, revised, and improved until the development team
produces a proper version of the fully fledge system. This process produces two types
of results: a specification of the design solution to be implemented (the interactive sys-
tem) and a set of design decisions that drive the evolution of the design along the iter-
ation cycles.
User interface prototypes are the most common type of artifacts used to specify de-
sign 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 pro-
cess advances, drawings are replaced by interactive specifications and then by execut-
able 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
Copyright © 2019 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
2
directly inform other important aspects of the interactive system, for that other artefacts
such as task models [3], dialog models and interaction models [4] must be used.
Empirical observations have demonstrated that development teams often make an
extensive use of annotations as a communication support [2]. It is a basic assumption
that decisions made by the development team will create iteration along the process and
affect the way artefacts must evolve. Indeed, prototypes and artefacts evolve along the
development process and many of the design decisions might be described in the form
of annotations. The dangling question is: What happens with annotations in a UCD
development process? This paper presents a micro-development process that is aimed
to describe the life cycle of annotations and how annotations co-evolve with artifacts
along the development process of interactive system. Moreover, we discuss how stake-
holders might make better use of annotations for improving the communication in a
UCD process.
2 Related Work
The first studies about annotations started with the identification of common practices
by university students on their paper textbooks [5]. Paper-based annotations work as a
conceptual model for electronic documents. Therefore, common definitions of annota-
tion often refer to text documents [6]. Kahn & Koivunen [7] define annotations as “user
made statements”, consisting in a body (i.e. text note or graphical content), a link (the
so-called anchor) to the target which include a location within the document as well as
other metadata. As we shall see, these three elements (body, target and link) are core
concepts not only for paper-based or electronic documents but they are essential to un-
derstand how annotations applies to the many artefacts used to build interactive system
as well.
In [8], Li et al. have defined a classification of annotation approach for Computer-
aided Design. This classification identify the following categories of attributes that
complete the specification of annotation: targeted media, audience, rendering system,
usage and function, representation, and storage location. This classification of annota-
tions bring another complementary view of annotations. Based on the literature on text
and electronic documents [5-12], we can summarize three main functions played by
annotations: to enrich a document, to support communication and to support an inten-
tion/activity carried out by the author of the annotation. Whilst most of the literature in
the matter refers to text documents, that classification is relevant for the development
of interactive systems.
More and more prototyping and IDE environments at least some basic mechanisms
for annotating artifacts [13]. Very recently, the W3C proposed a standard called Web
Annotation Data Model which was created for specifying a model and a format to en-
sure the sharing and reuse of annotations across different hardware and platform. All
these tools testimony of the increasing importance of annotation for building interactive
systems.
3
3 Use of Annotations by Stakeholders
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. [2]
pointed out that annotations are used by members of development teams to: record the
results of discussion including decisions and upcoming tasks, communicate and inform
other team members of the work done, gather internal and external feedback on arte-
facts stored in the workspace, conduct usability evaluations by documenting infor-
mation and by recording conversation between design teams and UX experts, justify
design choices, and document the design choices by describing them retrospectively.
The work of Gutierrez et al. [2] does not make any distinction between types of
stakeholders. It is worthy of recalling the classification of Winckler et al. [16] who
identify two groups of stakeholders taking part in a UCD process: the development
team (which encompass roles having responsibility with respect to the production of
artefacts) and external members (such as clients and end-users) who provide opinions,
requirements, and/or constraints for the design. Interesting to notice that these two
groups of stakeholders collaborate along the development process in iterative cycle.
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 con-
vey a large variate of intentions to the reader. Naghash et al [12] suggest 6 different
usages of annotations: i) clarifying and explaining the design; ii) verifying and request-
ing a verification from other designers or users; iii) exploring by asking questions to
obtain more details on end users’ needs; iv) altering or requesting an alteration proposed
by the end users; v) confirming and giving feedback on a design; and vi) asking ques-
tions to the designers.
Whilst the development team are responsible for creating artefacts and make use of
annotation to coordinate their activities, external member might use annotations to ex-
press 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 inter-
active systems.
4 Life Cycle of Design Artefacts
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. None-
theless, 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.
4
new user interface design is created following recommendations of a usability evalua-
tion). 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 repre-
sented 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 con-
tributor with the shared copy.
Fig. 1. Life cycle of artefacts in a UCD process.
5 Life Cycle of Annotations
It is interesting to notice that annotations are, at some extension, a special case of arte-
fact. 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 par-
ticular 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 annota-
tion 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.
5
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 cre-
ation 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, apprecia-
tion 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.
Fig. 2. Life Cycle of annotations in a UCD process.
6 Reciprocal Influence of Annotations and Artefacts
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 in-
terweaved 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
Fig. 3. Artefact and annotation lifecycle dependencies.
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 infor-
mation contained. Depending on this content, several type of impact can be identified:
no modification required (e.g. for informative annotations), localized modification re-
stricted 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-refer-
enced 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 infor-
mation. 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
7
artefact may be questioned or the state of the annotation can be updated to match it with
the new state of the artefact.
Discussion and future work
Annotations are a versatile tool for documenting the design by associating docu-
ments 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 devel-
opment 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 devel-
opment 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 prac-
tice of UCD process.
References
1. ISO 9241-210 2008. Ergonomics of human system interaction-Part 210: Human-centred de-
sign for interactive systems. Standard. International Organization for Standardization, Ge-
neva, CH.
2. Marisela Gutierrez Lopez, Gustavo Rovelo, Mieke Haesen, Kris Luyten, Karin Coninx. Cap-
turing Design Decision Rationale with Decision Cards. INTERACT (1) 2017: 463-482
3. Célia Martinie, David Navarre, Philippe A. Palanque, Camille Fayollas. A generic tool-sup-
ported framework for coupling task models and interactive applications. EICS 2015: 244-
253.
4. Winckler, M., Vanderdonckt, J., Trindade, F., Stanciulescu, A. Cascading Dialog Modeling
with UsiXML. International Workshop on the Design, Verification and Specification of In-
teractive Systems (DSVIS'2008). Kingston, Ontario, Canada, July 16-18 2008. Springer
LNCS 5136. pp. 121-135.
5. Catherine C. Marshall. 1997. Annotation: from paper books to the digital library. In Pro-
ceedings of the second ACM international conference on Digital libraries (DL '97). ACM,
New York, NY, USA, 131-140. DOI=10.1145/263690.263806
http://doi.acm.org/10.1145/263690.263806
6. Bringay S., Barry C., Charley J., Annotations: A new type of document in the Electronic
Health Record. Paper presented at the 2nd International Conference on Document Research
and Development in Sciences, arts and business: DOCAM 2004, University of California,
Berkeley, Etats-Unis, octobre 2004.
8
7. José Kahan and Marja-Ritta Koivunen. 2001. Annotea: an open RDF infrastructure for
shared Web annotations. In Proceedings of the 10th international conference on World Wide
Web (WWW '01). ACM, New York, NY, USA, 623-632.
DOI=http://dx.doi.org/10.1145/371920.372166
8. Li, C & Mcmahon, Chris & Newnes, Linda. (2009). Annotation in design processes: Clas-
sification of approaches. DS 58-8: Proceedings of ICED 09, the 17th International Confer-
ence on Engineering Design. 251-262.
9. Manuel Zacklad. Annotation : attention, association, contribution. Annotations dans les
Documents pour l'Action, Hermes science publications, pp.29-46, 2007.
10. Lortal G., Lewkowicz M., Todirascu-Courtier A., 2005, Annotation: Textual Media for Co-
operation, in Proceedings of Annotation for Cooperation Workshop November 24-25th
(p.41-50)
11. Maristella Agosti, Giorgetta Bonfiglio-Dosio, and Nicola Ferro. 2007. A historical and con-
temporary study on annotations to derive key features for systems design. Int. J. Digit. Libr.
8, 1 (October 2007), 1-19. DOI=http://dx.doi.org/10.1007/s00799-007-0010-0
12. Amir M. Naghsh, Andy Dearden, and Mehmet B. Özcan. 2005. Investigating annotation in
electronic paper-prototypes. In Proceedings of the 12th international conference on Interac-
tive Systems: design, specification, and verification (DSVIS'05), Stephen W. Gilroy and
Michael D. Harrison (Eds.).
13. Silva, T. R., Hak, J-L., Winckler, M. Nicolas, O. A Comparative Study of Milestones for
Featuring GUI Prototyping Tools. Journal of Software Engineering and Applications
(JSEA), Vol.10 No.6, June 23, 2017, ISSN Online: 1945-3124, ISSN Print: 1945-3116, PP.
564-589, DOI: 10.4236/jsea.2017.106031
14. W3C. Web Annotation Data Model. Available at: https://www.w3.org/TR/annotation-
model (April 30, 2019, last visit).
15. Jean-Luc Hak, Marco Antonio Winckler, David Navarre. PANDA: prototyping using anno-
tation and decision analysis. 8th ACM SIGCHI conference Engineering Interactive Compu-
ting Systems (EICS2016), Jun 2016, Brussels, Belgium. EICS ’16: Proceedings of the 8th
ACM SIGCHI Symposium on Engineering Interactive Computing Systems, pp. 171-176,
2016.
16. Winckler, M., Palanque, P., Farenc, C., Pimenta, M. Who does what with whom in Web
Development? 2nd International Workshop on Task Models and Diagrams for User Inter-
face Design - TAMODIA’2003, Heraklion, Greece, June 2003.