Final Papers for Human Computer Interaction (HCI) Practical ... - Liacs

Proceedings
Human Computer Interaction Project
Fall 2006
Lecturer
Fons Verbeek
Primary Assistants
Mounia Belmamoune
Yun Bei
Yanju Zhang
Course Assistants
Alexander Nezhinsky
Sander van der Maar

Preface
Assembled in this proceedings document are the final papers of the
Human Computer interaction course 2006-2007 for computer science and
media technology students. Only those projects that have been completed
within the given timeframe are included in the proceedings document. In
total 19 contributions are included in these proceedings.
The papers are ordered to subject without further ordering or ranking.
We, the course administration, have enjoyed the projects and the
supervision thereof for a great deal. The midterm presentations as well as
the final presentations were of good level and the students have actively
participated in the discussions. This is an important ingredient of an HCI
course; the midterm presentations gave in many cases idea of an expert
evaluation.
The papers are included “as is”. We have emphasized in some cases to
include more graphical material in the paper. This is important so that
readers can understand what the interface is supposed to do and how the
interaction is designed.
The separate papers will be submitted to the HCI content management
system (CMS) which can be used for browsing ideas for next years
students. It will help to set the level. In addition, in the same CMS the
final products stored and can be provided on request. Providing the CMS
is new to the HCI course and will help to learn from what other students
have been doing. We are happy that we can present the results of this
years HCI course in this manner.
We thank all students for their efforts in this course; we have appreciated
your input and critical attitude. We hope you enjoy browsing and reading
this document.
Leiden, February 2007
Fons J. Verbeek

HCI Projects
No. Group Group Members Project Title
1 01 Arjan Assink Simon Windt Beginnend Lezen
2 02 Mario Bardini Menno van Elk Learn &Enjoy
3 09 Michiel Helvensteijn Jori van Lier Platform game knowledge testing
4 23 Jens van de Water Christina Papakonstantinou Peter the Penguin
5 25 Anthony Woudenberg Marian Maas Mathematical Dice
6 14 Tim van Meurs Ioannis Panagiotou Puzzlemath
7 19 Frank Takes Tiago Borges Coelho Mobile Learning
8 10 Anton Hunsucker Sifferina de Jong The Music Man
9 27 Petr Krsek Loren Roosendaal Music Maestro! (Input part)
10 22 Xuan Wang Karen Sam Music Maestro! (Output part)
11 21 Sander van der Vlugt Job de Reus Blind typing for seniors
12 12 Joppe Kroon Alex Reuneker Help elderly using the mouse
13 7 Stijn de Gouw Elena Gavrielidou Visual Memory Game
14 26 Sjaak Wolff Ella Keijzer Online Flower Shop
15 18 Stefan Schrama Christian Detweiler Barschedule Catena
16 15 Erik Kuijl Police Academy
17 24 Fee Yun Wong Kees Kofferman Seek the thrill
17 Maja Jakobik Seek the thrill
18 04 Kerem Denizmen Sjoerd Kranendonk Whiteboard
19 08 Eyal Halm David van Paesschen Security system for cargo airlines
20 03 Roald de Vries Maarten Groeneweg Medication files for patients

Read Aid
Arjan Assink, Simon Windt
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
aassink@liacs.nl, simon.windt@quicknet.nl
supervised by Alexander Nezhinsky.
anezhinsky@liacs.nl
Read aid is a program that can assist small children in learning to read. The
program does this by presenting them with a clean, easy to use, but appealing
graphical interface. The interface is designed in such a way that the children
will not be easily distracted, but so that it does stay interesting for them to use!
1 Introduction
This paper will explain, in detail, the process we went through while developing
the Read Aid program. The initial idea for the program was formed when we
noticed that there were very few games that helped children in the earlier age-groups
to read. There we plenty of programs for the older children in the primary school, but
the age group 5-7 was neglected. The programs we did find for this age-group usually
had cluttered, and hard to use interfaces (even for adults), so we decided to create a
program that was clear to the children, easy to use, but at the same time was able to
keep their interest in the program and learning to read.
2 “Short Subject Background and problem definition”
The problem with teaching small children how to read is that it is very labor
intensive, the child has to be guided every step of the way, even when just practicing.
What we aim to do with Read Aid, is to take some of this strain away from the teachers
or parents, and allow the child to practice reading on their own. Read Aid is therefore
not a replacement for classical teaching, but a supplement.
Similar program’s are usually aimed at children in the higher age-group in
the primary school, that is why Read Aid is aimed at children in the age group 5-7.
Besides a different age-group, most alternatives have one thing in common, their
interface is very cluttered, or not attractive to look at. If we want small children to
stay interested in Read Aid, our interface will have to be very clear as well as attractive
and exciting for little children.

User analysis
For our first user Evaluation we went to a Dutch primary school, where we tested
our application with several children around age 7, who had just started reading. Our
major concern here was the level needed for the words and images we used for the
prototype, we thought they might be a bit to hard for the children. After our first testsubject
we discovered the children were already much better at reading than we had
expected, and the level of the words was right on the mark.
The biggest problem that erase from this first user analysis was that the children
kept “losing” the cursor. We solved this problem by making a custom cursor that was
bigger and much easier to find. Second problem was that the children didn’t really
understand the level choice that was given to them, so we disabled the option. It could
later be maid available to the teachers.
On the second user evaluation we used an eye tracking system. We already
made some changes to the game after the first user evaluation. We didn’t get any new
results from the second user evaluation.
3 "Clean, but fun"
As mentioned before, the problem with most programs the preceded Read
Aid is that their interface were not user-friendly, mostly due to 2 factors, they were
either to cluttered or they were not fun to use. Read Aid tries to solve both these issues.
We did this by first creating a clear, easy to use interface, with big buttons.
To further limit clutter and distraction, we decided to make the application full screen,
thus minimizing the distraction provided by any other programs that may be running
on the computer at the same time.
Our second challenge was to keep the child’s interest. This was a bit harder
to do, because we had to figure out what appealed to children of our user-group. After
some research we came up with the following things, which now seem painfully obvious:
sound, color, movement. We incorporated all of these things into Read Aid.
The child is provided with auditory comment on their progress throughout
the entire game, explanations are given by a voice, as well as congratulations when a
question is answered correctly. We also put as much color into the interface as we
could, without creating distraction from the questions asked. This is done by large
colorful buttons, and a colorful background. The background has a lower saturation
that the buttons and pictures, to prevent it from getting the upper hand in the design.
The hardest thing to incorporate into the design was movement, at first we
thought of maybe making the buttons slide into the screen, but we thought this might
“scare” the children, making them afraid to use the application. This is why we finally
decided to add short video-clips in between the question, when a child has success-

fully answered a question. This way the child is rewarded for a correct answer, and
the game stays interesting for them as well.
4 Results and Evaluation
When we arrived at the first prototype, the user evaluation was very encouraging.
At first we thought the game did not appeal to the children at all, because they
did not seem very excited during the test, however, afterwards their teacher approached
us and told us how excited the children were when they came to tell her
about the program. This was a very good thing to hear, because our program would be
completely useless if the children wouldn’t like playing with it.
A few small issues did come out of the first user evaluation, but those were
quickly fixed, and the second user evaluation showed that the modifications made
were a huge improvement. Our product now met the requirements we had set for it,
Read Aid had a clear and highly useable interface, and was a fun game to play for
young children.
During our class presentation, like our first user evaluation, a few small issues
were raised, for instance our background drew to much attention to itself, so we
changed the saturation of that. Besides small things like that, no major changes were
suggested for the program itself in terms of usability or structure.
5 Conclusion and Discussion
In conclusion, we think that Read Aid evolved into the game we were aiming
for. The children that played the game seemed excited and were able to play the game
autonomously, without much help from the teacher other than starting the application.
The movie-clips that were added after a question was answered correctly, and the
Dutch auditory aid during the program seemed to appeal greatly to the children,
which is exactly what we were hoping for.
6 Future Work
Read Aid is a complete application as it is, except for the content. In the
future, content could be retrieved dynamically from a database, and results of each of
the students could be stored as an expansion on the current program.
Besides expanding the current program, it could also be altered to fit the interests
of older children. This would have to be done not only by changing the content,
the images and words, but also by changing the layout of the screen. Perhaps

children of higher age groups would prefer different images, a different auditory explanation,
all this would have to be researched.
References
1. Future Lab, Report on Gaming for Childern in Education, 2006, 65 p.
Appendix

Gioca & Impara
Mario Bardini, Menno van Elk
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
Mariopwr@yahoo.it, Menno.vanElk@phil.uu.nl
supervised by Yanju Zhang, Fons J. Verbeek.
yanju@liacs.nl, fverbeek@liacs.nl
Gioca & Impara is Italian for play and learn. In this case it’s also the title of our
flashgame. The game itself is designed to teach children the basics of another
language. Because children like playing more then learning the educational
element is disguised as a feature of the game. To accomplish this goal we have
chosen the form of a slotmachine. The slotmachine presents a row of pictures
that forms a sentence. A number of possible sentences is given in another language
that users can choose between English, Italian and Dutch. The user has to
select the matching sentence to win coins. To encourage repetitive play the
coins can be spend in the game.
1 Introduction
The acquisition of language is something children are good at. Young children apparently
learn a new language without great difficulty. Knowledge of multiple languages
tends to be very useful at later ages so we think it would be a good idea to stimulate
the learning of a second language.
We have decided to hide the learning language part in a game. This is because children
like to play games a lot better then they like to learn another language. Most
other methods for learning a language use books, dictionaries and similar tools. Our
solution works with pictures. The sentences and words learned need to be read however
so we decided to limit our usergroup to children who are just learning to read.
In this paper we’ll show and discuss the steps we have taken in the development of
the game. First off is a description of the initial plan and the assumptions made. We’ll
focus on the difficulties of our approach and the results of the user evaluations. The
paper also contains a description of the final interface.

2 Development Trajectory
It is very important in life to have an education and to learn stuff. To contribute to
this we have decided we wanted to make software for children. Language is such a
major aspect of life and the authors had between them 3 languages to choose from, it
was soon clear that this knowledge somehow would have to be used in the program.
Within the constraints of making an educational children’s game and using our
knowledge of languages Gioca & Impara was conceived.
The game is focused around pictures. Even without formal knowledge about the way
children perceive software it would clearly be more attractive to them then plain text.
Pictures can be funny and give the opportunity to add color and atmosphere to the
game. Because of the graphic constraints we chose for the development platform of
Flash. Not only is Flash very suited to the construction of Graphical User Interfaces,
it also presented us with the opportunity of learning Flash, a skill we both sorely
lacked. Our game would thus be made in Flash and would use pictures to teach children
the basics of some other language.
With the plan for the game finished we concentrated on describing our usergroup.
Because of the skills involved in using the program our users could not be too young.
They would need to have a basic understanding of how to use a computer, they need
to be able to read and they would need to be able to understand the concepts used in
the program. Because of these constraints we restricted our usergroup to children in
the ages 6 and 7 years old. To complicate matters somewhat, we couldn’t just use
regular Dutch children because of our team composition.
With a detailed description of our usergroup and the programs constraints and target
finalized we next concentrated on creating a prototype design for the interface. Since
we wanted to use pictures to construct sentences and somehow refresh the pictures
for every new assignment we needed to design an interface that makes this possible in
an easy way. We chose the slotmachine interface because it is very suited to this specific
task of refreshing the pictures. Also, it’s a very common factor in several Nintendo
games. We therefore expect children to feel familiar with it when they see it.
The slotmachine is exceptionally good when compared to other games. It is very easy
to operate (only one button!) and looks very nice because of the animations. Other
software solutions on the language front use a more adult approach that doesn’t appeal
to children in the way the Nintendo approach does.
3 Spinning the Reels
In this project we concentrated our attention on usability requirements. We’re trying
to make a usable product, one where people can easily learn, that has functions that
allow people to do what they want to do, and that is well-liked in general.

Within the game we especially focus on aspects like ease of learning, task efficiency
and subjective satisfaction; making a system that scores high on, mainly, these factors.
We think that these are the most important aspects that a software developer should
consider when making a program for children because they like to complete a task in
a few steps without having a particular experience, and they are more satisfied if they
use a well-designed program.
To help new users learn the options that the game has to offer we use a cartoon that
hosts the program. A cartoon is used because children like them and somehow feel
they know them. It will give us the opportunity to present hints and help in a way that
children will accept. We reckon this gives the impression of a familiar face telling
them what to do. The cartoon will therefore be in the first screen. To further enhance
this personal-approach feeling the host prompts the child to introduce him or herself.
In the first screen is also available the option for language selection. To select a language
the user is prompted by the host to select his or her language, represented by a
flag and an abbreviation of the language (Ned, Eng, Ita).
The next phase in the program would be the selection of a style of play. Originally we
had planned to use several different modes here. First option would be to choose
whether you would like to learn new stuff or test your existing knowledge. These
styles are labeled ‘Practice’ and ‘Play’. We think this distinction is a very important
one because you cannot play the game until you have some basic knowledge of the
language that you are playing with. A user will feel bad about him- or herself if he or
she ‘needs’ to play the game without being able to actively influence the amount of
coins scored. The choice made in this screen will decide what screen you get to see
next.
In the ‘Practice’ section you would have been able to choose between learning words
or learning sentences. The interface for both would have been the same, except in the
words screen only one slotmachine reel would have been visible. The user should
then spin the reel(s) to show new imagery and try to remember the words that are
associated with the pictures. After learning the words and sentences in this mode the
user should then try him- or herself in the ‘Play’ section. In this section we had originally
planned a written exam and an exam based on speech-recognition (users had to
write and read the word/sentence).
Before starting work on the actual program we did a user evaluation with class 2 of
the British School in The Hague. The evaluation gave us a lot of information about
the sort of visuals children appreciate in a program. A detailed description of this
information is included in our article called User Evaluation. More important however
was the fact that this session immediately showed us the major design flaw in
our program.
Our evaluation asked children to write down the words and sentences that they
thought were depicted in one image and in two and three grouped images. This was
just in English but it turned out there’s a lot more ways of spelling the word ‘ele-

phant’ then we would have thought possible. It is also amazing to notice the wide
array of sentences that can be deduced from a picture of a cat and a picture of
someone sleeping. In short: we had to change our design. If children are allowed to
just type in an answer, they will never get it right.
The first prototype of the game therefore took a somewhat different approach. First
we got rid of the subdivision for each menu option. The game from now on only
offers the options of practice and test. In practice mode there is no different option to
learn individual words anymore because this is already included in the sentence section.
In the test section the answering option has turned to multiple choice system but
because you are not practicing, the stakes will be higher… This does increase the
difficulty somewhat but with the help of the ‘listen’ button children will be able to
find the right answer.
Our evaluation showed Super Mario to be the most popular cartoon character to host
the program. This works out very well because in all Mario games players are supposed
to collect coins and stars to buy new game-items with. This we have shamelessly
copied. In practice mode the player will be playing for 1 coin each question but
the test mode will have higher bets (not decided how much yet). This will keep practicing
interesting (you will still win stuff) but will also make it challenging to perform
well in the test mode (to get the really cool prizes).
4 Results and Evaluation
The results we have obtained so far are encouraging. We use the word encouraging
because we ought to do a final test with our original usergroup first before making
hard statements about results. Time constraints however forced us to do the evaluation
of our prototype with Dutch children. In this section we will therefore mainly
focus on the remarks that we received from various people involved in the design
process and their influence on the usability of the interface.
During discussion in class our attention was pointed to the possible difficulties involved
with the interface that we chose for the language selection. This remark was
later repeated by Mr. Paul Ellis, head teacher at the British School in The Hague. A
bit frightened by now, we included various questions related to this solution in our
questionnaire. Evaluation shows most children are perfectly able to interpret the flags
in the intended way, but, to help them who aren’t, we put the first 3 letters of the
language together with the flag picture.
In class it also turned out we had at first forgotten to include a reward for players in
our game. Rewards are however very important when working with children. According
to Mr. Ellis there is a very strong ‘what’s in it for me?’ attitude with children. We
decided to just ask our users what they would like to win while playing the game. It
turned out that the overwhelming majority thinks (virtual) coins are a great prize.
Keep in mind that our questionnaire was mostly multiple choice so the results are

perhaps somewhat biased. On the other hand we have had strict advice from people
who are used to working with children that we should not use (too many) open questions
in our evaluation. The answers on open questions tend to be pretty much unusable
in situations like this.
Our first evaluation we had prepared on big sheets of paper. Mr. Ellis suggested that
children might not be able to make the mental transition from interface sketches on
paper to real computer program screens. We tossed away our sheets and changed to a
clean powerpoint approach. A side from this being a lot more robust and controllable
it’s also much easier to show stuff exactly as intended. This is very important when
working with children.
Another issue raised during the project was how we where going to generate syntactically
correct and meaningful sentences. Because we have full control over the slotmachine
and the sentences shown this is no problem at all. All picture combinations
and given sentences are hard coded into the source code.
The evaluation of the final prototype has shown no apparent flaws in the game design.
Children navigate the game and operate the machine with ease. There was however
some disappointment when they discovered functions that don’t work (they couldn’t
win coins) but overall they enjoyed the slot machine idea and the whole design of the
program. After that evaluation, we decided to change just the first menu adding to the
flags the whole word of the language that they represent instead of only the first 3
letters.
5 Conclusion and Discussion
Working with children is a very rewarding experience. We had initially approached
our users like they are just small versions of adults with perhaps a greater interest in
flashy colors. Discussion with several specialists has made us realize that this is definitely
not the case. Children require a special unidirectional approach.
Children will not be able to enjoy a game that requires them to spell every word correct.
Also, because we want them to learn something from the game, we can’t just say
‘well… that’s not quite perfect but good enough’.
The effect of the game on the ability to learn the basics of another language is not
something that we have been able to test. The acquisition of language is a process that
takes a long while before the results will be noticeable. This is not something we can
scientifically prove during this project. Teachers we have spoken to however have
said they find the game to be an interesting approach to this subject and hope to see
ours and more of these programs appear in the near future.
On a side note we would like to remark that when working with other people (i.e. a
third party) it’s sometimes just not feasible to comply with the strict deadlines that
seem reasonable in a school course. Another thing we would like to comment upon is

the difference between designing a clear and concise interface and actually building
one. We think the course should try to keep these two factors more separate. It’s
easier to come up with a solution to a problem then to implementing said solution.
6 Future Work
There are still some features that we have thought about but have not been able t
implement in the game. For instance the prizes that can be bought with the accumulated
coins, perhaps new picture sets for the slotmachine. Also the game would need
to have a lot more sentences then just the two we made for testing the interface. Perhaps
thousands. The pictures needed to represent verbs are very difficult to come up
with. Perhaps professional artists could be involved. The interface could benefit from
the use of animations, especially the cartoon host.
After implementing all these, we could consider testing our prototype with our intended
usergroup. This could maybe be part of a longer research into the acquisition
of language for young children.
References
1. Alan Dix e.a, (2004). Human-Computer Interaction. Pearson Education Limited.
2. Soren Lauesen, Houman Younessi (2000). Six Styles for Usability Requirements.
Proceedings of REFSQ’98.
3. M.F. DiAngelo, C.J. Petrun (1995). Collecting productbased usability requirements.
IBM Systems Journal vol 34, no 1. (4-19)

Appendix
Fig 1. First menu
Fig 2. First menu (with mouse over the English flag)

Fig 3. Main menu
Fig 4. Main menu (with mouse over the first flag)

Fig 5. Practice section
Fig 6. Practice section (with mouse over the first flag)

Fig 7. Test section
Fig 8. Highscores page

Fig 9. Shop page

Platform game testing
Michiel Helvensteijn, Jori van Lier
January 10, 2007
Abstract
This project proposes a solution to the inability of children to keep
their attention at their studies. Doing tests has been proven to be a good
learning-tool, and our program will make taking tests fun for children by
embedding it in a popular game environment. We have shown that there
is interest in the idea, but that more than one semester is needed to create
a game nice enough to appeal to our target users. Our current program
can’t possibly compete with 3D games from the latest generation consoles.
1 Introduction
Children of the current generation have way too much video-gaming to do to
get any schoolwork done. Of course, because they have to learn for school,
whereas playing video-games is their own choice, and video-games are specifically
designed to appeal to them. Not much has been done about this, and
those attempts that did happen were of limited effect.
We attempt to combine learning with video-games to bring the best of both
worlds. You take a well-known virtual game-world and put in the knowledge the
children should know and you get learning that’s also fun! Well, it’s actually a
bit more complicated than that, as we will discuss later on.
We discuss the problem in more detail in section 2. Our solution to this
problem is discussed in section 3. In section 4 you can read about our relative
success and our conclusions are to be found in section 5. Lastly, in section 6 we
briefly discuss possible followup work that can be done in this area.
2 Let them learn it while they’re young
Our targeted user-group consists of school-going children of approximately nine
years of age. They have used computers before, but don’t often have real
computer-skills. They play video-games and most of them enjoy them immensely
and are willing to put significant time and energy into reaching the
goal of these games, much to the detriment of their scholastic performance.
They do, however, get really good at the in-game mechanics. If a game requires
logic and a child plays it often, he/she gets good at it. Same goes for handeye
coordination. Some young adults of the current generation easily get their
drivers-license, because they got high-speed racing ’experience’ playing Gran
Turismo. And younger children learn much more easily than adults. For example,
very young children easily learn a second language by simply being exposed
to it.
1

We have a problem. Children learn more easily when they’re young. But
this is exactly the time in their lives that they have trouble focussing on their
school-work. This is a waste. Even if children do put a lot of time into their
studies, it would be much more effective if they actually enjoyed it.
Several solutions have been suggested for this problem. There are some
games that are meant to teach arithmetic and language, and they are used
in schools. But they don’t really help all that much. Not much effort has
gone into making them and the children easily recognize them for what they
are: just tests with a colourful shell around them. Why would they want to
pop bubbles with arithmetic problems inside them, or see some french guy on
screen pronouncing french words, when they could be fragging opponents with
a railgun, or solving complicated dungeon-mazes with breathtaking graphics?
The current approaches are mostly insufficient.
3 ”It’s me! Mario!”
Our solution is to put the learning-tool into a game. Not wrap a game around
a learning-tool. Make sure that the primary goal of the game is fun, and make
sure testing the knowledge of the player is essential in solving the game. We
must make sure to make the game as ’addictive’ as the real games currently in
the market. That’s the key. Use a good story. Use an existing genre.
Because we don’t have enough time to create something suitable for this
project, we tried a slightly different approach. We used an existing game with
a character that children should be familiar with. Super Mario! The genre is
a platform game. We chose Super Mario Brothers 3 as a model. Mario (or
another character from the Mario world) walks through a familiar level of the
game. In the original, Mario is controlled with two arrow-keys and a jump-key.
The movement is done automatically now. Mario walks by himself. He just
has to jump at the right moments. Like when an enemy appears, or a bonus
block with a mushroom (bonus item) in it. This jumping is controlled by the
player correctly answering test-questions. If he/she doesn’t answer in time or
answers incorrectly, the correct answer flashes at him/her and Mario walks into
the enemy, traditionally losing a life. Mario’s lives can be seen as the number
of mistakes that can be made while still getting a passing grade for the test.
To compensate for the lack of good graphics and the lack of a good story
because of our general lack of time, we tried to introduce some random elements
into the game that should make it at least slightly more interesting. Instead of
just the Goomba (the standard enemy), Mario can randomly run into a Koopa
Troopa, a turtle-like enemy that leaves its shell behind. Mario can use this
shell to block the next enemy attack, if he answers a question incorrectly. We
will also introduce bonus blocks that either spawn a power mushroom, turning
Mario big, so he can take an extra hit before losing a life, or a life mushroom,
granting him an extra life.
We understand that these are feeble attempts to overcome the lack of manhours
and funds that real game-developers do have, but we hope that testing
the result will give us some information about the demand for such a game.
For our program to be usable by our target user-group, the following demands
must be met:
• It must have an intuitive interface. Make sure that the childs inexperience
2

with computers does not get in the way of the experience. The exact
demands are in our user evaluation tables.
• It must compel the player to play on. It should be addictive in a good
way.
4 Results and Evaluation
Our program has officially seen 3 versions, but there were really only 2. The
first prototype was severely limited in graphics and possibilities. Only Mario
could be chosen as character, only multiple choice questions could be posed in
the test and the scenery around the level was pretty much non-existant. Add to
that, the random bonus elements (koopa, bonus block) were not there yet. In
spite of all that, the results were encouraging. Every time-period measured was
within specifications. After asking the test-subjects about their opinion, they
agreed that the idea is good, but that the game is quite boring, and wouldn’t
keep their attention for any period of time.
We understand that our game is boring. The important part is that the
interface was clear and that, after having given an example, the children liked
the idea.
In response to this evaluation we only expanded the game to make it look
better and make it less boring. We added princess Peach as a playable character.
We added Koopa Troopa as an enemy. And all three types of questions can be
asked now:
1. Multiple choice questions.
2. Random arithmetic questions.
3. Open questions with a numeric answer.
That was prototype 2. And the results of user evaluation 2 are almost the
same as those for one. They liked the idea. They liked the improvements.
But they were not enough to make the game less boring. The girl did like the
addition of the Princess Peach character.
Our final product has seen a few changes since evaluation 2. Most notably
are the addition of bonus elements in the form of life-mushrooms (which let
the character gain a life) and power-mushrooms (which let the character grow,
so he/she can take another hit without losing a life). Also, we’ve added an
indication for the amount of lives left, and added a horizontal bar, which shows
how much time is left to answer a question, greatly enhancing visiblity. We did
not evaluate this version, but we are pretty confident that the final version is
better than the one used for evaluation 2.
5 Conclusions and Discussion
We find that the first usability requirement - the intuitive interface - has been
met. The children could, without much trouble, navigate through the startup
screen and they found it easy to interact with the game-environment.
3

The second, however, has not. As we expected, children are not really fascinated
by our game. We never stood much chance against titles from Nintendo,
Sony and Microsoft. However, we have noticed that adding more and random
game elements is a key factor to increasing user satisfaction. Also, something
can be said for the difficulty of the questions. We’ve kept these mostly trivial
to be sure that we’re only testing the interface. Had these questions been more
of a challenge, it would probaly have been more fun to play.
6 Future Work
Future work would include the creation of a real educational videogame, such as
we could not create in one semester. The interest is clearly there. The money
just has to come from somewhere.
The interface could definately do with some more auditory feedback, we
unfortunately didn’t get around to adding much of this. Also, while we’re on
the subject of sound, another neat idea would be to enhance the interface with
speech recognition software. Answers could be spoken instead of typed/clicked.
This would have a much greater appeal to the children.
Initially, we planned to make a teacher-only interface to compliment the
game interface. This could be used to create tests that can be run within
our game. The teacher would have to know nothing about the game-world.
Although we did not finish a teacher interface, one should certainly be created
in any future version of our idea.
References
[1] Dix, A., Finlay, J., Abowd, G., Beale, Russel.: Human-Computer
Interaction, third edition, Prentice Hall (2004).
[2] ”The Shyguy Kingdom”: http://tsgk.captainn.net/ (Mario sprite
collection)
4

7 Screenshots
5

Math for Kids
Christina Pakonstantinou, Jens van der Water
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
akosxristin@gmail.com, jvdwater@planet.nl
supervised by Yanju Zhang, Fons Verbeek.
yanju@liacs.nl & fverbeek@liacs.nl
Abstract. “Math for Kids” is a program of teaching, training, testing and keeping
track of children progress in math. The training part is accomplished
through computer games ideal for school use. Results on child’s progress are
easily accessed by the teacher. The whole design effort focused in simplicity,
coherence and attraction of the program; elements that, unfortunately, are often
omitted in similar systems. Moreover, badly designed features were carefully
avoided and when necessary replaced with other more efficient or attractive solutions.
1 Introduction
Computers have a lot to offer in education once used and designed in a proper way.
Primary schools often use computer games in order to help young children to learn
basic mathematic notions and operations. Teachers that have incorporated them in
their teaching in class prefer it as a quick learning tool, as well as, an easy way to
have as easy overview of children’s progress.
However, lots of computer systems already in market fail to be broadly used – or to
be used at all – because of design drawbacks. Computer games in general, and most
specifically those used in schools, must correspond to the needs of teachers and children,
as well as, to the role they are assigned within the teaching method.
“Math for Kids” deals with multiple problems within the context of developing a
system for educational reasons. It especially addresses children of group 4 (7-8 years
old) and their teachers.
In this paper we will describe the problems we detected in evaluating prior solutions,
examine the needs of our user group, cite our design decisions while developing
“Math for Kids” and discuss on the results of our research, the future work on “Math
for Kids” and the general concerns in the development of computer games for school
use.
1

2 Computers in schools
Computer games for school-use mainly address two different user groups: teachers
and children. On one hand, teachers need to have an easy access to the system, feel
able to control and use it in the minimum time needed. Critical information on children’s
progress must be easily accessible, but also safe from children’s access by
mistake. On the other hand games, which mainly address to kids, must be attractive,
simple and awarding. These are the problems “Math for Kids” deals with. We will
examine these problems separately for each user sub-group.
2.1 Teachers
Primary school teachers are not necessarily computer experts, nor do they always
have the patience or time to deal with a complex program. Much less when the program’s
use is not critical, but only supplementary. The program should help teachers
in their work and not spend their valuable teaching time.
Teachers, therefore, will not use a program that is unnecessarily complex and time
consuming. However, there are games that fail to be used, because of such reasons,
which, among others, may be caused by the lack of instructions or tutorials.
Moreover, teachers need to have easy access in children’s results. It is of high importance
and one of the main reasons why teachers do use computers in schools, to easily
keep track of children’s progress.
Another feature teachers appreciate in computer games is their capabilities of repetition.
There are kids that need special teaching methods, for example, children with
autism or low I.Q., that perceive mathematics more realistically, as simple counting.
These children need much more training, through repeating. To help children to derive
the abstract knowledge of “5+3=8”, without referring to books or pens, repetition
is a strong method in teaching.
Furthermore, computers automatically adjust to child’s capabilities by changing level
of difficulty according to the number of the kid’s correct answers. A comment of a
teacher referring to child’s different educational needs was “I like using computers…
Years ago it was ‘we all do the same in class ’. That was not good. ”
Last but not least, teachers using computers in class need their settings, as well as
general class’ results, to be safe from accidental access of children.
2.2 Children
Children of 7 to 8 years old have already been taught addition, subtraction and multiplication
up to 100. They are also taught to distinguish the different Euro banknotes
and coins, as well as to read the clock.
At this age children are not yet taught to use computers and not all of them - if any -
have an easy access to a computer at home. Their knowledge of computers is usually
limited to what the teacher shows them for the needs of a game. All of them can use
2

the mouse and most of them can type numbers, but some have difficulties to undo an
action, such as delete a number using the backspace key.
Apart from computer knowledge the main interest in this age is children’s capability
of understanding math. In general, the main issue is to repeatedly train children in
mathematical operations, so as to help them deduce from their knowledge of counting
the abstract sense of mathematics. Computer games are ideal for this by repeatedly
posing mathematical questions, but they risk from being boring.
Moreover, children do not like what they do not understand. This may apply to everything
a child deals with, including computer games. Referring to this a teacher’s comment
was “When they don’t understand and I am not there to help, they do not like it
any more.”
What really motivates children is competition and award. Implementing competition
in one-user games is a bit difficult, but award can be given in numerous ways. Award
from the teacher or the parents is of course of great importance but beyond of the
scope of a designer. Therefore, other means of award need to be found and incorporated
within the game itself. A usual approach is a “congratulation” text at the end of
the game, but as commented “They (kids) never read this. They just press OK.”
3 Simple and Coherent
“Math for Kids” consists of two parts: The menu, where the teacher chooses the class
she is working with, the child’s name, whether she wants to train, test or go through
the child’s results and the math operation she wants the child to train in; and the game
part, where the child (or teacher) chooses a specific game to start and of course the
games themselves. In both parts the philosophy is to be simple and coherent.
3.1 Menu
The menu was designed as simple as possible. Big buttons are predominantly used in
rational order, so as to minimize the effort and time needed from the teacher to complete
a task [1]. Moreover, we combined selections needed in one page [2] when
possible, so as to avoid having lots of menu pages that would be confusing, time
consuming and difficult to recover from an error done steps back.
Buttons change color after selection in order to have good visibility of selections
done [2]. The color chosen for the menu was a de-saturated blue, while for labels we
used a deep yellow, and black, whenever there was a message of importance to be
displayed, such as the names of the class [3] or the instructions in a tutorial [4].
In order for the system to store children’s results and progress, the teacher has to
select from the begging the child’s name [3]. After selection the name is apparent at
the top right of the screen. This way the kid will not have to enter its name every time
a different game starts. At this same page, there are two more buttons available: one
for adding names, at the start of the year, for example and one to remove names at the
3

end. Although, not functional, the choices of massively entering and removing games
should be also available.
The instructions for a game follow immediately after the selection of the game, presenting
also a picture of the game itself [4]. Because of the number of the game the
teacher has to select among, it is possible that she may not exactly remember the title
of the game she is looking for. The photo that appears with the selection of the game
will help her to quickly browse through the games with out actually entering any.
Labels on buttons were decided with the assistant of the teacher. People prefer to deal
with standardized labels, instead of having to re-learn new ones. In the difficulty
selection, for example, we used the recommended labels. The labels we used, as well
as what they indicate are listed in the following table:
LABELS MEANING
“Makkelijk” Easy Difficulty Level
”Gewoon” Normal Difficulty Level
“Extra” Advanced Difficulty Level
“Plus” Hard Difficulty Level
“Groep” For Class Selection
“Training” Training Mode
“Toets” Test Mode
“Resultaten” Results
“Plus en Min” Addition and Subtraction games
“Tafels” Multiplication Games
“Klok” For games to learn to read the Clock
“Euro” For games where children learn banknotes and coins
The result button is placed in the beginning of the menu for easy access. The train,
test or result mode after being chosen are apparent at the top right of the screen. The
same stands for the class and name of child, which after selection are apparent at the
top left of the screen. Because of the large number of children, the names appear for
selection in the middle of the screen, which serves as the information, instruction and
feedback providing place within the program.
Finally, when the user enters the menu page of the game selection- this is the page
where the children first get involved- the back button is deliberately omitted [5], in
order to prevent kids mistakenly entering the previous pages. The back button is instead
placed at the top right of the screen, discrete for the children but apparent to
teachers.
3.2 Games
A usual problem with computer games for children is assuming kids have computer
skills. Although, kids nowadays get acquainted with computers much earlier than
previous generations, it is very likely that children of such a young age get easily
confused in a game that requires more skills then they have. Moreover, the scope of
“Math for Kids” is not to make children computer experts, but to offer an easy to use
4

tool for the training of mathematics. Therefore, all games are designed to have only
mouse input. Multiple choices are predominantly used [6].
In order to keep the attention of the child, bright colors are used. Furthermore, games
use icons representing things that children are familiar with and trigger their interest,
such as cars, flowers ice-creams. Each game has a single theme, some addressing
more the boys than the girls and some the opposite.
Games are simple. The general idea is to be given an operation such as “5+3=?” and
to choose from a set of possible and available answers by mouse clicking.
Last but not least, the retaining of the child’s motivation is taken much into consideration.
Although implementing competition is difficult in one-user games, the design
of the “Race” game [7] uses a second car, apart from the one the child is “in”. In the
game the child’s car precedes as long as the child answers correctly the questions
posed. Small awards within the game are also implemented. For example, in the
“Bloem” game [8], whenever the child answers right a few times, a water-can waters
the small pots and the flowers grow.
Those techniques are used to motivate and encourage children while playing. However,
the final award at the end of the game is also important. This should not be
something irrelevant with the game, such as a text, but should instead be linked with
the whole game process. For example, in the “Race” game cars reach the final line,
and in the “Bloem” game flowers finally bloom. These are to be shown with the help
of a small movie clip, possibly with sound. Children, after all, like multi modality as
it is more fascinating and enhances their experiences.
4 Results and Evaluation
Because of the nature of the program, that is, the main user group being split in two
equally important subgroups, we will discuss the results of the evaluations in terms of
“teacher’s results” and “children’s results”.
4.1 Teacher’s results
The first evaluation focused on the menu part of the program which is intended for
teacher use only. There was a S.U.S. questionnaire given with questions covering
most aspects of usability. The average score reached 72.5, mainly because of the
design features of “Math for Kids”, such as coherence in button labels and order.
Questions referring to functionality and options availability were scored less, as the
presented prototype at that moment was not yet fully developed.
Teachers were further involved in development and evaluation of both the teacher
and the game part as developed in later stages of the program’s prototype. Their contribution
resulted in changes to both of these parts.
The design of the interface of the program was from the beginning designed as simple
as possible, which resulted to positive reaction towards the program. The grouping of
5

items to be selected was found well implemented. The order of buttons to be presented
followed the task analysis teachers provided:
Choose Class > Choose Child > Choose to train/test/see results
After a teacher’s suggestion the “results” button was added as an extra option in the
main menu at the first page. Another suggestion we had during evaluations is the
omission of the back button in the screen where children choose the particular game
they will play. This feature was also corrected in the further development of the program.
Finally, taking into account that teachers are the experts to comment on children
games, we had 3 primary school teachers to comment on the games for the kids. No
severe comments were made, except one: Among the different games available in the
program, there is one intended to teach children to read the clock. The original idea
was that the child would be given an hour on an analogue clock and it would have to
express the given hour by means of numbers [11].
However, after discussion with the teachers this turned out to be not an adequate
approach for children of that age. The reason was that reading the hour from a digital
clock is not yet taught at that age, and therefore children are not familiar with expressing
the hour by means of numbers. Therefore, instead, we used multiple natural
language expressions for the child to choose the right one from [6].
4.2 Children results
Children were actively involved in the design of the games, which is generally though
to be important 1 . Although the games’ inner structure and function can not efficiently
be evaluated by children, their overall appearance can, at least partly, align with children’s
perception of things. To make this point clear, we will consider an example
taken from the second evaluation’s procedure. The example refers again to the clock
game mentioned above.
It is clear that the structure of the game - that is what the goal will be, what the kids
will have to do and how they will do it - can not be evaluated by children in an efficient
way (within limited time constrains and lack of pedagogic expertise). But, the
actual representation of the clock should depend on how children “see” a clock.
In the second evaluation session at the school we asked 6 children to draw a clock
(amongst other objects to be used in the games as well). Surprisingly, children do not
visualise clocks as we would expect, that is alarm clocks on bedside tables or on the
wall. Instead, the majority of the kids drew them on church towers; which makes
sense, if one considers how many of these characteristic buildings can be found in
Dutch cities.
More of such similarities in drawings were found and were used in the games’ designing.
Moreover, all games were designed to have only mouse input, in order to
avoid frustration of mistyping; a usual problem with children games that assume
typing skills.
6

