=Paper=
{{Paper
|id=Vol-490/paper-3
|storemode=property
|title=Use of Abstraction during User Interface Development
|pdfUrl=https://ceur-ws.org/Vol-490/paper_03.pdf
|volume=Vol-490
|dblpUrl=https://dblp.org/rec/conf/iused/Hvannberg09
}}
==Use of Abstraction during User Interface Development==
https://ceur-ws.org/Vol-490/paper_03.pdf
Use of Abstraction during User Interface Development
A Position paper
Ebba Þóra Hvannberg
University of Iceland
Hjardarhaga 2-6, 107 Reykjavik, Iceland
+354 525 4702
ebba@hi.is
ABSTRACT communication between the software developers and usability
This paper postulates a thesis claiming that abstraction is an specialists must be tackled [1]. We can all agree that
essential part of communication during user interface communication is important, but how, what and why? Engineers
development, that models are a way of expressing those have long communicated by means of mathematics, structural
abstractions and that user interface developers and software (architectures) and behavioural models (electrical engineers).
engineers need the same language for communication. Motivated They communicate about materials, structures of buildings, input
by described myths and desired model characteristics stated in the and output of processes or systems. Computer scientists on the
literature, several counterarguments and arguments are given to other hand express things with logic or computer programs.
the thesis, backed up with results from empirical research studies. Because it seems so easy to change programs or write new ones,
The paper concludes with a plan of action to bring the thesis unlike concrete materials such as metal or cement, programmers
forward. think that modeling is not necessary, and in the race for fast
products to market, they skip the preparation and planning and
Categories and Subject Descriptors dive right into the implementation [2].
H5.2 [User Interfaces]: models Because of inherent complexity of software, or maintenance,
computer scientists tend to abstract from details for easier
General Terms comprehension during development. Much of the effort of
Human Factors research in software engineering has been on how to communicate
and articulate this abstraction. Early, this abstraction appeared as
functions, with input and output as descriptions of change of
Keywords states of the machine, then as user defined data structures. This
Models, Abstraction, Development was followed by entity-relationship models which had a strong
influence on data modelling. Finally, since few decades,
1. INTRODUCTION abstraction has been dominant in object-orientation, where
During software development, good communication within a abstraction occurs in forms of inheritance and encapsulation.
development team and between a team and the stakeholders is Reuse was the anticipated return on investment of abstraction,
essential. Many development lifecycle models have been initially with the concept of classes but when that did not meet
suggested, and since participatory design, most if not all lifecycle expectations, recent developments have centered more on
models have emphasized inclusion of users. Recent agile models components and services as a form of abstraction.
include two characteristics which involve users; writing some There have been different suggestions of specializing descriptions
kind of user stories and letting the buyer of the product decide of user interfaces from descriptions of software in general, such as
upon the next features in the product. Agile methods also stress patterns for user interfaces, frameworks and classes to user
that communication within teams are important, but they do interface programming [3]. Instead of specialization from general
discourage heavy documentation, processes or tools usage. software models, others have designed models for user interfaces
Communication within a team is sometimes between different independent of software development, such as cognitive models
roles. The gap between software engineering and user interface [4] . With the advent of the web as a platform, specific languages
development has been addressed to an extent in the literature and have been developed and engineering tools developed such as
the conclusion is that whatever method is used the difficulties in Web-ML and OO-H [5]. There have thus been countless
attempts to devise specific models for user interaction, and while
they are useful as such they will probably not be widely used by
Permission to make digital or hard copies of all or part of this work for software developers, or in an interdisciplinary team of software
personal or classroom use is granted without fee provided that copies are developers and user interface designers [1]. Those models which
not made or distributed for profit or commercial advantage and that
are based on software engineering models such as UML-Web
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
based Engineering (UWE) are perhaps more likely to be used in
requires prior specific permission and/or a fee. such teams [6].
Conference’04, Month 1–2, 2004, City, State, Country.
Copyright 2004 ACM 1-58113-000-0/00/0004…$5.00.
From time to time, or should I say continuously, the research 3.2 Models are difficult to create and few
community has been trying to discover why developers refrain
from using models as abstractions of software, be it informal or know how to make them
formal. As in the case of formal methods, scientists have tried to Not many modeling languages have been created exclusively for
elicit myths and refute them [7]. Sometimes these myths have user interface design or for that matter software development. The
been denied with facts, sometimes with general arguments. Myths predominant one for software development is UML and it is quite
are drawn from speculations, here say or common knowledge in large containing a number of different model types. The types of
the area. While it is useful to gather such tacit knowledge present problems architects describe are scattered information among
it explicitly, we need to conduct more empirical research different model views, incompleteness of models, disproportion,
investigating usage of models. A few such studies and my own i.e. more details in some parts than others and inconsistencies
results have motivated several statements of arguments for user between teams. Furthermore, architects claim that models are
interface modeling. The next section states a thesis, followed by sometimes used informally and there are a lack of modeling
counter arguments and arguments for that thesis. The paper conventions [11]. A study on the use of UML demonstrated that
concludes with a plan of actions. those with more UML experience used it more extensively than
those with less experience, suggesting that analysts need time to
learn how to use the UML language well [12].
2. THE THESIS
While I agree that modeling can be an intricate activity, I don’t
I postulate that a good way to communicate user interface designs, think it is the models themselves that are difficult to create, but it
and hence results of usability evaluations, is through abstractions. is the activity of abstraction which is hard. Successful user
I postulate that models as a form of abstraction are the best way to interface designers will always need to learn how to abstract.
discuss and argue about a user interface development. The models Some will learn it through modeling; others will learn it implicitly
are created during the requirements, design activities, used to as they gain experience. With models they are forced to do it but
assist during evaluation, used to express, understand and even they can avoid it they don’t use models, with unpredictable
predict results of an evaluation, and used to redesign a user results.
interface to fix a usability problem uncovered during evaluation.
Finally, I claim that for the task we need software development 3.3 Creating models are costly and not worth
models in order to bridge the gap between user interface and
software designers.
the effort
Creating models, especially if supporting tools are unavailable,
can be a difficult and time consuming effort. Not only are models
3. COUNTER ARGUMENT difficult to create but also evolve ensuring that the models are
Probably, not everyone agrees with the stated position. In the synchronized with the implementation. A survey says that 52.5
following, let us examine some of the counter arguments, some of percent of practitioners finish modeling when the model is
which are motivated by the characteristics of good models, i.e. complete, 33.8 percent of practitioners say that a model is done
abstraction, understandability, accuracy, predictability and when it has passed a review or an inspection, and 32.8 percent of
inexpensiveness [2], others which are motivated by myths stated practitioners say that the deadline is the stopping criterion.
in the literature [1, 7]. Whereas the completeness of a model is more often a stopping
criterion in larger projects, a deadline is more often a halting
3.1 Working software over comprehensive criterion for smaller projects [11]. These numbers tell us that
documentation models are created in different ways, and in the cases where the
One of the principles of agile development is working software models are not complete, developers do not take full advantage of
over comprehensive documentation. Daily face to face meetings the benefits of models, namely model driven development where
and frequent changing of roles or activities is meant to make up code is automatically generated from models [2].
for lack of documentation. Knowledge is tacit and not explicit [8]. A study we conducted recently showed that over 30% of the
Modelling is a process which aids in describing and abstraction defects could be blamed on faulty dialogue or navigational design,
what is to be built. In support of this counterargument Ambler [9] yet only a few of those defects were fixed [13]. Why? We
refers to Constantine [10] who says that it is a misconception that speculate that the reason may be that it was estimated too difficult
agilists do not model. The truth is, Ambler states, that they do to fix the usability problems because the solutions required a
model, but that they discourage extensive modelling up-front but revised user interface architecture and hence were too costly or
encourage active modelling along the way. Ambler supports this even too difficult to make.
by referring to agile methods’ literature, but also acknowledges Our conclusion, from our own and other research studies, is that it
that the models are sometimes rather informal. is very costly not to create models, and that unless models are
Further, some of the misunderstanding of models is that their complete, their full benefits are not reaped.
impact is to be mainly achieved through the end product. Instead,
modelling is a dynamic activity and much is gained by the
interaction which the modelling activity facilitates
3.4 Models are limited to describing those 4. ARGUMENT
characteristics of user interfaces which do not In this section we restate our claims and support them.
concern presentation
Models, especially very abstract ones, do not capture experience 4.1 Abstraction is key to communication
very well. To understand emotional experience, we need a With abstraction we are able to discuss main interactions and
detailed contextual implementation. principles in the software without burying it in too many details.
Abstraction makes it easier to plan, verify and design. Abstraction
A survey among 171 analysts showed that of seven different types
allows us to present different views of the user interaction.
of UML diagrams and narratives, class diagrams were used most
frequently, with 73% of the analysts saying that they were used in 4.2 Models are a good way to communicate
at least two-thirds of their projects. Use case diagrams were
second, use case narratives fourth (44%), but statechart diagrams during user interface development
came sixth, with less than 30% of the analysts saying that Sketches, scenarios or storyboards are all different types of
statecharts are used in at least 2/3 of the projects. On the other models, since they describe the real end product but leave out
hand when analysts were asked to mark those diagrams which some of its details. Diaper states that “HCI is an engineering
were never used, class diagrams ranked the lowest with only 3% discipline and therefore must model the real world that is assumed
to 25% for collaboration diagrams, ranked the highest [11]. to exist, notwithstanding how poor and partial might be our
models of it.“ [14]. Diaper emphasises the importance of task
In this same survey, respondents were asked for the usefulness of models since they describe a series of events or activities in time.
the different diagrams. Interestingly, whereas statechart diagrams He doesn‘t exclude other models but says that they play a lesser
were used much less frequently than class diagrams, they ranked role. Seffah and Metzker acknowledge that task models are widely
second in usefulness after class diagrams. used in the user interface community but warn that they may
If we were to ask user interface developers, I speculate that class describe functionality more than usability, thus not fulfilling the
diagrams are only useful for conceptual modelling, but activity objectives of the user interface developer.
diagrams and then state charts diagrams would be ranked higher One of the desirable characteristics of models is that they should
in terms of providing new information not found in use case be predictive. Prediction does not only include foreseeing the
narratives. behaviour of the user and the system through simulation, but also
Conceptual modelling is still very useful in user interface design. modelling of the development activity itself and not just the
Our study showed that around 23% of defects uncovered could be artefacts. With increased emphasis on approaches for the whole
attributed to wrong conceptual models [13]. As we see in UML lifecycle, including maintenance, we need to include models for
there are a number of different types of diagrams and this is what evaluations of user interfaces. Modelling evaluation results should
we should aim for in user interface modelling, but we need to link help us predict whether a defect is likely to be fixed, whether an
the different models together such as the presentation models to evaluator is likely to uncover defects, whether components are
the structural and behavioural models, or else the developers will likely to be faulty etc.
complain that there is a disconnect between the models.
4.3 Software development models can serve
3.5 Users do not understand models user interaction design and other components’
In a user-centered development, it is imperative to involve users at
all stages of development. It is also critical to include a multi-
designs
disciplinary group of experts. Therefore, the communication In communication between people a disagreement is often due to
language needs to be familiar to all. Undeniably, artifacts such as misunderstanding. We say that people don’t speak the same
low-fidelity prototypes, story boards, scenarios and use case language. To close the gap between software engineers and user
narratives are very accessible to users, and countless research interaction designers they need to speak the same language.
papers have claimed the usefulness of informal models of user Different dialects can be permissible but not different languages.
interaction design such as scenarios and prototypes.
The results of a study on how UML is used, partly refutes this 5. CONCLUSION
counterclaim. While the study’ results reveal that stakeholders are Current research gives evidence that user interface designers need
most likely to use use case narratives and use case diagrams, better help in their work. The number of defects found and the
clients are involved in developing, reviewing and approving other increasing criticality of user interfaces demands that we continue
components more than expected. All of the clients interviewed in searching for better ways to communicate and apply abstractions
the study welcomed the use of UML and some even showed in interaction designs.
insight into its usage [12]. As expected, client involvement is
highest with use case narratives, 76%, and lowest for statechart The counter arguments stated in this position paper are however
diagrams. real threats to this believe. I think these threats can be lessened
What is worrying is that models which are not useful with clients with the following plan of action:
may be useful for programmers, thus creating a gap between the
two groups. 1. Develop a domain specific modelling language for user
interface design which can be used by an
interdisciplinary team of user interface designers and
software developers.
2. Offer tutorials and develop body of knowledge for user 8. Pikkarainen, M., et al., The impact of agile practices on
interface modelling as an abstraction and communication in software development. Empirical
communication activity. Software Engineering, 2008. 13(3): p. 303-337.
9. Ambler, S., Tailoring Usability into Agile Software
6. REFERENCES Development Projects, in Maturing Usability, quality in
1. Seffah, A. and E. Metzker, The obstacles and myths of Software, Interaction and Value, Effie Lai-Chong Law,
usability and software engineering. Commun. ACM, Ebba Thora Hvannberg, and G. Cockton, Editors. 2008,
2004. 47(12): p. 71-76. Springer-verlag London. p. 75-95.
2. Selic, B., The pragmatics of model-driven development. 10. Constantine, L. Process Agility and Software Usability:
Software, IEEE, 2003. 20(5): p. 19-25. Toward Lightweight Usage-
3. Myers, B.A. and M.B. Rosson, Survey on user interface Centered Design. Accessed on April 25, 2006. 2001
programming, in Proceedings of the SIGCHI [cited 2009; Available from:
conference on Human factors in computing systems. www.foruse.com/articles/agiledesign.pdf
1992, ACM: Monterey, California, United States. 11. Lange, C.F.J., M.R.V. Chaudron, and J. Muskens, In
4. de Haan, G., G.C. van der Veer, and J.C. van Vliet, practice: UML software architecture and design
Formal modelling techniques in human-computer description, in Software, IEEE. 2006. p. 40-46.
interaction. Acta Psychologica, 1991. 78(1-3): p. 27-67. 12. Dobing, B. and J. Parsons, How UML is used. Commun.
5. Abrahão, S., et al. A Model-Driven Measurement ACM, 2006. 49(5): p. 109-113.
Procedure for Sizing Web Applications: Design, 13. Law, E.L.-C., et al., Impacts of Classification of
Automation and Validation in MoDELS 2007: Springer- Usability Problems (CUP) on System Redesign in
Verlag Usability and User-Centered Design in Software
6. Koch, N. and A. Kraus. The expressive power of UML- Development: Case Studies and Real Life Applications,
based engineering. . in Second International Workshop Ann Blandford, et al., Editors. 2010, in review, IGI
on Web Oriented Software Techonlogy (CYTED). 2002. 14. Diaper, D., The discipline of HCI. Interacting with
7. Bowen, J.P. and M.G. Hinchey, Seven more myths of Computers, 1989. 1(1): p. 3-5.
formal methods. Software, IEEE, 1995. 12(4): p. 34-41.