5 Conclusions and Discussion
Lots of changes were made after teachers’ suggestions and comments on the program’s
prototypes, for example, the addition of the results button in the first page of
the menu [1], so as to enable immediate access and over children’s progress. Instead
the option would be restricted to the end of each test or game and quick supervision
would have been impossible.
Another thing changed was the omission of the back button in the screen of games
selection [4], [5]. The reason for this is that children should not be given the chance
by the program to enter the teacher’s page and change for example the math type or
even watch the whole class’s results of tests etc. Note that this is also the page appeared
after having finished a game. It is therefore a page, in which kids will be entering
numerous times. Instead of the back arrow button, another more discreet button
was added in those pages at the top right of the screen [4].
Other changes made referred to the knowledge of the children at that age; which if
not taken into consideration the result would be a not appropriate game for these kids,
and therefore unusable.
During the developing process of “Math for Kids” we came to the general conclusion
that, although computer games are in general welcome in schools thanks to their
efficiency as teaching tools, they can also fail to be used due to their complexity of
design and their lack to address the actual needs of their user group. It is of high importance
to be in continuous contact with her intended user group, as the evaluations
showed.
Especially, when the artifact is aiming to be used as an educational tool, its requirements
to fulfill are numerous and of equal weight. Teachers’ goals and expectations,
children’s skills, likes and dislikes, as well as the actual role of the games within the
class teaching process must be highly considered. Participatory design can make the
best solutions appear and reveal aspects of the user group’s expectations one might
find hard to imagine from the beginning.
6 Future Work
Because of the limited duration of the project, there are still a lot of things that need
to be completed in “Math for Kids”, in order for it to be ready for use. First on the list
is the functionality of the “adding-deleting-selecting” names page supported by a data
base.
Secondly, there could be all the games added. Of course this would take a long time if
one considers that, up to now “Math for Kids” has buttons available for 38 different
games. If we also take into account the different levels of difficulty this number is
then multiplied by 4, whose outcome can also be multiplied by 4 for the 4 different
classes available in the first page.
7

Sound can also be added in all steps of the program and game stages, in the form of
earcons, providing feedback or as background music tallying with the game process.
Finally, but of high importance are the small movie clips during, and at the end of the
game, that are mend to attract children’s interest and attention, fulfilling their need
for award and encouragement.
6.1 The future in the field
Learning through computers, the so called e-learning, is a still developing but most
promising field. Computer games for school use can be an efficient and productive
tool for teachers in class, whose future can be as impressive as one can imagine.
“The technologies that will vastly change information and communication
are auto stereoscopic display systems, 3D sound, augmented
reality, virtual reality, and portable or wearable ubiquitous information
machines. Through any or all of these technologies, a teacher
can guide or a student can present projects within the node or beyond.”
2
However, there are major concerns on how far this change can go without emerging
drawbacks, which is one of the reasons why many schools avoid the use of computers.
Many believe that computers should not be assigned the role of the unique
tutor nor trigger the isolation of children in class, but instead they should be efficiently
used within the classical teaching method of multiple learning processes.
“We cannot truly transform educational practice for the better
through using new technologies unless we examine the roles the computer
can play in truly stimulating, supporting and favouring innovative
learning interactions that are linked to conceptual development
and improvements in understanding.” 3
Although, juveniles’ processing in learning is mostly based on repetition and rehearsal,
something on which computers are ideal to help at; there is still an imperative
need of a trainer with pedagogic experience to guide this whole process. Moreover,
“..In order for e-Learning to be used as successful means of education,
the pedagogy of a course should be taken under consideration.
The use of technology, although innovative and welcomed, can prove
quite perilous; Technology in e-Learning is important in the way it is
used, rather than how advanced it could be. The unsuccessful implementation
of technology in e-Learning is inevitably linked with the
poor implementation of pedagogy, which would ultimately make e-
Learning unsuccessful as a medium of communicating knowledge.” 4
8

References
1. Alan Dix et al, “Human-Computer Interaction”, 1996, Pearson Education, p. 391
2. http://www.technology.gov/reports/TechPolicy/2020Visions.pdf
3. Ravenscroft, A. (2001). Designing E-learning Interactions in the 21st Century: revisiting
and rethinking the role of theory. European Journal of Education p. 134
4. E.Gavtielidou, “Learning through interactive media”, Dissertation, 2006
Appendix
[1]
9

[2]
[3]
10

[4]
[5]
[6]
11

GAMES’ IDEAS AND DRAWING PROTOTYPES:
[7] [8]
[9] [10]
12

[11]
13

Dobbelrekenen
Marian Maas, Anthony Woudenberg
1 LIACS, Universiteit Leiden, Niels Bohrweg 1, Leiden
mpf.maas@gmail.com, ti83magic@hotmail.com
Geassisteerd door Alexander Nezhinsky & Fons Verbeek
anezhins@liacs.nl, fverbeek@liacs.nl
Hoofdrekenen blijkt voor veel basisschoolleerlingen een groot probleem te zijn. Zelfs in groep 8 blijkt dat
de vaardigheid van het hoofdrekenen vaak nog niet goed genoeg beheerst wordt. Dobbelrekenen
probeert hier verandering in te brengen door middel van een makkelijk te benaderen, snel te begrijpen
spel. Door middel van een prikkelend spel gecombineerd met onderlinge competitie onder de leerlingen
wordt getracht de manier van denken bij hoofdrekenen te stimuleren, en uit te bouwen tot iets natuurlijks,
in plaats van iets geforceerds.
1 Introductie
Hoofdrekenen is een essentieel onderdeel van de basisvaardigheden die een basisschoolleerling
zou moeten beheersen. Helaas blijkt op de middelbare school dat ruim de helft van de
aanwezige brugklassers zelfs de meest elementaire wiskundige begrippen NIET genoeg
beheerst om de nieuwe stof optimaal in zich op te kunnen nemen. Het leek ons daarom een
goed idee om hier een oplossing voor te zoeken, temeer vanwege het feit dat het zusje van één
van ons perfect in de doelgroep past. Gekozen is voor laatstejaarse basisschoolleerlingen, waar
het spel voornamelijk een kwestie van herhaling zou moeten zijn, en op zich geen nieuwe
begrippen leert; getracht wordt om de leerlingen beter hoofdrekenen aan te leren, ze er bekender
mee te maken. Om er geen saaie oefening van te maken is gekozen voor een oud spel,
genaamd Dobbelrekenen.
Dobbelrekenen is een spel dat met vijf dobbelstenen gespeeld wordt. Na een worp zijn drie
dobbelstenen beschikbaar om een opgave mee te maken, terwijl de twee overgebleven stenen
het antwoord bepalen. Uiteraard bestaat met een willekeurige worp niet altijd de mogelijkheid om
tot het juiste antwoord te komen; normaliter wordt er dan benaderd. Omdat het echter onze
bedoeling is dat de kinderen er iets van op steken, hebben wij besloten de kinderen te
verplichten tot een juist antwoord te komen; er is altijd minstens één manier om met de eerste
drie dobbelstenen tot een antwoord te komen dat gevormd wordt door de laatste twee. Er bleek
geen goede manier om te evalueren hoe goed of fout een bepaalde benadering was; deze
manier garandeert een binaire manier van antwoorden; een antwoord is goed, of het is fout.
Afhankelijk van het aantal pogingen en de tijd die de leerlingen er voor nodig hadden na het juist
beantwoorden van een vraag, krijgen ze een highscore toebedeeld. Deze manier van beloning
verschaft een manier van zelfovertreffing, en maakt het mogelijk om scores met andere
leerlingen te vergelijken. De voorspelling is dat de leerlingen zullen proberen steeds sneller tot
een juist antwoord te komen, en zo actief de opgaven maakt.
In dit document wordt dan ook besproken welke problemen we tegenkwamen bij de realisatie van
dit idee, en welke oplossingen we er voor gevonden hebben.

2 Doelgroep en bijbehorende problemen
De gedachte achter Dobbelrekenen is dat de leerlingen het spel in een verloren kwartiertje
kunnen spelen, wanneer ze daar zelf zin in hebben. En hoewel er tegenwoordig op de meeste
scholen computers zijn waar de leerlingen zelfstandig mee op de gang kunnen werken, zijn deze
verre van ideaal. Vanuit de gedachte van de huidige onderwijssituatie zijn de computers
goedkoop, en daarmee verband houdend, rijkelijk oud te noemen. Een van de uitdagingen was
dat we een grafisch interessant product wilden afleveren, dat toch nog speelbaar was op de oude
PII's. Daarbij dienden we ook rekening te houden met de beperkte resolutie; de beeldschermen
zijn net zo oud en beperkt als de systemen die ze begeleiden. Eén van de grootste en meest
opvallende ergernissen op de basisschool bleek dat de beschikbare educatieve programma's
slecht tot niet draaiden op de aanwezige systemen, ondanks de hoge mate van kwaliteit. Heel
duidelijk bleek dat er geen rekening gehouden wordt met de beperkte faciliteiten van de
hedendaagse basisschool. Het was voor ons een niet te negeren doelstelling ons programma
toch op de systemen te kunnen laten draaien, zodat er gewoon gebruik van gemaakt kon worden.
Om de rekenkracht zoveel mogelijk te ontzien, is er tevoren een lijst gemaakt met alle mogelijke
combinaties van worpen waarbij er met de eerste drie dobbelstenen tot een antwoord gekomen
kan worden. Volledig willekeurige worpen moesten namelijk in het beste geval 3, in het slechtste
geval tot wel 20 keer gedaan worden voordat er een goede combinatie gevonden was. Want let
wel; het was nodig exact op de doelstelling uit te komen, benadering was uitgesloten. Deze
herhaling van een vrij CPU-gevoelige functie bleek te omzeilen door tevoren extra
processorkracht toe te passen, en een lijst op voorhand te maken. Aan ruimte is er op de
systemen slechts weinig gebrek, dus hebben we qua time/space-tradeoff gekozen voor een
snellere tijd, ten koste van ruimte.
In het artikel "Teaching with Games; Using commercial off-the-shelf computer games in formal
education." wordt beschreven hoe kinderen onderwezen kunnen worden met behulp van
bepaalde commerciële computerspellen. Een typerend verschijnsel welke hierin niet uitvoerig
behandeld wordt is dat het onderwijzende personeel vaak de software dient te bedienen. Het
blijkt in de praktijk zelfs vaak nodig dat de juf dan wel meester eerst het pakket moet activeren en
instellen, voordat het kind kan spelen. Dit blijkt een contraproductieve manier van aanpak, daar
het kind niet op de computer kan als de juf/meester bezig is met andere zaken. Deze onnodige
vorm van arbeidsintensiviteit hebben we dan ook volledig vermeden door de interface simpel te
houden, zonder ellenlange lijsten met instellingen. Het kind, welke vaak beter overweg kan met
computers dan de leraar, zal hierin niet de weg kwijtraken, en kan zelf het spel spelen als het
daar zin in heeft.
Tijdens het evalueren bleek onder andere dat de door ons in eerste instantie bedoelde aanpak
met alleen de muis niet altijd even goed werkte. Twee kinderen vonden het jammer dat ze
volledig afhankelijk waren van de relatief langzame muis, en niet de mogelijkheid hadden het
toetsenbord te gebruiken. Om tegemoet te komen aan deze vragen, hebben we er uiteindelijk
voor gekozen beide manieren van invoer te implementeren.
3 Aanpak van de problemen
De traagheid van de computers was één van de voornaamste problemen. De grootste
uitdagingen lagen hier dan ook van in het verlengde; je kan het je niet veroorloven een
geheugenlek te hebben in een programma als dit, als het systeem waarop het draait net genoeg
bronnen heeft om het programma draaiende te houden. Elke versie werd dan ook getest op
geheugenlekkages, en of het nog altijd werkte op de P II's. Het bleek bijvoorbeeld in de door ons
gekozen ontwikkelomgeving niet triviaal om een zelfgemaakte cursor te tonen zonder dat daar
elke beeldverversing expliciet intensieve berekeningen voor moeten orden uitgevoerd. Door
middel van een niet gedocumenteerde omweg is het toch gelukt een soepel bewegende muis op

het scherm te krijgen, zonder de schokken die de reguliere methode ons bood.
Een ander probleem dat we tegenkwamen bij de op de school aanwezige programma's, was dat
er op het eerste gezicht geheel niet duidelijk is wat de bedoeling is. Een vlug spelletje zit er bij die
programma's simpelweg niet in. Bij Dobbelrekenen hebben we getracht om uit de interface te
laten blijken wat de bedoeling is. De cursor valt direct op, en ook de knoppen spreken direct voor
zich. Door het toepassen van de Gestalt wetten over perceptie en plaatsing (Johnson & Proctor,
2004) op de knoppen, wordt duidelijk dat er van de speler verwacht wordt een opgave te maken.
Verder is er een duidelijke klok aan de bovenzijde van het scherm, begeleid door een
knippereffect als de tijd bijna op is, laat duidelijk zien dat er een tijdlimiet is. Tot slot bevindt er
zich een venster waarin begeleidende informatie wordt gegeven als de muis over een onderdeel
geplaatst wordt, mocht dit nodig zijn. De "enter"-toets is groter dan de andere knoppen, opdat
deze niet gemist kan worden bij het trachten de snelste tijd neer te zetten. De toetsen om een
nieuw spel te starten en naar het hoofdmenu te gaan zijn vanzelfsprekend duidelijk, en ver van
het speelscherm gepositioneerd om ongewenst aanklikken te voorkomen. Deze staan, niet
toevallig, op exact dezelfde positie als de knoppen in het hoofdmenu, om continuiteit te
garanderen. Tot slot is de flow van het programma van boven naar beneden, als de leesrichting;
bovenaan de vorming van de berekening, onderaan het bevestigen ervan. Dit in
overeenstemming met Norman's Pertinence Model (Ashcraft, 2002).
4 Resultaten en evaluatie
De kinderen hadden commentaar op de kleuren, grootte van knoppen en de wijze waarop de
score berekend werd, welke na de eerste evaluatie dan ook sterk verkleind zijn. In eerste
instantie werd het programma ontwikkeld op een resolutie van 1152x864px, waar alles er goed
uitzag. op de testcomputer bleek uiteraard dat de knoppen explosief toenamen in formaat...
De kritiek was goed te gebruiken om het ontwerp te verbeteren. Natuurlijk waren de gebruikers
niet geheel tevreden met het programma dat we uiteindelijk ontwikkeld hebben, ze zijn immers
wel beter gewend op de computer thuis. Toch is het resultaat van ons onderzoek positief, want
het prototype maakt optimaal gebruik van de aanwezige voorzieningen en dat was het doel. Het
prototype van dobbelrekenen draait momenteel op een basisschool en wordt met voorzichtig
enthousiasme gebruikt. Bij installatie bleek wel dat we de computers overschat hadden,
aangezien er geen muisbesturing op zat. Dit is gelukkig kundig verholpen, waarna de
ingebruikname voorspoedig verliep. Hoezeer de wiskundige vaardigheden van de kinderen erop
vooruit zullen gaan is helaas niet te zeggen, maar het ligt in de lijn der verwachtingen dat ze het
leren door met de cijfers en operatoren te spelen.
5 Conclusie en discussie
referentie
en hci-ers moeten vaker nadenken over de aanweizge faciliteite
Het is nog te vroeg om te kunnen beoordelen of de kinderen op de lange termijn daadwerkelijk
een verhoogde vaardigheid in hoofdrekenen opgedaan hebben, en of dat al dan niet afkomstig is
van dit programma, maar tijdens de twee gedane evaluaties bleek wel dat, nadat de leerlingen
bekend werden met het programma, steeds sneller de opgave konden maken. Waar in het begin
nog meermaals de tijd bijna opraakte, werd er na een klein aantal gedane opgaven al
vooruitgang geboekt. De highscore functie was door de zeer korte tijd tussen de evaluaties
helaas nog niet volledig werkend ten tijde van de tweede user evaluatie, dus het zijn subjectieve
metingen, maar er leken twee curven te zijn. De eerste vooruitgang in tijd was de grootste,
namelijk de tijd die nodig was om de toetsen te vinden met de cursor, en de algehele bedoeling

onder de knie te krijgen. Na deze grote afname in responstijd zagen we dat er meer gelet werd
op de daadwerkelijke bedoeling van het spel, en werden er steeds vaker juiste antwoorden
gegeven in een korter tijdsbestek. Uiteindelijk blijkt de limiet van 30 seconden teveel te zijn, maar
hij is gewoon nodig om in het begin niet direct af te zijn. Voor de gevorderde maakt de tijdslimiet
niet meer uit, en gaat het alleen om de verstreken tijd (welke de score bepaalt!). Deze dubbele
vorm van spelplezier is een gegeven waar we toch wel trots op zijn...
Er is echter ook iets opgevallen waar we minder blij zijn, veel minder blij zelfs. Een heel simpel
wiskundig sommetje leert ons dat er met met twee dobbelstenen maar 36 mogelijke antwoorden
zijn. Verder liggen deze ook nog een tussen de 11 en 66 (ga maar na). Nu is het aantal
antwoorden beperkt, maar het aantal opgaven dat gemaakt kan worden is (mede hierdoor) vele
malen beperkter. De kans dat je met een deling nog valt in het interval van [11,66] EN geen van
beide cijfers van het getal hoger dan een 6 of lager dan een 1 is, is heel erg klein. Veel kleiner
dan de kans dat je dat met een vermenigvuldiging lukt... Evenzo met sommen en verschillen. Bij
het genereren van de lijst hebben we de volgende statistieken gevonden;
///////////////////////////////////////////////////////
// Total amount of equations tried: 3456 //
// Total amount of valid equations found: 483 (=14%) //
// //
// Additions: 312 //
// Subtractions: 74 //
// Multiplications: 371 //
// Divisions: 38 //
///////////////////////////////////////////////////////
Dit is de uitkomst na het proberen van 6*6*6 dobbelsteenconfiguraties, vermenigvuldigd met 4*4
operatoren, inclusief haakjes. De getallen geven weer hoeveel opgaven minstens één of meer
keer die operator bevatten. Hier is heel goed te zien dat de verhouding tussen incrementele
operatoren sterk scheef is ten opzichte van de verkleinende operatoren (- en /). Dit is vanwege
het feit dat de uitkomst een geheel getal moet zijn (de meeste delingen vallen al af), en in het
geval van aftrekken, er op 1 optie na een vermenigvuldiging aan vooraf moet gaan. Bij een
benadering van het te behalen getal zou dit probleem veel minder zijn; ook dit is echter weer een
probleem op zich.
6 Verdieping
Deze versie van Dobbelrekenen is bewust minimaal gehouden, om hem zo efficiënt
mogelijk in de schoolomgeving te kunnen laten gebruiken. Er kan echter nagedacht
worden over een variant voor thuis, die wat meer mogelijkheden biedt, zoals het
bijhouden van een persoonlijke lijst, naast de reguliere highscore lijst die voor alle
gebruikers geldt. Dit vereist echter een vorm van inloggen die we in deze versie niet
wilden gebruiken; het kost meer tijd om een spel te starten, meer ruimte voor de sterk
toegenomen hoeveelheid lijsten, en bleek uiteindelijk niet nodig. Daarbij zou de leraar
moeten ingrijpen als een kind de harde schijf vervuilt met telkens een verschillende
inlognaam; iets waar we niet zonder meer vanuit kunnen gaan dat dat tot de kennis van de
leraar behoort.
Voor deze versie hebben we gekozen voor een heel specifieke doelgroep kinderen, welke
de meest elementaire wiskundige operatoren kent. Helaas behoren machtsverheffingen en
worteltrekken niet tot de stof op basisscholen, wat het aantal opgaven sterk reduceert.

Om het spel wat aantrekkelijker te maken voor een wat ouder publiek, zouden deze twee
operaties toegevoegd kunnen worden. Ook zou er geëxperimenteerd kunnen worden met
het aantal dobbelstenen; zou de oplossing nog te zien zijn met vier dobbelstenen? Of zou
dit teveel zijn om binnen redelijke tijd exact op te kunnen lossen? Er kan nagedacht
worden over een marathon, waar men enkele opgaven maakt, waarna de tijd genotuleerd
wordt. Dit geeft een nauwkeuriger gemiddelde tijd, maar gaat ten koste van het idee dat
je even snel een potje kan doen. Ook hier zou onderzoek naar gedaan kunnen worden, of
het wel wenselijk is.
Bij het eigenhandig testen op de computer verbaasde we ons over het feit dat de muis
enorm gevoelig was voor zelfs maar de kleinste beweging die we maakten. Navraag bij
de leraar leerde ons dat dat de instellingen van de computer waren, maar dat ze geen idee
had hoe dit te veranderen. Een gegeven waar de kinderen al aan gewend leken, maar voor
ons als secundaire testers een gegeven was waar we ons kapot aan zouden ergeren bij
langdurig gebruik. In een applicatie voor gebruik op een basisschool wilden we dan ook
pleiten voor enkele, minder gebruikelijke opties, waaronder dus de gevoeligheid van de
muis. Een simpel schuifbalkje zou zoveel helpen, waardoor zowel het kind als de leraar
op gemakkelijke wijze de spelervaring sterk kan vergroten.
Er kan wellicht zelfs nagedacht worden over een wat volwassener versie, gericht op
volwassenen die het rekenen wat beter moeten gaan beheersen dan ze gewend zijn. We
denken hierbij aan PABO studenten, welke niet lang geleden weer in het nieuws waren
wegens hun beperkte wiskundige kennis, en beginnend(e) caissières en horeca-personeel.
We denken niet dat het een zelfstandig product zou kunnen vormen, maar in combinatie
met andere, kleine programma's zou het wellicht het hoofdrekenen positief kunnen
beïnvloeden.
Bronvermelding
1. Richard Sandford, Mary Ulicsak, Keri Facer and Tim Rudd, Teaching with Games;
Using commercial off-the-shelf computer games in formal education, Futurelab, 2006.
2. Alan Dix et al, Human Computer Interaction (3rd edition), Pearson-Prentice Hall, 2003.
3. Mark H. Ashcraft, Cognition (3rd edition), Pearson-Prentice Hall, 2002.
4. Addie Johnson and Robert W. Proctor, Attention: Theory and practice, Sage
Publications, 2004

PuzzleMath
Tim van Meurs, Ioannis Panagiotou
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
tvmeurs@liacs.nl, bone.jp@gmail.com
supervised by Yun Bei, Fons Verbeek.
ybei@liacs.nl & fverbeek@liacs.nl
Abstract. How do we design interfaces for children? In this paper we discuss
the process of making an educative game for children focused on their mathskills.
Usability and functionality play a big part in this process. The curiosity
of children is an important thing to keep in mind during the creation of a program
like this.

1. Introduction
1.1 A general approach
The last years we see a lot of games for children on the Internet. A lot of the games
do not help the kid to develop any skill, that could help him/her in mathematics and,
in general, most of them do not have any pedagogic purpose. On the other hand, the
games that have a pedagogic purpose or somehow help kids to develop their math
skills, after a while become really boring and children do not want to use them anymore.
1.2 Our approach
Our approach was to create a game that can combine those two things, attractiveness
and education. PuzzleMath is didactic, but in the same time not a boring game
and triggers the attention of the kid. PuzzleMath makes children to improve their
math skills. Fundamentally it helps kids to practice their already knowledge, like
adding, subtracting, multiplying and dividing, so as to start solving problems of multiple
equations and practice mathematical reasoning.
The main game consists with a grid of icons; each icon represents a number which
is “hidden”. Additionally each line and column has a specific given sum. The player
has to calculate the “hidden” numbers, represented by icons, given the position of the
icons in the grid and the sums of each line and column. This way the kid starts getting
acquainted with solving equations, in its effort to calculate the right number that corresponds
to each icon.
1.3 The outline
In this paper we will describe the problems that we encountered during the design
process, our intended user group and its needs. In addition we will demonstrate how
all these play a significant role in our decisions. Finally we will discuss its possible
impacts in future development of didactic games.

2. Math: the headache of kids
2.1 Abstraction of math
We all remember when we were kids ourselves learning math, how difficult it was
to connect the abstract meaning of numbers to something physical and visible – that is
– the difficulty of solving equations is one of the major problems that kids face when
they learn mathematics. They cannot understand the meaning of the “unknown number”
that they have to find in an equation. Generally kids have difficulty in understanding
how to divide, add, multiply or subtract numbers, in order to find something
“unknown”, although that is simply another number.
2.2 User group
Our main user group is consisted of kids from 9 to 10 years old. This is the age
where kids start learning unlimited adding and subtracting, multiplication, division
and the use of brackets (2) . We also focus in kids of higher ages, such as 11 and 12,
because there are a lot of kids in these ages that need help to improve their skills and
apply their already gained knowledge in an easy and fun way.

3. Icons do the work
In PuzzleMath we use icons, which are kid friendly, to represent numbers. We
found that this helps kids to solve equations, because the unknown number is now not
something abstract but something visible. A lot of games (1) use a system like this to
help children in improving their math-skills.
Moreover we tried different types of icons to see which one is more enjoyable for
a kid but in the same time not distracting.
Our design changed completely after our first evaluation. It seems that too much
color does not help kids to focus in the main game area. Moreover, we tried to keep
our game as minimal as possible and focus in it being tangible.
We have put three levels of difficulty: easy, medium and hard. This makes the
game suitable for more children with different levels of math skills. In addition, it
does not get boring but keeps on challenging kids.
We have also put a hint button that reveals the position of each number that is been
filled in as the corresponding number for an icon. This way kids know what is where
and minimize the chance of mistakes and misunderstandings.
Moreover, we have included a tutorial part to help kids to learn how to play the
game.
This way beginners will not have to guess how the game works, but will be properly
introduced in the philosophy of the game.

4 Results and Evaluation
In this section we will walk through different elements of our design and explain
how and why they changed through-out the building of various prototypes. We will
be talking about the first, second and final evaluation. Screenshots of each evaluation
are added in the appendix.
4.1 Buttons
Our first prototype featured a number of buttons with various sizes and colors below
and above the puzzle. Evaluations showed us that the buttons were not perceived
as logical and it took a lot of time for users to find the button they were looking for.
In the second prototype we chose to make one sort of button to use through-out the
program. This turned out to be a gray button that shows an pushing-down effect when
clicked on. The function of the button was shown as text inside the button and a little
icon/picture was added to each button to further clarify the actions.
4.2 Pictures
The pictures used in the first prototype didn't get very good response in the first
evaluation. Kids didn't really like them. So for the second and final prototype we
decided to use our second set of pictures we created for the paper design. These got
better response in the evaluation.
4.3 Hint-system
The biggest problem while making the program was creating a system that could
give hints to players if they were stuck in solving the puzzle. We thought of a number
of different options, of which some were proposed by other students while doing our
presentation. For the first prototype we chose the simplest option to implement, which
was to give the children a number they didn't guess yet as a hint to solve the rest of
the puzzle.
While doing the evaluation we were shown that children are fairly clever in figuring
this out which ended up in users clicking the hint-button 4 times and through that
solving the puzzle. That is why, for the second and final prototype, we chose to make
a system where the numbers that were already filled in were shown in the puzzle over
the pictures. This way, users had a better representation of the numbers in the puzzle
and were able to solve the puzzle more easily without having a system that gives
away correct answers.

4.4 The checking-system
In the puzzle is a button called 'controleer' which is Dutch for 'check'. This is used
to see whether the filled in answers are correct. The first prototype had a button
which didn't do anything unless the puzzle was solved correctly. This lead to frustration
if a user had filled in a wrong answer and the system didn't do anything. Also,
when a user would have figured out an answer but had it wrong, there was no clue to
tell them, so they could be puzzling for several minutes because their first answer was
incorrect. In the second and final prototype we changed the system so that the program
shows the user which answers are correct and which are incorrect so the user
can go back to his/her incorrect answers and check them instead of getting frustrated.
4.5 Menu
We found that the buttons shown below and above the puzzle in the first prototype
were confusing to children. That is why we chose to make a sort of menu on the right
side of the program for the second prototype. In the bottom of the menu were the
same two buttons that always stay there. Above that are the buttons that are used for
that specific part of the program and above that is the info of the player that is using
the program at that point. We found that users can find the buttons more easily when
they are all together in a separate part of the program. To even more clarify the menu
we chose to change the background color of the menu to differ from the backgroundcolor
of the rest of the program in the final prototype.
Overall, we think that through making a first prototype which was kind of a disaster
we could make a second and final prototype which is way better in usage due to
better consistency, color-use, etc.

5 Conclusion and Discussion
We found that it is possible to create in interface for a children's-game that is easy
to use and easy to learn. A user-group of children is both fun and stimulating. They
can do very unexpected things and can be very inventive in finding out stuff.
The choice to use Flash turned out to be a good one. Actionscript supported all the
options we wanted to add and it was easy to use with a background of PHP and C++.
It took some time to figure out some options, but was definitely the right choice for
making a program as we did.
The user evaluations showed us that consistency is important if inexperienced
computer-users use your program. They can more easily find the buttons if they are in
the same place and look the same every time.
We think we created a program that well suits our intended user-group and could
eventually be used in schools.

6 Future Work
We found that teachers and parents of children that used the program are very interested
in the results of the children to see whether they make any progress. An option
for this is to add some functionality which stores info about the time it took to
complete a puzzle and the number of times an answer was checked and the hint was
used in a database. Teachers and parents are then able to see the progress a child
makes and compare this progress to the progress of other kids to see whether they
need extra guidance in their math-skills.
Another option would be to add some extra games in the same kind of interface
where it is again possible to follow children's progress with the same database. This
way, a big program can be created where kids are able to improve their math-skills
and teachers and parents are able to follow their performance.

References
1. Rekenweb – Rekenmaar
http://www.fi.uu.nl/rekenweb/rekenmaar/leerlingen/index.html
2. Wikipedia – rekenen
http://nl.wikipedia.org/wiki/Rekenen
3. Huiswerkweb rekenen
http://www.huiswerkweb.nl/rekenpakket.htm

Appendix
Figures
Prototype 1:
Prototype 2:

Prototype 3 (final):

Mobile Learning
Tiago Borges Coelho, Frank Takes
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
borges@consola.org, ftakes@liacs.nl
supervised by Alexander Nezhinsky, HCI Course Administration
anezhins@liacs.nl & fverbeek@liacs.nl
This project is an attempt to combine the fun that
children experience while playing games on their mobile
phones with the aid of computer programs in the
educational process. We have developed a tool called
‘Mobile Learning’ which allows children in Dutch primary
school to play a game on their mobile phone and
meanwhile learn the English language. Children will
enjoy the application, because it has all the characteristics
of a real game: animation, audio, rewards
and different levels of difficulty.
1 Introduction
Nowadays, virtually every child of age ten and older has
a mobile phone. The specifications of these phones in
terms of CPU power and multimedia capabilities have increased
rapidly over the past few years. This allows
children to play relatively advanced and - in their eyes
- ‘cool’ games on their phones. However, up until now,
these games were mostly aimed at fun, and sometimes skill,
and the field of education has not yet been widely introduced.
We intend to combine the fun of a mobile phone
with the educational process that can be stimulated
through the concept of ‘fun’.
In this paper we will describe the development of ‘Mobile
Learning’, an application for mobile phones that
teaches Dutch children in primary school the English language,
while having fun. We will start with information
regarding both mobile phones and several forms of education,
after which we will evaluate what kind of users we
are aiming at. After the general information mentioned
above, we will elaborate on our application, and provide
some results of the evaluations that we did. We will present
the conclusions of our project, and conclude this
paper with several possible future work topics.

2 ‘‘The mobile phone as an educational
multimedia platform’’
2.1 Games
The fact that children enjoy playing games has been known
for hundreds of years. In addition to the traditional
board games, computer games have become extremely popular
during the last few decades. Relatively recently, a new
dimension has been given to computer games. New mobile
phones have sufficient capacity to play games with color,
animation and sound. This is due to the fact that nowadays
a phone has roughly the same specifications as a six
year old computer. This fairly new fully capable multimedia
platform offers some interesting possibilities.
2.2 Education
Schools and education are extremely important for any
country. Luckily, we live in a country where education is
at quite a high level. Because the standard needs such as
schoolbooks and paper educational material have been
around for such a long time, we can now focus on new media
to increase the education experience. Video and audio
have been in use for several decades, and over the last
ten to fifteen years, personal computer has also been
used for educational purposes 1 . The mobile phone is a new
platform, which has not yet been excessively used to enhance
the educational experience.
2.3 User analysis
Our project aims at children in 7 th
grade of Dutch primary
school. Their age varies between nine and eleven years
old. At this point in their primary education, they start
learning English for the first time. They have not had
any other language courses, and learning a new language
is not a familiar concept to them. Because they hear English
in their every-day world, they are often eager to
learn the language. English is often seen as one of the
more interesting classes, and is the favorite of quite a
few of the more intellectual children. A large portion of
these children already has a mobile phone. We expect that
in the nearby future, almost all of these children will
have a mobile phone with extensive multimedia possibili-

ties. They mainly use their telephones for calling, sending
text messages and playing games.
2.4 Bringing it all together
Our project brings together the three subjects described
above. We give the use of the mobile phone a new dimension,
as children will be able to play educational games
on their phone. They will like the game, because it is
fun to play. In the next section we will try to describe
why our game is ‘fun’ and how we came to our final product.
We will also try to explain why we made certain decisions
during the design of our prototype.
3 ‘‘Learn by playing’’
Our problem statement was how to design an interactive
application for improving child knowledge using the mobile
platform. The human activity to be supported is
learning. Our approach can be described as a Star lifecycle
model, as we wanted to have working prototypes that
were constantly evaluated by the target group. We did
want our tasks to be iterated, as it leads to the refinement
of our product. Moreover our goal was to design an
application that is centered on the user.
As there is not much information pertaining to the design
of mobile teaching applications, our product had to rely
on feedback from the users to refine and improve the user
experience. The result was that our application progressed
immensely from one prototype to the other, as the
feedback received from one prototype was implemented on
the next. This approach and solution for our problem led
to effective evaluation sessions with our target group,
as with the working prototypes the children could effectively
test the product and report on issues like affordability,
visibility and usability.
3.1 Simple and fun to use
Our usability requirements called for a simple and engaging
interface. The learnability of the system had to be
straightforward as our intended audience is notorious for
the lack of patience. Also such a system had to be efficient
in performing the task intended by the users. Fi-

nally the user must have a sense of satisfaction towards
the system.
These goals were reached by the constant improvement of
the system, through the iterated steps of prototyping.
Letting the users review and provide feedback for improvement
was the best solution for implementing our solution,
and making sure it has all the characteristics of
a useful product.
4. Results and Evaluation
Our end product is a mobile application, fully compatible
with cellphones that support Flashlite, the mobile version
of Flash. It conforms to the best practices for mobile
application development as it occupies very little
disk space on the phone, and because all images are vectorial,
it reproduces fast and shows no delays in the
framerate. The use of mobile devices’ native features,
such as the vibrating mode and audio, turned it into
gratifying experience for the user, as it gives visual,
audio and haptic feedback to the user, making for a more
submerging experience.
All of this makes for a satisfying solution for our problem
statement.
These conclusions were reached fundamentally through our
user evaluations and the feedback provided by the assistant
and the colleagues during the development process.
The user evaluations were done in two main sessions. Our
user group consisted of 9 to 11 year old children who are
currently in the 7th grade of primary school and are just
starting to learn the English language. Their native language
is Dutch. We have provided them with a Dutch introductory
presentation on what we were doing, why we were
making the tool, and that we needed their help to test it.
After they were done experimenting with the tool, the
children were given some questions to answer. These were
all related the usability of the system, the affordance
of the buttons and the appearance.
The resulting answers all tended towards a satisfying experience,
with the navigation being deciphered quite immediately,
as the children started pressing all the buttons
to see what happens. Once they spotted the buttons
that afforded actions they immediately started using the
tool as intended, hence the learnability of the system
was a success.
Some issues were presented regarding the overall aspect
of the application, yet this was not common to all users,
and was interpreted by us as divergence in taste.
Strangely the small size of the screen, and consequently

of the GUI was not referenced as an hindrance, probably
due to the habituation for such a constrain. The elements
in the interface were all perceptive, as we strived for
having simple and immediately recognizable shapes, arranged
in such a way as to allow for space between them.
We were also able to test our product during the class
presentation, where we collected feedback from our colleagues,
assistants and teachers. As they were not our
intended target audience, the feedback provided was
mostly subjective impressions. Still some ideas were implemented,
while others were not.
It was suggested that we use the vibration method in a
coherent way, following some methodology. We decided to
have the vibration be more subtle as the user approached
the end. The reason for this was so that the user would
perceive an evolution in the gameplay.
Another suggestion was that by detecting the right answer,
the user could be presented with a voice reading of the
word, a valuable feedback for apprenticeship. Yet we
later discovered that our work platform did not support
the use of audio recordings. Flashlite has limited sound
formats, with MIDI being the standard. As this format
does not support voice sounds it was impossible to implement
this feature.
Also it was suggested that we use some sort of dynamic
recording of a score, so that the user could in the end
be presented with a result. We decided not to implement
this as our objective was not to have an application that
fosters competitiveness, as this can be harmful for child
relationships with one another.
5 Conclusion and Discussion
The goal of our project was to create a fun game for
children in primary school that would teach them the English
language. We think that we succeeded in our goal,
because we got positive results from the children of our
user group. The use of a mobile phone as educational
platform is worth investigating further, as there are
many possibilities in this field of study. There are however
several limitations that have to be kept in mind
when designing educational mobile applications.
There is no QUERTY keyboard available, so you can only
use arrow navigation or number-mapping. In all cases it

should be really clear how the program is to be navigated.
During our evaluations we had quite some problems with
the different kinds of mobile phones. Even though most
phones meet the hardware specifications, not all phones
have the same API when it comes to navigation, sound
playback and visual display. This makes the design of a
real (educational) multimedia application that works on
different kinds of mobile phones hard, because the designer
has to take platform-dependent settings into account.
Yet, with all the limitation mobile phones present features
that are of interest for application developers.
Firstly the portability, which allows users to hold the
device in the hand, and can then carry it anywhere. This
allows for HCI to occur anywhere, and it is something
that can be explored. Secondly all the supporting features
in these devices, such as built-in cameras and
speakers, can be used by any application, allowing for
dynamic interaction between the users and the device. By
using the vibrating function, we brought more interest to
our application, as the users were pleased by this solution.
In conclusion, the mobile platform, aside from all incompatibilities
and constant evolution and change can be an
interesting platform for application development, as it
presents different and effective Input/Output solutions.
6 Future Work
Looking at our specific prototype, we could of course upgrade
our product with additional words. However, a whole
dimension could be given to the program, by having sentences
where the user fills in a certain word. Or the
user could be provided with a sentence, and has to find
the spelling error (if any). This would make the program
not only more interesting, but also more suitable for
older children that already have more experience with the
English language. But our project is only one example of
the many possibilities that the mobile platform offers on
the educational field. It can for example also be used in
mathematics, or as a questionnaire for classes like history,
geography and biology.
As cellphones tend to integrate new technologies and
evolve to process more information and have more resources,
we are constantly thinking of new ways to adapt
this tool to become a teaching platform for people.

References
1. Sandford, Richard et all, FutureLabs (2005). Teaching
with games.

The Music Man
Anton Hunsucker, Sifferina de Jong
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
antipasta@gmail.com, sifferina@gmail.com
supervised by Yun Bei, Fons Verbeek.
ybei@liacs.nl & fverbeek@liacs.nl.
Abstract. We designed a product which will allow children aged 11 or 12 years
old to individually learn about musical concepts in an interactive manner using
the computer. A musical instrument will be unnecessary as it will make use of
the computer keyboard. As children with these ages have a short attention span
and are bored by dull information the program needed ways to be able to retain
attention. We have shown that by chunking the information in small proportions
and keeping it clear and simple children are very well able to keep paying
attention. Also to stimulate them to learn more we used several concepts from
computer games, such as unlocking songs and competitiveness, which has
turned out to be very successful.
1 Introduction
These days a lot of children aged 11 or 12 have no or a little experience in musical
concepts. At that age they don’t mind, but when they get older they pity that they
never learnt more on this subject. A lot of people don’t know much about the different
notes, the score they are on, what they sound like or what they look like. Also
knowledge about different composers and their music is scarce. Therefore we tried to
design a program which will teach children about these basic musical concepts. As
children within this age group are very eager to learn, curious and competitive the
program needed to take advantage of these characteristics.
Also children spend about one and a half hours behind a computer, mostly entertaining
themselves or using it for other purposes such as studying. Children like to spend
their time behind a computer in a social manner, which is, doing it together with a
friend or playing against a friend.¹. Most computer programs designed to teach about
musical concepts are dull and only focus on the things to be taught, they are not designed
for a specific age group but for a specific group that has already decided they
want to learn more about music. Therefore these programs aren’t able to keep children
entertained and to stimulate them to learn more. In this paper we introduce innovative
ways to solve this problem. The program we designed will be a way for children
to learn about music, to stimulate them to learn more about music and to prepare
them for real music lessons when they want to start playing a musical instrument.

Also the program will be a way for parents to check if their child has a talent for
music and likes to play music, before they invest in an expensive instrument of which
they don’t know it will be used for a long time. Firstly we will start by defining our
problem and introducing an extensive user analysis, after that we will give an approach
to solving the problem. Next we will discuss the results and user evaluations
and finally we will draw our conclusion and discuss this.
2 Short Subject Background and problem definition
2.1 Discrepancies in music
Music has been known and enjoyed, in some form or another, by virtually every people
on the planet, since the dawn of history. While it is considered “elementary” or
even “natural” (compare birdsong), music’s principles and inner workings are not –
they require development and understanding of abstract and concepts, which are
certainly not deemed “natural” at first. While listening to music is an experience requiring
a minimal expense of effort on the listener’s behalf, producing music can only
be achieved by skill and training, a time-consuming, cerebral exercise. It is hence not
surprising that only a small portion of listeners are actually able to create music on
their own.
2.2 Learning music at an early age
2.2.1 Introduction
This skill is best fostered at an early age, as is widely known. It is not uncommon for
parents to encourage their children to take piano lessons, for instance. However, as
argued above, learning music, like learning to read and spell, requires the student to
deal with abstract concepts that seem to have little connection with reality at first.
2.2.2 Excerpts from User Analysis
Young children appear mentally ill-equipped for learning these concepts: they have a
short attention span, fewer intellectual capabilities, no knowledge of the mathematics
or physics pertaining to music theory and are generally not accustomed to thinking on
an abstract level. As opposed to an adult striving to learn music, a child has very little
basic knowledge to start with. Furthermore, often are they not studying music of their
own volition.
When using computerized teaching methods, children do have some valuable experience:
most, if not all, are familiar with Windows, have played videogames and are
compelled to use this knowledge in other fields.
2.2.3 Additional issues
Additionally, as music is rarely thought “just” as a concept – most often, it goes handin-hand
with learning to play an instrument. Hence, not only does the student has to
learn a lot of difficult theory, he/she has to overcome the motorical challenges of
mastering the xylophone, piano, or guitar at the same time! Without an instrument,
though, the child would not be able to practice his newly acquired knowledge and it

would remain just a mental concept. This further increases the costs of learning music,
and is a financial obstacle for many a parent. Also, is there an “ideal” instrument for
learning music?
2.3 Challenges in teaching music & alternative methods
All this introduces several unique challenges for the teacher. Difficult, “dry” knowledge
must be circumvented (or thoroughly simplified) at first, until the child’s expertise
has advanced to level deemed adequate for introduction. The child’s musical
learnings should be kept at pace with his/her mastery of the instrument. The child
must persevere in the course of several years in order to be truly acquainted with the
inner workings of music. Often this is accomplished by, for instance, hiring a piano
teacher who teaches the child for several years. While this personal approach deals
with issues such as attention span and allows the student to learn at his/her preferred
pace, it is arguably very expensive, even more so if a piano has to be bought. Sending
children to a music school is more affordable, but reduces the time the teacher can
allot for each child, and individual children risk falling behind. All the while the child
must remain motivated; even more so for self-study, which is certainly the cheapest
possibility.
2.4 (Short) Conclusion
We feel that by using interactive, multimedial teaching techniques in our application
can remedy part of the problem: most children play videogames, or are at least acquainted
with the use of a computer. By incorporating analogous elements (interactivity,
a scoring system, and reward) in our program we strive to keep the student motivated,
and he/she can repeat any part of the course at his/her leisure.
3 Introducing Multimedial and Interactive Teaching Techniques
In order to be able to teach children about musical concepts our program should first
of all correspond to a Windows user environment as children in this age group are
most skilled using Windows. Therefore the buttons in our interface have names that
resemble names of buttons in Internet Explorer. Furthermore we designed our icons
in a way that they resemble icons with a similar meaning in Windows. Also the saving
progress should be automatic, since children of this age can decide in an instance
to exit the program. The program should be able to make children keep paying attention,
and as they have a short attention-span this is difficult. We tried to do this by
chunking the information in small proportions presented in simple comprehensible
language and offering pictures and exercises regularly throughout the theoretical parts.
When children have a difficult time trying to play an exercise they can press a button
for an example and the program will show them how to play the notes, and what it
should sound like.
To make sure children were stimulated to learn more and wouldn’t quit using the
program we tried to introduce aspects from the gaming world into our program. As
children learn more they can unlock more music. This will be a stimulation to learn

more and is a new and innovative way to do so. By finishing a piece or exercise successfully
a popup will appear with the notification that another musical piece has
been unlocked for playing. This will be part of a competitive element in the program
as children can brag about the total number of songs that they have unlocked.
Also children can keep track on their progress in order to be able to compare themselves
with others. With this another competitive element is also incorporated in the
program. Children can thus brag about their achievements to their friends who are
also using the program. Also they can play against each other and compare their mistakes.
This way children can also stimulate each other to try harder on practicing a
specific part of the program. Next to that there is an option in the program where
children can just play and enjoy themselves without having to read about the theoretical
part of making music. In this option we did choose to display the notes played on
the computer’s keyboard so children learn without noticing it. The program is also
designed to make children curious after music they wouldn’t naturally listen to, such
as classical music. An encyclopedia on classical music is included in the program so
they can read about the composer that composed the music they for example have just
unlocked.
The usability requirements we set at the onset of our program were that the software
should be suitable for the task, thus allowing users to complete tasks efficiently without
presenting unnecessary problems or obstacles and since we were dealing with
children this is a very important aspect. Also due to the fact we were dealing with
children our program should be easy to use. It should be easy to learn, intuitive, and
appropriate to the user's abilities which we have stated earlier. We realized this by
giving the program simple controls which are also used on the internet and in Windows,
such as back, next and head menu buttons and selection bars. We also made
sure that playing the notes on the keyboard would be easy, therefore we concluded it
would be best to make use of the piano key configuration since this has been the same
for centuries. We actually did have a problem here, as a computer keyboard isn’t as
wide as a piano keyboard. We had to split the piano keyboard in two and used the
upper two rows of the computer keyboard for the lower part of the piano keys and the
lower two rows of the computer keyboard for the higher part of the piano keys. Also
we chose simple names for other buttons so they would explain themselves through
their name. We also wanted the users to enjoy themselves using the program that it
looked nice and that users would be tranquil and relaxed while using the program as
to create a good learning environment. Important is that users wouldn’t be irritated by
the design of the program.
Another usability requirement is that the system's speed of response to commands and
instructions should be immediately shown on screen, and should be appropriate to the
task and the workers abilities. When a user hits a key or a button there should be
immediate response of the software to show the systems state to the user. A user
should always be able to know in what state a system is to prevent confusion, therefore
feedback is very important. When a button is pressed or a key has been hit something
should happen, we realized this by giving direct response in the shape of a
popup balloon or a sound.

The software should also prevent the users from errors and allow error recovery. The
program doesn’t require save operations as of how far the pupil has progressed in the
program, this is done automatically. Also buttons disappear when they have no function.
When doing an exercise a pupil can press the opnieuw button which will allow
him or her to start over.
4 Results and Evaluation
During the development of our program we have made a lot of adjustments and
changes. These were mostly due to feedback we received from multiple resources and
the result of our user evaluations. When you take a look at our first paper design
(figure 1) you will notice it had a lot of color. One comment on this was that it was
too distracting and looked too cluttered. To keep it a simple and organized learning
environment we then decided to cut back on the colors. When you take a look at the
final prototype (figure 2) it is neat and uncluttered. Also the buttons are child friendly,
it looks like a nice program that you will enjoy to use.
We kept the color scheme of light yellow and blue throughout the program which
takes care of the coherency in the program. This way we minimize on confusion: a
button always has the same colors. To minimize clutter we also cut down on the number
of popups that were used to inform users. The program now only shows a popup
when a song has been unlocked. Where buttons used to stay visible in the old version
when they didn’t have a function, we made sure that now they disappear. Users were
confused by the error sounds they heard when they clicked these buttons, and after a
while it became irritating, since they couldn’t see that a button wasn’t active, they
kept on clicking them and thus hearing the error sound. Another button that was
unclear was the scrollbar. As there was more on a page to be viewed, the use of a
scroll bar was important; we made the scrollbar in the style of the buttons and added a
flashing arrow at the end of a page that reminds users that there is more on a page to
be read.
Since users in our age group are very playful an important aspect in our program is
playfulness. In the first version there wasn’t an opportunity to just hit keys, make
noise and just play. During the user evaluation we found that children missed this
aspect in the program. We have taken care of that by changing the recognition of
notes, which didn’t add much to the program, into free playing. Here users are able to
make noise, but they still learn since the program shows the note they play on the
screen. To make the program more adapted to our users this was an improvement.
A lot of users didn’t understand how to play the notes, which was more due to the
difficulty of the note system itself rather than to the interface itself. We built in an
example button, which can be clicked when users don’t understand how to play the
notes. The program then shows when to play which note and what the tune should
sound like. This makes the program more self-explanatory and more resistant to errors.
Since our program isn’t meant to teach children piano, but more to teach children to
read notes and general musical concepts, we chose not to make an association between
the piano and the computer keyboard in the program. At first this was a little

problematic since children found it hard that the note A wasn’t on the A key on the
computer keyboard, when they progressed with the lessons in the program it became
natural to them. We made the decision not to put the A on the A key because it would
make playing songs on the keyboard very hard when the different notes are scattered
over the keyboard.
The changes we made on behalf of the user requirements turned out to be very successful.
We tested them during user evaluations. The controls were clear; no questions
were raised by using them. The names of the buttons were self-explanatory most
of the times, but in some cases they weren’t clear. We therefore decided to add
mouseovers in the head menu to solve that problem. The system’s speed of response
is perfect. The state of the system is clear all the time. Though the program asks a lot
of processing, it responds well on a computer with the speed of these days. The
measures we have taken to prevent errors also turned to work out well. When an error
has been made it is always possible to return to the last state and start over, which is a
perfect way to learn music. Learning music is done by practicing, making mistakes
and starting over again. Most of the users enjoyed using the program, and were interested
to have it on their home computer. A lot of the children never thought about
taking on music lessons and were motivated, due to the use of the program, to learn
more.
Due to the time we had for this project we weren’t able to finish a progress page, thus
this function has been disabled in the program.
5 Conclusion and Discussion
At the onset of our project we stated that children aged 11 or 12 didn’t know much
about music. This turned out to be true. From the 14 children we asked only one was
taking music lessons and another had had music lessons. Most children weren’t interested
to learn about music. The idea about learning music mostly contains having
lessons at a music school, buying an instrument and thus deciding what instrument to
choose. Also it is an expensive and time consuming activity and a lot of parents aren’t
sure their child will enjoy her- or himself doing it. We have concluded that our program
is a good way to see if a child likes to learn about music and has a talent for it.
Besides that a lot of children don’t know what it is like to learn about music. They
think they don’t like it but after haven spent some time with the program a lot of
children actually were motivated to learn more. Thus by handing them a way of learning
music which uses the right techniques, they are very well able to get motivated
and are even enthusiastic about it. Our program also results in competitiveness between
children who both use the program, which also works stimulating. Users experience
the use of the program as a kind of playing. They know they are learning
something, but enjoy doing it, which is the best way to get into contact with new
things. After finishing the whole curriculum a child should be motivated enough to
take on real music lessons with a real instrument.

6 Future Work
Since we were limited in the time we could spend on the project we couldn’t develop
all the things we first planned. One of these things is building in user profiles. Together
with the progress option in the program this would be a nice new way for users
to compare their progress and to realize more competitiveness through the program as
to stimulate users to learn more and try harder. Also this would make playing together
more fun. The lessons in the program aren’t complete. We only attend to the first
three notes of a music curriculum. To make this program complete it should attend to
at least one whole stave, but a lower and a higher stave would be even better. Another
option that could be built in the program is a way to record the music a user has made,
in paper sheet as well as in a form of music, for example mp3 or midi. A nice option
that would add value to the project would be to build in an option to maintain a database
to which the user can add more music to play with the program.
References
1. http://www.opvoedadvies.nl/computerspel.htm
Appendix
Figures
Music Man!
Leren en Oefenen
Welkom bij Music
Man! Met dit
programma kan je
Liedjes
noten leren lezen,
liedjes leren spelen,
noten leren
Noten Herkennen
herkennen en kennis
maken met
verschillende
bekende
Encyclopedie
componisten.
Maak een keuze
door
op de verschillende
Voortgang
opties te klikken.
Hallo, typ eerst je naam:
OK
Stoppen
Figure 1: old layout of the head menu Figure 2: current layout of the head menu

Music Maestro! – The input of a conducting program for children
Loren Roosendaal and Petr Kresk
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
magicmystery1@hotmail.com and kresk10@post.cz
supervised by Yun Bei, HCI
yunbei@gmail.com
“Music Maestro!” is a conducting program that lets children conduct a virtual orchestra more intuitively
than comparable programs allow. Its aim is to make children feel in charge like Maestros and stimulate a
future interest in the creative and intuitive aspects of music. The program contains two novel interface
features: an input method by motion tracking and a feedback consisting of interactive cartoons. This report
focuses on tracking motion to influence the volume and pace of a virtual orchestra. Our motion tracking
system proves to be more robust for children than conventional input methods such as infrared batons
[1]. Another report by group 22 shows how an output consisting of interactive 3D cartoon instruments can
contribute to experiencing the program. Both novelties were combined to encourage children in musical
expression through physical exercise.
General introduction
The primary goal of “Music Maestro!” is to engage children in the process of expressing their own feelings
about songs through physical exercise, thus encouraging them to continue exploring the world of music in a
playful way. The program tracks motion to influence a virtual 3D orchestra visually and audibly. In the setting
of a beautiful concert hall, cartoon-like instruments characterize the interaction of the child with the
music. The gestures children are used to determine both the pacing and volume. The project does not focus
on factual knowledge or very precise musical skills. The aim of this project is to make the child feel as
though (s)he is conducting an actual piece of music and to stimulate a future interest in the creative and
intuitive aspects of music. The visual feedback of “Music Maestro!” is described in another paper and the
input in this one. The input is a novelty, as more conventional input methods are replaced by intuitive motion
tracking input without requiring any additional input devices, this is especially suited for children that are
about eight years old.
Problem, approach and outline of this paper
Our main research question is how conducting programs for children can be both robust and enjoyable. We
considered an intuitive approach essential, as we don’t expect the children to have prior experience with
similar programs or the desire to study a manual of any kind. We first explain the general background of
conducting programs and why we have chosen our approach for the input. Our solution to our research problem
concerning the input is to use motion tracking for the entire program. This form of input not only allows
for highly intuitive conducting, but it is also used to navigate the actual program, so children can work with
the program easily and autonomously. After an overview of the user evaluation, we will draw conclusions
based on our observations from individual and group sessions with our target group.
2 How can intuitive conducting programs be both robust and enjoyable for children?
New interaction methods for digital music and other multimedia are a hot topic in today’s research community,
and since Nintendo introduced the Wii in 2006 the general public has been introduced to the first steps
towards new forms of digital interaction. We hope our novel methods of multimedia interaction with motion
tracking and interactive cartoons encourage children to explore music.

The background of conducting programs
The conducting programs have so far never been used with bare hands as there was always some extra device
involved. Three technical solutions were found for tools to help the computer to keep track of the input. The
most successful has been the infrared baton (the stick conductors use to lead an orchestra), but there were
also colored gloves and even a jacket. Nintendo introduced the first interactive animated orchestra in 2006.
The jacket was the least successful, as only one article mentions this research tool and this was in
2000 [2]. 16 sensors were put in a conductor’s jacket to track his movements. More efficient methods were
needed for extracting this data.
Gloves of a particular color were worn by a conductor of a virtual orchestra in 1999 to track the
conductor's hands by searching for the color of the gloves via a process known as color thresholding [3].
Once the gloves were extracted from each video frame, further processing determined the instantaneous location
of the gloves. About three years later in 2002, this tracking could be done by inexpensive cameras and
some actual gestures could be recognized [4].
Though the gloves may look as an attractive alternative for tracking actual hand gestures, the most
successful tool in this research is the baton, the same tool a real conductor would have. The infrared baton
was first mentioned for the purpose of conducting devices in 2000 [5]. The positions of the baton and conductor’s
hand were identified in a sequence of images from a pair of cameras, and tracked in 3D space. In
2001 and 2002 an exhibit was held in the house of music Vienna, using an infrared baton to conduct an audio/video
recording of the Vienna Philharmonic [6]. The infrared signal was tracked by a computer and converted
to influence the music output. The system didn’t tolerate bad conducting, so it wasn’t useful for commercial
purposes in every day life. However, it was a successful exhibit until a certain breakthrough was
established in 2004 when a cheap infrared baton was used to make children conduct a virtual orchestra, allowing
the user more freedom for making mistakes with an inexpensive tool [1]. This was also presented in
an exhibit at a museum, but this time for children. As these systems with infrared batons were exhibited, the
feedback had to be attractive. Big screens showed actual footage of a real orchestra. This movie could speed
up or slow down a little as this was the visual output the user would get. Though the exhibit in 2004 was
especially for children at the children’s museum in Boston, the same feedback was given: they used footage
of a real orchestra and no cartoons.
This system with the infrared baton was put into a commercial product by Nintendo in September
2006, the Wii. This little “remote control” is not only used for conducting music, but also for other gaming
activities. The feedback if the Wii consist of an animated hall with cartoon musicians. This is the only animated
concert of which children (actually whole families) are able to influence the tempo. In 2006 the Wii
costs about $250 and could be a “trendsetting” product of which some features are still to be improved.
Figure 1: Exhibit at the Children’s Museum in
Boston in 2004. The input is given by an infrared
baton and the screen shows footage of an actual
orchestra that speeds up and slows down with the
conducted music.
Figure 2: The infrared device Wii by Nintendo shows similar
intentions as “Music Maestro!” but our system uses motion tracking
to enhance more intuitive conducting for children. Though the
Wii uses cartoon characters, we felt their approach was more for a
whole family than for young children on their own.

Why we used motion tracking input
The report of the output group proves that our cartoon instruments supply both enjoyable feedback during the
conducting process and guidamce throughout the entire program, allowing a child to operate the program
autonomously. This report however focuses on the motion tracking input we used in our program. We developed
an input system that, using only a webcam, gathered information about the speed of the gestures and the
width of the gestures being made by the child. As children tend to be very active and experimental while
using the program, no form of traditional conducting input, such as infrared batons [1], is suitable for them.
Because of the rapid changes in the conducting behaviour of the children the response time of the program
had to be fast, otherwise children would overcompensate as they would feel that they’d have to conduct even
slower or even faster since the music wouldn’t respond in time. Gesture tracking systems such as batons [1]
or even full body sensors [2] require too much time to relate a motion/gesture to an intended change in the
music. Another benefit of our input method is the fact that the system and it’s users can be physicaly separated
and as such there’s no risk of breaking any (expensive) devices.
Our target group: children of about eight years old
“Music Maestro!” was developed for children of about eight years old. Though the ages of users may vary
greatly, we focused on these young children.
Eight year old children are in the process of mastering physical skills, and they enjoy playing many
kinds of games. This includes everything from small muscle skills like handling a pencil to large muscle
skills like catching a ball. Because these skills are not yet polished, craft projects often end up messy, for
example with crooked nails and too much glue.
Children at this age are eager to learn and master new knowledge in a playful way. When confronted
with potentially interesting experiences, they are curious and open to new challenges. With their increased
ability to think and reason, they enjoy several types of games with simple rules. They usually start their activities
with bursts of energy and are constantly active. Their emotions, however, change quickly. It is impossible
for them to concentrate on one thing for a long time.
Making friends becomes easier at this age and the children have fun and excitement by playing together.
Interactive communication is very important for their social lives.
Children at this age are often not capable of using computers by using a mouse or keyboard accurately
and proficiently yet. However, they begin to develop their own interests in different areas, among which
music could be an attractive one. Eight year old children do not have much conducting experience and their
conducting gestures are quite different from an expert with musical knowledge. It’s not easy for them to give
accurate rhythmic responses. Here are some characteristics of their conducting behavior:
- Children show a wide range of movements. They like making their own gestures according to their feelings
about the music. Expecting you can restrict them to conduct in a specific way is not realistic.
- When children make beat-like gestures, these beats are often not synchronous with the beats of the music.
This means that children may make repetitive gestures, but these gestures don’t have the same beat as the
original music.
- Children enjoy pushing the limits of how quickly or slowly they can make the orchestra play. It is natural
for children to experiment while conducting. They like changing their gesture speed suddenly either making
it very fast or very slow to see what will happen.
3 Motion tracking and sound stretching
Solutions for the interaction with children
One goal of our project is to provide opportunities for children to practice physical skills that are not too
complex, but still challenging enough. For example swinging arms and positioning hands, without any precise
requirements for the movement of fingers, is likely to be completed successfully even by beginners.
Learning how to conduct our virtual orchestra would be within the range of doable yet challenging tasks for
them. It is probable that the children remember basic and simple rules after a brief and clear intro program.
The music used in our project is simple enough for children to conduct, containing recognizable melodies
(for example popular classical music). A beautiful concert hall with cartoon-like characterized instruments is
attractive for the children, especially if the instruments interact with the conductor. The conducting program
is also suitable for groups (see our user evaluation report, appendix 1). The children have no problem conducting
in turns and watch others; they even encourage each other. Eight year old children get bored or impatient
very easily if the activity is not that attractive. As a result, the user interface must be carefully designed

to not only attract, but also to keep hold of a child’s interest. This requires the input methods to detect the
children’s movements immediately, allowing the output team to show visual feedback in real-time. Also a
special welcome to attract the child’s attention in the first place, would be a smart move. Luckily our motion
tracking setup is perfectly suitable for achieving this.
Technical solutions
Children without any computer skills are able to use our program. Our gesture recognition system should be
robust to their wide range of (unexpected) movements. If this would not be the case, the changes oheard in
the music would sound awkward; noise and stepping artifacts would arise from the rapid changes in volume
and tempo. One way to make this auditory feedback more robust is to set minimum and maximum values for
the speed and volume, for example 30 % difference from the original values. The gestures of the children
usually don’t have the same beat as the original music. Our system adopts a simple velocity-based scheme,
decoupled from the “beats” that children make. This way, children can make their movements in every beat
they like, but the program only looks at the speed and size of their gestures over a short time without paying
much attention to the beat of the individual movements. This means that the speed of the program can not
vary too radically, especially when absolute minimum and maximum values are used for the tempo and volume
of the music. Minimum and maximum values can also be set for relative changes in volume and speed
over a short time. We use this mechanism to smoothly blend between changes in tempo and volume instead
of making radical changes. This way the music stays recognizable without the child loosing much freedom to
experiment.
Conclusions
The complete system feedback is attractive and interactive for children. The output consists of clear real-time
musical feedback and interactive cartoons. The children hear and see immediate response to their actions.
The musical pieces are easily recognized by the children and the method of conducting is experienced as both
intuitive and powerful. The final response time achieved by the input system is much faster then the response
time of the users and as such offers a smooth experience. Both volume and tempo changes are perceivable
within 50 milliseconds at most and are in full effect within around 200 milliseconds, slightly faster then the
average human response time.
The interface is simple and easy to understand. There are only two simple rules to remember concerning
the conducting, that all have immediate feedback and are practiced with physical activities. First rule:
the conducting speed influences the pace. Second rule: the size of the gestures influences the volume. The
rest is understood by simply listening to the cartoon trumpet that guides users through the program. A short
and interactive introduction program is needed to make sure the children understand the possibilities of the
program, especially if they are using it for the first time. Children are generally not capable of remembering a
lot of instructions at once and we wanted to keep the use of our program suitable for their playful attitude.
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. Instead
of giving instructions about the whole program at once, pieces of information are given carefully during
the program with the help of audio, images and physical exercise. That is why we decided to make a cartoon
trumpet introduce the program to children while running it. As soon as somebody comes near the webcam,
the cartoon trumpet asks the child to help the orchestra that needs a conductor. Next the trumpet offers an
introduction program in case the child has no experience with the program. It is possible to conduct music
right away if the webcam tracks no movement. Appendix 3 shows a storyboard with screenshots of the program
to demonstrate this. If the child waves, the introduction begins. This is all the child will hear about the
program in general. All instructions for specific parts of the program are given at those parts themselves. The
task analysis in appendix 2 and especially the storyboard in appendix 3 show the flow of the program that is
designed to give information piece by piece in an enjoyable and interactive way through physical exercise to
appeal to young children.

4 Results and Evaluation
Research setup
Our research took place in two Dutch “fifth grades” (children there usually are eight or nine years old). The
approach of the second user evaluation resembled the first one, except that an improved program was used,
as described in the user evaluation report in appendix 1. We also showed both programs to a whole class to
see group responses and get extra comments. We decided to make a cartoon trumpet to guide the children
through the program while running it, so the children can use the program autonomously. The trumpet’s
instructions are stated in appendix 1 and 3.
Our setup for both user evaluations contained the following features:
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.
- A camera recorded the reactions of the children on our program for further analysis.
- The program was individually tested by two children per user analysis; four in total. The estimated
time for one child to play with the program was about 10 minutes. The children didn’t see each other
conduct and were tested in a quiet separate room.
After the individual tests, the program was taken to two classes for about 15 minutes to see how the children
would respond in groups. About sixty children in total tested the program.
These are the main questions for this user evaluation:
- Is the program attractive and enjoyable for the children?
- Do the children get the general idea of the program, especially influencing volume and tempo?
- Is the response time of the program correct?
- Does the music give clear audible feedback, but does it stay recognizable?
(With “recognizable” is meant that the original version of the music is still obvious, so there are limits to
the change in speed and volume and the sound-stretching works.)
Individual testing
Once the children started interacting with the program, they became less aware of their environment
and started to experiment enthusiastically. The program really captured their attention. Though the
children were enthusiastic during the first evaluation, we found some points that needed
improvement.
- The applause at the end of a song proved to be clear feedback that a song had ended. This
was much nicer for the children than the indication at the bottom of the screen, which also
showed the conducted volume and tempo. They were so much into their playful conducting,
that they did not have the desire for anticipation such as these indication bars allowed.
We were surprised at this, because we thought they would like extra feedback. This was
also suggested at the presentations of the evaluations in class. However, it turned out the
children preferred the program without the bars. The cartoon instruments were enough
visual feedback for them. So we removed the bars from the program, as they distracted the
children.
- One child did not understand that he could choose from more than one song and conducted
the same song three times in a row. The trumpet said there were three songs, but
children often can’t remember a lot of instructions at the same time. So instead of showing
one picture at the time, three pictures are shown in the menu at the same time. The song
that can be chosen is highlighted and presented by the cartoon trumpet.
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of
hearing a beep after choosing a song, the child will be told that the conducting can begin.
- At the beginning the instructions were a little too fast. The cartoon trumpet has to speak a
bit slower.
No problems were experienced with the input and sound components, the children enjoyed their ability to
change the tempo and volume of the music in every possible way.
During the second evaluation the reactions were very positive and the children did not mention anything to
improve. Though we looked for possible improvements in the recordings of the reactions, it really seems like
the comments of the children were sincere. So no improvements were asked for after the second prototype.

Group testing
Both prototypes were tried by thirty children after the individual sessions (three groups of about ten children
at the time). The children tried the program one at the time while the others observed the one that was playing.
New conclusions could be drawn from the observed group behavior.
- Both the general flow of the program and the specific elements were understood very well by the
groups. The children were helping and telling each other what to do. The more chaotic environment
did not decrease the capacity to understand the program. On the contrary: the reactions were more
spontaneous.
- The children seemed more relaxed in groups. On their own the children could look a little tense and
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.
A lot of children felt free to experiment in unexpected manners.
- Both during the individual and the group testing, the children could deal with the program autonomously.
They probably found the instructions clear. Moreover, they seemed to like the program for
the high degree of freedom to experiment with their movements for direct feedback.
- In the groups the children looked both at the screen and at each other.
Conclusions based on the user evaluation
Based on the results of the user evaluations the following conclusions were drawn:
- For children of this age it’s essential to have motion tracking and not gesture recognition, because
they love the feedback they get on their unexpected experimental movements. The children tried all
kinds of unexpected movements, so we are glad to have used motion tracking instead of gesture recognition.
- An extra tempo or volume indication is not appreciated, as children do not pay attention to them,
don’t understand their function or are annoyed by them. We thought the children would like the extra
feedback about tempo, volume and remaining time (this was suggested to us at the presentations
of the user evaluations), but instead we removed the indication bars from our program.
- To our surprise the program is remarkably suitable for groups of children, as children often experience
no extra distraction in the chaos of the remarks of their peers, but encouragement. In this setup,
one child conducts and the others watch. We suspect that an important aspect of the fact that the
others don’t mind watching is the combination of feedback of sound and cartoon characters.
- The children enjoyed the program unanimously. In groups they even shouted how much they liked
the program even though we had not asked any questions. One girl conducted for about 15 minutes
straight– a long time to stay focused for an eight year old. After 15 minutes we had to ask her to stop
and it was only then that she noticed how tired her arms were because of all the conducting.
- And finaly, the most important results for this paper. The instructions by the cartoon trumpet are attractive
and capture the children’s attention, just like the conducting itself. Our method of using a
cartoon to guide children through the program proves to be effective and enjoyable for our target
group. The children went through the program without reading a word; they just listened to the
instructions of the cartoon. The instructions were easily understood by most children and they
enjoyed learning how to use the program. Our research shows that cartoons can be used in
conducting programs for educational purposes and entertainment at the same time. Both the general
flow of the program and the specific elements are easily understood. As soon as a child stands in
front of the webcam, it can deal with the program autonomously because the cartoon trumpet tells
them what to do. The children understood the menu function at once. Little supervision and no extra
instructions our remarks from our side were necessary.
The second prototype of the program was fully understandable and enjoyable for children and there were no
indications that improvements were necessary where HCI was concerned.
5 Conclusion and Discussion
Our main research question is how intuitive conducting programs can be both robust and enjoyable for children.
With “intuitive” is meant in this case that the child can use the program without any prior knowledge of
computers or conducting and that the child can go through the program autonomously without any difficulty.
This means that the program has to be robust, as any average child of about eight years old can understand
and enjoy all the aspects of the program on its own. For this reason the system works with cartoon instruments
that provide simple, enjoyable feedback and guide the children through the program. However, this

paper describes another aspect of the program that makes it both robust and enjoyable: the motion tracking
input system. The child doesn’t need to handle any device and doesn’t have to make specific gestures, which
stimulates the use of a wide range of physical expressions to conduct the music. Because of the fast response
time the children don’t experience any problems selecting menu options or conducting. The sound stretching
used to change the tempo of the music runs smoothly and doesn’t stetch the music too far, which could make
it sound like strange noise rather then music. The entire input system is also robust in that it adapts well to the
environment, even in the case of sudden changes, like turning on a light.
Reactions of about sixty children show that they enjoyed the program unanimously (see the user
evaluation in appendix 1). All main questions for our user evaluation were answered positively with the second
prototype. The program is attractive and enjoyable for our target group. The quick response times are
vital for the enjoyment of the program. The children watch the screen with concentration and eagerly respond
to the combination of music and cartoons. The children intuitively understand the effect of their motions and
gestures and picking a song by waving is easy, while the children can still move around and talk without
triggering the song selection unintentionaly. The children understand and enjoy the conducting of the instruments,
especially in little groups as they like to encourage each other. But on their own they also like to explore
a lot physical activities as they experiment in how to conduct. They have no problem conducting a song
they have already heard. They even enjoy learning the songs, perhaps so they can anticipate the the music
better. In all cases we had to ask the children to stop, as they never seemed to get bored by themselves, at
least not within 15 minutes.
Our overall conclusion about “Music Maestro!” is that it does reach its primary goal to engage children
in the process of expressing their own feelings using songs and through physical exercise. Hopefully
this will encourage them to continue exploring the world of music in a playful way.
Though the results of our research are satisfactory, we there is always room for improvement in the input
department. For example the use of stereovision, which would allow us to detect the depth of the conducting
gestures as an extra component of the input. The detection of some specific gestures that children make intuitively
could also improve their experience, if we had enough time to study and record children in order to
gather these gestures. Moreover, our program had minimum and maximum values, so the feedback would
always be correct and understandable. Do children like that or would they enjoy “messing up” the program?
And how would this affect the educational value of the program? If more detailed music data was made
available to us we could test this by allowing certain instruments to play off key for example.
6 Future Work
Having explored realtime music conducting there is still a wide array of possible expansions and improvements
in this field, such as more advanced gesture and posture recognition; detecting conductors facial expressions
for a major/minor effect on the music and using stereovision to obtain depth information which
could be used to add even more possible factors influencing the music. We believe these techniques hold
great promise, as children showed tended to make faces at the program, showing a wide range of emotions.

References
1. E. Lee, T. M. Nakra, J. Borchers (2004). You’re The Conductor: A Realistic Interactive Conducting
System For Children. New Interfaces for Musical Expression NIME04-68 – NIME04-73.
2. Teresa Marrin Nakra (2000). Inside the Conductor.s Jacket: Analysis, Interpretation and Musical
Synthesis of Expressive Gesture; M.I.T. Media Laboratory Perceptual Computing Section Technical
Report No. 518
3. Michael T. Driscoll (1999). A Machine Vision System for Capture and Interpretation of an Orchestra
Conductor's Gestures; A Thesis Submitted to the Faculty of the Worchester Polytechnic Institute,
Degree of Master of Science in Electrical and Computer Engineering
4. 2002: Paul Kolesnik and Marcelo Wanderley: Recognition, Analysis and Performance with Expressive
Conducting Gestures Proceedings of the International Computer Music Conference, pp. 367–
370. International Computer Music Association.
5. Jakub Segen, Joshua Gluckman, Senthil Kumar (2000). Visual Interface for Conducting Virtual Orchestra
Proceedings of the International Conference on Pattern Recognition (ICPR'00) 1051-
4651/00
6. Jan O. Borchers, Wolfgang Samminger, Max Mtihlhi (2001). Conducting A Realistic Electronic Orchestra;
tJIST 01 Orlando FLA Copyright ACM 2001 1-58113-438 -x/01/11
7. Tian-Shu Wang, Heung-Yeung Shum, Ying-Qing Xu, and Nan-Ning Zheng (2000). Unsupervised
Analysis of Human Gestures; Artificial Intelligence and Robotics Lab, Xi’an Jiaotong University,
Xi’an; H.-Y. Shum, M. Liao, and S.-F. Chang (Eds.): PCM 2001, LNCS 2195, pp. 174–181, 2001
8. Andersen, T. H. 2003. Towards novel DJ interfaces. Proceedings of the NIME 2003 Conference on
New Interfaces for Musical Expression. pp. 30–35.
9. Camurri, A., B. Mazzarino, and G. Volpe. 2003. “Analysis of Expressive Gesture: The EyesWeb
Expressive Gesture Processing Library.” Gesture Workshop 2003 Lecture Notes in Computer Science,
vol. 2915. Genova: Springer, pp. 460–467.
10. Borchers, J., E. Lee, W. Samminger, M. Mühlhäuser (2004). Personal Orchestra: A realtime audio/video
system for interactive conducting. ACM Multimedia Systems Journal Special Issue on
Multimedia Software Engineering, 9(5): 458–465.
11. E. Lee, M. Wolf, J. Borchers (2005). Improving Orchestral Conducting Systems in Public Spaces:
Examining the Temporal Characteristics and Conceptual Models of Conducting Gestures. Proceedings
of the CHI 2005 Conference on Human Factors in Computing Systems. pp. 731–740.
12. Eric Lee, Thorsten Karrer, Jan Borchers (2006). Toward a Framework for Interactive Systems to
Conduct Digital Audio and Video Streams Computer Music Journal 30(1), Spring 2006 – Preprint
Draft February 9.
Appendix
Appendix 1: The user evaluation report of “Music Maestro!”
Appendix 2: Task analysis
Appendix 3: Storyboard of “Music Maestro!”

APPENDIX 1: The user evaluation report of “Music Maestro!”
1 Motivation and plan
Developing a program for children is especially challenging when it comes to this novel application in human
computer interaction. One aspect is choosing the right age for the conducting program, apart from the question
if the program is understandable and enjoyable for the chosen target group. Though documentation is
available on the subjects of mental and physical development of children, only a user evaluation with the
target group will prove if all intentions have been realized. Our target group consists of boys and girls of
about eight years old (the reasons explained in the User Analysis of our Paper Design).
These are the main questions for this user evaluation:
- Is the program attractive and enjoyable for the children?
- Do the children get the general idea of the program, especially influencing volume and tempo?
- Is the response time of the program correct?
- Does the music give clear audible feedback, but does it stay recognizable?
(With “recognizable” is meant that the original version of the music is still obvious, so there are limits
to the change in speed and volume and the sound-stretching works.)
The user evaluations were planned in a Dutch primary school. Our research took place in two Dutch “fifth
grades” (children there usually are eight or nine years old). The approach of the second user evaluation resembled
the first one, except that a slightly different program was used, as will be discussed in chapter 6. We
also showed both programs to a whole class to see responses of groups and get extra comments.
Our setup for both user evaluations contained the following features:
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.
- A camera recorded the reactions of the children on our program for further analysis.
- The program was individually tested by two children per user analysis; four in total. The estimated
time for one child to play with the program was about 10 minutes. The children didn’t see each other
conduct and were tested in a quiet separate room.
- After the individual tests, the program was taken to two classes for about 15 minutes to see how the
children would respond in groups.
2 Instructions
The first part of the evaluation consists of the scope and flow of the program. As we develop a program for
children, a special approach was required. For instance, children are generally not capable of remembering a
lot of instructions at once and we wanted to keep the use of our program suitable for their playful attitude.
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. That
is why we decided to make a cartoon trumpet introduce the program to children while running it. Instead of
giving instructions about the whole program at once, pieces of information are given carefully during the
program with the help of audio, images and physical exercise.
The cartoon trumpet tells the child that an orchestra needs a conductor and asks for help. Next the trumpet
offers an introduction program in case the child has no experience with the program. It is possible to conduct
music right away if the webcam tracks no movement. If the child waves, the introduction begins. This is all
the child will hear about the program in general. All instructions for specific parts of the program are given at
those parts themselves. English instructions given by the trumpet are quoted below. (Note: the actual prototype
of the program had to be in Dutch as the program was tested by Dutch children.)

“Hello, could you help us? We need a conductor for our orchestra. Please stand still if you already know
how this works. In case you haven’t conducted before, we’ll show you how to do it if you wave to us first. So
if you stand still you can begin right away. But we will teach you how to conduct if you wave now.”
The second part of the evaluation deals with specific elements within the interface. We added instructions at
two specific parts of the program: the introduction and the menu.
Quotes of the cartoon trumpet the introduction program:
“Okay, I’ll teach you how to conduct. When you make big movements, I’ll play loud. And when you make
small movements, I’ll play soft music. Try it!”
(The child conducts a little piece of music to practice with the volume.)
“Well done! And now we’ll talk about the tempo. When you move more, the music plays faster. When you
move less, the music plays slower. Let’s practice!”
(The child conducts a little piece of music to practice with the tempo.)
“Great! Please stand still. Now you know how to conduct the orchestra; only those two things you practiced
before will be combined. So if your movements are big and fast, the music will be louder and faster. Now
we’re going to choose a song. You can choose from three: the Mexican Hat Dance, the Bull Fighters’ Song
and the Russian Dance.”
Quotes of the cartoon trumpet in the menu:
“If you want to play the Mexican Hat Dance, you can wave now!”
“Do you want to hear the Bull Fighters’ Song? Please wave!”
“Wave now for the Russian Dance!”
3 Observations
The observations of the user evaluations are listed in two tables below, including the research question for
every number of the task analysis (see appendix 1). After the observations of the first evaluation and comments
on the first prototype, we will discuss the alterations we made for the second prototype. Then the results
of the second user evaluation are shown. The last chapter contains the conclusions about our evaluation
process.

3a Observations Table User Evaluation 1 (see Appendix 1: Revised Task Analysis)
Task Research question Criteria Observations (one boy, nine years old and one girl, eight years old)
1.1 Does the intro screen attract The child looks at the Yes, the children constantly look at the screen. They look quite concentrated and a
the right attention?
screen.
little tense because of the setting of the evaluation. They smile a little.
1.2 Is the response time correct The child gets feed- Yes, the system responds immediately when it tracks movement. The child easily
when a child gets into range? back in range. gets into webcam range.
1.3 Is the welcome by the cartoon The child pays atten- The children pay attention and are curious. In a chaotic setting, it may be better if
nice and comprehensible? tion.
the cartoon trumpet speaks slower. Most text is easily understood though.
1.4 Does the program go to the Immediate response Yes, the program goes to the intro part quickly and fluently, so the child under-
intro part (right after waving)? to the intro program. stands the next step.
1.5 Does the program skip the intro Response in a few This item was not used in the evaluation as the program was new for all children.
and go to the menu?
seconds (no move). However, the skipping of the intro program worked as well as the program itself.
2.1 Is the intro by the cartoon nice The child pays atten- Yes, the children pay attention and in and know they should move when the music
and comprehensible?
tion.
starts.
2.2.1 Does the program track the The child gets imme- In all cases the children experimented with movements. The volume feedback was
size of the movements right? diate volume feedback appropriate and immediate, so the children understood it (max. 100 ms).
2.2.2 Does the program track the The child gets imme- In all cases the children experimented with movements. The tempo feedback was
tempo of the movements right? diate tempo feedback appropriate and immediate, so the children understood it (max. 100 ms).
2.3 Is the menu intro by the car- Child still pays atten- The children pay attention. We don’t know it they truly understand this menu intro,
toon comprehensible?
tion.
because no interaction is required here, but they seem to listen to the cartoon.
3.1 Is the menu choice by the car- The child understands The menu choice itself is very clear, but there was confusion because it was not
toon comprehensible?
what to do.
obvious that the children could choose from three songs.
3.2 Does the program start a song The child gets imme- Yes, the song starts immediately as soon as enough motion is tracked. The child
if the child waves?
diate song feedback. gets direct feedback.
3.3 Does the program handle the The child gets feed- The children made a lot of unsuspected movements to experiment. Luckily the pro-
conducting gestures right? back on movements gram works with motion tracking instead of gesture recognition; works for this age!
3.4 What does the child do at the (Is the child eager for The children are pleased with the applause, which seems a clearer indication of the
end of a song?
a new song?)
ending of a song than the indication bars. They are eager to conduct a next song.
3.5 Does the program interrupt The child gets the This feature was never used by the children during the evaluation. Remarkably,
when the child wants this? wanted interruption. they have no problem conducting a song more than once.
4. Is the transition at the end of Not annoyed by inter- The transition is very smooth. (Also the transition from one user to another was
the program smooth enough? ruptions of program. never a problem during the group evaluation.)
Green = evaluated positively Grey = no reliable result available Red = aspects of the program that need improvement

4 Comments of the children on the first prototype
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic
results. Instead some simple open questions were asked to the children and remarks were noted.
Questions Nr Answers of the children
How did you like the 1 It’s fun!
program? 2 It’s very nice and funny.
Were there some things 1 I really liked the music.
you especially liked? 2 I liked that the cartoons did things when I moved. I liked the last song.
Were there some parts 1 Yes, I did not understand I could choose from different songs.
that made you doubt? 2 Yes, the cartoon spoke a bit fast in the beginning. And these strange
colored bars (tempo, volume) on the bottom of the screen.
Were there some parts 1 This strange thing on the bottom of the screen (the volume and tempo
you didn’t like?
indications that showed how far the song was).
2 I didn’t like the Russian Dance, but I liked the other songs.
The first prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).
The children were not very talkative when it came to the open questions. However, we observed their reactions
during the first evaluation. The children were very positive about the playful interactive elements of our program.
They were shy at the beginning, facing three adults on their own. This was because we observed the children
while they conducted. But once they started interacting with the program, they became less aware of their
unusual environment and started to experiment enthusiastically. The program really captured their attention once
they were not shy anymore. Though the children were enthusiastic during the first evaluation, we found some
points that needed improvement.
5 The first and second prototype
The first prototype was tested on a laptop that was connected with a webcam and additional speakers. This
prototype is available on DVD. It contained the following features:
- A motion tracking system for the input of the program: the position of the movements influenced the
volume and the quantity influenced the tempo.
- An introduction screen with a cartoon trumpet that gave instructions according to the movements.
- An introduction program to experiment with the volume and the tempo separately.
- A menu that was introduced by the trumpet and showed one image about the theme of a song at the
time the song was presented.
- Three songs to choose from the menu and the conduct with tracked movements. There was applause
after each song.
- A virtual orchestra and bars that showed the change in tempo, volume and how much time was left of
the song on the bottom of the screen.
With the observations and remarks of the first evaluation, the following improvements were designed for the
second prototype:
- The applause at the end of a song proved to be clear feedback that a song had ended. This was for the
children much nicer than the indication at the bottom of the screen, which also showed the conducted
volume and tempo. They were so much into their playful conducting, that they did not have the desire
for anticipation such as these indication bars allowed. So we removed the bars from the program, as
they were only distraction for the children.
- One child did not understand that he could choose from more than one song and conducted the same
song three times in a row. The trumpet said there were three songs, but children can often not remember
a lot of instructions at the same time. So instead of showing one picture at the time, three pictures
are shown in the menu at the same time. The song that can be chosen is highlighted and presented by
the cartoon trumpet.
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of hearing a
beep after choosing a song, the child will be told that the conducting can begin.
- At the beginning the instructions were a little to fast. The cartoon trumpet has to speak a bit slower.

3b Observations Table User Evaluation 2 (see Appendix 1: Revised Task Analysis)
Task Research question Criteria Observations
1.1 Does the intro screen attract The child looks at the Yes, the children constantly look at the screen. They look quite concentrated and a
the right attention?
screen.
little tense because of the setting of the evaluation. They smile a little.
1.2 Is the response time correct The child gets feed- Yes, the system responds immediately when it tracks movement. The child easily
when a child gets into range? back in range. gets into webcam range.
1.3 Is the welcome by the cartoon The child pays atten- The children pay attention and are curious. The instructions are easily understood.
nice and comprehensible? tion.
1.4 Does the program go to the Immediate response Yes, the program goes to the intro part quickly and fluently, so the child understands
intro part (right after waving)? to the intro program. the next step.
1.5 Does the program skip the Response in a few This item was not used in the evaluation as the program was new for all children.
intro and go to the menu? seconds (no move). However, they did understand the intro choice, so probably also the skipping.
2.1 Is the intro by the cartoon nice The child pays atten- Yes, the children pay attention and in and know they should move when the music
and comprehensible?
tion.
starts.
2.2.1 Does the program track the The child gets imme- In all cases the children experimented with movements. The volume feedback was
size of the movements right? diate volume feedback appropriate and immediate, so the children understood it (max. 100 ms).
2.2.2 Does the program track the The child gets imme- In all cases the children experimented with movements. The tempo feedback was
tempo of movements right? diate volume feedback appropriate and immediate, so the children understood it (max. 100 ms).
2.3 Is the menu intro by the car- Child still pays atten- The children pay attention. We don’t know it they truly understand this menu intro,
toon comprehensible? tion.
because no interaction is required here, but they seem to listen to the cartoon.
3.1 Is the menu choice by the The child understands The menu choice itself is very clear and the children understand they can choose
cartoon comprehensible? what to do.
from three songs.
3.2 Does the program start a song The child gets imme- Yes, the song starts immediately as soon as enough motion is tracked. The child
if the child waves?
diate song feedback. gets direct feedback.
3.3 Does the program handle the The child gets feed- The children made a lot of unsuspected movements to experiment. Luckily the pro-
conducting gestures right? back on movements gram works with motion tracking instead of gesture recognition; works for this age!
3.4 What does the child do at the (Is the child eager for The children are pleased with the applause. They are eager to conduct a next song.
end of a song?
a new song?)
The feedback bar for volume and tempo allowed for more anticipation.
3.5 Does the program interrupt The child gets the This feature was never used by the children during the evaluation. Remarkably, they
when the child wants this? wanted interruption. have no problem conducting a song more than once.
4. Is the transition at the end of Not annoyed by inter- The transition is very smooth. (Also the transition from one user to another was
the program smooth enough? ruptions of program. never a problem during the group evaluation.)
Green = evaluated positively Grey = no reliable result available

4 Comments of the children on the second prototype
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic
results. Instead some simple open questions were asked to the children and remarks were noted. The children
do not seem to be very inventive in their answers. Luckily observations and records were made about the
children’s behavior to gather more information. Their reactions were very positive and they did not mention
anything to improve. Though we looked for possible improvements in the records of the reactions, it really
seems like the comments of the children were sincere. So no improvements were asked for after the second
prototype.
Questions Nr Answers of the children
How did you like the 1 Yes, it’s really fun!
program? 2 It’s a lot of fun!
Were there some things 1 I liked the cartoons and what they did when I moved.
you especially liked? 2 I liked that I could move to make things happen. The applause is nice.
Were there some parts 1 No, I understood everything.
that made you doubt? 2 No, there were not.
Were there some parts 1 No, I liked everything.
you didn’t like? 2 No.
The second prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).
6 Group behavior
Both prototypes were tried by thirty children (three groups of about ten children at the time). So the program
was tested by sixty children in total. This happened after the individual testing. We do not add another observations
or comments table, because the children tried the program one at the time while the others observed
the one that was playing. The remarks of the individuals in the groups were like the ones obtained by individual
testing. However, some new conclusions could be drawn from the group behavior.
- Both the general flow of the program and the specific elements were understood very well by the
groups. The children were helping and telling each other what to do. The more chaotic environment
did not decrease the capacity to understand the program. On the contrary: the reactions were more
spontaneous.
- The children seemed more relaxed in groups. On their own the children could look a little tense and
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.
A lot of children felt free to experiment in unexpected manners.
- Both during the individual and the group testing, the children could deal with the program autonomously.
They probably found the instructions clear. Moreover, they seemed to like the program for
the high degree of freedom to experiment with their movements for direct feedback.
- In the groups they looked both at the screen and at each other.
7 Analysis
For children of this age it’s essential to have motion tracking and not gesture recognition, because they love
the feedback they get on their unexpected experimental movements. The children tried all kinds of unexpected
movements, so we are glad to have used motion tracking instead of gesture recognition. An extra
tempo or volume indication is not appreciated, as children do not pay attention to them, don’t understand
their function or are annoyed by them. To our surprise the program is remarkably suitable for groups of children,
as children often experience no extra distraction in the chaos of the remarks of their peers, but encouragement.
The instructions by the cartoon trumpet are attractive and capture their attention, just like the conducting
itself. Both the general flow of the program and the specific elements are easily understood. As soon
as a child stands in front of the webcam, it can deal with the program autonomously because the cartoon
trumpet tells what to do. In the second evaluation, the children understood the menu function very well at
once. Little supervision and no extra instructions our remarks from our side were necessary. The second
prototype of the program was fully understandable and enjoyable for children and there were no indications

that improvements were necessary where HCI was concerned. However, we could think about three alterations
that could increase the enjoyment of the visual feedback, but we not sure to realize them. The instruments
can provide a more realistic output by connecting them to specific areas within the spectrum of the
music. The lights could dim and spotlights shine to increase the suspense of the scene. We could also create
five instruments instead of three to make the visual feedback more fun.

APPENDIX 2: Task analysis
Both prototypes have this task decomposition. The second prototype is practically the final product, as the
user evaluation showed little to improve.
Task decomposition
0. conduct virtual orchestra of “Music Maestro!”
1. start program
1.1 pay attention to introduction screen
1.2 get into webcam range
1.3 listen to cartoon
1.4 wave or move
1.5 stand still
2. go through intro program
2.1 listen to cartoon
2.2 experiment with conducting orchestra
2.2.1 pace gestures for volume music
2.2.2 size gestures for speed music
2.3 listen to cartoon
3. conduct orchestra
3.1 listen to cartoon
3.2 wave to choose song
3.3 make correct movements
3.4 after song return to menu
3.5 stand still to interrupt song
4. stop program; go out of range webcam
Plan 0.
Do 1
Plan 1.
If user is inexperienced
1.1 – 1.2 – 1.3 – 1.4
If user is experienced
1.1 – 1.2 – (1.3 –) 1.5
Plan 2.
2.1 – 2.2 – 2.3
Plan 2.5.
2.2.1 – 2.2.2
Plan 3.
3.1 => 3.2 => 3.3 => when 3.4 OR 3.5 => back to 3.1
Note: it the webcam receives no motion for a little while, it will go to the menu (3.5).
If it receives no motion for a longer while (for example because the child walked away), the introduction
screen appears (4).
This task decomposition resulted in the hierarchical task analysis on the next page.

APPENDIX 3: Storyboard of “Music Maestro!”
Page 1 - the numbers in the text boxes refer to the task analysis of appendix 2
1.1 – 1.2 Nobody stands in front of the webcam
the right way: the welcome screen shows a cartoon
trumpet that moves a little. A child pays
attention and comes closer. As soon as a child
gets in front of the webcam the program uses this
information to gain the child’s interest.
1.4 The child waves or moves and the introduction
program starts (2.1).
2.1 – 2.2 – 2.2.1 The introduction program: the
cartoon trumpet says: “Okay, I’ll teach you how to
conduct. When you make big movements, I’ll play loud.
And when you make small movements, I’ll play soft
music. Try it!” The child hears a piece of music
and experiments with the volume.
1.3 The cartoon explains the purpose of the program:
“Hello, could you help us? We need a conductor
for our orchestra. Please stand still if you already
know how this works. In case you haven’t conducted
before, we’ll show you how to do it if you wave to us
first. So if you stand still you can begin right away. But
we will teach you how to conduct if you wave now.”
1.5 The child doesn’t move. The introduction
program is skipped and the optional songs are
shown (3.1).
2.2 – 2.2.2 After the experiment with the volume
the cartoon trumpet says: “Well done! And now
we’ll talk about the tempo. When you move more, the
music plays faster. When you move less, the music
plays slower. Let’s practice!” The child hears a
piece of music and experiments with the tempo.

APPENDIX 3: Storyboard of “Music Maestro!”
Page 2 - the numbers in the text boxes refer to the task analysis of appendix 2
2.3 The cartoon trumpet says: “Great! Please stand
still. Now you know how to conduct the orchestra; only
those two things you practiced before will be combined.
So if your movements are big and fast, the music
will be louder and faster. Now we’re going to choose a
song. You can choose from three: the Mexican Hat
Dance, the Bull Fighters’ Song and the Russian
Dance.” The program goes to 3.1
3.2 The child waves or moves when the preferred
song is pointed out by the icons and announced
by the cartoon trumpet.
3.4 – 3.5 When the song ends or in case the child
stands still (and doesn’t conduct) the program
goes back to the song menu automatically.
3.1 The song menu is shown with three icons that
are pointed out one by one every time they are
introduced by the cartoon trumpet: “If you want to
play the Mexican Hat Dance, you can wave now! Do
you want to hear the Bull Fighters’ Song? Please
wave! Wave now for the Russian Dance!”
3.3 The cartoon trumpet says the child can conduct.
The music begins. The child influences the
volume and tempo by moving in front of the
webcam.
4. If the camera does not detect any motion for
some time, the welcome screen is shown and the
program is ready to start the process again.

Music Maestro! – The feedback of a conducting program for children
Karen Sam and Xuan Wang
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
karensam@hotmail.com, colleewx@hotmail.com
supervised by Yun Bei, HCI
yunbei@gmail.com
“Music Maestro!” is a conducting program that lets children conduct a virtual orchestra more intuitively
than comparable programs allow. Its aim is to make children feel in charge like Maestros and stimulate a
future interest in the creative and intuitive aspects of music. The program contains two novel interface
features: an input method by motion tracking and a feedback consisting of interactive cartoons. This report
about the output focuses on the 3D cartoon instruments that change in volume and pace to characterize
the interaction between child and music. We show how interactive cartoons give enjoyable and attractive
feedback in this conducting program for children. The report about the input proves our motion tracking
system to be more robust than conventional input methods such as infrared batons [1]. Both novelties
were combined to encourage children in musical expression through physical exercise.
1 Introduction
General introduction
The primary goal of “Music Maestro!” is to engage children in the process of expressing their own feelings
of songs through physical exercise, thus encouraging them to continue exploring the world of music in a
playful way. The program tracks motion to influence a virtual 3D orchestra visually and audibly. In the setting
of a beautiful concert hall, cartoon-like instruments characterize the interaction of the child with the
music. The gestures children are used to determine both the pacing and volume. The project does not focus
on factual knowledge or very precise musical skills. The aim of this project is to make the child feel as
though (s)he is conducting an actual piece of music and to stimulate a future interest in the creative and intuitive
aspects of music. The input of “Music Maestro!” is described in another paper and the feedback in this
one. The feedback is a novelty, as more conventional output methods are replaced by playful cartoon characters
especially for children of about eight year old.
Problem, approach and outline of this paper
Our main research question is how conducting programs for children can be both robust and enjoyable. We
considered an intuitive approach essential, as we don’t expect the children to have prior experience with
similar programs or the desire to study a manual of any kind. We first explain the general background of
conducting programs and why we have chosen our approach for the visual feedback. Our solution to our
research problem concerning the visual feedback is to use cartoon instruments. These cartoon instruments are
not only enjoyable for children, but also guide them through the program, so children can work with the
program autonomously. After an overview of the user evaluation, we will draw conclusions based on our
observations from individual and group sessions with our target group.
2 How can intuitive conducting programs be both robust and enjoyable for children?
New interaction methods for digital music and other multimedia are a hot topic in today’s research community,
and since Nintendo introduced the Wii in 2006 the general public has been introduced to the first steps
towards new forms of digital interaction. We hope our novel methods of multimedia interaction with motion
tracking and interactive cartoons encourage children to explore music.

The background of conducting programs
The conducting programs have so far never been used with bare hands as there was always some extra device
involved. Three technical solutions were found for tools to help the computer to keep track of the input. The
most successful has been the infrared baton (the stick conductors use to lead an orchestra), but there were
also colored gloves and even a jacket. Nintendo introduced the first interactive animated orchestra in 2006.
The jacket was the least successful, as only one article mentions this research tool and this was in
2000 [2]. 16 sensors were put in a conductor’s jacket to track his movements. More efficient methods were
needed for extracting this data.
Gloves of a particular color were worn by a conductor of a virtual orchestra in 1999 to track the
conductor's hands by searching for the color of the gloves via a process known as color thresholding [3].
Once the gloves were extracted from each video frame, further processing determined the instantaneous location
of the gloves. About three years later in 2002, this tracking could be done by inexpensive cameras and
some actual gestures could be recognized [4].
Though the gloves may look as an attractive alternative for tracking actual hand gestures, the most
successful tool in this research is the baton, the same tool a real conductor would have. The infrared baton
was first mentioned for the purpose of conducting devices in 2000 [5]. The positions of the baton and conductor’s
hand were identified in a sequence of images from a pair of cameras, and tracked in 3D space. In
2001 and 2002 an exhibit was held in the house of music Vienna, using an infrared baton to conduct an audio/video
recording of the Vienna Philharmonic [6]. The infrared signal was tracked by a computer and converted
to influence the music output. The system didn’t tolerate bad conducting, so it wasn’t useful for commercial
purposes in every day life. However, it was a successful exhibit until a certain breakthrough was
established in 2004 when a cheap infrared baton was used to make children conduct a virtual orchestra, allowing
the user more freedom for making mistakes with an inexpensive tool [1]. This was also presented in
an exhibit at a museum, but this time for children. As these systems with infrared batons were exhibited, the
feedback had to be attractive. Big screens showed actual footage of a real orchestra. This movie could speed
up or slow down a little as this was the visual output the user would get. Though the exhibit in 2004 was
especially for children at the children’s museum in Boston, the same feedback was given: they used footage
of a real orchestra and no cartoons.
This system with the infrared baton was put into a commercial product by Nintendo in September
2006, the Wii. This little “remote control” is not only used for conducting music, but also for other gaming
activities. The feedback if the Wii consist of an animated hall with cartoon musicians. This is the only animated
concert of which children (actually whole families) are able to influence the tempo. In 2006 the Wii
costs about $250 and could be a “trendsetting” product of which some features are still to be improved.
Figure 1: Exhibit at the Children’s Museum in
Boston in 2004. The input is given by an infrared
baton and the screen shows footage of an actual
orchestra that speeds up and slows down with the
conducted music.
Figure 2: The infrared device Wii by Nintendo shows similar
intentions as “Music Maestro!” but our system uses motion tracking
to enhance more intuitive conducting for children. Though the
Wii uses cartoon characters, we felt their approach was more for a
whole family than for young children on their own.

Why we used our visual feedback
The report of the output proves our motion tracking system is more robust than any infrared device for conducting,
especially when used by children. This report however focuses on the animated feedback that accompanies
the conducted music. If Nintendo has developed a virtual orchestra for conducting, why should
we bother to make our own animated feedback?
First of all, we feel that the orchestra of the Wii is rather for the whole family and not especially for
young children; it’s a compromise. The animation resembles a normal concert hall and the movements and
characters are less explicit than we intended to make them to capture the attention of children. We decided to
make the instruments characters themselves in a magical scene.
Second, and most important, we wanted to avoid conventional menu options where reading and user
experience are usually required. Our program requires no reading and no prior knowledge about the program
or menu options. A cartoon instrument guides the child through the program step by step with audio feedback.
Our target group: children of about eight years old
“Music Maestro!” is developed for children of about eight years old. Though the ages of users may vary
greatly, we focused on these young children.
Eight year old children are in the process of mastering physical skills, and they enjoy playing many
kinds of games. This includes everything from small muscle skills like handling a pencil to large muscle
skills like catching a ball. Because these skills are not yet polished, craft projects often end up messy, for
example with crooked nails and too much glue.
Children at this age are eager to learn and master new knowledge in a playful way. When confronted
with potentially interesting experiences, they are curious and open to new challenges. With their increased
ability to think and reason, they enjoy several types of games with simple rules. They usually start their activities
with bursts of energy and are constantly active. Their emotions, however, change quickly. It is impossible
for them to concentrate on one thing for a long time.
Making friends becomes easier at this age and the children have fun and excitement by playing together.
Interactive communication is very important for their social lives.
Children at this age are often not capable of using computers by using a mouse or keyboard accurately
and proficiently yet. However, they begin to develop their own interests in different areas, among which
music could be an attractive one. Eight year old children do not have much conducting experience and their
conducting gestures are quite different from an expert with musical knowledge. It’s not easy for them to give
accurate rhythmic responses. Here are some characteristics of their conducting behavior:
- Children show a wide range of movements. They like making their own gestures according to their feelings
about the music. Expecting you can restrict them to conduct in a specific way is not realistic.
- When children make beat-like gestures, these beats are often not synchronous with the beats of the music.
This means that children may make repetitive gestures, but these gestures don’t have the same beat as the
original music.
- Children enjoy pushing the limits of how quickly or slowly they can make the orchestra play. It is natural
for children to experiment while conducting. They like changing their gesture speed suddenly either making
it very fast or very slow to see what will happen.
3 Interactive cartoons guide children step by step
Solutions for the interaction with children
One goal of our project is to provide opportunities for children to practice physical skills that are not too
complex, but still challenging enough. For example swinging arms and positioning hands, without any precise
requirements for the movement of fingers, is likely to be completed successfully even by beginners.
Learning how to conduct our virtual orchestra would be within the range of doable yet challenging tasks for
them. It is probable that the children remember basic and simple rules after a brief and clear intro program.
The music used in our project is simple enough for children to conduct, containing recognizable melodies
(for example popular classical music). A beautiful concert hall with cartoon-like characterized instruments is
attractive for the children, especially if the instruments interact with the conductor. The conducting program
is also suitable for groups (see our user evaluation report, appendix 1). The children have no problem conducting
in turns and watch others; they even encourage each other. Eight year old children get bored or impatient
very easily if the activity is not that attractive. As a result, the user interface must be carefully designed
to not only attract, but also to keep hold of a child’s interest. This requires the cartoon characters to respond

to the children’s movements immediately, showing visual feedback in real-time. Also a special welcome to
attract the child’s attention in the first place, would be a smart move. Cartoons are very suitable for this purpose.
Technical solutions
Children without any computer skills are able to use our program. Our gesture recognition system should be
robust to their wide range of (unexpected) movements. If this would not be the case, the size and movements
of the instruments would look awkward; some parts of instruments would become too big and the movements
too nervous. One way to make this visual feedback more robust is to set minimum and maximum values for
the speed and volume, for example 30 % difference from the original values. The gestures of the children
usually don’t have the same beat as the original music. Our system adopts a simple velocity-based scheme,
decoupled from the “beats” that children make. This way, children can make their movements in every beat
they like, but the program only looks at the speed and size of their gestures over a short time without paying
much attention to the beat of the individual movements. This means that the speed of the program can not
vary too radically, especially when absolute minimum and maximum values are used for the speed and volume
of the cartoons. Minimum and maximum values can also be set for relative changes in volume and speed
over a short time. This way the instruments stay easily recognizable and aesthetically pleasing without the
child loosing much freedom to experiment.
Conclusions
The visual feedback is attractive and interactive for children. The output consists of interactive cartoons and
clear real-time musical feedback. The children see and hear immediate response to their actions. The cartoons
appear on a screen and look like the 3D cartoons children are used to. The cartoons make little movements to
attract attention. The screenshots in the storyboard of appendix 3 give an idea how the cartoon instruments
give visual feedback in the program; only in the program they move and blink with their eyes to make a more
realistic and friendly impression.
The interface is simple and easy to understand. There are only two simple rules to remember concerning
the conducting, that all have immediate feedback and are practiced with physical activities. First rule:
the conducting speed influences the pace. Second rule: the size of the gestures influences the volume. The
rest is understood by simply listening to the cartoon trumpet that guides users through the program. A short
and interactive introduction program is needed to make sure the children understand the possibilities of the
program, especially if they are using it for the first time. Children are generally not capable of remembering a
lot of instructions at once and we wanted to keep the use of our program suitable for their playful attitude.
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. Instead
of giving instructions about the whole program at once, pieces of information are given carefully during
the program with the help of audio, images and physical exercise. That is why we decided to make a cartoon
trumpet introduce the program to children while running it. The cartoon trumpet always moves a little to keep
the attention in a subtle way. As soon as somebody comes near the webcam, the cartoon trumpet asks the
child to help the orchestra that needs a conductor. Next the trumpet offers an introduction program in case the
child has no experience with the program. It is possible to conduct music right away if the webcam tracks no
movement. Appendix 3 shows a storyboard with screenshots of the program to demonstrate this. If the child
waves, the introduction begins. This is all the child will hear about the program in general. All instructions
for specific parts of the program are given at those parts themselves. The task analysis in appendix 2 and
especially the storyboard in appendix 3 show the flow of the program that is designed to give information
piece by piece in an enjoyable and interactive way through physical exercise to appeal to young children.
4 Results and Evaluation
Research setup
Our research took place in two Dutch “fifth grades” (children there usually are eight or nine years old). The
approach of the second user evaluation resembled the first one, except that an improved program was used,
as described in the user evaluation report in appendix 1. We also showed both programs to a whole class to
see group responses and get extra comments. We decided to make a cartoon trumpet to guide the children
through the program while running it, so the children can use the program autonomously. The trumpet’s
instructions are stated in appendix 1 and 3.
Our setup for both user evaluations contained the following features:

- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.
- A camera recorded the reactions of the children on our program for further analysis.
- The program was individually tested by two children per user analysis; four in total. The estimated
time for one child to play with the program was about 10 minutes. The children didn’t see each other
conduct and were tested in a quiet separate room.
After the individual tests, the program was taken to two classes for about 15 minutes to see how the children
would respond in groups. About sixty children in total tested the program.
These are the main questions for this user evaluation:
- Is the program attractive and enjoyable for the children?
- Do the children get the general idea of the program?
- Do the children understand how to choose a song?
- Do the children understand and enjoy the conducting of the instruments?
Individual testing
Once the children started interacting with the program, they became less aware of their environment
and started to experiment enthusiastically. The program really captured their attention. Though the
children were enthusiastic during the first evaluation, we found some points that needed
improvement.
- The applause at the end of a song proved to be clear feedback that a song had ended. This
was much nicer for the children than the indication at the bottom of the screen, which also
showed the conducted volume and tempo. They were so much into their playful conducting,
that they did not have the desire for anticipation such as these indication bars allowed.
We were surprised at this, because we thought they would like extra feedback. This was
also suggested at the presentations of the evaluations in class. However, it turned out the
children preferred the program without the bars. The cartoon instruments were enough
visual feedback for them. So we removed the bars from the program, as they distracted the
children.
- One child did not understand that he could choose from more than one song and conducted
the same song three times in a row. The trumpet said there were three songs, but
children often can’t remember a lot of instructions at the same time. So instead of showing
one picture at the time, three pictures are shown in the menu at the same time. The song
that can be chosen is highlighted and presented by the cartoon trumpet.
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of
hearing a beep after choosing a song, the child will be told that the conducting can begin.
- At the beginning the instructions were a little too fast. The cartoon trumpet has to speak a
bit slower.
During the second evaluation the reactions were very positive and the children did not mention anything to
improve. Though we looked for possible improvements in the recordings of the reactions, it really seems like
the comments of the children were sincere. So no improvements were asked for after the second prototype.
Group testing
Both prototypes were tried by thirty children after the individual sessions (three groups of about ten children
at the time). The children tried the program one at the time while the others observed the one that was playing.
New conclusions could be drawn from the observed group behavior.
- Both the general flow of the program and the specific elements were understood very well by the
groups. The children were helping and telling each other what to do. The more chaotic environment
did not decrease the capacity to understand the program. On the contrary: the reactions were more
spontaneous.
- The children seemed more relaxed in groups. On their own the children could look a little tense and
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.
A lot of children felt free to experiment in unexpected manners.
- Both during the individual and the group testing, the children could deal with the program autonomously.
They probably found the instructions clear. Moreover, they seemed to like the program for
the high degree of freedom to experiment with their movements for direct feedback.
- In the groups the children looked both at the screen and at each other.

Conclusions based on the user evaluation
Based on the results of the user evaluations the following conclusions were drawn:
- For children of this age it’s essential to have motion tracking and not gesture recognition, because
they love the feedback they get on their unexpected experimental movements. The children tried all
kinds of unexpected movements, so we are glad to have used motion tracking instead of gesture recognition.
- An extra tempo or volume indication is not appreciated, as children do not pay attention to them,
don’t understand their function or are annoyed by them. We thought the children would like the extra
feedback about tempo, volume and remaining time (this was suggested to us at the presentations
of the user evaluations), but instead we removed the indication bars from our program.
- To our surprise the program is remarkably suitable for groups of children, as children often experience
no extra distraction in the chaos of the remarks of their peers, but encouragement. In this setup,
one child conducts and the others watch. We suspect that an important aspect of the fact that the
others don’t mind watching is the combination of feedback of sound and cartoon characters.
- The children enjoyed the program unanimously. In groups they even shouted how much they liked
the program even though we had not asked any questions. One girl conducted for about 15 minutes
straight– a long time to stay focused for an eight year old. After 15 minutes we had to ask her to stop
and it was only then that she noticed how tired her arms were because of all the conducting.
- And finaly, the most important results for this paper. The instructions by the cartoon trumpet are attractive
and capture the children’s attention, just like the conducting itself. Our method of using a
cartoon to guide children through the program proves to be effective and enjoyable for our target
group. The children went through the program without reading a word; they just listened to the instructions
of the cartoon. The instructions were easily understood by most children and they enjoyed
learning how to use the program. Our research shows that cartoons can be used in conducting programs
for educational purposes and entertainment at the same time. Both the general flow of the
program and the specific elements are easily understood. As soon as a child stands in front of the
webcam, it can deal with the program autonomously because the cartoon trumpet tells them what to
do. The children understood the menu function at once. Little supervision and no extra instructions
our remarks from our side were necessary.
The second prototype of the program was fully understandable and enjoyable for children and there were no
indications that improvements were necessary where HCI was concerned.
5 Conclusion and Discussion
Our main research question is how intuitive conducting programs can be both robust and enjoyable for children.
With “intuitive” is meant in this case that the child can use the program without any prior knowledge of
computers or conducting and that the child can go through the program autonomously without any difficulty.
This means that the program has to be robust, as any average child of about eight years old can understand
and enjoy all the aspects of the program on its own. For this reason the system works with motion tracking.
The child doesn’t need to handle any device and doesn’t have to make specific gestures, which stimulates
physical expressions on music. However, this paper describes another aspect of the program that makes it
both robust and enjoyable: the cartoon instruments that guide the child through the program.
This research proves that the flow of our program is easily understood by both individual children
and groups. Essential for this success is the use of cartoon characters that guide the children through the program.
As soon as the child gets into the range of the webcam, the program responds; the cartoon starts to talk
to the child to attract its attention. Next the child can choose to go to the introduction program or straight to
the conducting part. The child never has to read a word; every instruction is audible. Moreover, paying attention
to the instructions is attractive for the children as the words seem spoken by the cartoon that moves
around a little and blinks its eyes. The child gives feedback to the program through physical exercise with the
help of instructions by a cartoon. Avoiding the conventional menu by using a cartoon that tells the child how
to conduct and when, makes the program robust enough to let children deal with the program autonomously.
This is our main criteria for the robustness of the visual feedback that accompanies the music and forms a key
element in the workflow of the program. Because our target group consists of children of about eight years
old, this means they both have to understand and enjoy the program. If the program is not understood, the
child can not deal with it and if the program is not enjoyed, the child doesn’t even want to play.

Reactions of about sixty children show that they enjoyed the program unanimously (see the user
evaluation in appendix 1). All main questions for our user evaluation were answered positively with the second
prototype. The program is attractive and enjoyable for our target group. The animated cartoon instruments
are vital for the enjoyment of the program. The children watch the screen with concentration and
eagerly respond to the combination of music and cartoons. The children get the general idea of the program
because they are guided by a cartoon that explains the intention of the program and offers an introduction
with the basic principles of the program. The cartoon also guides the children through a menu of songs. The
children understand how to choose a song, because the cartoon encourages them in their feedback. None of
the childen had any problems with understanding the menu. The children understand and enjoy the conducting
of the instruments, especially in little groups as they like to encourage each other. But on their own they
also like to explore a lot physical activities as they experiment in how to conduct. They have no problem
conducting a song they have already heard. They even enjoy learning the songs, perhaps so they can anticipate
the the music better. In all cases we had to ask the children to stop, as they never seemed to get bored by
themselves, at least not within 15 minutes.
Our overall conclusion about “Music Maestro!” is that it does reach its primary goal to engage children
in the process of expressing their own feelings using songs and through physical exercise. Hopefully
this will encourage them to continue exploring the world of music in a playful way.
Though the results of our research are satisfactory, we still remain with the question about extra feedback. If
indication bars with the tempo, volume and remaining time are not appreciated by children, is there any form
of extra feedback they would like? What methods could be used to give children improved feedback without
reducing the simplicity and ease of use of the program or cluttering its interface as bars and graphs apparently
easily do for children?
Moreover, our program had minimum and maximum values, to the feedback would always be correct
and understandable. Do children like that or would they enjoy “messing up” the program? And how
would this affect the educational value of the program?
6 Future Work
Having explored cartoon instrument visualization there is still a wide array of possible expansions and improvements
in this field, such as more advanced cartoon expressions. For example, facial expressions and
more precise reactions to the beat and frequency spectrum of the music can be added to the program. Should
track splitting be implemented to separate instruments, even more advanced and specific visualizations would
be possible. Other fields for future experiments include (stage) lighting, showing a real conductor and 3D
camera movements to highlight specific points of interest.

References
1. E. Lee, T. M. Nakra, J. Borchers (2004). You’re The Conductor: A Realistic Interactive Conducting
System For Children. New Interfaces for Musical Expression NIME04-68 – NIME04-73.
2. Teresa Marrin Nakra (2000). Inside the Conductor.s Jacket: Analysis, Interpretation and Musical
Synthesis of Expressive Gesture; M.I.T. Media Laboratory Perceptual Computing Section Technical
Report No. 518
3. Michael T. Driscoll (1999). A Machine Vision System for Capture and Interpretation of an Orchestra
Conductor's Gestures; A Thesis Submitted to the Faculty of the Worchester Polytechnic Institute,
Degree of Master of Science in Electrical and Computer Engineering
4. 2002: Paul Kolesnik and Marcelo Wanderley: Recognition, Analysis and Performance with Expressive
Conducting Gestures Proceedings of the International Computer Music Conference, pp. 367–
370. International Computer Music Association.
5. Jakub Segen, Joshua Gluckman, Senthil Kumar (2000). Visual Interface for Conducting Virtual Orchestra
Proceedings of the International Conference on Pattern Recognition (ICPR'00) 1051-
4651/00
6. Jan O. Borchers, Wolfgang Samminger, Max Mtihlhi (2001). Conducting A Realistic Electronic Orchestra;
tJIST 01 Orlando FLA Copyright ACM 2001 1-58113-438 -x/01/11
7. Tian-Shu Wang, Heung-Yeung Shum, Ying-Qing Xu, and Nan-Ning Zheng (2000). Unsupervised
Analysis of Human Gestures; Artificial Intelligence and Robotics Lab, Xi’an Jiaotong University,
Xi’an; H.-Y. Shum, M. Liao, and S.-F. Chang (Eds.): PCM 2001, LNCS 2195, pp. 174–181, 2001
8. Andersen, T. H. 2003. Towards novel DJ interfaces. Proceedings of the NIME 2003 Conference on
New Interfaces for Musical Expression. pp. 30–35.
9. Camurri, A., B. Mazzarino, and G. Volpe. 2003. “Analysis of Expressive Gesture: The EyesWeb
Expressive Gesture Processing Library.” Gesture Workshop 2003 Lecture Notes in Computer Science,
vol. 2915. Genova: Springer, pp. 460–467.
10. Borchers, J., E. Lee, W. Samminger, M. Mühlhäuser (2004). Personal Orchestra: A realtime audio/video
system for interactive conducting. ACM Multimedia Systems Journal Special Issue on
Multimedia Software Engineering, 9(5): 458–465.
11. E. Lee, M. Wolf, J. Borchers (2005). Improving Orchestral Conducting Systems in Public Spaces:
Examining the Temporal Characteristics and Conceptual Models of Conducting Gestures. Proceedings
of the CHI 2005 Conference on Human Factors in Computing Systems. pp. 731–740.
12. Eric Lee, Thorsten Karrer, Jan Borchers (2006). Toward a Framework for Interactive Systems to
Conduct Digital Audio and Video Streams Computer Music Journal 30(1), Spring 2006 – Preprint
Draft February 9.
Appendix
Appendix 1: The user evaluation report of “Music Maestro!”
Appendix 2: Task analysis
Appendix 3: Storyboard of “Music Maestro!”

APPENDIX 1: The user evaluation report of “Music Maestro!”
1 Motivation and plan
Developing a program for children is especially challenging when it comes to this novel application in human
computer interaction. One aspect is choosing the right age for the conducting program, apart from the question
if the program is understandable and enjoyable for the chosen target group. Though documentation is
available on the subjects of mental and physical development of children, only a user evaluation with the
target group will prove if all intentions have been realized. Our target group consists of boys and girls of
about eight years old (the reasons explained in the User Analysis of our Paper Design).
These are the main questions for this user evaluation:
- Is the program attractive and enjoyable for the children?
- Do the children get the general idea of the program?
- Do the children understand how to choose a song?
- Do the children understand and enjoy the conducting of the instruments?
The user evaluations were planned in a Dutch primary school. Our research took place in two Dutch “fifth
grades” (children there usually are eight or nine years old). The approach of the second user evaluation resembled
the first one, except that a slightly different program was used, as will be discussed in chapter 6. We
also showed both programs to a whole class to see responses of groups and get extra comments.
Our setup for both user evaluations contained the following features:
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.
- A camera recorded the reactions of the children on our program for further analysis.
- The program was individually tested by two children per user analysis; four in total. The estimated
time for one child to play with the program was about 10 minutes. The children didn’t see each other
conduct and were tested in a quiet separate room.
- After the individual tests, the program was taken to two classes for about 15 minutes to see how the
children would respond in groups. About sixty children in total tested the program.
2 Instructions
The first part of the evaluation consists of the scope and flow of the program. As we develop a program for
children, a special approach was required. For instance, children are generally not capable of remembering a
lot of instructions at once and we wanted to keep the use of our program suitable for their playful attitude.
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. That
is why we decided to make a cartoon trumpet introduce the program to children while running it. Instead of
giving instructions about the whole program at once, pieces of information are given carefully during the
program with the help of audio, images and physical exercise.
The cartoon trumpet tells the child that an orchestra needs a conductor and asks for help. Next the trumpet
offers an introduction program in case the child has no experience with the program. It is possible to conduct
music right away if the webcam tracks no movement. If the child waves, the introduction begins. This is all
the child will hear about the program in general. All instructions for specific parts of the program are given at
those parts themselves. English instructions given by the trumpet are quoted below. (Note: the actual prototype
of the program had to be in Dutch as the program was tested by Dutch children.)
“Hello, could you help us? We need a conductor for our orchestra. Please stand still if you already know
how this works. In case you haven’t conducted before, we’ll show you how to do it if you wave to us first. So
if you stand still you can begin right away. But we will teach you how to conduct if you wave now.”
The second part of the evaluation deals with specific elements within the interface. We added instructions at
two specific parts of the program: the introduction and the menu.

Quotes of the cartoon trumpet the introduction program:
“Okay, I’ll teach you how to conduct. When you make big movements, I’ll play loud. And when you make
small movements, I’ll play soft music. Try it!”
(The child conducts a little piece of music to practice with the volume.)
“Well done! And now we’ll talk about the tempo. When you move more, the music plays faster. When you
move less, the music plays slower. Let’s practice!”
(The child conducts a little piece of music to practice with the tempo.)
“Great! Please stand still. Now you know how to conduct the orchestra; only those two things you practiced
before will be combined. So if your movements are big and fast, the music will be louder and faster. Now
we’re going to choose a song. You can choose from three: the Mexican Hat Dance, the Bull Fighters’ Song
and the Russian Dance.”
Quotes of the cartoon trumpet in the menu:
“If you want to play the Mexican Hat Dance, you can wave now!”
“Do you want to hear the Bull Fighters’ Song? Please wave!”
“Wave now for the Russian Dance!”
3 Observations
The observations of the user evaluations are listed in two tables below, including the research question for
every number of the task analysis (see appendix 2 of the final report of “Music Maestro!”). After the observations
of the first evaluation and comments on the first prototype, we will discuss the alterations we made for
the second prototype. Then the results of the second user evaluation are shown. The last chapter contains the
conclusions about our evaluation process.

3a Observations Table User Evaluation 1 (see Appendix 1: Revised Task Analysis)
Task Research question Criteria Observations (one boy, nine years old and one girl, eight years old)
1.1 Does the intro screen attract The child looks at the Yes, the children constantly look at the screen. They look quite concentrated and a
the right attention?
screen.
little tense because of the setting of the evaluation. They smile a little.
1.2 Does the child understand the The child gets into The child easily gets into webcam range. The audible feedback makes this rather
webcam range?
webcam range. clear. However, the good result may partly be due to the setting of the evaluation.
1.3 Is the welcome by the cartoon The child pays atten- The children pay attention and are curious. In a chaotic setting, it may be better if the
nice and comprehensible? tion.
cartoon trumpet speaks slower. Most text is easily understood though.
1.4 Does the child understand the The child waves inten- Yes, the children wave intentionally to begin the introduction. They seem curious
intro choice?
tionally.
after the invitation of the cartoon trumpet.
1.5 Does the child understand the The child stands still. This item was not used in the evaluation as the program was new for all children.
skip intro choice?
However, they did understand the intro choice, so probably also the skipping.
2.1 Is the intro by the cartoon nice The child pays atten- Yes, the children pay attention and in and know they should move when the music
and comprehensible?
tion.
starts.
2.2.1 Does child understand the It moves hands right, In some cases it is very clear the child understands that the position of the move-
volume intro? Enough time? playing with speed. ments influences the volume. In all cases they experimented with movements.
2.2.2 Does child understand the It moves hands right, In some cases it is very clear the child understands that the quantity of the move-
speed intro? Enough time? playing with volume. ments influences the tempo. In all cases they experimented with movements.
2.3 Is the menu intro by the car- The child still pays The children pay attention. We don’t know it they truly understand this menu intro,
toon comprehensible? attention.
because no interaction is required here, but they seem to listen to the cartoon.
3.1 Is the menu choice by the The child understands The menu choice itself is very clear, but there was confusion because it was not
cartoon comprehensible? what to do.
obvious that the children could choose from three songs.
3.2 Does the child understand It moves its hands. The children understand very easily that they should wave to hear a new song. It
how to wave for a song?
should be clearer when a child can start conducting when the song starts.
3.3 Does the child understand the The child moves right, The children made a lot of unsuspected movements to experiment. Luckily the pro-
conducting gestures?
likes to pay attention. gram works with motion tracking instead of gesture recognition; works for this age!
3.4 What does the child do at the (Is the child eager for The children are pleased with the applause, which seems a clearer indication of the
end of a song?
a new song?)
ending of a song than the indication bars. They are eager to conduct a next song.
3.5 Does the child use / under- The child stands still This feature was never used by the children during the evaluation. Remarkably, they
stand interruption?
to interrupt.
have no problem conducting a song more than once.
4. Is the transition at the end of Not annoyed by inter- The transition is very smooth. (Also the transition from one user to another was
the program smooth enough? ruptions of program. never a problem during the group evaluation.)
Green = evaluated positively Grey = no reliable result available Red = aspects of the program that need improvement

4 Comments of the children on the first prototype
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic results.
Instead some simple open questions were asked to the children and remarks were noted.
Questions Nr Answers of the children
How did you like the 1 It’s fun!
program? 2 It’s very nice and funny.
Were there some things 1 I really liked the music.
you especially liked? 2 I liked that the cartoons did things when I moved. I liked the last song.
Were there some parts 1 Yes, I did not understand I could choose from different songs.
that made you doubt? 2 Yes, the cartoon spoke a bit fast in the beginning. And these strange
colored bars (tempo, volume) on the bottom of the screen.
Were there some parts 1 This strange thing on the bottom of the screen (the volume and tempo
you didn’t like?
indications that showed how far the song was).
2 I didn’t like the Russian Dance, but I liked the other songs.
The first prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).
The children were not very talkative when it came to the open questions. However, we observed their reactions
during the first evaluation. The children were very positive about the playful interactive elements of our program.
They were shy at the beginning, facing three adults on their own. This was because we observed the children while
they conducted. But once they started interacting with the program, they became less aware of their unusual
environment and started to experiment enthusiastically. The program really captured their attention once they were
not shy anymore. Though the children were enthusiastic during the first evaluation, we found some points that
needed improvement.
5 The first and second prototype
The first prototype was tested on a laptop that was connected with a webcam and additional speakers. This prototype
is available on DVD. It contained the following features:
- A motion tracking system for the input of the program: the position of the movements influenced the volume
and the quantity influenced the tempo.
- An introduction screen with a cartoon trumpet that gave instructions according to the movements.
- An introduction program to experiment with the volume and the tempo separately.
- A menu that was introduced by the trumpet and showed one image about the theme of a song at the time
the song was presented.
- Three songs to choose from the menu and the conduct with tracked movements. There was applause after
each song.
- A virtual orchestra and bars that showed the change in tempo, volume and how much time was left of the
song on the bottom of the screen.
With the observations and remarks of the first evaluation, the following improvements were designed for the second
prototype:
- The applause at the end of a song proved to be clear feedback that a song had ended. This was for the
children much nicer than the indication at the bottom of the screen, which also showed the conducted volume
and tempo. They were so much into their playful conducting, that they did not have the desire for anticipation
such as these indication bars allowed. So we removed the bars from the program, as they were
only distraction for the children.
- One child did not understand that he could choose from more than one song and conducted the same song
three times in a row. The trumpet said there were three songs, but children can often not remember a lot of
instructions at the same time. So instead of showing one picture at the time, three pictures are shown in
the menu at the same time. The song that can be chosen is highlighted and presented by the cartoon trumpet.
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of hearing a beep
after choosing a song, the child will be told that the conducting can begin.
- At the beginning the instructions were a little to fast. The cartoon trumpet has to speak a bit slower.

3b Observations Table User Evaluation 2 (see Appendix 1: Revised Task Analysis)
Task Research question Criteria Observations
1.1 Does the intro screen attract The child looks at the Yes, the children constantly look at the screen. They look quite concentrated and a
the right attention?
screen.
little tense because of the setting of the evaluation. They smile a little.
1.2 Does the child understand the The child gets into The child easily gets into webcam range. The audible feedback makes this rather
webcam range?
webcam range. clear. However, the good result may partly be due to the setting of the evaluation.
1.3 Is the welcome by the cartoon The child pays atten- The children pay attention and are curious. The instructions are easily understood.
nice and comprehensible? tion.
1.4 Does the child understand the It raises its hands Yes, the children wave intentionally to begin the introduction. They seem curious
intro choice?
right.
after the invitation of the cartoon trumpet.
1.5 Does the child understand the The child stands still. This item was not used in the evaluation as the program was new for all children.
skip intro choice?
However, they did understand the intro choice, so probably also the skipping.
2.1 Is the intro by the cartoon nice The child pays atten- Yes, the children pay attention and in and know they should move when the music
and comprehensible?
tion.
starts.
2.2.1 Does child understand the It moves hands right, In some cases it is very clear the child understands that the position of the move-
volume intro? Enough time? playing with speed. ments influences the volume. In all cases they experimented with movements.
2.2.2 Does child understand the It moves hands right, In some cases it is very clear the child understands that the quantity of the move-
speed intro? Enough time? playing with volume. ments influences the tempo. In all cases they experimented with movements.
2.3 Is the menu intro by the car- Child still pays atten- The children pay attention. We don’t know it they truly understand this menu intro,
toon comprehensible? tion.
because no interaction is required here, but they seem to listen to the cartoon.
3.1 Is the menu choice by the The child understands The menu choice itself is very clear and the children understand they can choose
cartoon comprehensible? what to do.
from three songs.
3.2 Does the child understand It moves its hands. The children understand very easily that they should wave to hear a new song. The
how to wave for a song?
children know they can start conducting when the song starts.
3.3 Does the child understand the The child moves right, The children made a lot of unsuspected movements to experiment. Luckily the pro-
conducting gestures?
likes to pay attention. gram works with motion tracking instead of gesture recognition; works for this age!
3.4 What does the child do at the (Is the child eager for The children are pleased with the applause. They are eager to conduct a next song.
end of a song?
a new song?)
The feedback bar for volume and tempo allowed for more anticipation.
3.5 Does the child use / under- The child stands still This feature was never used by the children during the evaluation. Remarkably, they
stand interruption?
to interrupt.
have no problem conducting a song more than once.
4. Is the transition at the end of Not annoyed by inter- The transition is very smooth. (Also the transition from one user to another was
the program smooth enough? ruptions of program. never a problem during the group evaluation.)
Green = evaluated positively Grey = no reliable result available

4 Comments of the children on the second prototype
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic
results. Instead some simple open questions were asked to the children and remarks were noted. The children
do not seem to be very inventive in their answers. Luckily observations and records were made about the
children’s behavior to gather more information. Their reactions were very positive and they did not mention
anything to improve. Though we looked for possible improvements in the records of the reactions, it really
seems like the comments of the children were sincere. So no improvements were asked for after the second
prototype.
Questions Nr Answers of the children
How did you like the 1 Yes, it’s really fun!
program? 2 It’s a lot of fun!
Were there some things 1 I liked the cartoons and what they did when I moved.
you especially liked? 2 I liked that I could move to make things happen. The applause is nice.
Were there some parts 1 No, I understood everything.
that made you doubt? 2 No, there were not.
Were there some parts 1 No, I liked everything.
you didn’t like? 2 No.
The second prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).
6 Group behavior
Both prototypes were tried by thirty children (three groups of about ten children at the time). So the program
was tested by sixty children in total. This happened after the individual testing. We do not add another observations
or comments table, because the children tried the program one at the time while the others observed
the one that was playing. The remarks of the individuals in the groups were like the ones obtained by individual
testing. However, some new conclusions could be drawn from the group behavior.
- Both the general flow of the program and the specific elements were understood very well by the
groups. The children were helping and telling each other what to do. The more chaotic environment
did not decrease the capacity to understand the program. On the contrary: the reactions were more
spontaneous.
- The children seemed more relaxed in groups. On their own the children could look a little tense and
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.
A lot of children felt free to experiment in unexpected manners.
- Both during the individual and the group testing, the children could deal with the program autonomously.
They probably found the instructions clear. Moreover, they seemed to like the program for
the high degree of freedom to experiment with their movements for direct feedback.
- In the groups they looked both at the screen and at each other.
7 Analysis
For children of this age it’s essential to have motion tracking and not gesture recognition, because they love
the feedback they get on their unexpected experimental movements. The children tried all kinds of unexpected
movements, so we are glad to have used motion tracking instead of gesture recognition. An extra
tempo or volume indication is not appreciated, as children do not pay attention to them, don’t understand
their function or are annoyed by them. To our surprise the program is remarkably suitable for groups of children,
as children often experience no extra distraction in the chaos of the remarks of their peers, but encouragement.
The instructions by the cartoon trumpet are attractive and capture their attention, just like the conducting
itself. Both the general flow of the program and the specific elements are easily understood. As soon
as a child stands in front of the webcam, it can deal with the program autonomously because the cartoon
trumpet tells what to do. In the second evaluation, the children understood the menu function very well at
once. Little supervision and no extra instructions our remarks from our side were necessary. The second
prototype of the program was fully understandable and enjoyable for children and there were no indications
that improvements were necessary where HCI was concerned. However, we could think about three alterations
that could increase the enjoyment of the visual feedback, but we not sure to realize them. The instruments
can provide a more realistic output by connecting them to specific areas within the spectrum of the
music. The lights could dim and spotlights shine to increase the suspense of the scene. We could also create
five instruments instead of three to make the visual feedback more fun.

APPENDIX 2: Task analysis
Both prototypes have this task decomposition. The second prototype is practically the final product, as the
user evaluation showed little to improve.
Task decomposition
0. conduct virtual orchestra of “Music Maestro!”
1. start program
1.1 pay attention to introduction screen
1.2 get into webcam range
1.3 listen to cartoon
1.4 wave or move
1.5 stand still
2. go through intro program
2.1 listen to cartoon
2.2 experiment with conducting orchestra
2.2.1 pace gestures for volume music
2.2.2 size gestures for speed music
2.3 listen to cartoon
3. conduct orchestra
3.1 listen to cartoon
3.2 wave to choose song
3.3 make correct movements
3.4 after song return to menu
3.5 stand still to interrupt song
4. stop program; go out of range webcam
Plan 0.
Do 1
Plan 1.
If user is inexperienced
1.1 – 1.2 – 1.3 – 1.4
If user is experienced
1.1 – 1.2 – (1.3 –) 1.5
Plan 2.
2.1 – 2.2 – 2.3
Plan 2.5.
2.2.1 – 2.2.2
Plan 3.
3.1 => 3.2 => 3.3 => when 3.4 OR 3.5 => back to 3.1
Note: it the webcam receives no motion for a little while, it will go to the menu (3.5).
If it receives no motion for a longer while (for example because the child walked away), the introduction
screen appears (4).
This task decomposition resulted in the hierarchical task analysis on the next page.

APPENDIX 3: Storyboard of “Music Maestro!”
Page 1 - the numbers in the text boxes refer to the task analysis of appendix 2
1.1 – 1.2 Nobody stands in front of the webcam
the right way: the welcome screen shows a cartoon
trumpet that moves a little. A child pays
attention and comes closer. As soon as a child
gets in front of the webcam the program uses this
information to gain the child’s interest.
1.4 The child waves or moves and the introduction
program starts (2.1).
2.1 – 2.2 – 2.2.1 The introduction program: the
cartoon trumpet says: “Okay, I’ll teach you how to
conduct. When you make big movements, I’ll play loud.
And when you make small movements, I’ll play soft
music. Try it!” The child hears a piece of music
and experiments with the volume.
1.3 The cartoon explains the purpose of the program:
“Hello, could you help us? We need a conductor
for our orchestra. Please stand still if you already
know how this works. In case you haven’t conducted
before, we’ll show you how to do it if you wave to us
first. So if you stand still you can begin right away. But
we will teach you how to conduct if you wave now.”
1.5 The child doesn’t move. The introduction
program is skipped and the optional songs are
shown (3.1).
2.2 – 2.2.2 After the experiment with the volume
the cartoon trumpet says: “Well done! And now
we’ll talk about the tempo. When you move more, the
music plays faster. When you move less, the music
plays slower. Let’s practice!” The child hears a
piece of music and experiments with the tempo.

APPENDIX 3: Storyboard of “Music Maestro!”
Page 2 - the numbers in the text boxes refer to the task analysis of appendix 2
2.3 The cartoon trumpet says: “Great! Please stand
still. Now you know how to conduct the orchestra; only
those two things you practiced before will be combined.
So if your movements are big and fast, the music
will be louder and faster. Now we’re going to choose a
song. You can choose from three: the Mexican Hat
Dance, the Bull Fighters’ Song and the Russian
Dance.” The program goes to 3.1
3.2 The child waves or moves when the preferred
song is pointed out by the icons and announced
by the cartoon trumpet.
3.4 – 3.5 When the song ends or in case the child
stands still (and doesn’t conduct) the program
goes back to the song menu automatically.
3.1 The song menu is shown with three icons that
are pointed out one by one every time they are
introduced by the cartoon trumpet: “If you want to
play the Mexican Hat Dance, you can wave now! Do
you want to hear the Bull Fighters’ Song? Please
wave! Wave now for the Russian Dance!”
3.3 The cartoon trumpet says the child can conduct.
The music begins. The child influences the
volume and tempo by moving in front of the
webcam.
4. If the camera does not detect any motion for
some time, the welcome screen is shown and the
program is ready to start the process again.

Blind typing for seniors
Job de Reus, Sander van der Vlugt
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
jobplain@planet.nl, sander1986@wanadoo.nl
supervised by Sander van der Maar, Fons J. Verbeek.
svdmaar@liacs.nl
Abstract. There are circulating many types of courses in blind typing. These
courses can be followed either on the internet or at a physical place somewhere.
We have made an online blind typing course especially for seniors. Many courses
are made for children or young adults. The most are very boring. Our goals for
this project were to make a course for seniors with some novelties. We have done
this by making more options and features in the course. Seniors can change the
font size and the colour. To make it less boring we have create 2 games. After the
evaluations we have noticed that our course isn’t boring. They like the
configuration part.
1 Introduction
Blind typing has a major value for a person. The biggest advantage is the profit in time.
An e-mail message with 500 characters can be written in 2 minutes with blind typing.
A person without blind typing skills has needed at least 4 minutes for the same e-mail.
That is a waste of time. There are a lot of advantages. We will pronounce some
advantages.
• There is no need to look down (for the keyboard) with the head. This will
degrease the complaints about the neck.
• The movement with the head is minimal. The head is only pointed to the
screen.
• What is typed can be read directly. Because of this the mistakes in typing a
character can be revised at the moment.
• The head is only pointed to a book or paper (for instance) when typing text
from these objects, otherwise the head must move from the book or paper to
screen, from the screen to the keyboard.
• If the skills for blind typing are very good, the brains don’t need to “think”
more then needed. The process of typing is like an automatic pilot. There is no
need to look for a particular character, because of this, there is no waste of
intellectual energy. All the energy goes to the actual job. This results (if the
text must be creative) in a better text (more quality).
Blind typing is very handy. Because of this there are a lot of courses, but we haven’t
found any blind typing course for seniors. We created one. In particular those with an
age of 50 and above.
At this age, the so-called old age starts. This is a disease with very real symptoms. This
disease is also known as senectus.We want to make something clear. We want to say
that not every senior has symptoms. Only a few percents have these symptoms. That is
our user group. There are also seniors without symptoms and they like our course a lot.
We have made this course especially for seniors with these symptoms. Fortunately,
every senior can do this course too.
How can we create a user interface for persons with these symptoms? There are lot of
website with information about guidelines and golden rules for making a user interface.

We have tested our design by persons with these symptoms. They gave us some very
good feedback.
We have used Flash for creating the course. We have made the course very interactive
(mouse-over effects, direct manipulation, games). That is easy to do (a big advantage
of Flash).
2 Problem Definition
What is the difference between “normal” users and seniors? In our introduction we
mentioned about symptoms for seniors. We describe these symptoms here.
• Loss of sight
• Loss of memory
• Reduced muscle strength
• Decreased ability to concentrate and react
• Some seniors may also have heavier emotions.
These are typical senior problems. We have used this point to investigate in our design.
There are many websites and courses on the internet. What are the most obliging
problems for this user group (and maybe more people) when they are on a website.
• Crowded, chaotic pages
• Small and indistinct fonts
• To much text on the screen
• The text colour on a website contrasts not enough with the background colour.
• The navigation is very vague.
It is very important to take attention to these problems. The “computer” generation is
more flexible than the generation of people with an age of 60.
What are the direct problems for our user interface with these points?
The loss of sight is usually enacted by having problems with reading small fonts and
distinguishing colours. For a typing course this is a problem, as this leaves out colour
codes to show whether a user is right or wrong. Moreover, not being able to read the
letters is a big problem, because it is all about reading characters.
The loss of memory is also very important, because the users need to remember what
they learned in the course. This isn’t a course you can do in just one hour. To learn a
new skill, you need to focus on it. If you can’t concentrate you might just be able to do
the practical part, but it won’t teach you anything. We had to find a way to keep
attention to our course.
The navigation is very important. If a senior don’t know where he or she is they will be
very frustrated. We have a lot of pages. The structure of our course must be very clear
with an obvious navigation. There is some theory, there are lessons with different steps
and a final, and there are some games.
It’s not only learning how to move the finger to the specific key. The theory part must
support the practical part. If a user learns it wrong is very difficult to change that. A
separate section must be available for the theory. With the aid of pictures it is possible
to make it clear how they have to hold their fingers. We have already mentioned it.
Most blind typing courses are boring. It must be more attractive with interesting things
to do (games).
We are making a blind type course for older people. We expect that our user group
knows a little bit from computers, e-mail and the internet (by all means some skills)
Otherwise, there would be no reason for them to do this course computer skills.

3 Approach
Here you can read about our approach. Which problems occur and how have we solved
them. Guidelines are very important to make a user interface. There are tons of
guidelines. Our approach was to find the correct guidelines and articles.
3.1 Other Blind Typing Courses
Our blind typing course has been based on a real blind typing course. One of us had a
blind typing course 8 years ago (1998). It was a very satisfying course. We have used
the following parts of this course.
• Begin with the simplest characters (d and k, then the e and i).
• Repetition and repetition. This is very important. Each character is used at
least in 5 lessons. You can’t learn a character in 1 lesson.
• Don’t show the next characters. Only show the character they have to type at
that moment. Otherwise they want to type to fast. Speed isn’t important in the
beginning. They have to know the location of the character.
• In the game “Speed” the whole sentence can be seen on the screen. A user can
automatically reading forwards. This increased the speed and this is more
natural. If a user types something from a paper, the user can see the whole text.
Don’t show the next characters in a lesson, but in a game like “Speed” it is
very useful.
We have looked on the internet for other courses. We have learned the following points
from other blind typing courses.
• Use random characters in a lesson. If a user wants to do a lesson again, he
doesn’t know which characters he can expect. It is always different.
• In the game “Speed” the whole sentence can be seen on the screen. A user can
automatically reading forwards. This increases the speed and this is more
natural. If a user types something from a paper, the user can see the whole text.
• The most blind typing courses were very boring. Only a text field where a
user has to fill in some characters. There was no error detection.
• In the beginning we already wanted to use games in our course. We haven’t
found cool games to play in other courses. This is a real novelty in our course.
3.2 Websites for Seniors
There are some websites especially for seniors. SeniorWeb is an example we have used
for our project. Seniors can read news, information and events. It is like a start page for
seniors (like a portal). There is a forum where seniors can discus about internet and
their hobbies. We have posted a link to our course. Unfortunately, there was almost no
feedback and response. One person was angry about our course because he wants that
we see seniors as normal persons. He hates all the software products which have been
made especially for seniors in particular. He thinks that seniors are equal with younger
people. We can agree a little bit with this, but on the other hand, there are a lot of
seniors who finds this course very pleasant to work. We have made options to change
the font size and the colour. He doesn’t have to do that. Seniors can also do this course
without any physical or mental problems.
3.3 Font
We want the best readably text. The font is very important. There are many fonts to use.
In an article [1], they have tested the most used fonts (Arial, Times New Roman,
Verdana and Franklin). The results are that Verdana and Arial are the most legible
fonts. Times New Roman and Franklin were least legible.

In another article [2] they have studied how fast an average people can read text with
different fonts. Of the fonts studied, Verdana appears to be the best overall font choice.
Besides being the most preferred, it was read fairly quickly and was perceived as being
legible.
3.4 Font Size
Some seniors have worse eyes then others. We have made 4 versions with different
font sizes. The smallest font is the standard font size of the most websites. The biggest
one is 2 times bigger. The seniors can choose which one they prefer. We are using
Flash; this means that it is impossible to change the font size in the browser. Flash
doesn’t use HTML. That’s why we have chosen for this solution.
3.5 Navigation
Our structure is very clear. There are 4 main sections, home, theory, practice and
games. A senior can go to every part of the website within 3 clicks. There are a lot of
shortcuts and the buttons are very clear with obvious text within. The user always
knows where he or she is. The top of the content part shows the page where the user is
at that moment (for example: Practice – Lesson 14 – Step 3). We have used standard
guidelines for this part.
A nice thing we have made is the shortcut to the next step in a lesson. After a step the
user can see the results, if he want to go to the next step, the user has to press on the
“Next step” button with the mouse. The hands are already on the keyboard. We have
made it possible that a user only has to press the “Enter” key to go to the next step.
They can go faster to a new step and another benefit is that it prevents RSI (a little bit).
3.6 Colour
Here are guidelines we have followed [3].
• A white background with black text is considered the best possible format for
website and printed copy.
• Use of colours within your website should stay consistent. Otherwise, if you
use colours that are completely different on every page, how will your visitors
know that they are still on your website? If you ever want your visitors to
recognize your website, having a consistent look and feel is important.
We have only used 4 different colours for our main lay-out. These are yellow, orange,
grey and blue. These are safe colours. There was a reason why we have used these
colours. This is mentioned in the following guideline [4].
• A possible solution is to design in black and white, and adding colour only for
emphasis since colour should never be the only visual cue for anything. If
colours must really be used to distinguish items, then use blue, yellow, white
and black. These combinations are less likely to be confused than others
There is also a black-white version of our website. We have done this by the following
reasons [5].
• What colours work on the web and what don't? Black and white work best, of
course. The colour issue doesn't come into play if everything is in greyscale,
so design your site in black and white first. This is a good idea, even without
considering colour-blind people, because you should never rely solely on
colour.
• Most colour-blind people see black and white accurately.
The human visual system produces sharper images with achromatic colours

These are the reasons why we have a black-white version for our website. There is
another reason. We have used the websites http://www.drempelsweg.nl and
http://www.seniorenweb.nl for information about usability. These websites can also be
turned into a black-white version. They have done this with the same reasons we have
described.
There are also many colour blind people. The most obliging colour blindness (7 to 10%)
is the combination red-green [6]. We only use this colour to see if a character is typed
correct (then green, otherwise red). If a person doesn’t see the difference between a
correct or incorrect character, then this person can change to the black-white version
We have used the colour grey to determine whether it is good or not. We have placed
two extra lines in the square to make it clear that the correct key is pressed.
3.7 Consistence
This is a very important point in our design. Our course is very consistence. The
buttons are all the same. We have always used the same font and font size. All the
buttons have the same effect. This is no matter of following guidelines. This has more
to do with decent programming. Don’t create buttons when you need them. Determine
the longest text in a button. Make all the buttons that length. Otherwise there are at the
end 10 different buttons. We have made 2 buttons. Small buttons for text with only 1 or
2 words and larger buttons for more words. The buttons are always placed at the same
place.
3.8 Games
We have developed two games. The game “Degrease the circle” is a real game. This is
a circle that grows slowly. If a user enter the correct key (what is placed in the middle
of the circle), the ball will shrink a little bit. Then it grows again. The circle must be
smaller than a certain size, otherwise the player is game over. The concept of this idea
comes from an old project. One of us had made this game in another language and only
with numbers. We haven’t consulted any source for aid. We had enough Flash skills to
make this. Although it took much more time then we thought in the beginning. This is
because the code was complex and there were always difficult bugs to solve.
3.9 Help
There is a help page where seniors can go if they don’t understand something. We have
made a FAQ (Frequently Asked Questions) where seniors hopefully can find their
problem. For example, it is possible that seniors press the “Caps lock” key. Every
character will be a capital so that every input will be incorrect. They can read in the
“Help” how to turn of this feature.
3.10 Bugs
The code (actionscript) was more complex than we thought in the beginning. We have
consulted many Flash websites to find particular answers for our problems. Most time
whether we had an answer for a problem, a new problem occurred. It was very difficult
to make it bug free.

4 Evaluation and results
We first start with the evaluations.
4.1 Evaluation
We had two evaluations. These were very useful for our project. They liked especially
the novelty parts and the visual parts in the course. These novelties make the difference
among other blind typing courses. Here is a positive reaction from our evaluation.
• The games provide for variation and are nice to try. This makes it more
attractive. The games are chosen very well. Nice exercises and nice to do.
They can measure how fast they can type. Everyone wants to know how fast
they can type. Certainly if they are learning and they want to see their
improvements.
Here is a positive reaction in relation to the visual parts.
• Clear and nice way to make it obvious which keys they can expect in a certain
lesson. The pictures in the lessons are a nice extra support for learning blind
typing.
The users can change the configuration immediately if they enter the course. They
don’t have to search.
• I like the home page where you can change the colour and font size. Seniors
don’t need to search for these things.
• It is very good that you can change the colours and font size immediately
when you arrive on the website.
The main issue: How is the usability? Here are some reactions about our usability.
• Quiescent layout with a clear view.
• You have ordered the information at a good manner. Clear text and not too
extensive (theory part).
• It looks good and professional.
• We like the colours. The colour orange makes it happily and lively. (otherwise
it was a little bit boring). The white background in the middle of the screen is
nice.
• We can read everything. We like it to increase the font size with 1 step. It is
very nice that we can configure that. We like the font too.
• They are clear with nice icons. Every button is circa the same. The colour and
font (and that blue effect) are the same, only the length of the button can
change.
• There are a lot of back buttons. There is always a back button and the main
menu is always visible. We hadn’t any problems with it.
• The lessons are very nice. They are very logical.
There was a lot of feedback from our testers. We have used a lot of this feedback to
improve our course. We haven’t used all the feedback because we disagree some
feedback (see Evaluation rapport). A nice thing with this user group was that we hadn’t
expected all these feedback. We are students with a lot of knowledge about computers,
design and that kind of stuff. How was it possible for them that they can see things in
our design we didn’t see already by ourselves. We had convinced them before the
evaluation that we have a lot of design and technical skills but we are no seniors and
that some parts in the course are logical for us, but not for people with less computer
experience (like them). They have listened to us and give us some good feedback.

4.2 More Feedback
Our team assistant has given us some feedback. He thought that games are a real
addition for the course. We agree, the games are making the difference with normal
blind typing courses. We have spent a lot of time in creating these games.
Some ideas weren’t a good idea. We wanted to make the course that there was no need
to use a mouse. Everything could be controlled with the keyboard. It was a nice idea
but it isn’t a real addition. This was the feedback of our team assistant.
• That they don't have to use a mouse with your software is a nice touch
(although it conflicts with the part where they have to click on "finish"), but I
don't consider it an innovation. I think the game part will count as such.
We had also some feedback after our presentation 1.5 months before the deadline..
Do the seniors know that the buttons are really buttons? We think that the buttons look
like buttons. They have a roll-over effect and the text is very clear in the button. We
have already mentioned it, we think that our user group has enough computer skills to
understand the buttons.
We showed the concept version of the game “speed”. They gave us some good
feedback to improve this.
4.3 Results
We have made a good product. There isn’t a URL available at the moment but we are
going to do that. The course has been completed and works perfectly. We haven’t find
bugs and everything works well. They can go to the help for aim. They can change the
colour of font size. In the theory part is many information available about blind typing.
The games are working perfectly and lesson 1 till lesson 30 is available.
5 Conclusion and Discussion
Our conclusion is that we have reached all our goals concerning the usability. We have
made a very clear and plain user interface. Especially the games make it very attractive
to do this course. Together with the possibility to change the colour and font size we
reach not only our user group but many people.
We even think that our course is so good that there are some plans to make it
commercial (see Future Work).
We haven’t spent time to investigate how many seniors are interesting in a blind typing
course (this wasn’t our goal). There is a chance that we are going to investigate this
because we want to make it commercial (we have already mentioned it). We don’t
know how much the need is for a blind typing course for seniors. Maybe there are
already glad that they can work with a computer. Why is it necessary to learn blind
typing? Our generation has grown up with computers. It is possible that our generation
have to work with computers in the future for our work. For our generation, it is much
more important that we have these skills. It’s less important for seniors, although there
are a lot of benefits to have these skills. We hope that there is a good market for these
user group in this particular field.

6 Future Work
The course can be expanded by a lot of things.
6.1 Speed
With the game “Speed”, someone can measure his own typing speed. This is only
possible if a senior knows all the characters. There are a couple of stories. These stories
use all the characters. It would be nicer if there are some levels. Level 1 contains only
the first 10 characters of the alphabet. Level 2 contains the first 18 characters. Now, a
senior can play this game a lot earlier.
6.3 Video’s
We have used pictures to see how a senior has to place his hands to type a character.
This can be improved by using real videos of the hand. In this movie you can actually
see the moving finger. Now, there is no indistinctness how they have to type a certain
character.
6.4 Commercial
This course can be followed on the internet. Everyone is allowed to follow it. There is
no registration system; this means that everyone can use it for free. This could be
otherwise. It is very simple to make it commercial with a registration system. This
means that people have to pay 5 euro (for instance). It is possible to make this in Flash.
There are some extra advantages by using a registration system.
• Storing of personal data (high scores in games, last lesson practised, personal
settings, score in the final of a lesson)
• A hall of fame. A place with the highest typing speed of all the users.
• They have to pay 5 euro (for instance) before they get access to the course.
References
1. Sheedy JE, Subbaram MV, Zimmerman AB, Hayes JR: Text legibility and the letter
superiority effect. HUMAN FACTORS 47 (2005): 797-815
2. Michael Bernard, Bonnie Lida, Shannon Riley, Telia Hackler, & Karen Janzen: A
Comparison of Popular Online Fonts: Which Size and Type is Best?. (2002) [Online].
http://psychology.wichita.edu/surl/usabilitynews/41/onlinetext.htm
3. A guide to top color combinations in web design [Online].
http://www.allwebdesignresources.com/colorusageinwebdesign.html
4. Burca Karagol-Ayan: Color vision confusion, University of Maryland (2001) [Online].
http://www.otal.umd.edu/UUPractice/color/
5. Mario Parise: Color theory for the color-blind (2005) [Online]. http://www.digitalweb.com/articles/color_theory_for_the_colorblind/
6. Color blinness [Online]. http://en.wikipedia.org/wiki/Color_blindness
7. Job de Reus, Sander van der Vlugt (2007). Blind typing for seniors. Journal 8 pages

Learning elderly to use the mouse
Joppe Kroon, Alex Reuneker
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
joppekroon@hotmail.com, alex@reuneker.nl
Supervised by Mounia Belmamoune, Fons Verbeek.
mounia@liacs.nl, fverbeek@liacs.nl.
This project aims to teach elderly to use the mouse. Many introductory
computer courses for elderly start by explaining the interface and functions,
neglecting the fact that their users may not know how to use the mouse. We
have shown that our product improves their experience, and makes using the
mouse easier. We are the first ones that focus on elderly with this approach,
while a lot of similar products focus on children and are not suitable for elderly.
1 Introduction
The group of people with an age of 65 or higher is rapidly expanding in Holland.
Elderly are very fond of contact with other people, but are not always as able to travel
that well. Therefore computers and the internet could help them getting into contact
with others, entertain them and give them the opportunity to connect to the whole
wide world. It is a pity that a lot of elderly are easily scared by computers, and don't
know how to use them. The idea is to make it as easy an entertaining as possible to
introduce elderly into the world of computers. A lot of courses and books for elderly
involving the first steps in computing, directly begin to explain how the computer
works, and how to do the desired actions, completely neglecting the fact that some of
the participants or readers don’t even know how to use the mouse.
This is where our product comes in. The interactive, game-like interface, will help
elderly use the mouse. In our experience it is quite hard to first learn to work the
mouse, because the mapping of the mouse does not directly correspond to the pointer
on the screen (horizontal movements VS vertical feedback on the screen). The
innovation of our project is that it is aimed at elderly. The idea of mouse training is
not new. There are some programs on the Internet that do the job, but most of them
are aimed at young children and the rest is aimed at middle-aged people. The
knowledge, learning ability and use of language is completely different for these user
groups than for elderly people. Because of this, the existing products are not suitable
for our user group.

This paper gives an overview of not only the capabilities, functionalities and
possibilities of the product, but also gives a view on the evaluation and the
development trajectory of the product.
2 Short subject background and problem definition
Today’s world is becoming increasingly technological. You can't turn a corner without
bumping into a computer. This is great for whiz kids, but those who haven't learned to
use this new technology are left behind more and more. This group consists mainly of
senior citizens. Therefore a lot of books on computer use are aimed specifically at this
user group of the digitally challenged. However, every one of these books overlook
one little thing...
2.1 An outline of the problem and our solution
Let’s take a look at the situation to improve our insight. There are elderly who want to
learn how to use the computer, and have bought a book to this effect. After reading the
first few pages they sit down in front of a computer and try to complete the first task in
the book. But they find they cannot complete even the simplest task, because they do
not know how to use the mouse or even what it's supposed to do. Frustratingly there's
no chapter in the book explaining how this thing operates. At this point they may
already give up, or ask someone if they can help them out. That someone else
probably will just explain how to complete the current task, which leaves the person in
question having to ask for help every time a new function is introduced.
Having to ask someone to help increases the feeling of inadequacy and that puts the
point of giving up nearer and nearer. We do not want our senior citizens dropping out,
so we will have to improve this process of getting acquainted with the computer.
That's where our product comes in. In stead of the “someone else” explaining the
workings of the mouse, the user will first use our product to gain experience with the
mouse. From here the elderly are introduced to the mouse step by step, learning
everything there is to know to use mouse. After which he or she will be able to
complete the tasks in the textbook with confidence.
2.2 Alternatives
There are several alternatives to our solution which you can split in two groups:
• The Internet solution
• The Microsoft solution

The Internet solution consists of websites or programs which are typically available
through the Internet. These introduce the user to the mouse and give them a few tasks
to complete, much like our solution. Individual problems aside, there's one problem
they all have in common. They do not target elderly specifically, most of them even
target children. And that means the elderly user will be intimidated by the colors and
language, and give up before they have even begun.
The Microsoft solution on the other hand relies on the games provided with every
windows distribution. Every game uses just a subset of mouse functions and are
therefore very well suited to introduce the mouse to a new user. However, these
functions are not explained beforehand, which means someone else has to come in and
explain these functions for every new game. Besides that, there are added difficulties
for elderly users. For example the size of the game elements, or the fast graphics.
2.3 An insight into the elderly user
Our research has shown that the elderly user is one with its own special demands for a
product. The main difficulty when dealing with an elderly user is that they are easily
intimidated by technology. Therefore they do not use trial and error while working
with a computer, they are actually afraid they will break it as if they are pushing a self
destruct button. Furthermore, many have decreased ability on one or more areas, and
are not able to position the mouse, read, or hear as you would expect from any other
user. Next to this, the mouse is, at first use, an illogical piece of machinery. It does not
clearly communicate how you should operate it, and when you do find out that moving
over a surface provokes a response, it probably is not the one you would expect.
Moving sideways, moves the pointer sideways on the screen. However, a forward
motion moves the pointer up and a backward motion moves it down. A typical user
would trial and error his way through but, as said before, most elderly users do not use
trial and error.
3 From problem to solution
Before solving the problem, it was necessary to address the right problem. And as
important: who’s problem is it? First we addressed the problem, the following
statement is used:
‘Many elderly don’t know how to use the mouse, or never used it. Because most of the
introductory courses designed for elderly focus on using programs, there is a gap
between the present knowledge of elderly and the knowledge needed to start with
these courses.’

We deliberately made a problem description, to be able to fall back on this, and to be
able to test if we succeeded in our goal: solving this problem. We speak of elderly in
this problem description. Therefore we needed to clarify this user group:
‘The intended user group consists of elderly people in Holland. Some characteristics
are: age of 65 and up, Dutch speaking (and none, or little English speaking), no or
little understanding of computers, no or little experience with both computers,
standard software (Microsoft Windows) and the internet, good but slow hand eye
coordination, a high percentage of the group with bad sight.’
Because we differed very much from our user group, we first wrote some scenario’s,
and did task analysis trying to capture the experience of our intended user group. After
that we wanted to test on which level our user group was operating the mouse. We
used a null test for this (see the results in appendix). This way we could determine on
what level to begin teaching the elderly. From these results we set up our usability
requirements. Our usability requirements focus on understandability, readability and
affordance of the interface. The goals in these are to have an understandable interface
which relates to the world of elderly, readable text for elderly with possible bad sight
and affordance not only of the software interface elements, but also the affordance of
the mouse. What can they do with it, how does it work and how is it manipulated.
These usability requirements are tested in the final user evaluation. We decided that
the product should involve a large portion of gaming, so the learning curve of the
product would be disguised by the gaming aspect. After presenting the paper design
interface to elderly and discussing it with them, we developed the actual product.
During this development we had problems trying to find a way go give information to
the user about how to play the games using the mouse. Just presenting text would not
encourage the user to read it, and text would not be sufficient to give examples. We
chose to use movies to explain working with the mouse and give examples of how to
play the game. This gave us the opportunity to use both speech and visualization to
explain our product.
4 Results and Evaluation
After developing the product, a final test was needed. In this final test we had to find
out whether our solution solved the stated problem or not. We have done this by first
letting the test subjects use or product. After this we presented them with our null test
program (note that these test subjects are NOT the same as the original null test or
first evaluation subjects. This is the only way to come up with valid conclusions), and
we recorded the time they needed to complete the null test. The next logical step was
to compare these results to the initial results we had from the beginning of the project.
When the average time needed after using our program would be lower than the
average time needed before using our program, we could conclude that we had solved
the problem, and vice versa. Off course, this statement is a bit harsh, because we

tested with only 5 test subjects every time (4 on the last test). To make the statement
last on a scientific level we would have to run a test with a larger test group.
Our hypothesis, that no test subject would need more than 20 minutes to complete the
tasks, is found to be right. The conclusion, based on the figures and numbers as
outcome of the test as shown below is summative, as said in the goal of the user
evaluation. Therefore a short conclusion can be given, which is:
‘Our products works, it decreased the time needed to complete the null test (from an
average of 16.4 minutes to an average of 6.5 minutes, which is a 60 percent
decrease).’
Because of the small test groups this outcome is to be taken very light. One or two
very good or bad participants significantly influence the numbers. The percentage of
decreased time could be lower. However the test results indicate that the product
works significantly well. Further research is needed to calculate the precise decrease
of time needed to learn using the mouse.
The product could be improved on several aspects, which came forward during the
second user evaluation.
• All the users in our test group had an incorrect grip of the mouse. This
problem had been encountered in the previous test and we had tried to solve
it by explaining how to grip the mouse in a movie.
• The explanatory movies were too fast paced.
• The sensitivity of the mouse proved a problem for most users however, and
often caused the pointer to be positioned on the ‘begin’ button.
• Most of the test subjects saw clicking the mouse as a solution to everything,
provoking the wrong computer reactions.
• Clicking often resulted in dragging, because the mouse was clicked too long
and moved in between pressing and releasing.
The formative part of the evaluation, the usability scores, have given us the
opportunity to draw the following conclusions:
• People are neutral in using the program, they don’t especially like or dislike
it. We should improve the gaming aspect to increase the entertainment value.
• The program is found to be complex. Improvement needed.
• The program is founded to be moderately easy. No improvement needed.
• People think they need technical assistance. This is probably caused by fear,
which the product should take away.
• The options in the product were not always easy to find and use.
Improvement is needed here.
• The program was found not consistent enough. We don’t know the reason
behind this yet, but improvement is needed.

• The test subjects don’t know if other people will learn using the mouse with
this program easily. This must be improved in order to see it being used by
more elderly.
• People found the product fast enough to use. No improvement needed.
• Most people felt certain when using the product. No improvement needed.
• People thought they had to learn (ask) things before using the program.
Improvement is needed here, by explaining more in the beginning of the
product.
We focused on understandability, readability and affordance:
• The metaphors were interesting enough to the elderly to draw a line between
their own world and the computer. This can be concluded from the reactions
of the test subjects during the tests.
• The font used was of right type and size, no ‘difficult’ words or sentences
came up during the evaluation.
• The affordance was of such a level that the elderly not always knew what to
do with the interface objects. This must be improved.
• The visibility is not good enough yet. The game characters were to small for
some of our test subjects. Therefore we need to improve this.
During the development our assistant helped us with feedback on prototypes and
documents. The most important feedback we got was that we had lost sight of the
gaming aspect. Our first prototype existed of only explanation of the working of the
mouse. The reason for this was that the results of the null test were so bad that we lost
sight of the fun aspect, and were challenged to come up with a product that improved
this bad results. As we look back now we think we had a useful null test, and we
should not be scared of the results next time in a similar project. We used the
feedback of our assistant to rapidly change our prototype to more of a gaming
environment, where learning by playing was exploited more. Nevertheless the
gaming aspect should be improved even more.
5 Conclusion and Discussion
The overall conclusion is that we succeeded in significantly decreasing the time
needed to learn elderly how to use the mouse, but the product could be capable of
decreasing it even more and giving the elderly more pleasure while learning by
improving the above mentioned usability aspects. As mentioned before, elderly are a
special user group with it's own special demands for a product. This can be daunting
for any developer, enough to prevent developers to target elderly with their products.
This however is quite unfair for the many elderly users that could benefit from
working with a computer. Besides that, it's also a big economical problem, because
costs could be saved by investing in a particularly clear and robust interface, but now
a large percentage of potential customers is shut out. Our product has proven to be an
effective remedy to this problem. After using our product, elderly could complete

tasks involving the mouse much faster, and relied less on help from others. This could
stimulate other developers to actually develop applications specifically for the elderly,
gaining them a new market, and gaining the elderly better software.
Our product fills a void in the chain of products helping elderly users acquire
computer skills. It provides the very first step to get acquainted with the computer that
was missing until now.
6 Future Work
Work in the near future would consist of:
• Improve the explanatory movies by slowing them down and implementing
fast forwarding and rewinding options. Also the quality and angle of the
movies must be improved.
• Give hints during the game to clear up the game play.
• Improve the interface. The erratic mouse movements and clicks caused a lot
of buttons to be clicked on the interface. It seems that this problem can only
be addressed by removing all elements and displaying the game full screen.
• Improve the gaming aspect to increase the entertainment value.
• Improve the interface in such a way that it eliminates the thought of the
elderly that they need technical assistance, which they do not.
• Improve visibility.
This future work could decrease the time needed to complete the null test even more,
and therefore elderly would be able to use the mouse in less time and effort.
When we look at the further future, we can say that nowadays practically everyone is
growing up with computers, and learns how to use at young age. Therefore our
program serves a need right now: there are a lot of elderly who never used a computer,
but probably will not be needed anymore in the not so near future (30 years or more).
However, there will always be elderly and there will always be new things to learn. It
can be expected that the problems elderly encounter now will be similar to the
problems we will encounter when we are old. That means that the product itself
hopefully will not be necessary in the future, but all insights gained while making the
product will be instruments in creating future products aimed at elderly.
References
1. Digital Equipment Corporation (1986), System Usability Scale.
2. Joel Sposky (2000) ,Designing for programmers,
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html.
3. R.J.H. Tolido (1996), IAD: Evolutionary development of Information Systems.

4. Redmond-Pyle & Moore (1995), Graphical User Interface Design and Evaluation.
5. Bell & Parr (2002), Java for students.
Appendix
Screenshot of lesson 1: Cleaning up Bruno’s droppings
Screenshot of lesson 2: Reach the bridge by scaring sheep away

Table of initial null test results (null test held on 2 november 2006)
Control group (first null test) time in minutes
Task User 1.1 User 1.2 User 1.3 User 1.4 User 1.5
1 7 10 4 4 7
2 3 2 1 3 2
3 6 5 3 6 7
4 4 3 1 1 3
Total 20 20 9 14 19
Mean 16,4
Table of null test results after using the product (second evaluation held on 10
january 2007)
Test group (second user evaluation) time in minutes
Task User 1.1 User 1.2 User 1.3 User 1.4
1 1 1 1 1
2 1 1 1 2
3 1 1 3 3
4 2 1 4 2
Total 5 4 9 8
Mean 6,5

Visual Memory Game
Stijn de Gouw, Elena Gavrielidou
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
cdegouw@liacs.nl & vitabr3vis@hotmail.com
supervised by Yanju Zhang, Fons Verbeek
yanju@liacs.nl & fverbeek@liacs.nl
Abstract: The rapid rise in Internet gaming and the recent popularity of the
Casual Game genre have shown that the major contributor to this market is the
‘Baby Boomers’, users of ages 40 to 60. One of the main concerns of this
group, is Memory loss, Memory training and Memory retrieval, as shown by
the rise in the sales of this genre of games. Our aim was to develop such a game
to open a new market of educational Casual Gaming by creating a Visual
Memory Game for this particular target market. By creating a Memory Game
for the PC, we emulated the success of similar games on restricted gaming
platforms, and in this way, addressing a much wider audience. As shown from
game evaluations we performed, the 40 to 60 year olds embraced and
appreciated the creation of a Memory Game for their most popular gaming
platform, the Personal Computer.
1. Introduction:
Computers, video games and the Internet have become ingrained features of our
everyday lives. Computer use has come to be a major source of fun and
entertainment. For most people, computer use and video game play has long been
established as an integrated part of daily life, in a balanced healthy manner.
As memory loss and memory training seem to be the current trend in games
development, we see an emerging pattern in the fabrication of games claiming to aid
your memory. The most popular brain training game at the moment is ‘Dr
Kawashima's Brain Training: How Old Is Your Brain?’ developed by Nintendo and
intended for the Nintendo Dual Screen (DS) console. Brain Training is not just a
game; it’s a pop culture phenomenon, a brain stimulator and a daily obsession.
Unsurprisingly, the game has recently won a BAFTA award in the United Kingdom,
in the category of innovation. Dr Kawashima's Brain Training comprises a variety of
mini-games designed to give brains a workout.
Following Nintendo’s success, other companies are also trying to capitalize on this
opportunity. Mobile phone developer Upstart Games is creating “IQ Academy",

which marks the player's performance in various tasks of recognition, logical
prediction and spatial resolution. It then rates the player and mixes up the puzzles
offered next time, promoting further improvement. Whereas Nintendo's games use
the DS's stylus and touch screen, IQ Academy employs a simple multiple-choice
system, which make it accessible to anyone with a mobile phone.
The issue at hand is that there is shortage of credible memory testing games for the
computer platform. Although such computer games exist, the plethora is CD-ROM
based, and this poses problems of mobility, accessibility and time-management. A
CD-ROM game can only be accessed from the user’s home at specific times, as it is
not very handy to carry the CD-ROM around and play whenever he or she feels like.
From our preliminary research we have realized that those of the games that are
trying to target the on-line market, all comprise of a repetition of one specific
memory game, namely identifying a pair of playing cards from a pack of cards turned
upside down. This genre of games does not target the specific problem we face,
which is to find the most effective means of creating an educational online game that
comprises of credible, usable and successful exercises which will make it attractive to
a specified user group, which will be discussed later on in this paper.
In order to tackle the problem of creating an utterly efficient online memory game,
we need to identify the environment in which this game will evolve. Therefore two
important aspects need to be established; the general background and advances in
computer gaming, and most significantly, the audience for such games. In addition,
there needs to be a clear connection between this specific audience and their
consequent need for such a game, in order to determine the target audience this game
is constructed for. These issues will be discussed in the second section of this paper.
After having recognized the environment and target audience, the most effective
technique for addressing this audience must be identified, and this is what the third
part of this paper will consist of. Implementing the relevant HCI theories for the
correct output of the game is crucial, if the game is to become successful, and its
innovative aspects will be discussed in order to show how it will survive with the
current competitors.
Furthermore, the usability tests the game has undergone in order to ensure its
credibility will be analysed in the fourth section of this paper. This will certify that
the theories have been implemented in an appropriate manner, so as to make the game
a success within its preferred audience.
Future developments in relation to this game, and plans for further expansion, in
terms of other markets or even in terms of perfecting its prototype status, will be
discussed in the fifth part.
Finally, conclusions and personal reflections on the development process and the
deliverables of this artifact will be analysed in the conclusive part of this paper.

2. Casual Gamers, Baby Boomers, and Memory Loss:
Memory and concentration problems are common with age, including difficulties in
focusing and in maintaining attention. Some problems are more serious than others.
People with more severe memory lapses may be suffering from one of a series of
conditions of the brain known as dementia, or Alzheimer’s disease. Dementia affects
your ability to carry out normal and usually easy daily activities. Problems can occur
at any age, although due to increased fragility and vulnerability the ability to encode
new memories of events or facts and working memory shows decline in people over
40. People over 60 show more rigorous symptoms if these are not prevented or
treated by nutritional rebalancing or mental mind-mapping exercises.
The aim of creating this game is to target this exact age group of 40 to 60 year olds,
who are concerned with their abilities of concentration, and their need to focus on
particular tasks without being distracted over a period of time. This is the age group
that tends to forget things that one would automatically and easily recall. As memory
gives you the ability to store information and events for later recollection, the brain
that controls these processes could be viewed as a muscle itself, which, if not properly
exercised, will eventually lose its power. The target group has already expressed the
need for such brain exercise, as is shown by the rising sales of Nintendo’s ‘Brain
Training Game’. Therefore, the underlying problem we face is developing a game for
an already established target market in need, but addressing it in its widest form,
namely, creating a memory game that will be accessible to everyone who doesn’t
have access to handheld consoles such as the Nintendo DS.
In addition to being prone to memory loss, this particular age group surprisingly
holds a total of 20% of the online usage market, as opposed to the group who would
be expected to have the majority (the 18 to 24 year olds) who hold a humble 17.8%
of the online usage market:
“The analysis also shows that 45- to 64-year olds surf the Internet
more frequently, stay there longer, and check out more Internet pages
than even their college-age counterparts” [Lispman (2002)]
While establishing the target group for the memory game we realised that potential
users must be defined in terms of what they want, or will accept, what kind of
distribution will be most convenient for them and through what channels of
communication they can be best reached, as well as what the want from the final
product itself. A further aspect of importance when designing with the user in mind is
realising the group’s competency in terms of computer and Internet usage. The results
of our research stunned us once again, when we realized that the target group, also
known as ‘Baby Boomers’ whose computer knowledge was perceived highly
unlikely, is indeed quite computer literate, due to the amount of time they spend
online:
“While most adults age 50 or above are more likely to be intermediate
Internet users testing the waters of the Internet, their heavy online
habits have set them on a fast track to become fully accustomed to the
medium. Compared to 18- to 24-year olds, they spend on average 6.3

more days per month on the Internet, stay logged on 235.7 minutes
longer and view 178.7 more unique pages per month.”[Lispman (2002)]
Furthermore, this certain age group seems to be quite active in the realm of ‘Casual
Gaming’. It is a necessity today for almost every person who spends most of his/her
day working in front of a computer screen, to find ways that will enable him to
escape, even for five minutes, from whatever preoccupies his mind. One of the most
popular and frequent solutions to this, are quick, addictive games, which can be found
online.
The expression ‘Casual Game’ came to be used to refer to a category of electronic or
computer games targeted at a mass audience, with no particular computer skills. The
main characteristic of Casual Games is that they have a few simple rules and an
engaging and addictive game design, making it easy for a new player to begin
interacting with the game in just moments.
“According to research firm IDC, the online gaming population alone is set to reach
256 million people by 2008. The firm estimates that the U.S. market for primarily
casual downloadable games will grow to more than US$760 million in 2007.” [Early,
(2005)]
The fact that Casual Games require no long-term time commitment or special skills
from the user, combined with the fact that there are comparatively low production
and distribution costs for the producer, makes them such a popular part of the gaming
market, and consequently make them a good choice of style for launching our own
online game.
Consumers progressively rate home computers as a means of a multiple range of uses,
including Internet and e-mail services, games, and educational and work uses. The
driving force behind this is the availability of hardware that is both smaller in size and
more stylish in design nowadays, making the PC an even more acceptable addition to
the living room.
As technology barriers are falling, and computers start to penetrate our everyday lives
faster than before, the average age of online Casual Gamers is increasing. The ‘Baby
Boomers’ are becoming computer literate, and as they experience the world of the
computer, they become more interested in Casual Gaming, since this generation is
less likely to own game consoles, as it is evident in Figure 1(See Appendix).
Therefore the problem at hand will be tackled thus: Creating an online ‘casual game’
to help prevent or treat Memory Loss, and addressing the age group of 40 to 60 year
olds, for primarily two reasons: they hold the largest share in the online ‘Casual
Game’ and Internet usage market, and are constantly interested in solutions to battle
with memory loss.

3. Visual Memory Game: the Online Solution
The interface design of the game was set up according to ‘Schneiderman's 8 golden
rules of design’[Skaalid (1999)]. To improve the game’s usability, it is important to
have a well-designed interface.
The fact that this game will be online means that the users will never be constrained
in any way; playing it is possible at any time from anywhere, as long as a computer
with an internet connection is present.
The primary attributes of the design, are, that it must have a consistent, intuitive and
simple interface that is intended in aiding the users in navigating through, by means
of intuitive, constant and consistent navigation and buttons, that the users can
familiarise themselves with easily. This layout design provides an innovative
solution for a market segment that is essentially a driving force of the market, yet few
products are designed with this target group in mind!
Furthermore, by offering error prevention and easy reversal throughout the game, the
user will be able to distinguish the navigational process from the feedback provided
through the buttons. This will also give the functionality to frequent players, as the
familiar environment will make it easy to play the game several times: The entire
game is a linear exercise consisting of eight smaller parts, each one aiming to train a
different aspect of the brain. Concise instructions at the beginning of each sub-level
guide the user through the exercises. The game was designed in a user-friendly
manner, meaning the user makes all decisions with the OK button, which is handily
situated next to the answer bar. Functionally, this model aims to give the user group
the confidence to navigate through the game without feeling lost or confused in any
of the levels. When the user reaches the final screen, the score will be displayed,
giving the desired feedback that the game promises through out its adventure-style
linearity.
The main philosophy of this game, is that it must be straightforward and simple for
novice users, but also be functional enough for more experienced users to be able to
navigate through it consistently. This is accomplished by giving the user an interface
that does not require elaborate thinking to navigate through. Also, it is important to
stress that besides being an entertaining game, this product offers beneficial
knowledge to its end users, in an easily accessible ‘Casual Game’ manner, which is a
technique that has not been explored in depth by the game producing market.
This game aims to evolve as a natural consequence of reliable and appropriate
handling of the information known about user preferences, and their implementation
in a functional game. There will be a strong, consistent visual hierarchy, within which
important elements such as navigational buttons are emphasised. Furthermore, the
content is organised logically and predictably.
Employing the ‘Gestalt’ [Saw, (2000)] theory, we will create an overall graphic
balance and organisation in the game, to draw the user to the content, which is the
crucial goal of the design interface. This balance between attracting the eye with
visual contrast will consequently provide the website with a perceived sense of
organisation.

Finally, the graphics that will be used throughout the page will be optimised for web
use, which means that they will be small in size (in megabytes), so that the game can
load into browsers quickly, even when accessed by users with slow Internet
connections. The goal of this design scheme is essentially to transmit internal
information and to communicate with potential users and the general casual gamer
public.
Essentially, we are taking Nintendo’s concept of ‘Dr. Kawashima’s Brain Training
game”, which has already been a proven success, on the constrained DS console and
opening it to a wider on-line audience, a target market that has yet to see an
innovative educational game as such.
4. Results and Evaluation:
Two separate evaluations were conducted. The first was mostly concerned with the
design layout and ensuring that the target group focusing on was the optimal one. The
second dealt with the functionality of the game, the improved design layout, and rated
the confidence with which the users interacted with various aspects of the game.
The results derived from these evaluations were truly positive. Evaluators commented
and complimented the simplicity of the layout. In terms of functionality, the font size
and button size was found to provide the users with confidence to navigate through
the various levels of the game.
The main issue faced by the users when first playing the game was the functionality
of answer boxes. Initially some users were not sure as to how these were to be used
and consequently special care was given to the timing of the games, as well as the
way in which buttons were disabled during movie clips and instructions shown on
screen, and this is something the users thought would be very helpful in making the
functionality of the answer boxes clearer. The consistent positioning of the buttons at
the right side of the screen proved to be a choice favoured by the users, who
commented on the fact that this allowed them to focus on the game screen and
confidently move from level to level.
The colour scheme employed was evaluated as giving a ‘serious’ note to the actual
game, which the users found inspiring when playing. This was said to enable them to
concentrate to the goal of the game, which was to obtain a high score.
In terms of feedback, the users did not appreciate a result screen at the end of each
game. The overall opinion on this, was that by seeing a score result after each level,
the attention was shifted from the game towards the scores, and this is something that
we altered for the final working prototype, where the score is only displayed at the
end of the final level. The evaluators also commented that they quickly became
familiar with the interface, due to the consistent positioning of the minimal functions
in each game.

5. Conclusion and Discussion:
When attempting to create an interactive game to be implemented on an electronic
platform, it is extremely important to design with the user in mind. The fact that the
Visual Memory Game appealed to its intended audience mainly results from the
careful consideration of the user group, and the precise understanding of this groups
needs in terms of computer games. It was also important to realise that this segment
of the market holds the first place in terms of computer and Internet usage, and
therefore we wanted to fabricate a game that would suit their needs as novice to
intermediate users.
Trying to implement HCI theories for the creation of a user specific game was a
challenging task, especially when this game had as a particular purpose to tackle with
a problem that this user group faces, namely, Memory loss. This was an issue that had
to be approached with care, and target within this user group the specific need to
resolve this issue, by presenting a game they would indeed find credible. For this, we
had to create an atmosphere of reliability and consistency, which would boost the
users’ confidence and enable them to view this game as an educational and fulfilling
experience.
In addition, the creation of this game aimed to open a new market of Educational
Casual Games, having in mind that this specific user group is interested in Casual
Games, yet, no one has been creating them for the purpose of aiding and educating
this particular target group. By creating this game, and evaluating it with real users,
we came to the conclusion that venturing on the creation of such educational Casual
Games for this specific market is a feasible move, as the target audience has
responded very well to this first game of this genre.
6. Future Work:
The trends of the market reveal that there is huge potential for growth in new, nonretail,
distribution channels for games – the internet games market – which is growing
at over seven times the pace of the traditional, retail-based games market. The goal
of successfully implementing this game does not only aim to benefit from the market
trends, but also pave the way in a new category of educational games that will be
particularly tailored for online use. With the rise in the popularity of e-learning, the
potential of producing inexpensive educational games for casual use is enormous.
We would like to further develop this genre by creating a series of different games for
the specific age group, that would not only aim to tackle with their memory issues,
but also help them advance their computer skills and general knowledge. In the future
we would also like to expand the age group, and concentrate on creating educational
games for other target markets, with the same philosophy and HCI theories in mind.

References
1. Lispman, Andrew (2000) U.S. Baby Boomers and Seniors are Fastest Growing
Internet Demographic Group, New York – Last Accessed January 2007
[http://www.comscore.com/press/release.asp?id=181]
2. Early, Chris (2005) Casual Gaming Gets Serious, Washington – Last Accessed
January 2007
[2http://www.microsoft.com/presspass/features/2005/jul05/0719CasualGaming.msp]
3. Skaalid, Bonnie (1999) Shneiderman’s Principles of HCI Design, New York – Last
Accessed January 2007
[http://www.usask.ca/education/coursework/skaalid/theory/interface.htm]
4. Saw, James (2000) Design and Composition: Gestalt, Last Accessed January 2007
[http://daphne.palomar.edu/design/gestalt.html]
Appendix
Figure 1: Casual Gaming Age Distribution

Figure 2: Game Level 1
Figure 3: Game Level 2

Online Flower Shop
Sjaak Wolff, Ella Keijzer
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
sjaakwolff@hotmail.com, ella.keijzer@gmail.com
supervised by: Sander van der Maar, Fons J. Verbeek.
svdmaar@liacs.nl & fverbeek@liacs.nl
Abstract:
Our project is based on all those online shops at the world wide web. We designed
one specially for elderly people. Elderly people most of the time feel uncomfortable
buying something on the internet. The novelty in this project is
'Heidi', the saleswoman who leads you trough the website, if you want. She tries
to make you feel comfortable and give you information about the website. In
our user evaluation we saw this worked quite well. Our subjects feel comfortable
and want to come back to the shop.
1 Introduction
Nowadays buying something on the internet is for a lot of people a normal thing to
do. It is not difficult for those who work a lot with the computer to understand the
structure and the procedure of an online shop. There are a lot of different shops all
over the internet. For the course Human Computer Interaction by F. Verbeek; we
made an online flower shop.
We did not make a usual flower shop. We made it for a special user group. Our user
group is the group that doesn’t work with the computer very often. Although they
might not be really old, they are most of the time older then 40. It is often very difficult
for those elderly people (you can read elderly as: people who are not grown up
with computers) to buy something from the internet.
Our idea was to make an online-flower shop, which is very accessible for people
who are not very familiar with the computer. In this shop you can order al sorts of
flowers. You can order (mourning-, birth-) bouquets, plants and you can also choose
from a collection of vases. We made our whole project in Flash; which enables us to
make an eye catchy design. To access our shop, you need to know how to work with
the mouse.
The structure of our paper is as follows: first we tell something about the background
and we give our problem definition. Second we introduce you to our solution,

and finally the results and evaluation. At the end you can read the conclusion, discussion
and a short view on the future.
2 Short Subject Background and problem definition
First of all it is nice to have a online shop which is very intuitive. There are many
shops on the internet, but they are most of the time very confusing. We made a shop
'just as the one in your neighborhood'; small and nice.
Most important for our design is the user analysis. Our user group consists of the
so called elderly people. Elderly people are most of the time not grown up with computers.
You have to think on people born before 1960. Even in their jobs, they seldom
use a computer.
People who are not grown up with computers are most of the time very uncomfortable
with them. They do not understand a directory structure or even a mouse. Also
they do not really trust or like the computer. Sometimes they have bad eyes which
make it difficult for them to read large texts from the screen. We want our user group
to feel comfortable by buying something on the internet. Those older people like human
contact, they must have the feeling there is a 'ask-possibility', as in a 'real-life'
shop. Compare the dislike of older people for ticket-machines, cash-machines etcetera.
Those people are used to go to a shop. In the future they might not be as mobile as
they are now and therefore are not always able to go outside. It would be very nice if
they get more used to use the internet, they then can spare a lot of time and energy
with that.
So our program has to be easy to use and understand, without losing the functionality
of the ‘bigger’ online shops.
For our program, the only thing you need is a mouse. Our user group is maybe not
used to use a computer, but they have to understand how a mouse works.
3 Heidi, the saleswoman
To make the elderly feel comfortable with buying something on the internet we introduce
Heidi. Heidi is our saleswoman, just as the one you know from your neighborhood
shop. She guides you trough the website; but only if you Want to be guided. She
will say unambiguous things. She says her things in a text balloon, so you can read it.
This is because our elderly can relax while reading the text; they can read on their own
tempo. Also when they are distracted, they do not miss important information. If Heidi
asks you a question, you can choose and click your answer (see appendix pictures).
It is also interesting to mention why we chose to set the menu on the left. It is really
obvious to do so, because everyone does. People know already were to look, compared
to the F-pattern by eye tracking 2 . Although our user group is not used to the internet, it
is nice for them if all websites have the same layout.

For our design we also get a lot of inspiration from John Meada's book; “Laws of
Simplicity” 1 . (Worth reading for HCI interested people).
4 Results and Evaluation
User evaluations
First user evaluation
In our first user evaluation, we asked our subjects several question, while showing
them a raw draft of the shop. In the prototype we gave Heidi three sentences to say.
She really spoke; for this prototype we had made a computer voice. But most of the
people get confused by that. Not everyone had enabled his audio boxes, and some of
them want to talk back to Heidi. If they were distracted, they did not follow where the
site was about anymore. After this, we decided to make the text Heidi was going to
say, not audible, but in a text balloon (see appendix pictures).You can see how that
looks on the screen shots in the appendix.
Furthermore, we find that our subjects had some problem with the shopping cart.
They didn’t really understand what the icon meant, so we did a test and made several
icons and the one being used now came out best. (see appendix pictures)
Second user evaluation
In this user evaluation we didn’t only do a questionnaire, but we also did some observations.
We saw that most of the subjects chose to get help from Heidi by entering
the shop. From this we concluded that Heidi is a good concept to lead people trough a
site.
In the questionnaire our users reported us that they feel comfortable. They talked
about Heidi as if she was the nice girl next door.
Their feeling of comfort was not only because of Heidi, but also because of the nice
design of the shop, which they liked. After this evaluation, we just made a few little
changes.
Remarks from Presentation
During our presentation in class, someone gave us the advise to make the cash desk
inside the 'scrapbook', which is located on the right. This looked to us as a good idea.
But finally, we did not apply it because of lack of space, and stylistic prospective. Our
user group understood how it works anyway. Some of them even said: 'It felt natural,
as if I was going physical to the cash desk'.
Another remark was that you were able to compose a bouquet of your own. We
thought that was a good idea, so that’s another thing we added to our final product.
Someone recommended us to use some special software for designing Heidi and let
her talk. Finally we didn’t use it because we changed the whole concept about the
talking of Heidi.

5 Conclusions and Discussion
Our solution to use Heidi, worked quite well. We learned from our user evaluations
and changed some major things.
We thought that a speaking (with sound) saleswoman would be a good idea; we
saw it on several big sites. But in our case it didn’t work quite well.
Furthermore, the shopping car icon was a problem at first, so we made a few test
icons, and we let the users choose which they thought are the best. Although the current
one came out best we still think this is a part that could be improved.
Another point of discussion is that right now we based it on a small collection of
items which can be sold. If you would have a very large collection of items in the shop
it would require a lot of enhancement to effectively find what product you’re looking
for.
6 Future Work
When it is more common to have a speaker (which is on) and a microphone on your
computer; it will be very nice if Heidi really speaks to you, and you can answer with
your voice. Therefore you need a very good and stable voice recognition system.
Composing a bouquet could be more clear. For example, you really can see your
bouquet composed, so if you add a flower you see the bouquet grow.
Heidi is now just a static picture with a text balloon. But it might be nice if she
would be more dynamic, had some facial expressions, so she would be more like a
‘real’ person.
References
1. John Meada The Laws of Simplicity (Simplicity: Design, Technology, Business, Life)
ISBN-10: 0262134721 ISBN-13: 978-0262134729 see also: http://lawsofsimplicity.com/
2. http://www.useit.com/alertbox/reading_pattern.html
http://www.useit.com/eyetracking/ F-shaped pattern for reading a webpage; Jakob
Nielsen and Kara Pernice Coyne

Appendix

Cashdesk:
Shoppingcart icon:

Barschedule Catena
Christian Detweiler, Stefan Schrama
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
cdetweil@liacs.nl, sschrama@liacs.nl
supervised by Alexander Nezhinsky.
anezhinsky@casema.nl
Abstract: We have successfully written an online subscribing system for the
barshifts on VSL Catena.

1 Introduction
In the world of automated systems, there are a lot of different subscribing systems for
all sorts of things. One of the things that didn’t existed was an online subscribing
system for the bartenders at VSL Catena. Our goal was to write such a system, both
simple and with a good overview.
2 “Short Subject Background and problem definition”
At Catena current barshifts are being subscribed to by filling in your name in a
timetable on the kitchen door or by the Head of Bartenders, who calls you and then
fills in your name. This means that you don’t know who is going the be the bartender
for a certain shift, unless you are physically at Catena. The Barcomity at Catena was
looking for a better sollution and contacted the Networkingcomity. I, Stefan Schrama,
am the president of the Networkingcomity and decided to make this assignment into
my HCI project. Together with my course partner Christian Detweiler we started
developing the system.
3 The Approach to solve the problem
A Simple Approach
Simplicity is central to this project. The application has to be clear enough to be used
without any explanation. To achieve the required clarity choices were made on
different levels.
Global layout
At the highest level a distinction was made between 1) information and functions
related to the user, 2) information and functions related to navigation, and information
and functions related to the bar schedule itself. The layout of these components that
was chosen reflects the importance of each component to the application as a whole.
The navigation component, which is the most frequently used component, is located
at upper left of the screen, because this is where most of the users (who are used to
reading from left to right) begin viewing. The size of the navigation component is
limited, because the interactions with this component, although frequent and
important, are short. The user does not have to stay focused on this component very
long. Directly under the navigation component is the component for user information
and functions. It is located under the navigation component, because it does not
require the user's immediate attention. The information displayed in this component is
generally information the user is already aware of, and the displayed function are
usually only used once per session. Therefore, the component's size is limited. The

entral component of the application, both visually and functionally, is the bar
schedule. It is located in the center of the screen, because it should be the point of the
user's focus most of the time. For the same reason the size of the bar schedule
component (about 3/5 of the screen) was chosen. Another reason for the size of the
bar schedule component is the space required for the various elements of the bar
schedule, which will be discussed in more detail below. Besides the placement of
components based on the user's focus, the navigation component and the barschcedule
component are located next to each other because actions taken by the user in the
navigation component directly influence what is displayed in the navigation
component to its right.
Layout of the individual components
In designing the components attention was paid to each component's function, and the
relation of (some of) the components to one another.
The navigation calendar consists of a part for navigating from month to month within
the component, and a part for selecting a week for display in the bar schedule
component. The part for navigating from month to month consists of a drop-down
menu with the number of the month and one with the year. On the sides of the menus
are arrows for navigating to previous and next months. Under the navigation section
there is a calendar, in which the week displayed in the bar schedule component is
shaded. When the user moves the cursor over the various weeks the cursor changes to
indicate the week is 'clickable'. Also, the week under the cursor is highlighted. Weeks
are selectable as a whole, because that is how they are displayed in the bar schedule
component. To further emphasize the relation between the calendar component and
the bar schedule component the color of the selected week in the calendar is the same
as the background color of the week displayed in the bar schedule. Also the row of
day names in the calendar has the same color as in the bar schedule.
In the bar schedule component, the days of the week are displayed vertically (as
opposed to horizontally in the calendar). Although this may seem counterintuitive, it
is consistent with the layout of the "paper version" of the bar schedule currently in use
at Catena, so it is familiar to the users. The content of the bar schedule depends on the
role of the user, which can be Head Bartender, Bartender, or Normal User. If the user
is a Head Bartender, the barschedule will contain the names of people signed up to
tend bar during each of the three shifts that are available every day of the week. If the
user clicks on a name, information about that user is displayed on top of the schedule.
Next to the name is a button to send a reminder (or other message) to that person. A
simple form with which to send the mesage is displayed over the schedule, so the user
doesn't have to navigate away from the schedule. If a shift is not full, the word
“nobody" is displayed instead of a name, with a button next to it to send a message to
all Bartenders encourage them to sign up for that shift. Again a simple mail form is
displayed over the schedule. If the user is a Bartender, a green button with the label
"sign up" is displayed for all empty slots, a red "sign out" button is displayed in all
slots the user has already signed up for, and a user name is displayed for all slots
filled by anyone but the user. The buttons are large, clearly colored and labeled, to

limit the possibility of any confusion as signing up and signing out are the most
important functions of the application. To further enhance clarity, changes to the
schedule are immediately visible, instead of appearing after the page has reloaded, as
is often the case in web-based applications. If the user is a Normal User, only
bartender names are displayed in filled slots.
The user information component (under the calendar component on the left) displays
user information such as name and role, as well as a "log out" link. A link was used
instead of a button, because in logging out the user navigates to a page away from the
application - all other buttons have effects within the application. If the user is a
Bartender, there is a button labeled "view all of your shifts", which, when clicked
upon, causes an overview of all the users entries in the bar schedule database to be
displayed (again on top of the bar schedule) so the user does not have to view every
week seperately to see if he or she has signed up for a shift.
4 Results and Evaluation
The evaluation went smoothly, the main reason for this is that the system is almost
finished. Logging in was easy, although I found out that my data in the Catena
database wasn’t filled in correctly. The weekview looks really good and is easy to use.
The monthview made it very easy to select a different week. –Pim, experienced
bartender
The presentation raised two big questions. The first one was about our
weeknumbernavigation just above the weekview. Remarks about confusion with the
monthnavigation on the left side of the interface were taken into consideration and we
removed the navigation on top of the weekview and moved all navigation in the
calendarlike monthnavigation, wich now also includs week selection. The second
question was about the fact that you had to fill in your name if you wanted to
subscribe for a barshift, this when you were already logged in and your name is
known by the system. This was a good remark and that’s why we just made a
subscribe-button, wich fills in your name automatically.
The questions at the presentation influenced our design positively. The evaluation
didn’t really help us, it just made sure we made a good system.
5 Conclusion
We are very happy we succeeded in making a simple system with a great overview on
barshifts, despite all the functionality the system has. Ofcourse we ran into some
problems, but that’s just part of the process. All problems were, in the end, fixed so
we were able to turn in the project before the deadline.

6 Future Work
There is room for some expansion in the system, for instance we could add a page for
subscribing to a cocktailbar shift or the daily mensa at Catena. Maybe the users of the
system think of something nice to implement. Anyhow, the system has all the
functionality the Barcomity expected, but there is always room for improvement.
Appendix
De interface

Police Academy :
Training Tactical Actions
of the Police
By Eric Kuijl
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
erickuijl@tiscali.nl
supervised by Sander van der Maar and Fons Verbeek.
svdmaar@liacs.nl & fverbeek@liacs.nl
Abstract. To make our society a safer place it is very important that police officers
get good education and that they keep their knowledge up to date. I designed
a program that makes learning and training easier for the police students
and their supervisor(s). With this program police students –individually or in a
team- can train their knowledge of the law and of police authority in a more
motivating way than they are used to now. The fact that students can level the
questions in difficulty and the fact team training can be done can be considered
innovative in this area. After being reviewed by current police students the program
seems to be quite useful and attractive to them.
1 Introduction
These days public safety is a hot item but lack of money and expertise resulted in
chaotic and old fashioned ways of educating police officers. To support the authorities
with educating their personnel in a better and more up-to-date way I thought of a system
which gives police students the opportunity to train and update their knowledge.
I created a program that police students (rookies or police officers who need to update
their knowledge and/or update their skills after several years on duty) can use to learn
specific knowledge so they know what to do in certain situations. These situations will
be realistic situations which the police officer might run into during his daily work.
The program can be used as training to test the knowledge of a police officer individually
but also for formal evaluating of police officers (exam).
In this paper the general background of the current situation is described as well as the
users involved. Furthermore I describe my solution to the problem,. the program and
the evaluation with potential users. I conclude this paper with possible discussion topics,
conclusions and possible future work.
1

2 Background and problem definition
2.1 Background
Since I work daily with police officers and police students I noticed a lot of those police
students and officers being unhappy with the current situation regarding police education.
At this moment education methods specifically focused on gaining knowledge
of the law and police authorities on the street is very outdated. Police students have to
work with questions on paper (mostly multiple choice questions) and studying in
books. Since I think it is very important that police officers are well educated I
thought of ways of improving the way police students can learn the law and police authorities.
A safe society is partly a result of well educated police officers!
There are other developments regarding police education but they do not focus on
knowledge gaining but more on specific skills. For example the police already use
shooting simulators for teaching police students when and how to use fire arms. These
skills are labeled as ‘competences’ by the Dutch police academy. Knowledge gaining
is mostly done by the police students in their own time and during lectures. They only
visit the police academy to visit lectures, to learn skills (competences) and to do exams.
As stated earlier the problem is mostly experienced by the police students themselves.
They want to have a better way to gain knowledge necessary for police work and to
pass the exams of the police academy.
2.2 User analysis
The user group consists of male and female police students and supervisors. Most of
the police students just started with the police education and have an age between 18
and 30 years old. Also older police officers would want to train long forgotten knowledge.
The age of these officers will be between 45 and 60 years old. The police students
with lower ages usually have more experience with computers but most of the
older officers will not have that much experience in computer use. All of these users
are familiar with using simple computer desktop environments (like word processing)
since that is necessary for basic police work. For a large part of the users this is almost
the only thing they do with computers so the interface must be usable with the
greatest ease.
The student supervisors will only use the program to add or delete questions or categories,
to create exams and to do other administrative tasks. The supervisors will
mostly be older than 30 years old since you can only become a supervisor when you
are an experienced police officer yourself.
2

3 Police training
3.1 General
Since I focused primarily on the police students gaining knowledge I had to find a way
to make them learn easily and quickly. This should also be possible at another place
than the police academy for instance the home of the police student since the police
academy states that studying in own time is important.
I chose to transform the original pieces of paper with multiple choice questions to a
computer program in which the police student has to answer multiple choice questions
of a specific category like arresting suspects, traffic, using violence et cetera. These
questions are chosen randomly by the program and the student can –after answering
the question- chose a difficulty level to evaluate that specific question. If he thinks that
this question was very difficult the program will ask the student more questions about
that specific subject and/or repeat that question later on in training. I chose this approach
because by using the difficulty level the police student can easily train himself
and find the gaps in his or her knowledge and train that specific topic more often. Also
training for an exam of a certain category can easily be achieved. If the student chooses
the wrong answer a message will be showed that the answer he chose is the wrong
answer. If the police student gives the correct answer a sound will be played and an
explanation will be showed why the answer is correct. By using this method the student
does not only know that he answered the question correctly but also knows some
more of the why and how and eventually learn theory without a lot of reading from a
book.
I also thought of implementing a team aspect in the program. It seems quite useful to
train team capacities with a program which students can use in their own time. This
can be achieved by sketching situations in which the student works together with other
people and has to make decisions within the team. The program can be used on a computer
network at the police academy but this might also be possible from the student’s
home using the Internet to communicate with other students.
Another option in the program is an exam mode. The students can log into the system
and do an exam made by the supervisor. This time they do not have the possibility to
level the question in difficulty and all the questions are time driven since police officers
also have to make these choices on the streets quickly.
The last option in the program is the administration mode for the supervisors. In this
mode a supervisor can select questions he wants to ask the students at an exam, add
and delete questions from the database and other administrative tasks.
3

3.2 Requirements
The program should be very approachable, as the intended goal is to learn, and nothing
in the interface should be anyhow directing away from this goal. Therefore the
user-interface is Windows based of which police students are all familiar with. Also
the user-interface is usable as simply as possible without losing essential functionality.
The program should work intuitive so that a student does not need much time to understand
what is on his or her screen. This means that the student does not need a lot
of explanation or help from someone else when using the program. Like this all police
students will be able to work with the system and feel comfortable using it.
4 Results and Evaluation
4.1 Presentation of paper design
During the presentation of the paper design for my fellow students I took note of some
comments and suggestions they had. One of the comments was that the logo of the
system was quite big and distracting because of the colors used. I agreed with that
comment and I made the logo a bit smaller and less fancy so the attention of the user
would stay at the question part of the screen.
Another suggestion was to look at the time it takes for the user to answer a question to
see if the user does not know the answer and just takes a gamble. Since I did not really
saw the purpose of implementing such a thing in this program I did not agree. The system
is meant for the police student who needs to train for an exam and he is not saved
by a system who tracks it if he takes a gamble. Also during an exam the correct answer
counts, disregarding if you take a gamble or not. So I did not implement this in the
program.
After the presentation a discussion started between me and some of the students about
the team training part of the system. Fellow students thought that it would be a good
idea to make it scenario based. After discussing this idea with police students later on
it became clear that team training is done in real life with actors and that this part of
police education is something of which most police students are fairly happy with. According
to some of the police students it could be possible to implement team play in
the program but then it should be presented as a (theoretical) preparation for actual
team training. It was clear that most of the police students think that especially gaining
theoretical knowledge is the most important part which can be improved compared to
the current educational methods. Since it is not very clear if team training is really
something the police students want and because I did not have sufficient time for implementing
it within this project, I decided to not implement a team training part in
this system but keep it open for future discussion. It will be mentioned in the prototype
but is not available (yet).
4

4.2 Evaluation of paper design
With the first user evaluation I wanted to get feedback from the evaluator concerning
the learning process used in the program, the layout of the screens, the colors used in
the screens, the questions asked to the user in the program, the specific texts used in
the program and interaction possibilities. I wanted the evaluator to look at the screens
and think aloud about good and bad things he saw or thought. I was seated next to the
evaluator and wrote down what he said. I took note of the physical reactions of the
evaluator (for instance expression on the face) and wrote that down. Images of the
screens can be found in Appendix A.
The evaluator was a male person between 25 and 30 years old and was at that moment
a student at the Dutch police academy. He just started his 2 nd year at the police academy
and had basic knowledge about computers (word processing) and using the Internet.
The first reactions of the evaluator were positive. He thought that the screens looked
professional and nice. He did have some suggestions to make the screens more user
friendly and police officer proof. For example he said that during training time driven
questions are not needed since it is training; during exam time driven questions might
be an option. He also thought that it is a bit strange that a Dutch program has an English
name (which at that time was ‘Open Learning Environment for Law Agencies
aka OLELA) so he suggested to use a Dutch name for the system. He promised to give
me a list of questions and answers that are used at the Dutch police academy. I agreed
with his comments. Eventually I changed the name of the system into Training Tactisch
Optreden Politie (TTOP) (In English : Training Tactical Actions of the Police).
4.3 Evaluation of prototype
The second user evaluation took place with the same evaluator. With the second evaluation
I wanted to get feedback from the evaluator concerning the usability of a working
prototype. Therefore I used a questionnaire in which the System Usability Scale
(SUS) is used. I showed the evaluator a set of questions and the evaluator had to give
a value to different parts of the prototype. After having the evaluator work with the
prototype and after he answered the questions we had a personal conversation about
things that the evaluator was not able to answer in the questions. It is possible that the
evaluator had more comments than was arranged for in the questions so with the free
discussion the evaluator got the opportunity to give that specific feedback.
First of all the SUS questionnaire gave a result of 9.5 which shows that the evaluator
is very enthusiastic about the usability of the prototype. Since the evaluator also did
evaluation 1 it might be wise to let some other evaluators fill in the questionnaire as
well. There might be change there since these evaluators are totally new to the prototype.
Since not enough time was available within this project more questionnaires can
be done at a later time. The SUS questionnaire filled in by the evaluator can be found
in appendix B.
5

Secondly the evaluator had some comments like the fact that it would be more attractive
to show the grading of difficulty of the question after the questions has been answered.
Like that focus will change more clearly from the question to grading the
question. He also thought that it is better if more explanation is given why the answer
the user gave is correct. Also he added that it would be useful if the user can chose beforehand
which category he wants to get questions from. He said that it would also be
nice if the user can choose more than one category or simple choose all of them. And
again, I agreed with these comments.
I did not agree with his comment that after answering a question you should not immediately
see if the answer is correct or not. I think it is clear that a person first thinks
about the question before answering it so before answering the question the user
should always make up his mind. Since it is training and not an exam it is not a disaster
when the user at the first question makes this kind of mistake. After that it is clear
to him how it works and will not make the same mistake again.
During the discussion –while talking about education at the Dutch police academy- I
decided to not implement sounds in the system. The computers at the police academy
are in one computer room so the use of sound would be very annoying for other people.
Also most computers at the police academy are not equipped with headphones or
speakers.
5 Conclusion and Discussion
As a conclusion I can say that the police student I had contact with, was very happy
with the TTOP system. He thought that the design was clear, good color use (blue
background as ‘police color’) and a professional look. He felt comfortable using the
system and he thought that he would use a final version of the TTOP system in the future.
The SUS result of 9.5 underlines this conclusion.
Looking back at the evaluation moments it is clear that these moments have been very
valuable for developing the TTOP system. Lots of time you –as the designer of the
program- think about things from your own point of view. You think of what a user
might think of the several aspects of the system but it is much better to ask the users
themselves.
The comments and suggestions given by fellow students and the evaluator regarding
the prototype were very useful and I agreed with most of them. It also opened discussions
and made me think about specific parts of the system in a more detailed way.
For example the team training part of TTOP seemed quite simple to me in the beginning
but turned out to be much more complex. Together with police students I could
not find a good way how to implement such a thing and there wasn’t even consensus
about a team training part being useful.
6

6 Future Work
In the future some more work can be done related to the team part of the system. Research
can be done to see how team training works at the Dutch police academy at this
moment. With that information and in cooperation with potential users it might be
possible to determine if and how team work can be attached to the TTOP system.
Also some more user evaluations can be done (like the SUS questionnaire) to gain
more insight views about the usability of the TTOP system according to new potential
users.
References
1. Bevan, N, Kirakowski, J and Maissel, J, 1991, What is Usability?, in H.-J. Bullinger,
(Ed.). Human Aspects in Computing: Design and use of interactive systems and work
with terminals, Amsterdam: Elsevier.
2. Brooke, J. SUS – A quick and dirty usability scale.
3. Dix, A., Finlay, J., Abowd, G.D., Beale, R. Human-Computer Interaction (3 rd edition,
2004).
4. Kirakowski, J and Corbett, M, 1988, Measuring User Satisfaction, in D M Jones and
R Winder (Eds.) People and Computers IV. Cambridge: Cambridge University Press.
5. Pratchett, T., 1990 Moving Pictures. London: Gollancz
7

Appendix A
8

Appendix B
SUS Questionnaire
1. I think that I would like to
use this system frequently
2. I found the system unnecessarily
complex
3. I thought the system was easy
to use
4. I think that I would need the
support of a technical person to
be able to use this system
5. I found the various functions in
this system were well integrated
6. I thought there was too much
inconsistency in this system
7. I would imagine that most people
would learn to use this system
very quickly
8. I found the system very
cumbersome to use
9. I felt very confident using the
system
10. I needed to learn a lot of
things before I could get going
with this system
Strongly Strongly
disagree agree
X
X
X
X
X
X
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
X
X
1 2 3 4 5
1 2 3 4 5
X
1 2 3 4 5
1 2 3 4 5
X
1 2 3 4 5
1 2 3 4 5
9

Seek the thrill
Fee Yun Wong, Kees Koffeman, Maja Jakóbik
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
fwong@liacs.nl, kees@koffeman.net, mjakobik@yahoo.com
supervised by Mounia Belmamoune
mounia@liacs.nl
Abstract. An existing non-commercial website for searching information about
the items on the book list of Vrij Nederland is redesigned during our project.
The very valuable information should be found and presented in an easier and
more attractive way. Splitting the information and functionality over a number
of tabs and using different kinds of search methods makes our site different
from the old one. It also differs from the most commercial sites. Hopefully it is
easier to use and more attractive for the users. Moreover the maintenance site
has taken into account and made consistent with the site for search engine.
1 Introduction
Vrij Nederland (VN) is a Dutch weekly magazine featuring critical articles on current
events and unveiling interviews. Political issues, national and world news, business,
society and so on are discussed in the magazine. Since 1980 VN has been releasing a
detective and thriller guide which is an extensive list of titles obtainable in Dutch,
every summer. The 27 th edition has been published on 2006 June 3.
A database for the list of detectives and thrillers has been set up by W. A. Kosters
and H. J. Hoogeboom. Its interface design must be improved, as it is not very user
friendly. A lot of information has been gathered on one page which makes the website
visually and its usage not pleasant. To solve this problem the product is renewed and
evaluated in order to build a basis for further development in the future.
2 Redesigning an existing website
As the information in the database is very valuable, the makers of the site would like
to strive for as many visitors as possible. We have investigated another approach to

make the site easier and more attractive, what hopefully results in an increasing
popularity of the site.
The present site gives too much information on one page. The structure of the
information is not very clear which makes it confusing. The legibility of the text is
very low. Besides that the combination of the used colors makes the interface not very
appealing.
On the other hand, we have taken a look at the commercial sites, like
www.kooyker.nl, www.bol.com, or www.amazone.co.uk.
All of them concentrate on giving as much information at once as possible.
Trying to catch the visitors’ attention for promotions and bestsellers which ends up in
an interface full of information, many colors, flicking text, pictures and animations.
The search part of their sites is quite the same – an area with a few fields to fill in the
search criteria surrounded with all the other distracting information.
It is very difficult to determine what is easy and attractive for a very large and
much differentiated group of people. We cannot concentrate on only the gender, age,
religion or skin color. We merely know that our users can read Dutch (or came on our
site by accident and will not stay for long) and are interested in reading, especially in
thrillers and/or detectives. The rest of the characteristics we can only guess.
The maintenance of the database is also very important. It still has to be done by
retyping the information from the list published by VN. Assistance during this
important yet dull task should be given, so there will be less chance of errors and
faster to recover them.
This task is done by an expert in computer science and a frequent user of the
Internet. The work of a data typist is not a task which can hold his interest for long,
thus it must be done quickly and efficiently. More time and energy can then be put in
searching for other information such as interesting facts about the concerning authors,
titles, movies based on the books etc.
3 Seek the thrill
As we are not designing a commercial site, we do not have to catch the users’
attention for the best selling titles or the lowest prizes (figure 1). We can concentrate
on providing a few good approaches for searching, as we expect it could be
interesting for the users. In addition splitting the background information from the
search functionality and splitting the different search approaches supply the user more
rest and it is still easy to reach and to find (figures 4, 5, 6, 7, 8 and 9).
Keeping it simple makes the site easy to use, even for new visitors. We had to
make assumptions that the user will know a few basic things. When you would like to
search for books of a particular author, you will probably be asked to type in his/her
Seek the thrill 2

name. And that will be probably on a tab or a field with text “Author” as description.
An idea of tabs is also assumed as broadly known and used one.
The user is free to choose the way he wants to search for information. Whether all
titles of a particular author are desired or more search criteria are expected, it is
possible and easy to find. Because of this our search engine provides users a lot of
flexibility.
As we provide the user with a lot of lists, we prevent the user for making mistakes.
Naturally a slip is still possible (e.g. selecting a wrong item in the list which was in
the neighbourhood of the desired item), but it is easy to recover and gives the user a
clear view of the possibilities. He can efficiently give the criteria for searching by
genre, period or series.
The attitude is the most subjective usability aspect. How do you make sure your
users will not become frustrated or bored when using your site? What to do to let
them keep visiting it again? How to make sure they feel comfortable, interested and
satisfied? We must think about aesthetics as much as about the correct working
program. We have chosen for rest, survey ability and easiness. Soft colors, not too
much text on one tab, no flicking or moving objects – that is our approach. We hope
that the users will not miss those aspects and that the provided information with extra
interesting facts will keep the attention.
On the other site a person will do the maintenance task. This part is secured by a
login (figures 10, 11, 12 and 13). The rest of this site is kept quite consistent with the
search part. The different approaches are on different tabs, lists are provided where it
is possible. The possible errors should be easy to recover.
4 Results and evaluation
The first prototype has been evaluated by a few persons. We concluded that dividing
the information over tabs and giving the different search approaches especially, were
found both attractive and easy to use. Based on the reactions of our testers we think
that learnability and flexibility targets has been met. The fact that no mistakes were
made, suggests that also efficiency is satisfied. But the attitude still asks for more
attention. Our testers found the site boring and sober. The colors were not vivid
enough. Moreover the impression of the presentation of the results of search part was
called not well-organized. Our second prototype deals with the question of colors but
we have found it very difficult to present the search results in a different way. The
information is very difficult, perhaps even impossible to structure as it contains a lot
very different aspects and facts.
For the maintenance we used the walk-through evaluation method with talking
aloud. Our conclusion was that the site is easy to learn and to use. Here, other aspects
of usability are important. The feedback of actions, not loosing the track of actions,
Seek the thrill 3

finding and correcting the made errors are as much important as making it both easy
and efficient as possible.
5 Conclusion and discussion
As we got through the possible tasks and the analysis of the users, we found it quite
easy to find a good surveyable way for implementation. Functionality, especially for
the search part, is quite easy and mostly already exists. But we still have difficulty
with finding the satisfactory balance between de boring rest and screaming vivacity.
We as designers found that soft and bright colors are better fitting, but our testers
found it boring and sad. The same story applies to the maintenance part. We wanted
to emphasize the feedback of success or failure of the taken actions, but using red and
green makes it very sharp, especially in contrast with the sober background we prefer.
You do not want to look at it longer than for a few moments.
Another interesting point of discussion is the presentation of the search results.
Now the testers found it very chaotic. At the first impression it is ordered by author,
indented for titles, but after that there is a lot of different information about a book,
which is very difficult to present in a different and more structured way. And yet the
same story holds for maintenance. How to make it easy and surveyable to get as much
structure as possible when inserting all those information? And how to make it a more
attractive task? After all it is data typing, not really a creative task (and it will stay this
way, as long as there will be no other way of input, like an electronical file is handed
over by VN, which perhaps needs just inserting some extra information). Even
searching for extra information or struggling with names and original titles in strange
languages makes it not very exciting task to do.
6 Future work
The design of the site gives space for future additions and changes. As we have seen,
some ideas to make the site more fun can be explored. Perhaps the pictures of covers
by the titles (or when “boring” cover, a picture from the book) could be added.
Perhaps more and different search criteria could be provided. A bit of data mining
could be done, by presenting the top 100 most searched titles or most appreciated
titles by readers. The possibility to give an own opinion about titles could be made
and the results analyzed. And the open issues from this moment could be solved.
There could be also an extending for DVD, CD-ROM etc., but this part depends
more of what plans has VN.
Seek the thrill 4

References
1. Search prototype, http://koffeman.net/hci/2/
2. Maintenance prototype, http://www.koffeman.net/hci/2/admin/
3. Dr. Ir. Fons J. Verbeek: HCI Practical Assignment, LIACS (2006)
4. Dr. Ir. Fons J. Verbeek: HCI Lecture slides, LIACS (2006)
5. Alan Dix et al.: Human Computer Interaction, 3 rd edition, Pearson-Prentice Hall,
(2003)
6. VN Detectives en Thrillergids … 10000 titels,
http://www.liacs.nl/~kosters/vnster.html
7. Vrij Nederland VN, http://www.vn.nl/vn/show
8. Kooyker site, http://www.kooyker.nl
9. Amazone site, http://www.amazone.co.uk
10.Bol.com site, http://www.bol.com
Appendix
Search part
Figure 1: Home
Seek the thrill 5

Figure 2: Help
Figure 3: Contact
Seek the thrill 6

Figure 4: Search title
Figure 5: Search author
Seek the thrill 7

Figure 6: Search genre
Figure 7: Advanced search
Seek the thrill 8

Figure 8: Browse
Figure 9: Quick search
Seek the thrill 9

Maintenance part
Figure 10: Login
Figure 11: Author main screen
Seek the thrill 10

Figure 12: Edit author
Figure 13: Add new author
Seek the thrill 11

Whiteboard
Kerem Denizmen, Sjoerd Kranendonk
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
kdenizme@gmail.com, sjoerd.kranendonk@gmail.com
supervised by Yun Bei, Fons Verbeek.
ybei@liacs.nl & fverbeek@liacs.nl
The Whiteboard project was conceived specifically for the liacs faculty to provide
a uniform structure for every course website, unlike blackboard, focusing
more on the interface than on functionality. The main goal of the project was to
incorporate an easy to understand structure for student to perform there school
tasks and gather information about the course and its content. The innovation
that Whiteboard brings is more the sum of its parts then a single idea, the cupboard
structure, tabs and Q&A sections all contribute to this. We have shown
that there are much more pleasant interface alternatives to blackboard and that
data can be nicely organized so that it can be used for every course.
1 Introduction
The Leiden university incorporates a data organization website called Blackboard
[1], where course sites and other functionality are gathered in a uniform way for the
students. The interface of Blackboard course sites were in our opinion lacking in
organization and interface design while incorporating many (useful) functions. Also,
the liacs (Leiden institute of advanced computer science) [2] faculty members don’t
use the blackboard as there portal for course sites but rather use there own websites
for course data, which results in different websites for every course with some being
better than other. The Whiteboard project was conceived to offer a better alternative
to Blackboard course websites, and also unifying the structure of the liacs faculty
course sites. In general, our approach to the problem was very user centered, what
would the students like to see on the course sites, and what are the most used features
of a course site that students use. Combined with suggestions from teachers, we believe
we achieved our goal of offering a basis for liacs course website design. Our
paper will discuss the methods used for Whiteboard website organization and overall
approach to the problem of organizing course data.

2 “Short Subject Background and problem definition”
The Whiteboard project was not meant to be a groundbreaking innovation, but more a
guideline for how course data organization should be handled for the liacs faculty.
Other goals of our project was to make students more efficient(and feel more pleasant)
with using course sites and give teachers a nice framework to organize there data.
Uniform course data organization can be difficult because there are many different
courses with different requirements for every course. Because of this, there should be
clear categorization between various course needs. A uniform course website should
address all these needs in the basic design, even though it will probably not be used
by some courses. Categorizing various course needs was one of the most difficult part
of the Whiteboard project, this was because we wanted the site to be elegant and
simple, yet incorporating everything that all teachers need for there courses. The look
of the site was also made to feel more pleasant than that of Blackboard, because we
feel that this is also important in motivating students to use the course sites more, and
of course to give a more professional feel to the liacs faculty.
3 Tabs, cupboards and style.
The General idea for Whiteboard was that students could find data efficiently and
prevent the screen from being cluttered. The look of the site was also one of the main
subject we paid attention to, with the intention of it being simple yet elegant. We
intentionally kept the site simple and didn’t want it to have very much functions like
Blackboard, we felt that this could be confusing and a lot of the features would probably
not be used.
Our approach to the look of the site has been consistent with what we want to achieve,
and attractive looking site which is formal yet functional and doesn’t have unnecessary
colors or other paintjobs. We didn’t want to fill the screen with too much text
either cause this can hurt the design [3]. The design was meant to be more appealing
to the students (the younger generation), although it can surely be improved, the
established look of the site is certainly better than we expected.
3.1 General design:
Our main approach to data organization in course websites were tabs. This was
mainly because we needed a good solution to categorize the main topics found in
course websites. The tabular approach gave the students a more efficient way to navigate
the course site and also gave the course site more style than other alternatives.
The tabs were designed to have a good visibility (big) while not being distracting for
the student, also, we wanted the tabs to look good but not distract, so we chose for an
“apple” look for our tabular structure.
The tabs categorize the course site in many different subjects. The subjects that are
implemented are General, Lectures, Schedule, Lab, Practice, and Q&A. Each has its

own page consistent with the rest of the site. Within each of the pages, we used a
cupboard metaphor. Students can open each of the cupboards and take out data, the
cupboards close when another cupboard is opened, this to prevent clutter and to prevent
making the page unnecessarily long. The cupboards are of course just big buttons
(blocks) which can be clicked, when clicked, they open up and a field appears in
front of the user, which can hold links, text or pictures. This approach of cupboards
resulted in a compact site where very little scrolling has to be done to get information.
We felt that by keeping everything compact with tabs and cupboards, the user would
be able to be more efficient than on Blackboard. The cupboard metaphor is consistent
within all course pages and this makes navigating the site much easier. The cupboard
does have disadvantages of course, in some instances it can be useful to have data
organized in a table which we have done with the schedule. The schedule is more
clear in a table form because one can see the complete schedule with one look at the
page. If we had tried to be fully consistent with all pages, we would have traded off
ease of use for consistency but we decided that consistency was not important enough
to dismiss ease of use in this particular instance.
New announcements are presented to the user in a red box so that it catches attention.
This could of course be expanded later on so that the teacher can decide which color
the announcement will appear. We wanted new announcements to appear at the top of
each page, and that they were disposable. By clicking on the x button, the announcements
can be discarded and can be alter found on the news page.
The Quick jump buttons were intended for pages that stretch longer than the current
page size. To prevent scrolling, the quick jump buttons were implemented so that the
user can jump to a cupboard in an instance. Even though it is meant for long pages,
we found that this feature was also used a lot on single screen pages, so it also ads
flexibility in the way the user wants to interact with the site.
3.2: catogories
One of the more difficult parts of the design was to categorize the different headings
and also the cupboards. Many changes have been made to the category part of Whiteboard.
As mentioned earlier, we categorized the main headings into General, News
Lectures, Schedule, Lab, Practice, and Q&A tabs. Cupboards within the tabs were
also categorized, with most being straight forward like course lecture numbers the
General tab was the most difficult to categorize the cupboards as we didn’t want too
much data in one cupboard, but we also didn’t want it to be near empty.
The General page is the default page that loads up, here Students can see new announcements,
course information and contact information, all organized in cupboards
and clear headers. Links to emails are provided in the contact header.
The news page is where all the past announcements are going to be placed, as of the
writing of this report, it is still undecided how the information is going to be presented,
but we do not intend to be inconsistent with the rest of the site.

The schedule page is little different than the other pages, it presents its data in a tabular
form because this seems to be the best way to present a schedule for a course. We
decided to implement the schedule page after the implementations after we had some
comments about how that was the best way to present schedules. The schedule has
links to the lecture page, where students can download course files from that lecture
and see general information about the lecture. The schedule is meant to have a quick
look at what is coming and what the topics are.
The Lectures and Lab pages are the pages that the student will probably use the most,
they contain the cupboard style and let students click on the cupboards to download
lectures, papers and Lab work. Its pretty much consistent with the rest of the course
site and there is nothing out of the ordinary about it.
The Practice page is meant to be a page where the students test there knowledge and
practice for the exams. Quizzes and exams are presented as links. When a student
clicks on the Quiz links, they are sent to the corresponding quiz page which is again
using the cupboard style of web design. Students answer questions in a multiple
choice format and get the results of there quiz after they fill out all questions. The
exam links send them to the exam page, which again complies to the cupboard style,
this time in an exam question and answer form. This was done intentionally so that
students can see the answer to the corresponding question whenever they want on the
same page. It is cumbersome to switch pages all the time to check the question and
answer of the exams on some other liacs course sites. If the teacher wants, it could
still link the exams to PDFs.
In the Q&A page we wanted to give students feedback as to who answered the question
and which questions are still pending. We decided to have pictures of the assistants
and lecturer posted before every answer. This was because a picture can be very
effective in quickly showing information and is also handy for students to recognize
there assistants/teachers clearer. Pending questions are hidden away in the bottom
cupboard which students can use to see if they don’t ask questions that are already
pending to be answered.
4 Results and Evaluation
The users that evaluated our prototype were all rather positive, this seems to be partly
because of disliking the current systems (blackboard, liacs site), but the overall tendency
is also positive about the prototype in particular.
At the time of the first user evaluation there was not much to evaluate, except for the
general look and feel of the design and a first evaluation of the cupboard' style of
presenting information. This evaluation was done with only the standard SUS form.
There was also not much to get out of the evaluations, for instance the fact that all
three considered the prototype at that time somewhat inconsistent was probably because
it was not nearly finished, but rather sketchy.

The second evaluations were done with more students (of different universities) and
generated more results in terms of possible improvement. Overall this evaluation was
also very positive, but we must consider that part of this is because all evaluators
know (either of) us in one way or the other. For the results of this evaluation and the
things we decided to implement before the final presentation please check the second
evaluation report. Currently some of the changes have already been implemented but
some have yet to be done.
The things that are most visibly implemented in our solution (final prototype) are
taken from the various comments we asked our evaluators to provide. We also received
some usable advice in the 'open' comments. The way we set up evaluations
gave us what we wanted: direct critical comments on specific aspects of the prototype
and an overall grading of the prototype. This general grading was to see if we were
on the right track or if certain tab categories needed more improvement than the others.
We did not come up with new features on our own, but did implement some features
we previously skipped, for instance the announcements. We originally had this in the
design, but when we were told to focus and narrow down our functionality, it got
(temporarily) dropped. It was mentioned in the evaluations so now it it implemented
after all.
Screen shots are as an appendix, but the prototype can also be visited at the test site
[4].
The feedback from the assistant was not always clear, but this may have in part been
due to our project proposal and paper designs not being clear enough. This has however
resulted in some loss of time in figuring out what was expected from us in various
stages of the project. During the course of this project there were a few times
where we were not sure to continue with our own proposal or to switch to a new,
similar project, but our own proposal appealed the most to us so as you can see we
stuck to it.
From the start to the end there were some conceptual changes made. Initially we
wanted to just make the student part of the site, with a part for logged in and a part for
not logged in visitors. Obviously the part for logged in users would have more functionality
and customization options. After this proposal we were told to also think of
the other user group, the teachers, since they have to provide all the data the students
will want to use. Then after making a paper design concerning these three user groups:
not logged in visitors, logged in students and logged in teachers, we were told to
focus on one thing since it would be too much work to implement everything. This
lead us to the design that is active on the afore mentioned location [4]. The final prototype
is just a proof of concept because it lacks login functionality, edit functionality
and concerns just one course. Although the prototype is not fully functional we think
as a proof of concept it is still successful, as the user evaluations have pointed out.
The way of presenting all the course related data in a tabbed design in one page is
liked by all evaluators, especially in contrast with the current situation of scattered
data over various sources and pages (Blackboard, Liacs pages, PDF's etc.).

The usability requirements or specifications for the prototype are mostly unchanged
since the paper design, with exception of the compatibility regarding web browsers.
Internet Explorer is not supported in the final prototype, even if that is a much requested
feature by the user group (since I.E. Is a browser that is often used). We have
decided to focus (as stated in the evaluations) on the features and functionality of the
site instead of making it fully compatible. From experience we know that everything
we have done should be possible for both browsers and even for some more rare
browsers. We have just chosen to use our time for the functionality instead of compatibility.
The site is still usable with FireFox and a regular pc or mac with keyboard and mouse.
5 Conclusion and Discussion
From the evaluations and positive reactions to Whiteboard, it is clear that we made
the right choices for uniform course website design. Students would welcome a
course information structure that would present all related course data in one place
and on virtually one screen. Preventing clutter and giving the site an appealing and
simple look was one of our main goals for the project, and we had this planned even
within the infancy phases of the Whiteboard project. The cupboard style, tabs and
other functions all help in maintaining this view of simple and compact data organization.
Although Whiteboard is not a project about adding lots of functionality like
Blackboard, it still succeeds in implementing the necessary functions for students to
enjoy there coursework. Whiteboard also intentionally left out functionality to keep it
as simple as possible and prevent confusion. This project has no stand alone innovations
but is more an innovation in the sum of its parts, and was meant to be a guideline
for future liacs course site design. We feel that after the evaluations that our prototype
is even more improved and functional, even if we had to drop a lot of features
because of time pressure.
6 Future Work
Future work on Whiteboard could include better communications and more evaluations
with the teachers to understand how they would like the site to be set up and
what kind of topics it should encapsulate. Other useful work would be a message
board, as we wanted to do this but had no time to finish it. Also we thought about
certain options for users like turning off the closing cupboard functions and let them
stay open when clicked on. We would have liked to spend more time on the announcements
and the General page, so this could be a good beginning for future work
on the site. The biggest improvement would be to make a backend of the site so that
teachers could easily edit there site and put in content. Our beginning goal for our
project was to include a backend from the start, but as the scope of the project grew

igger, we had to leave it out and focus on other things. A login function was planned
for registered students, so that they could customize the functionality of the site and
maybe personalize there site but again due to time constraints wasn’t implemented
and left for future work.
References
1. http://blackboard.leidenuniv.nl/webapps/portal/frameset.jsp.
2. www.liacs.nl
3. Human Computer Interaction (3 rd edition) Alan Dix et al Pearson-Prentice Hall
4. http://mffonline.com/whiteboard/ firefox only

Appendix: Screenshots
(taken from http://mffonline.com/whiteboard, viewed in FireFox 2.0 for Mac)

Cargo Export Security Management Optimizer
Eyal Halm 1 , David van Paesschen 1
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
eehalm@zonnet.nl, david.vanpaesschen@gmail.com
supervised by Mounia Belmamoune
mounia@liacs.nl
Abstract. The security department of a cargo airline has the task to make sure
no bombs are being flown disguised in commercial shipments. The supervisor
of a security department has to manage each pallet through the appropriate
security procedures before it is loaded onto the aircraft. Nowadays this complex
and error-sensitive management task is done with the use of several sheets of
paper. In order to make cargo export security management more efficient, safer
and easier to handle we have developed a software tool named CESMO.
Working with this tool has shown to be more efficient, less error-sensitive and
very easy.
1 Introduction
Automation comes in degrees. In the most extreme form, automation is making a
certain process fully automated, i.e. the process will be no longer human-driven but it
will be working completely on its own. In a much weaker form, automation stands for
doing a particular piece of work normally done by hand, with the help of a computer.
In many industrial branches there is a tendency for using fully automated processes as
much as possible. Some tasks, however, we aren’t yet willing to hand over to the
computer. Security procedures are typically tasks we don’t want to loose control of.
In security it is of vital interest everything goes according to a well thought out, well
defined plan. The supervisor of a security department has the difficult task to manage
this. For such supervisors, the use of the computer as a tool can be more than
welcome.
1.1 Problem Introduction
The security department of a cargo airline has the task to make sure no bombs are
being flown disguised in commercial shipments. Shipments arrive from various
places and will be exported on cargo flights. The security has to take care that no
objects are being flown that can cause danger when an aircraft is in the air. At the
head of the security department there is a supervisor, who is in control of all the
procedures within the department. He has to be sure every shipment is fully checked

efore it is loaded onto an aircraft. The job of a supervisor is one in which no
mistakes are allowed; a small mistake can be fatal.
Doing such a task by pencil and paper – taking into account that every piece of paper
with important information goes from hand to hand and that every security worker
that fills in the papers, has his own handwriting – is asking for trouble. Using the
computer to keep track of all the information is not only more convenient, it is also
more efficient, but most of all … much safer.
In the security department one of the writers of this paper worked for, there is no
good software system to assist the supervisor. Our aim was to develop a software tool
for optimizing the management of a cargo export security department.
1.2 Paper Outline
The remaining part of this paper is divided in five sections (sections 2 – 6). In section
2 we will explain the exact problem we wanted to solve, in context to its background.
Furthermore we will describe what is done in a cargo export security department and
we will analyze what a supervisor is like. In section 3 we show in detail our approach
to solving the defined problem, our expectations and requirements. Section 4 yields
the results of our developed solution and the evaluation of the intended users of
CESMO. Also, we will discuss the development towards our solution and we will
review our expectations and the usability requirements. Section 5 summarizes our
findings and discusses the results. In the last section, section 6, we will look to the
future and mention some future developments related to our research.
2 Background and Problem Definition
Cargo airlines are airlines dedicated to the transport of goods. These airlines are also
threatened by terrorist attacks. As said earlier, the security department of such an
airline has to make sure no bombs are being flown disguised in commercial
shipments.
2.1 Background of the Problem
As the shipments arrive by truck to the export warehouse of the airliner, they are
being thoroughly checked by the security department. The shipments are then being
built on pallets – the basic units that are being loaded onto a cargo aircraft. The
supervisor of the department has to take each pallet through the appropriate security
procedures to make sure it is safe to load it onto the aircraft.
Managing the whereabouts of every pallet is nowadays done with some lists of pallets
on separate sheets of paper. The progress of the security handling for each pallet is
updated in these lists. At a certain point an amount of about 50 pallets is assigned to a
cargo flight and all these pallets have to be Ready To Fly (RTF), which means they

have to be fully security checked; a pallet which is not yet RTF is not allowed to
board an aircraft.
The current way for managing the security procedures of each pallet is quite
complicated and is said to yield human errors every now and then. These errors
usually have to be solved with last-moment remedies, which cause delays in
exporting the pallets to their destination.
Safety and speed are the two most important properties of a well-functioning cargo
export security department. First of all, you have to be sure there are no bombs being
flown in the shipments; it is clear that it is of vital interest that certain errors aren’t
made. Second, you want to deliver the goods on time, which means that the security
system has to be very efficient. The present-day method is not the most safe, efficient
and easy way to manage the export security. With the use of a software tool it could
be a lot more optimized.
2.2 Problem Definition
The problem we want to solve is quite clear:
Design an easy-to-learn software tool to assist the supervisor of a cargo export
security department to make his work more efficient, and more error-free.
2.3 User Analysis
CESMO is about to be used only by the supervisor of a cargo export security
department. Therefore we designed the interface purely to the qualities and needs of
such a supervisor.
I. A supervisor has at least a low-level experience with computers.
II. Our user is a highly trained security worker and is fluent with all the security
procedures that have to be followed in a process.
III. Under his supervision are workers who perform security tasks.
IV. The supervisor has to be in complete control of the whereabouts of all the
pallets in the system.
V. Because a security department has to deal with many pallets and all these
pallets have to be fully checked, a supervisor works under great pressure.
Our tool will be used by supervisors only if it will introduce an improvement.
Therefore, we have to keep in mind what the innovation of the system is, what our
intended users expect and what their motivation could be to use the tool.
The main innovation would be that the software application frees the supervisor of
paperwork by offering all the information he needs on a single computer-screen. The
intended user would at least expect more speed and efficiency, less errors and (if
errors are made) an optimized error-handling. More efficiency, increased safety and
lower workloads could be motivations to use the application.

3 Intuitive One-Screen Interface: From Paper to the Screen
Because one of the most important demands of a supervisor is to have a quick and
clear overview of where every pallet is and what their security state is at a particular
moment, we decided to design a one-screen interface. The main tasks the new system
assists are to obtain information of a certain pallet quickly and to update the
information if required. CESMO keeps all the information of all the pallets in the
warehouse transparent and easy to update.
3.1 Set-up of the Information Representation
A certain pallet, let’s say x can be in one of the following three states:
I. Pallet x is being on the way to the warehouse.
II. Pallet x is being present in the warehouse.
III. Pallet x is being loaded onto an aircraft.
When a pallet is on the way to the warehouse it is already known if the pallet is
immediately RTF (Ready to Fly) or first needs a long security program (LP). (This is
also true for pallets that are being built in the warehouse itself.) So, pallets that are on
the way can be subdivided in two lists:
Ia. Needs LP
Ib. Is RTF
In the warehouse, a pallet can still have the status of needing LP or of being RTF.
Pallets that run in a long security program are checked in pressure tanks. Let’s say
there are two tanks, a new and an old pressure tank (respectively NPT and OPT). The
pallets in the warehouse are in one of the following four lists:
IIa. Needs LP
IIb. Is being checked in NPT
IIc. Is being checked in OPT
IId. Is RTF
When a pallet is RTF is can be assigned to one of the cargo flights. If a cargo airline
has a maximum of three flights at a certain time, a pallet can be assigned to one of
these flights. So, in the last state there are three lists:
IIIa. Is assigned to flight 1
IIIb. Is assigned to flight 2
IIIc. Is assigned to flight 3
To be able to show all the possible information on one screen we just needed nine
lists, divided over three parts. The left part then consists of two lists, the middle part

of four and the right part of three. (See Appendix A, Fig. A1 for a screenshot of the
main screen of CESMO.)
As you maybe notice, we represent the information in such a way that it is close to the
real security process. The lists are placed in an intuitive left-to-right, chronological
order. A pallet starts at the left of the screen (being on his way to the warehouse) and
ends at the right (being assigned to a flight).
3.2 Updating Information
The supervisor has to be able to add pallets to the lists, update their information or
status and delete them.
A pallet can be added to the system either as being on its way to the warehouse, or as
being created in the warehouse itself. Using buttons to add pallets to the system, a
pallet can appear in the lists Ia, Ib, IIa and IId (see paragraph 3.1).
To update the status of a pallet, a pallet has to move from one list to the other. If, for
example, a pallet was on its way to the warehouse (being RTF) and is now present at
the warehouse, the pallet has to move from list Ib to list IId. Moving a pallet from one
list to the other is made possible by buttons between the lists (where a move is
possible). If a pallet can move from a certain list to another list, there is also a line
drawn between the two lists. It is always clear which moves are possible.
Pallets that are in list IIa (need long program) can be moved to the lists IIb (new
pressure tank) and IIc (old pressure tank). The supervisor can enter the start and end
time for both pressure tanks, with the use of text boxes.
Pallets that are in list IId (present in the warehouse and RTF) can be moved to the
flight lists (IIIa, IIIb and IIIc). There are two buttons between list IId and every flight
list (so a total of six buttons), one for assigning a pallet to the lower deck of an
aircraft, one for assigning a pallet to the main deck.
The supervisor can give each flight its corresponding number with the use of a text
box. When an aircraft has left to transport the pallets, the supervisor can delete the
pallets of the flight list, one-by-one using the flown button.
3.3 Adding Speed and Error-Handling
It is clear that updating information by clicking a button is much faster than updating
pallet information by crossing out and rewriting. But the biggest gain in speed, using
a software tool, comes from the fact that computers are much better in searching than
we humans are. Imagine you have a pile of papers with lists of pallets on it and I ask
you to find me pallet x. Ask a computer to find pallet x and it shows you the result
immediately.
If a supervisor wants to see the information of a particular pallet in the system, but he
does not know in which state (list) the pallet is, he can find the pallet easily with the
use of a search function. He simply instructs CESMO to find a certain pallet and it
will output the result within milliseconds.
Replacing the handwritten lists with lists in a one-screen computer interface – in
which all the lists are connected to each other in the way they intuitively are – has

certainly a positive effect on the amount of errors that can be made performing a task.
Decreasing the error-rate is one of the main improvements we achieved with the
development of CESMO. Making errors however, can never be fully prevented.
We can distinguish two kinds of errors: slips and mistakes. Someone makes a slip,
when he or she has the appropriate goal, but messes up the actions. Someone makes a
mistake, when he or she forms the wrong goal. In order to handle the ‘slip-sensitivity’
in the tool, we designed the interface in such a way it is quite impossible to perform
the wrong action given a certain goal. The buttons are clear and the user is restricted
to perform those actions that are actually possible in the real security procedure.
Because of the intuitive location of all the lists and buttons between them, the system
is not more ‘mistake-sensitive’ than the paperwork method. But a big improvement is
the error-handling in the new system. If an error is made, it is relatively easy to undo
the action immediately using the well-known ‘undo’ button.
For errors consisting of more than one action, or errors made some time ago we
added a mode that makes it possible for the supervisor to reverse his actions. All the
buttons that are used to move pallets from the left of the screen to the right become
buttons that move pallets from the right of the screen to the left. E.g., the button that
makes it possible to move a pallet from list IIa to IIb becomes a button that does the
reverse action, moving a pallet from IIb to IIa. If, by mistake, a pallet is assigned to a
flight when it actually is being checked in one of the pressure tanks, the supervisor
can bring the pallet back to the list where it actually belongs.
There are two extra functions in this ‘reverse’ mode (which we will called Panic
Mode, see Appendix A, Fig. A2 for a screenshot): one that shows the history of a
pallet and one that deletes a pallet from the list (for example, when it is broken).
Because deleting a pallet is an action that should not be made by mistake, a dialog
box appears when you push the button to delete a pallet. The dialog box asks the user
whether he is sure he wishes to delete the pallet and then forces the user to click on
the ‘yes’ button in order to actually delete it. If a supervisor still managed to delete a
pallet by mistake, the deletion can also be undone.
Making an error is human, but a good design is one that prevents as many errors as
possible and that – when errors are made – provides the user with easy error-handling.
In the next session we show how we evaluated our design.

4 Results and Evaluation
To evaluate our design we first needed to define the specifications for the usability
testing in detail about the goals we are trying to reach with the use of CESMO. We
wanted to test the learnability, throughput and flexibility of the system and the user’s
attitude towards it. See Appendix B for the detailed description.
4.1 Evaluation Sessions and Results
Next, we set up two evaluation sessions with two supervisors from the Cargo Export
Security Department. At the time of the evaluations, our CESMO prototype was fully
functional so we could actually check the performance of the user being given tasks
that simulate the daily work in a shift.
A session consisted of two parts, one to measure the learnability, throughput and
flexibility of the system and one to get to know the attitude of the users. In the first
part the evaluator was given a series of tasks to perform (see Appendix C), of which
the time and error-rate were measured. We taped the evaluators doing the tasks to be
able to obtain a precise measurement. The results of the first part of both evaluations
are shown in Fig. 1. In the second part we gave our subjects a questionnaire using the
System Usability Scale (SAS) to test their attitude towards CESMO. These
questionnaire and its results can be found in Appendix D.
Time (secs)
45
40
35
30
25
20
15
10
5
0
Time per Task
1 2 3+4 5 6 7 8 9 10 11 12 13 14 15 16
Task #
Worst
Evaluation 1
Evaluation 2
Fig. 1. Graph showing worst acceptable time to perform a certain task, the best possible time
and the time actually measured in the evaluation sessions
Best

4.2 Conclusions and Improvements
With the evaluation sessions we wanted to test learnability, throughput, flexibility and
attitude. With the results of both sessions we can conclude several things:
Learnability. The evaluators’ first impression is that CESMO is very easy to learn. In
the results we can see that in general there is a positive learning curve – the more they
get to “play” with CESMO, the better the performance becomes.
From the results of these evaluations we conclude that the evaluators can easily make
the analogy between the real-world process and what CESMO represents in the nine
lists. In task 15 the subject was asked to get extra information on a certain pallet. This
is done by double-clicking on a pallet. This function is the only function in the system
that lacks analogy to the real-world and is not – in fact – intuitive. In the first
evaluation they were just told how to find the extra information, in the second
evaluation we didn’t remind them of it. They performed badly, but – as they told us –
double-clicking for extra information is something simply learned after using
CESMO for a couple of times.
Throughput. As can be seen in Fig. 1. no task reached the worst acceptable time.
Most of the tasks were actually performed in a highly acceptable time. Furthermore,
the first eight tasks as well as the fourteenth and sixteenth show an improvement in
performance in the second evaluation.
The speed decrease of tasks 11, 12 and 13 are due to an improvement we made
between the two evaluation sessions. In the version used for the first session the
supervisor was able to inverse actions (using Panic Mode) without giving a reason for
the movement. For the second version we added a pop-up textbox asking for the
reason of the inverse action. Typing a message adds up to the time used to act in
Panic Mode. The erratic result of task 15 is already explained in the section on
learnability.
Flexibility. The Panic Mode proved to be a very powerful solution for the flexibility
of CESMO. In most of the cases the evaluator understood when he had to switch to
this mode in order to do certain actions. After the first evaluation we improved the
affordability of the extra functions in Panic Mode (showing the history of a pallet and
deleting a pallet) by showing the buttons of Panic Mode also in the main screen, but
greyed out. This makes it easier to see when to switch to Panic Mode.
Attitude. As said before we used a System Usability Scaled questionnaire to test the
attitude of the subjects. The subjects seemed very satisfied with the system. During
the first evaluation one of the subjects advised us to use a larger font, which we did in
the new design. In CESMO the supervisor has to move every pallet one by one from
one list to another. It takes more time than moving a group of pallets at once, but –
and the users agreed – it is much safer this way. If you select a whole group of pallets
to move the chance a pallet gets selected that does not have to be moved is bigger
than when you select and move the pallets one by one.
In general the tested users were very satisfied with the design. Our project supervisor
advised us to use a different colour setting as strong colours have a negative effect on
the user, especially when the shifts of a security supervisor are long. We adjusted the
colours for the final design to desaturated and less bright colours.

5 Conclusions and Discussion
We developed CESMO in order to make the work of the supervisor more efficient
(faster) and safer (lower error-rate / optimized error-handling). As shown in the
previous section, we succeeded. Using CESMO simply makes managing the security
procedures a lot more efficient and thanks to a clear structured and intuitive onescreen
interface also produces a lower error-rate.
We started the design of CESMO with a clear picture of how to present all the
information on one screen. We never deviated from that picture, because what we
thought of was an intuitive logical set-up of the information. At the start of the first
evaluation it became clear that the set-up was indeed very easy to understand. In
general, the adjustments we made after evaluating the system weren’t very large-scale.
However, both evaluations were of great importance to the development of CESMO
as the resulting adjustments were improvements to the system.
We started our project with the thought of optimizing the management work of a
supervisor by automating the list updating. During the project and with thanks to the
feedback given by class members after presenting them our progress we realised this
tool is just the tip of the iceberg when it comes to the automation of security
management.
6 Future Work
As CESMO is only a tool that provides an overview of the state and whereabouts of
every pallet in the warehouse, the supervisor keeps in charge of passing the right
information to the security workers. In addition, the supervisor is the only one that
can enter and update information, information that is given to him by other
departments, transport companies or security workers. We started this paper with a
few words on automation, saying that it comes in degrees. CESMO is a tool that just
starts the automation process of cargo export security handling management. A
possible next step could be providing every security worker with a PDA or handheld
PC with CESMO running on it and a barcode scanner. Every pallet bears a barcode
and it could be possible to enter a pallet to the system by simply scanning its barcode.
This way you automate the input that is still handwork in the developed version of
CESMO.
With the use of PDA’s or handheld PC’s, communication between the workers and
their supervisor can become more streamlined. The workers use the barcode scanners
to generate the input to the system; the supervisor can change the information and
then send it back to the PDA’s or handheld PC’s of the security workers.
Computerized security work still demands lots of human intervention, but concerning
the management of the process, it seems that there is still more to develop.

Appendix A. Screenshots of CESMO
Fig. A1. Screenshot of CESMO’s main screen. The screen is clearly divided into three parts:
the left for pallets on the way, the middle for pallets present in the warehouse and the right for
pallets assigned to a flight. Solid lines between lists show which movements of pallets can be
made, the buttons show the direction (in main screen mode always from left to right). Dashed
lines show were pallets can be entered. In the bottom there is the “Search Pallet” and the
“Undo Last”-button as well as the switch to Panic Mode. (See Fig. A2)

Fig. A2. Screenshot of CESMO’s Panic Mode. Because this mode is used for reverse actions,
the buttons for creating a pallet and the “Flown”-buttons aren’t present here. All the movement
buttons are reversed (pointing from right to left) and the “Delete Pallet”-button and “Show
History”-button are active now

Appendix B. Specification for Usability Testing
Learnability
The ease of learning the system can be measured by checking the results of tasks
examined several times. We can even check for improvement within one evaluation,
because some tasks demand quite similar actions.
We think the interface is quite intuitive, so we expect a very fast learning. The only
aspect of the interface we think can take some time is learning where to look for the
right list and see the analogy between the interface and the real world.
Throughput
We will check the throughput of the interface with the help of a list of tasks,
measuring speed and error rate. In an evaluation session we measure the user’s
performance on the tasks. The ‘worst’ acceptable time and error-rate are chosen to be
the time and error-rate of the tasks performed in the old-fashioned way (without
CESMO, using paperwork). We plan performances to be the ‘best’ possible time *
1.2 and free of errors.
Flexibility
CESMO is made for a particular sort of user. We don’t distinguish between novices,
regular users or experts. All supervisors should be able to handle this interface to its
deepest functions. When a mistake is made, it is best if it is corrected as soon as
possible, preferably by the same supervisor. We will check if our solution for
flexibility (Panic Mode) is indeed sufficient. To be able to check this, we introduced
some Panic Mode tasks in the list of tasks.
Attitude
We will provide our users a SAS-questionnaire (see Appendix D) to get an indication
of their attitude towards our product.

Appendix C. Tasks Evaluated
1. A fax arrived from LHR.
Add these pallets to CESMO:
Fax from LHR
Pallet Dest Class
P5F 0012 TLV LP
P6P 5619 TLV LP
P6A 8122 TLV LP
AQ6 0001 TLV RTF
2. We got a list of built pallets from the builder.
Add these pallets to CESMO:
Builder form – Pallets built in AMS
Pallet Dest Class
P6P 6112 BKK RTF
P6P 6114 BKK RTF
P6P 6116 BKK RTF
P6A 8729 TLV LP
3. + 4. Truck from LHR arrives in AMS.
Move these pallets:
Pallet Dest Class
P5F 0012 TLV LP
P6P 5619 TLV LP
P6A 8122 TLV LP
AQ6 0001 TLV RTF

5. Put pallets in the NPT.
Move these pallets to the NPT:
P5F 0012
P6P 5619
P6A 8122
P6A 8729
Update NPT In and Out times (14:00 – 17:00).
6. Put pallets in the OPT.
Move these pallets to the OPT:
P5F 1234
P6P 2011
Update OPT In and Out times (15:00 – 20:00).
7. Open the NPT.
Move the 4 pallets in the NPT.
8. Open the OPT.
Move the 2 pallets in the OPT.

9. You got an uplift from the export.
Create flight 810.
Move the pallets to the flight 810.
Flight 810 – 30/11/2006
AMS → TLV
Pallet From Dest
P5F 0012 LHR TLV
P6P 5619 LHR TLV
P6A 8122 LHR TLV
AQ6 0001 LHR TLV
P6A 8729 AMS TLV
P6P 6112 AMS BKK
P6P 6114 AMS BKK
P6P 6116 AMS BKK
P5F 1234 FRA TLV
P6P 2011 FRA TLV
10. Pallet moved by mistake.
Click on the pallet AQ6 0002.
Move it to the RTF list (by mistake).
Undo the last action.
11. Pallet AQ6 0003 found open in the system.
Move it to the OPT.
Fill in Time In and Time Out (23:00 – 3:00).
12. A phone call from the export.
They ask you what the whereabouts of pallet P6P 1357 are.
Where can you find it?
They tell you it’s a mistake – the pallet is for sure still on the way to AMS.
Move this pallet to the On The Way LP list.

13. Pallet P6P 6112 is broken down.
Delete it.
14. Searching for a pallet.
Look for pallet P6P 6116.
15. More info about a pallet.
Ask for extra info about the pallet P6P 6114.
16. Flight 810 has left AMS.
Move the pallets from CESMO with the “Flown”-button.

Appendix D. System Usability Scale Questionnaire with Results
1
2
3
4
5
6
7
8
9
10
I think that I would like to use
this system frequently
Strongly
Disagree
I found the system unnecessarily
complex x
I thought the system was easy to
use
I think that I would need the
support of a technical person to
be able to use this system
I found the various functions in
this system were well integrated
Strongly
Agree
1 2 3 4 5
x
I thought there was too much
inconsistency in this system x
I would imagine that most people
would learn to use this system
very quickly
I found the system very
cumbersome to use x
I felt very confident using the
system
I needed to learn a lot of things
before I could get going with this
system
x
x
x
x
x
x

Inzage medicatiedossier voor patienten
Roald de Vries, Maarten Groeneweg
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands
r.a.de.vries.2@umail.leidenuniv.nl, mgroenew@liacs.nl
supervised by Mounia Belmamoune, Fons Verbeek
mounia@liacs.nl, fverbeek@liacs.nl
Abstract. The aim of this project has been to build a user friendly interface for
patients to their medication file ('medicatiedossier'). The interface has to provide
possibilities to view certain medication data, which is necessary for legal
reasons, and possibilities for patients to give feedback on the use of medication
as an interesting added value for treating party.
1 Introduction
In recent years, the medical world has heavily computerized itself. On hospital level,
but also on national level. A recent case indicating ongoing development in this direction
is the decision of the government to introduce burgerservicenummers (abbreviated
'BSN', a unique civilian service numbers).
The medical automation has resulted in national databases containing general information
on medication, and hospital-wide databases containing for example patient
information and treatment history. Hospitals now use computer systems as a primary
mean to keep track of patients' medical history, presence and future (in the sense of
prescribed medication). On a national scale there are protocols for interchanging information,
and the BSN should help to streamline this interchangeability.
According to the 'wet op geneeskundige behandelovereenkomst' (abbreviated
'WGBO', a law on medical treatment agreement), every patient has the right to examine
his own dossier. The 'Nederlandse Patienten Consumenten Federatie' (abbreviated
'NPCF', the dutch federation for patients) stresses for the rights of these patients, and
has thus requested the development of an interface to medication dossiers for patients.
The Leiden University Medical Center has initiated a project (reference [2]) to develop
an interface offering these requirements as stated by the NPCF, and more. They
have added the requirement that the patient should be able to add feedback on what
medication was taken when, and on possible side effects of medication. In the context
of the human computer interaction course 2007 (reference [1]), we have decided to
build this interface (reference [3]).

2 "Please state the nature of the medical emergency"
Where in the old way of prescribing medication this was always done in a way that
the patient could check – think of a doctor writing notes that the patient takes to the
pharmacy – in the new way, with automated prescriptions, this is not automatically
possible. As explained in the previous section though, it is required. That means that
for ongoing automation in medical care, a patient interface to his medication dossier
has to be available.
The only program that resembles this patient interface, is the specialist variant, Medicator
(see attachment [4]). It is a locally used (within one hospital for example) very
extended interface in which the medication of all patients can be managed. Moreover
it assumes that its users are familiar with specialist terminology.
The user assumptions of Medicator, obviously, don't apply to the users of the interface
to construct. The users are so different, that Medicator can only serve as inspiration,
instead of as an example. We will now first evaluate the interface users, and then
in the next section specify our way to address their needs.
User analysis
The interface is targeted to be used by patients with prescribed medications, who
wish to keep an overview of their medical records and keep track of their medicine
use. They are normally only consumers of health care and will not have any specific
medical knowledge.
Experience with computers is not something that can be counted on, especially with
persons of older ages. On the other hand, premise for using the interface is starting it
up – which implies some (maybe very basic) computer knowledge. The interface,
therefore, will have to be usable for those with only very basic computer use skills. A
web browser based interface will be used for ease of use and to allow access from
home computers without having to install new software.
3 A task oriented approach
Since the requirements of the interface come down to a limited number of tasks that
the user has to be able to fulfill, we have decided to choose a task oriented approach.
The tasks that are required are:
view personal medication history
give feedback on medication use (when, how much)
give feedback on medical state, specifically side effects of medication
view logs on which health care provider has viewed a patients medical history

Choosing one of these tasks is done by clicking a tab on a tabbed page, with one tab
per task. Below, the tabs are described one by one.
1. view personal medication history
In the first tab, a complete list of prescribed medication can be found. A special role
in this list is played by still active medication. Any record in this list can be selected,
and for a selected medication record, extra information on this medication will be
shown – like an extended description, and side effects. Another important item form
the pictures. Using images of both packages of the medication and of the medication
itself, it should be made clear which name relates to which medication in the patients
hands, in the real world.
2. add information on medication use
In the third tab, the patient can add feedback on the actual use of medication for any
item appearing in the list of active medications on tab 1. The date to which this feedback
applies can be entered using a 'date picker' only, so that an incorrect date can
never be entered. The default date is always 'today'.
3. add information on medical state
In the third tab, the patient can add any information on his health state. The date is
handled in a similar way as on the first tab (see previous paragraph). Special attention
goes to side effects of the currently prescribed medication. In a drop-down-box, all
side effects mentioned in the medication list will be options. For flexibility, it has to
be possible for a patient to enter this feedback in a text field without any restrictions,
so also 'anything else' will be an (and the default) option in the side effects dropdown-box.
4. view logs
In the fourth tab, the user can view for every inspection of his records, when it was
done, by which institution, and what information was viewed.
One element is not part of these tabs, and that is the help button on the top right.
Clicking on it will open a new window; in the interface, though, it is without content.
It seems out of the scope of this project to provide a complete help file. Moreover it
would be an illusion to think that any interface innovation can be made in that, building
it as a side project along with the rest of the interface.
We have decided to provide an login screen for the site. On entering the site, one of
the four tasks described above can be chosen. Before this can actually be performed,
the user has to login, which happens in the login screen. From there the user is directed
to the right tab.

Expected result
The expected result depends on the extend to which the interface has been explained
to the patients. We may assume that it will be explained verbally to some extent, and
that patients will get a folder explaining it. On the other hand it would be naive to
think that they remember a verbal explanation well, and many people will never read
the folder.
It is crucial that the patient understands how to find information on his medication.
This is the primary reason of existence of this site. The usability of forms is less important
since they merely add value for the health care provider (and therefore the
patient). As far as finding information is concerned, the patient should be able to find
what medicine he should use for how long and in what quantities. He should also be
able to find out which health care providers have viewed his medical history when.
As far as the forms in the interface are concerned, it is important that they are so clear
that doubt on the patient's side won't lead to not using the interface.
4 Results and Evaluation
To test for the expected results we've done two usability tests. The first one being an
expert user evaluation, the second an end user evaluation. The form of the expert user
evaluation was very open. We just asked experts to give their opinion on the site as it
was. That has resulted in the attached expert evaluations (attachment [3]). The user
evaluations were done with a question list, and are attached to this document. All
usability tests were in dutch. Below we'll give an English summary of the expert user
evaluations. The states of the interface during these evaluations and of the final state
can be found in appendix A
Expert user evaluations summary
Evaluator 1 has suggested the addition of a start page, from which any of the three
(three at the time, now four) tabs can be selected to start in and adding a description
of the interaction between medications. He also thinks navigation within the site is
clear, but boring.
Evaluator 2 has suggested to make the text of the medication history tab longer, to
better describe everything that can be done there. He didn't understand why the medication
name should be repeated in the medication use feedback form. It was not clear
what the difference between the two feedback forms was. Evaluator 2 has also suggested
to include help functionality.

Effects of expert evaluations
Expert user 1 has suggested to introduce a starting screen. We have added it even
before the login screen, so that patient know what they're going to login for.
We believe we have also addressed the problem of the site being boring, at least partially,
by making more use of icons.
Most of the other feedback from expert user 1 are due to the development stage of the
project.
Expert user 2 has suggested to rename tab 1 to reflect that also feedback on medication
use can be given. We have decided not to rename it, but to add tool tips to the
tabs for a more extensive explanation.
Expert user 2 also mentioned that (1) the added value of the second tab was not clear
having a feedback form also in the first tab and (2) the medication name was superfluously
repeated in the form on the first tab. We've handled this by separating the
first tab in an information tab without a feedback form, and a medication use feedback
form on a separate tab.
Also after this second expert user evaluation we have introduced the help button.
Second user evaluations round
As mentioned before the second user evaluations round was different in setup. We've
created a document with an explanation of the site, and a few tasks to fulfill. The first
user (attachment [1]) has done this well, which means no reasons for concern, and has
suggested some useful things. First is to make entries in the forms editable. We've
added this functionality. The second is to allow a user to give a time span for a side
effect instead of a single date. We think that this is not really important, and might
lead to more confusion rather than clarity, so we have rejected it.
In the second user evaluation (attachment [2]) we had some problem with the fact that
it had not been made clear what functionality the interface did and didn't offer. This
lead to confusion entering feedback into the interface. It appears, though, that the user
has always tried the correct way of entering certain information first, and then started
searching for other ways.
User 2 says it wasn't possible to indicate that a certain side effect was caused by a
certain medication. This is because the relation normally is not clear. Of course intuitions
on this can be put in the 'opmerkingen' field below the side effects. He also suggests
to merge the two feedback forms into one on the second tab. We believe that
this will only make the confusion bigger.

5 Conclusion and Discussion
We may conclude that the task oriented approach to this interface is a good one. In
general, the user evaluations have been satisfactory. Especially the tabbed navigation
seems to work well.
This interface is a first step towards a real web application. At some stage, it might be
extended and more functionality might have to be offered. It will have to turn out
whether or not the tabbed approach will still be the right one, if a multitude of tasks
has to possible to be fulfilled.
6 Future Work
The obvious future work is implementation of the back-end for this interface. But
also the interface itself can be further developed to offer more functionality, as it will
eventually have to.
References
1. HCI website; hci.liacs.nl
2. Project; http://www.liacs.nl/~fverbeek/courses/hci/exampleprojects2006.pdf project
(1)
3. final version of the interface; rdv.homelinux.net/hciproject
Attachments
1. Usability_test(1).pdf
2. Usability_test(2).pdf
3. expert_user_evaluation.pdf
4. Artsen Handleiding Medicator.pdf

Appendix A
The following images show the state of the interface during the expert user evaluations.

The following images show the state of the interface during the end user evaluations.

The following images show the final state of the interface.