Final Papers for Human Computer Interaction (HCI) Practical ... - Liacs
Final Papers for Human Computer Interaction (HCI) Practical ... - Liacs
Final Papers for Human Computer Interaction (HCI) Practical ... - Liacs
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Proceedings<br />
<strong>Human</strong> <strong>Computer</strong> <strong>Interaction</strong> Project<br />
Fall 2006<br />
Lecturer<br />
Fons Verbeek<br />
Primary Assistants<br />
Mounia Belmamoune<br />
Yun Bei<br />
Yanju Zhang<br />
Course Assistants<br />
Alexander Nezhinsky<br />
Sander van der Maar
Preface<br />
Assembled in this proceedings document are the final papers of the<br />
<strong>Human</strong> <strong>Computer</strong> interaction course 2006-2007 <strong>for</strong> computer science and<br />
media technology students. Only those projects that have been completed<br />
within the given timeframe are included in the proceedings document. In<br />
total 19 contributions are included in these proceedings.<br />
The papers are ordered to subject without further ordering or ranking.<br />
We, the course administration, have enjoyed the projects and the<br />
supervision thereof <strong>for</strong> a great deal. The midterm presentations as well as<br />
the final presentations were of good level and the students have actively<br />
participated in the discussions. This is an important ingredient of an <strong>HCI</strong><br />
course; the midterm presentations gave in many cases idea of an expert<br />
evaluation.<br />
The papers are included “as is”. We have emphasized in some cases to<br />
include more graphical material in the paper. This is important so that<br />
readers can understand what the interface is supposed to do and how the<br />
interaction is designed.<br />
The separate papers will be submitted to the <strong>HCI</strong> content management<br />
system (CMS) which can be used <strong>for</strong> browsing ideas <strong>for</strong> next years<br />
students. It will help to set the level. In addition, in the same CMS the<br />
final products stored and can be provided on request. Providing the CMS<br />
is new to the <strong>HCI</strong> course and will help to learn from what other students<br />
have been doing. We are happy that we can present the results of this<br />
years <strong>HCI</strong> course in this manner.<br />
We thank all students <strong>for</strong> their ef<strong>for</strong>ts in this course; we have appreciated<br />
your input and critical attitude. We hope you enjoy browsing and reading<br />
this document.<br />
Leiden, February 2007<br />
Fons J. Verbeek
<strong>HCI</strong> Projects<br />
No. Group Group Members Project Title<br />
1 01 Arjan Assink Simon Windt Beginnend Lezen<br />
2 02 Mario Bardini Menno van Elk Learn &Enjoy<br />
3 09 Michiel Helvensteijn Jori van Lier Plat<strong>for</strong>m game knowledge testing<br />
4 23 Jens van de Water Christina Papakonstantinou Peter the Penguin<br />
5 25 Anthony Woudenberg Marian Maas Mathematical Dice<br />
6 14 Tim van Meurs Ioannis Panagiotou Puzzlemath<br />
7 19 Frank Takes Tiago Borges Coelho Mobile Learning<br />
8 10 Anton Hunsucker Sifferina de Jong The Music Man<br />
9 27 Petr Krsek Loren Roosendaal Music Maestro! (Input part)<br />
10 22 Xuan Wang Karen Sam Music Maestro! (Output part)<br />
11 21 Sander van der Vlugt Job de Reus Blind typing <strong>for</strong> seniors<br />
12 12 Joppe Kroon Alex Reuneker Help elderly using the mouse<br />
13 7 Stijn de Gouw Elena Gavrielidou Visual Memory Game<br />
14 26 Sjaak Wolff Ella Keijzer Online Flower Shop<br />
15 18 Stefan Schrama Christian Detweiler Barschedule Catena<br />
16 15 Erik Kuijl Police Academy<br />
17 24 Fee Yun Wong Kees Kofferman Seek the thrill<br />
17 Maja Jakobik Seek the thrill<br />
18 04 Kerem Denizmen Sjoerd Kranendonk Whiteboard<br />
19 08 Eyal Halm David van Paesschen Security system <strong>for</strong> cargo airlines<br />
20 03 Roald de Vries Maarten Groeneweg Medication files <strong>for</strong> patients
Read Aid<br />
Arjan Assink, Simon Windt<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
aassink@liacs.nl, simon.windt@quicknet.nl<br />
supervised by Alexander Nezhinsky.<br />
anezhinsky@liacs.nl<br />
Read aid is a program that can assist small children in learning to read. The<br />
program does this by presenting them with a clean, easy to use, but appealing<br />
graphical interface. The interface is designed in such a way that the children<br />
will not be easily distracted, but so that it does stay interesting <strong>for</strong> them to use!<br />
1 Introduction<br />
This paper will explain, in detail, the process we went through while developing<br />
the Read Aid program. The initial idea <strong>for</strong> the program was <strong>for</strong>med when we<br />
noticed that there were very few games that helped children in the earlier age-groups<br />
to read. There we plenty of programs <strong>for</strong> the older children in the primary school, but<br />
the age group 5-7 was neglected. The programs we did find <strong>for</strong> this age-group usually<br />
had cluttered, and hard to use interfaces (even <strong>for</strong> adults), so we decided to create a<br />
program that was clear to the children, easy to use, but at the same time was able to<br />
keep their interest in the program and learning to read.<br />
2 “Short Subject Background and problem definition”<br />
The problem with teaching small children how to read is that it is very labor<br />
intensive, the child has to be guided every step of the way, even when just practicing.<br />
What we aim to do with Read Aid, is to take some of this strain away from the teachers<br />
or parents, and allow the child to practice reading on their own. Read Aid is there<strong>for</strong>e<br />
not a replacement <strong>for</strong> classical teaching, but a supplement.<br />
Similar program’s are usually aimed at children in the higher age-group in<br />
the primary school, that is why Read Aid is aimed at children in the age group 5-7.<br />
Besides a different age-group, most alternatives have one thing in common, their<br />
interface is very cluttered, or not attractive to look at. If we want small children to<br />
stay interested in Read Aid, our interface will have to be very clear as well as attractive<br />
and exciting <strong>for</strong> little children.
User analysis<br />
For our first user Evaluation we went to a Dutch primary school, where we tested<br />
our application with several children around age 7, who had just started reading. Our<br />
major concern here was the level needed <strong>for</strong> the words and images we used <strong>for</strong> the<br />
prototype, we thought they might be a bit to hard <strong>for</strong> the children. After our first testsubject<br />
we discovered the children were already much better at reading than we had<br />
expected, and the level of the words was right on the mark.<br />
The biggest problem that erase from this first user analysis was that the children<br />
kept “losing” the cursor. We solved this problem by making a custom cursor that was<br />
bigger and much easier to find. Second problem was that the children didn’t really<br />
understand the level choice that was given to them, so we disabled the option. It could<br />
later be maid available to the teachers.<br />
On the second user evaluation we used an eye tracking system. We already<br />
made some changes to the game after the first user evaluation. We didn’t get any new<br />
results from the second user evaluation.<br />
3 "Clean, but fun"<br />
As mentioned be<strong>for</strong>e, the problem with most programs the preceded Read<br />
Aid is that their interface were not user-friendly, mostly due to 2 factors, they were<br />
either to cluttered or they were not fun to use. Read Aid tries to solve both these issues.<br />
We did this by first creating a clear, easy to use interface, with big buttons.<br />
To further limit clutter and distraction, we decided to make the application full screen,<br />
thus minimizing the distraction provided by any other programs that may be running<br />
on the computer at the same time.<br />
Our second challenge was to keep the child’s interest. This was a bit harder<br />
to do, because we had to figure out what appealed to children of our user-group. After<br />
some research we came up with the following things, which now seem painfully obvious:<br />
sound, color, movement. We incorporated all of these things into Read Aid.<br />
The child is provided with auditory comment on their progress throughout<br />
the entire game, explanations are given by a voice, as well as congratulations when a<br />
question is answered correctly. We also put as much color into the interface as we<br />
could, without creating distraction from the questions asked. This is done by large<br />
colorful buttons, and a colorful background. The background has a lower saturation<br />
that the buttons and pictures, to prevent it from getting the upper hand in the design.<br />
The hardest thing to incorporate into the design was movement, at first we<br />
thought of maybe making the buttons slide into the screen, but we thought this might<br />
“scare” the children, making them afraid to use the application. This is why we finally<br />
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 <strong>for</strong> a correct answer, and<br />
the game stays interesting <strong>for</strong> them as well.<br />
4 Results and Evaluation<br />
When we arrived at the first prototype, the user evaluation was very encouraging.<br />
At first we thought the game did not appeal to the children at all, because they<br />
did not seem very excited during the test, however, afterwards their teacher approached<br />
us and told us how excited the children were when they came to tell her<br />
about the program. This was a very good thing to hear, because our program would be<br />
completely useless if the children wouldn’t like playing with it.<br />
A few small issues did come out of the first user evaluation, but those were<br />
quickly fixed, and the second user evaluation showed that the modifications made<br />
were a huge improvement. Our product now met the requirements we had set <strong>for</strong> it,<br />
Read Aid had a clear and highly useable interface, and was a fun game to play <strong>for</strong><br />
young children.<br />
During our class presentation, like our first user evaluation, a few small issues<br />
were raised, <strong>for</strong> instance our background drew to much attention to itself, so we<br />
changed the saturation of that. Besides small things like that, no major changes were<br />
suggested <strong>for</strong> the program itself in terms of usability or structure.<br />
5 Conclusion and Discussion<br />
In conclusion, we think that Read Aid evolved into the game we were aiming<br />
<strong>for</strong>. The children that played the game seemed excited and were able to play the game<br />
autonomously, without much help from the teacher other than starting the application.<br />
The movie-clips that were added after a question was answered correctly, and the<br />
Dutch auditory aid during the program seemed to appeal greatly to the children,<br />
which is exactly what we were hoping <strong>for</strong>.<br />
6 Future Work<br />
Read Aid is a complete application as it is, except <strong>for</strong> the content. In the<br />
future, content could be retrieved dynamically from a database, and results of each of<br />
the students could be stored as an expansion on the current program.<br />
Besides expanding the current program, it could also be altered to fit the interests<br />
of older children. This would have to be done not only by changing the content,<br />
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,<br />
all this would have to be researched.<br />
References<br />
1. Future Lab, Report on Gaming <strong>for</strong> Childern in Education, 2006, 65 p.<br />
Appendix
Gioca & Impara<br />
Mario Bardini, Menno van Elk<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
Mariopwr@yahoo.it, Menno.vanElk@phil.uu.nl<br />
supervised by Yanju Zhang, Fons J. Verbeek.<br />
yanju@liacs.nl, fverbeek@liacs.nl<br />
Gioca & Impara is Italian <strong>for</strong> play and learn. In this case it’s also the title of our<br />
flashgame. The game itself is designed to teach children the basics of another<br />
language. Because children like playing more then learning the educational<br />
element is disguised as a feature of the game. To accomplish this goal we have<br />
chosen the <strong>for</strong>m of a slotmachine. The slotmachine presents a row of pictures<br />
that <strong>for</strong>ms a sentence. A number of possible sentences is given in another language<br />
that users can choose between English, Italian and Dutch. The user has to<br />
select the matching sentence to win coins. To encourage repetitive play the<br />
coins can be spend in the game.<br />
1 Introduction<br />
The acquisition of language is something children are good at. Young children apparently<br />
learn a new language without great difficulty. Knowledge of multiple languages<br />
tends to be very useful at later ages so we think it would be a good idea to stimulate<br />
the learning of a second language.<br />
We have decided to hide the learning language part in a game. This is because children<br />
like to play games a lot better then they like to learn another language. Most<br />
other methods <strong>for</strong> learning a language use books, dictionaries and similar tools. Our<br />
solution works with pictures. The sentences and words learned need to be read however<br />
so we decided to limit our usergroup to children who are just learning to read.<br />
In this paper we’ll show and discuss the steps we have taken in the development of<br />
the game. First off is a description of the initial plan and the assumptions made. We’ll<br />
focus on the difficulties of our approach and the results of the user evaluations. The<br />
paper also contains a description of the final interface.
2 Development Trajectory<br />
It is very important in life to have an education and to learn stuff. To contribute to<br />
this we have decided we wanted to make software <strong>for</strong> children. Language is such a<br />
major aspect of life and the authors had between them 3 languages to choose from, it<br />
was soon clear that this knowledge somehow would have to be used in the program.<br />
Within the constraints of making an educational children’s game and using our<br />
knowledge of languages Gioca & Impara was conceived.<br />
The game is focused around pictures. Even without <strong>for</strong>mal knowledge about the way<br />
children perceive software it would clearly be more attractive to them then plain text.<br />
Pictures can be funny and give the opportunity to add color and atmosphere to the<br />
game. Because of the graphic constraints we chose <strong>for</strong> the development plat<strong>for</strong>m of<br />
Flash. Not only is Flash very suited to the construction of Graphical User Interfaces,<br />
it also presented us with the opportunity of learning Flash, a skill we both sorely<br />
lacked. Our game would thus be made in Flash and would use pictures to teach children<br />
the basics of some other language.<br />
With the plan <strong>for</strong> the game finished we concentrated on describing our usergroup.<br />
Because of the skills involved in using the program our users could not be too young.<br />
They would need to have a basic understanding of how to use a computer, they need<br />
to be able to read and they would need to be able to understand the concepts used in<br />
the program. Because of these constraints we restricted our usergroup to children in<br />
the ages 6 and 7 years old. To complicate matters somewhat, we couldn’t just use<br />
regular Dutch children because of our team composition.<br />
With a detailed description of our usergroup and the programs constraints and target<br />
finalized we next concentrated on creating a prototype design <strong>for</strong> the interface. Since<br />
we wanted to use pictures to construct sentences and somehow refresh the pictures<br />
<strong>for</strong> every new assignment we needed to design an interface that makes this possible in<br />
an easy way. We chose the slotmachine interface because it is very suited to this specific<br />
task of refreshing the pictures. Also, it’s a very common factor in several Nintendo<br />
games. We there<strong>for</strong>e expect children to feel familiar with it when they see it.<br />
The slotmachine is exceptionally good when compared to other games. It is very easy<br />
to operate (only one button!) and looks very nice because of the animations. Other<br />
software solutions on the language front use a more adult approach that doesn’t appeal<br />
to children in the way the Nintendo approach does.<br />
3 Spinning the Reels<br />
In this project we concentrated our attention on usability requirements. We’re trying<br />
to make a usable product, one where people can easily learn, that has functions that<br />
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<br />
and subjective satisfaction; making a system that scores high on, mainly, these factors.<br />
We think that these are the most important aspects that a software developer should<br />
consider when making a program <strong>for</strong> children because they like to complete a task in<br />
a few steps without having a particular experience, and they are more satisfied if they<br />
use a well-designed program.<br />
To help new users learn the options that the game has to offer we use a cartoon that<br />
hosts the program. A cartoon is used because children like them and somehow feel<br />
they know them. It will give us the opportunity to present hints and help in a way that<br />
children will accept. We reckon this gives the impression of a familiar face telling<br />
them what to do. The cartoon will there<strong>for</strong>e be in the first screen. To further enhance<br />
this personal-approach feeling the host prompts the child to introduce him or herself.<br />
In the first screen is also available the option <strong>for</strong> language selection. To select a language<br />
the user is prompted by the host to select his or her language, represented by a<br />
flag and an abbreviation of the language (Ned, Eng, Ita).<br />
The next phase in the program would be the selection of a style of play. Originally we<br />
had planned to use several different modes here. First option would be to choose<br />
whether you would like to learn new stuff or test your existing knowledge. These<br />
styles are labeled ‘Practice’ and ‘Play’. We think this distinction is a very important<br />
one because you cannot play the game until you have some basic knowledge of the<br />
language that you are playing with. A user will feel bad about him- or herself if he or<br />
she ‘needs’ to play the game without being able to actively influence the amount of<br />
coins scored. The choice made in this screen will decide what screen you get to see<br />
next.<br />
In the ‘Practice’ section you would have been able to choose between learning words<br />
or learning sentences. The interface <strong>for</strong> both would have been the same, except in the<br />
words screen only one slotmachine reel would have been visible. The user should<br />
then spin the reel(s) to show new imagery and try to remember the words that are<br />
associated with the pictures. After learning the words and sentences in this mode the<br />
user should then try him- or herself in the ‘Play’ section. In this section we had originally<br />
planned a written exam and an exam based on speech-recognition (users had to<br />
write and read the word/sentence).<br />
Be<strong>for</strong>e starting work on the actual program we did a user evaluation with class 2 of<br />
the British School in The Hague. The evaluation gave us a lot of in<strong>for</strong>mation about<br />
the sort of visuals children appreciate in a program. A detailed description of this<br />
in<strong>for</strong>mation is included in our article called User Evaluation. More important however<br />
was the fact that this session immediately showed us the major design flaw in<br />
our program.<br />
Our evaluation asked children to write down the words and sentences that they<br />
thought were depicted in one image and in two and three grouped images. This was<br />
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<br />
array of sentences that can be deduced from a picture of a cat and a picture of<br />
someone sleeping. In short: we had to change our design. If children are allowed to<br />
just type in an answer, they will never get it right.<br />
The first prototype of the game there<strong>for</strong>e took a somewhat different approach. First<br />
we got rid of the subdivision <strong>for</strong> each menu option. The game from now on only<br />
offers the options of practice and test. In practice mode there is no different option to<br />
learn individual words anymore because this is already included in the sentence section.<br />
In the test section the answering option has turned to multiple choice system but<br />
because you are not practicing, the stakes will be higher… This does increase the<br />
difficulty somewhat but with the help of the ‘listen’ button children will be able to<br />
find the right answer.<br />
Our evaluation showed Super Mario to be the most popular cartoon character to host<br />
the program. This works out very well because in all Mario games players are supposed<br />
to collect coins and stars to buy new game-items with. This we have shamelessly<br />
copied. In practice mode the player will be playing <strong>for</strong> 1 coin each question but<br />
the test mode will have higher bets (not decided how much yet). This will keep practicing<br />
interesting (you will still win stuff) but will also make it challenging to per<strong>for</strong>m<br />
well in the test mode (to get the really cool prizes).<br />
4 Results and Evaluation<br />
The results we have obtained so far are encouraging. We use the word encouraging<br />
because we ought to do a final test with our original usergroup first be<strong>for</strong>e making<br />
hard statements about results. Time constraints however <strong>for</strong>ced us to do the evaluation<br />
of our prototype with Dutch children. In this section we will there<strong>for</strong>e mainly<br />
focus on the remarks that we received from various people involved in the design<br />
process and their influence on the usability of the interface.<br />
During discussion in class our attention was pointed to the possible difficulties involved<br />
with the interface that we chose <strong>for</strong> the language selection. This remark was<br />
later repeated by Mr. Paul Ellis, head teacher at the British School in The Hague. A<br />
bit frightened by now, we included various questions related to this solution in our<br />
questionnaire. Evaluation shows most children are perfectly able to interpret the flags<br />
in the intended way, but, to help them who aren’t, we put the first 3 letters of the<br />
language together with the flag picture.<br />
In class it also turned out we had at first <strong>for</strong>gotten to include a reward <strong>for</strong> players in<br />
our game. Rewards are however very important when working with children. According<br />
to Mr. Ellis there is a very strong ‘what’s in it <strong>for</strong> me?’ attitude with children. We<br />
decided to just ask our users what they would like to win while playing the game. It<br />
turned out that the overwhelming majority thinks (virtual) coins are a great prize.<br />
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<br />
who are used to working with children that we should not use (too many) open questions<br />
in our evaluation. The answers on open questions tend to be pretty much unusable<br />
in situations like this.<br />
Our first evaluation we had prepared on big sheets of paper. Mr. Ellis suggested that<br />
children might not be able to make the mental transition from interface sketches on<br />
paper to real computer program screens. We tossed away our sheets and changed to a<br />
clean powerpoint approach. A side from this being a lot more robust and controllable<br />
it’s also much easier to show stuff exactly as intended. This is very important when<br />
working with children.<br />
Another issue raised during the project was how we where going to generate syntactically<br />
correct and meaningful sentences. Because we have full control over the slotmachine<br />
and the sentences shown this is no problem at all. All picture combinations<br />
and given sentences are hard coded into the source code.<br />
The evaluation of the final prototype has shown no apparent flaws in the game design.<br />
Children navigate the game and operate the machine with ease. There was however<br />
some disappointment when they discovered functions that don’t work (they couldn’t<br />
win coins) but overall they enjoyed the slot machine idea and the whole design of the<br />
program. After that evaluation, we decided to change just the first menu adding to the<br />
flags the whole word of the language that they represent instead of only the first 3<br />
letters.<br />
5 Conclusion and Discussion<br />
Working with children is a very rewarding experience. We had initially approached<br />
our users like they are just small versions of adults with perhaps a greater interest in<br />
flashy colors. Discussion with several specialists has made us realize that this is definitely<br />
not the case. Children require a special unidirectional approach.<br />
Children will not be able to enjoy a game that requires them to spell every word correct.<br />
Also, because we want them to learn something from the game, we can’t just say<br />
‘well… that’s not quite perfect but good enough’.<br />
The effect of the game on the ability to learn the basics of another language is not<br />
something that we have been able to test. The acquisition of language is a process that<br />
takes a long while be<strong>for</strong>e the results will be noticeable. This is not something we can<br />
scientifically prove during this project. Teachers we have spoken to however have<br />
said they find the game to be an interesting approach to this subject and hope to see<br />
ours and more of these programs appear in the near future.<br />
On a side note we would like to remark that when working with other people (i.e. a<br />
third party) it’s sometimes just not feasible to comply with the strict deadlines that<br />
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<br />
one. We think the course should try to keep these two factors more separate. It’s<br />
easier to come up with a solution to a problem then to implementing said solution.<br />
6 Future Work<br />
There are still some features that we have thought about but have not been able t<br />
implement in the game. For instance the prizes that can be bought with the accumulated<br />
coins, perhaps new picture sets <strong>for</strong> the slotmachine. Also the game would need<br />
to have a lot more sentences then just the two we made <strong>for</strong> testing the interface. Perhaps<br />
thousands. The pictures needed to represent verbs are very difficult to come up<br />
with. Perhaps professional artists could be involved. The interface could benefit from<br />
the use of animations, especially the cartoon host.<br />
After implementing all these, we could consider testing our prototype with our intended<br />
usergroup. This could maybe be part of a longer research into the acquisition<br />
of language <strong>for</strong> young children.<br />
References<br />
1. Alan Dix e.a, (2004). <strong>Human</strong>-<strong>Computer</strong> <strong>Interaction</strong>. Pearson Education Limited.<br />
2. Soren Lauesen, Houman Younessi (2000). Six Styles <strong>for</strong> Usability Requirements.<br />
Proceedings of REFSQ’98.<br />
3. M.F. DiAngelo, C.J. Petrun (1995). Collecting productbased usability requirements.<br />
IBM Systems Journal vol 34, no 1. (4-19)
Appendix<br />
Fig 1. First menu<br />
Fig 2. First menu (with mouse over the English flag)
Fig 3. Main menu<br />
Fig 4. Main menu (with mouse over the first flag)
Fig 5. Practice section<br />
Fig 6. Practice section (with mouse over the first flag)
Fig 7. Test section<br />
Fig 8. Highscores page
Fig 9. Shop page
Plat<strong>for</strong>m game testing<br />
Michiel Helvensteijn, Jori van Lier<br />
January 10, 2007<br />
Abstract<br />
This project proposes a solution to the inability of children to keep<br />
their attention at their studies. Doing tests has been proven to be a good<br />
learning-tool, and our program will make taking tests fun <strong>for</strong> children by<br />
embedding it in a popular game environment. We have shown that there<br />
is interest in the idea, but that more than one semester is needed to create<br />
a game nice enough to appeal to our target users. Our current program<br />
can’t possibly compete with 3D games from the latest generation consoles.<br />
1 Introduction<br />
Children of the current generation have way too much video-gaming to do to<br />
get any schoolwork done. Of course, because they have to learn <strong>for</strong> school,<br />
whereas playing video-games is their own choice, and video-games are specifically<br />
designed to appeal to them. Not much has been done about this, and<br />
those attempts that did happen were of limited effect.<br />
We attempt to combine learning with video-games to bring the best of both<br />
worlds. You take a well-known virtual game-world and put in the knowledge the<br />
children should know and you get learning that’s also fun! Well, it’s actually a<br />
bit more complicated than that, as we will discuss later on.<br />
We discuss the problem in more detail in section 2. Our solution to this<br />
problem is discussed in section 3. In section 4 you can read about our relative<br />
success and our conclusions are to be found in section 5. Lastly, in section 6 we<br />
briefly discuss possible followup work that can be done in this area.<br />
2 Let them learn it while they’re young<br />
Our targeted user-group consists of school-going children of approximately nine<br />
years of age. They have used computers be<strong>for</strong>e, but don’t often have real<br />
computer-skills. They play video-games and most of them enjoy them immensely<br />
and are willing to put significant time and energy into reaching the<br />
goal of these games, much to the detriment of their scholastic per<strong>for</strong>mance.<br />
They do, however, get really good at the in-game mechanics. If a game requires<br />
logic and a child plays it often, he/she gets good at it. Same goes <strong>for</strong> handeye<br />
coordination. Some young adults of the current generation easily get their<br />
drivers-license, because they got high-speed racing ’experience’ playing Gran<br />
Turismo. And younger children learn much more easily than adults. For example,<br />
very young children easily learn a second language by simply being exposed<br />
to it.<br />
1
We have a problem. Children learn more easily when they’re young. But<br />
this is exactly the time in their lives that they have trouble focussing on their<br />
school-work. This is a waste. Even if children do put a lot of time into their<br />
studies, it would be much more effective if they actually enjoyed it.<br />
Several solutions have been suggested <strong>for</strong> this problem. There are some<br />
games that are meant to teach arithmetic and language, and they are used<br />
in schools. But they don’t really help all that much. Not much ef<strong>for</strong>t has<br />
gone into making them and the children easily recognize them <strong>for</strong> what they<br />
are: just tests with a colourful shell around them. Why would they want to<br />
pop bubbles with arithmetic problems inside them, or see some french guy on<br />
screen pronouncing french words, when they could be fragging opponents with<br />
a railgun, or solving complicated dungeon-mazes with breathtaking graphics?<br />
The current approaches are mostly insufficient.<br />
3 ”It’s me! Mario!”<br />
Our solution is to put the learning-tool into a game. Not wrap a game around<br />
a learning-tool. Make sure that the primary goal of the game is fun, and make<br />
sure testing the knowledge of the player is essential in solving the game. We<br />
must make sure to make the game as ’addictive’ as the real games currently in<br />
the market. That’s the key. Use a good story. Use an existing genre.<br />
Because we don’t have enough time to create something suitable <strong>for</strong> this<br />
project, we tried a slightly different approach. We used an existing game with<br />
a character that children should be familiar with. Super Mario! The genre is<br />
a plat<strong>for</strong>m game. We chose Super Mario Brothers 3 as a model. Mario (or<br />
another character from the Mario world) walks through a familiar level of the<br />
game. In the original, Mario is controlled with two arrow-keys and a jump-key.<br />
The movement is done automatically now. Mario walks by himself. He just<br />
has to jump at the right moments. Like when an enemy appears, or a bonus<br />
block with a mushroom (bonus item) in it. This jumping is controlled by the<br />
player correctly answering test-questions. If he/she doesn’t answer in time or<br />
answers incorrectly, the correct answer flashes at him/her and Mario walks into<br />
the enemy, traditionally losing a life. Mario’s lives can be seen as the number<br />
of mistakes that can be made while still getting a passing grade <strong>for</strong> the test.<br />
To compensate <strong>for</strong> the lack of good graphics and the lack of a good story<br />
because of our general lack of time, we tried to introduce some random elements<br />
into the game that should make it at least slightly more interesting. Instead of<br />
just the Goomba (the standard enemy), Mario can randomly run into a Koopa<br />
Troopa, a turtle-like enemy that leaves its shell behind. Mario can use this<br />
shell to block the next enemy attack, if he answers a question incorrectly. We<br />
will also introduce bonus blocks that either spawn a power mushroom, turning<br />
Mario big, so he can take an extra hit be<strong>for</strong>e losing a life, or a life mushroom,<br />
granting him an extra life.<br />
We understand that these are feeble attempts to overcome the lack of manhours<br />
and funds that real game-developers do have, but we hope that testing<br />
the result will give us some in<strong>for</strong>mation about the demand <strong>for</strong> such a game.<br />
For our program to be usable by our target user-group, the following demands<br />
must be met:<br />
• It must have an intuitive interface. Make sure that the childs inexperience<br />
2
with computers does not get in the way of the experience. The exact<br />
demands are in our user evaluation tables.<br />
• It must compel the player to play on. It should be addictive in a good<br />
way.<br />
4 Results and Evaluation<br />
Our program has officially seen 3 versions, but there were really only 2. The<br />
first prototype was severely limited in graphics and possibilities. Only Mario<br />
could be chosen as character, only multiple choice questions could be posed in<br />
the test and the scenery around the level was pretty much non-existant. Add to<br />
that, the random bonus elements (koopa, bonus block) were not there yet. In<br />
spite of all that, the results were encouraging. Every time-period measured was<br />
within specifications. After asking the test-subjects about their opinion, they<br />
agreed that the idea is good, but that the game is quite boring, and wouldn’t<br />
keep their attention <strong>for</strong> any period of time.<br />
We understand that our game is boring. The important part is that the<br />
interface was clear and that, after having given an example, the children liked<br />
the idea.<br />
In response to this evaluation we only expanded the game to make it look<br />
better and make it less boring. We added princess Peach as a playable character.<br />
We added Koopa Troopa as an enemy. And all three types of questions can be<br />
asked now:<br />
1. Multiple choice questions.<br />
2. Random arithmetic questions.<br />
3. Open questions with a numeric answer.<br />
That was prototype 2. And the results of user evaluation 2 are almost the<br />
same as those <strong>for</strong> one. They liked the idea. They liked the improvements.<br />
But they were not enough to make the game less boring. The girl did like the<br />
addition of the Princess Peach character.<br />
Our final product has seen a few changes since evaluation 2. Most notably<br />
are the addition of bonus elements in the <strong>for</strong>m of life-mushrooms (which let<br />
the character gain a life) and power-mushrooms (which let the character grow,<br />
so he/she can take another hit without losing a life). Also, we’ve added an<br />
indication <strong>for</strong> the amount of lives left, and added a horizontal bar, which shows<br />
how much time is left to answer a question, greatly enhancing visiblity. We did<br />
not evaluate this version, but we are pretty confident that the final version is<br />
better than the one used <strong>for</strong> evaluation 2.<br />
5 Conclusions and Discussion<br />
We find that the first usability requirement - the intuitive interface - has been<br />
met. The children could, without much trouble, navigate through the startup<br />
screen and they found it easy to interact with the game-environment.<br />
3
The second, however, has not. As we expected, children are not really fascinated<br />
by our game. We never stood much chance against titles from Nintendo,<br />
Sony and Microsoft. However, we have noticed that adding more and random<br />
game elements is a key factor to increasing user satisfaction. Also, something<br />
can be said <strong>for</strong> the difficulty of the questions. We’ve kept these mostly trivial<br />
to be sure that we’re only testing the interface. Had these questions been more<br />
of a challenge, it would probaly have been more fun to play.<br />
6 Future Work<br />
Future work would include the creation of a real educational videogame, such as<br />
we could not create in one semester. The interest is clearly there. The money<br />
just has to come from somewhere.<br />
The interface could definately do with some more auditory feedback, we<br />
un<strong>for</strong>tunately didn’t get around to adding much of this. Also, while we’re on<br />
the subject of sound, another neat idea would be to enhance the interface with<br />
speech recognition software. Answers could be spoken instead of typed/clicked.<br />
This would have a much greater appeal to the children.<br />
Initially, we planned to make a teacher-only interface to compliment the<br />
game interface. This could be used to create tests that can be run within<br />
our game. The teacher would have to know nothing about the game-world.<br />
Although we did not finish a teacher interface, one should certainly be created<br />
in any future version of our idea.<br />
References<br />
[1] Dix, A., Finlay, J., Abowd, G., Beale, Russel.: <strong>Human</strong>-<strong>Computer</strong><br />
<strong>Interaction</strong>, third edition, Prentice Hall (2004).<br />
[2] ”The Shyguy Kingdom”: http://tsgk.captainn.net/ (Mario sprite<br />
collection)<br />
4
7 Screenshots<br />
5
Math <strong>for</strong> Kids<br />
Christina Pakonstantinou, Jens van der Water<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
akosxristin@gmail.com, jvdwater@planet.nl<br />
supervised by Yanju Zhang, Fons Verbeek.<br />
yanju@liacs.nl & fverbeek@liacs.nl<br />
Abstract. “Math <strong>for</strong> Kids” is a program of teaching, training, testing and keeping<br />
track of children progress in math. The training part is accomplished<br />
through computer games ideal <strong>for</strong> school use. Results on child’s progress are<br />
easily accessed by the teacher. The whole design ef<strong>for</strong>t focused in simplicity,<br />
coherence and attraction of the program; elements that, un<strong>for</strong>tunately, are often<br />
omitted in similar systems. Moreover, badly designed features were carefully<br />
avoided and when necessary replaced with other more efficient or attractive solutions.<br />
1 Introduction<br />
<strong>Computer</strong>s have a lot to offer in education once used and designed in a proper way.<br />
Primary schools often use computer games in order to help young children to learn<br />
basic mathematic notions and operations. Teachers that have incorporated them in<br />
their teaching in class prefer it as a quick learning tool, as well as, an easy way to<br />
have as easy overview of children’s progress.<br />
However, lots of computer systems already in market fail to be broadly used – or to<br />
be used at all – because of design drawbacks. <strong>Computer</strong> games in general, and most<br />
specifically those used in schools, must correspond to the needs of teachers and children,<br />
as well as, to the role they are assigned within the teaching method.<br />
“Math <strong>for</strong> Kids” deals with multiple problems within the context of developing a<br />
system <strong>for</strong> educational reasons. It especially addresses children of group 4 (7-8 years<br />
old) and their teachers.<br />
In this paper we will describe the problems we detected in evaluating prior solutions,<br />
examine the needs of our user group, cite our design decisions while developing<br />
“Math <strong>for</strong> Kids” and discuss on the results of our research, the future work on “Math<br />
<strong>for</strong> Kids” and the general concerns in the development of computer games <strong>for</strong> school<br />
use.<br />
1
2 <strong>Computer</strong>s in schools<br />
<strong>Computer</strong> games <strong>for</strong> school-use mainly address two different user groups: teachers<br />
and children. On one hand, teachers need to have an easy access to the system, feel<br />
able to control and use it in the minimum time needed. Critical in<strong>for</strong>mation on children’s<br />
progress must be easily accessible, but also safe from children’s access by<br />
mistake. On the other hand games, which mainly address to kids, must be attractive,<br />
simple and awarding. These are the problems “Math <strong>for</strong> Kids” deals with. We will<br />
examine these problems separately <strong>for</strong> each user sub-group.<br />
2.1 Teachers<br />
Primary school teachers are not necessarily computer experts, nor do they always<br />
have the patience or time to deal with a complex program. Much less when the program’s<br />
use is not critical, but only supplementary. The program should help teachers<br />
in their work and not spend their valuable teaching time.<br />
Teachers, there<strong>for</strong>e, will not use a program that is unnecessarily complex and time<br />
consuming. However, there are games that fail to be used, because of such reasons,<br />
which, among others, may be caused by the lack of instructions or tutorials.<br />
Moreover, teachers need to have easy access in children’s results. It is of high importance<br />
and one of the main reasons why teachers do use computers in schools, to easily<br />
keep track of children’s progress.<br />
Another feature teachers appreciate in computer games is their capabilities of repetition.<br />
There are kids that need special teaching methods, <strong>for</strong> example, children with<br />
autism or low I.Q., that perceive mathematics more realistically, as simple counting.<br />
These children need much more training, through repeating. To help children to derive<br />
the abstract knowledge of “5+3=8”, without referring to books or pens, repetition<br />
is a strong method in teaching.<br />
Furthermore, computers automatically adjust to child’s capabilities by changing level<br />
of difficulty according to the number of the kid’s correct answers. A comment of a<br />
teacher referring to child’s different educational needs was “I like using computers…<br />
Years ago it was ‘we all do the same in class ’. That was not good. ”<br />
Last but not least, teachers using computers in class need their settings, as well as<br />
general class’ results, to be safe from accidental access of children.<br />
2.2 Children<br />
Children of 7 to 8 years old have already been taught addition, subtraction and multiplication<br />
up to 100. They are also taught to distinguish the different Euro banknotes<br />
and coins, as well as to read the clock.<br />
At this age children are not yet taught to use computers and not all of them - if any -<br />
have an easy access to a computer at home. Their knowledge of computers is usually<br />
limited to what the teacher shows them <strong>for</strong> the needs of a game. All of them can use<br />
2
the mouse and most of them can type numbers, but some have difficulties to undo an<br />
action, such as delete a number using the backspace key.<br />
Apart from computer knowledge the main interest in this age is children’s capability<br />
of understanding math. In general, the main issue is to repeatedly train children in<br />
mathematical operations, so as to help them deduce from their knowledge of counting<br />
the abstract sense of mathematics. <strong>Computer</strong> games are ideal <strong>for</strong> this by repeatedly<br />
posing mathematical questions, but they risk from being boring.<br />
Moreover, children do not like what they do not understand. This may apply to everything<br />
a child deals with, including computer games. Referring to this a teacher’s comment<br />
was “When they don’t understand and I am not there to help, they do not like it<br />
any more.”<br />
What really motivates children is competition and award. Implementing competition<br />
in one-user games is a bit difficult, but award can be given in numerous ways. Award<br />
from the teacher or the parents is of course of great importance but beyond of the<br />
scope of a designer. There<strong>for</strong>e, other means of award need to be found and incorporated<br />
within the game itself. A usual approach is a “congratulation” text at the end of<br />
the game, but as commented “They (kids) never read this. They just press OK.”<br />
3 Simple and Coherent<br />
“Math <strong>for</strong> Kids” consists of two parts: The menu, where the teacher chooses the class<br />
she is working with, the child’s name, whether she wants to train, test or go through<br />
the child’s results and the math operation she wants the child to train in; and the game<br />
part, where the child (or teacher) chooses a specific game to start and of course the<br />
games themselves. In both parts the philosophy is to be simple and coherent.<br />
3.1 Menu<br />
The menu was designed as simple as possible. Big buttons are predominantly used in<br />
rational order, so as to minimize the ef<strong>for</strong>t and time needed from the teacher to complete<br />
a task [1]. Moreover, we combined selections needed in one page [2] when<br />
possible, so as to avoid having lots of menu pages that would be confusing, time<br />
consuming and difficult to recover from an error done steps back.<br />
Buttons change color after selection in order to have good visibility of selections<br />
done [2]. The color chosen <strong>for</strong> the menu was a de-saturated blue, while <strong>for</strong> labels we<br />
used a deep yellow, and black, whenever there was a message of importance to be<br />
displayed, such as the names of the class [3] or the instructions in a tutorial [4].<br />
In order <strong>for</strong> the system to store children’s results and progress, the teacher has to<br />
select from the begging the child’s name [3]. After selection the name is apparent at<br />
the top right of the screen. This way the kid will not have to enter its name every time<br />
a different game starts. At this same page, there are two more buttons available: one<br />
<strong>for</strong> adding names, at the start of the year, <strong>for</strong> example and one to remove names at the<br />
3
end. Although, not functional, the choices of massively entering and removing games<br />
should be also available.<br />
The instructions <strong>for</strong> a game follow immediately after the selection of the game, presenting<br />
also a picture of the game itself [4]. Because of the number of the game the<br />
teacher has to select among, it is possible that she may not exactly remember the title<br />
of the game she is looking <strong>for</strong>. The photo that appears with the selection of the game<br />
will help her to quickly browse through the games with out actually entering any.<br />
Labels on buttons were decided with the assistant of the teacher. People prefer to deal<br />
with standardized labels, instead of having to re-learn new ones. In the difficulty<br />
selection, <strong>for</strong> example, we used the recommended labels. The labels we used, as well<br />
as what they indicate are listed in the following table:<br />
LABELS MEANING<br />
“Makkelijk” Easy Difficulty Level<br />
”Gewoon” Normal Difficulty Level<br />
“Extra” Advanced Difficulty Level<br />
“Plus” Hard Difficulty Level<br />
“Groep” For Class Selection<br />
“Training” Training Mode<br />
“Toets” Test Mode<br />
“Resultaten” Results<br />
“Plus en Min” Addition and Subtraction games<br />
“Tafels” Multiplication Games<br />
“Klok” For games to learn to read the Clock<br />
“Euro” For games where children learn banknotes and coins<br />
The result button is placed in the beginning of the menu <strong>for</strong> easy access. The train,<br />
test or result mode after being chosen are apparent at the top right of the screen. The<br />
same stands <strong>for</strong> the class and name of child, which after selection are apparent at the<br />
top left of the screen. Because of the large number of children, the names appear <strong>for</strong><br />
selection in the middle of the screen, which serves as the in<strong>for</strong>mation, instruction and<br />
feedback providing place within the program.<br />
<strong>Final</strong>ly, when the user enters the menu page of the game selection- this is the page<br />
where the children first get involved- the back button is deliberately omitted [5], in<br />
order to prevent kids mistakenly entering the previous pages. The back button is instead<br />
placed at the top right of the screen, discrete <strong>for</strong> the children but apparent to<br />
teachers.<br />
3.2 Games<br />
A usual problem with computer games <strong>for</strong> children is assuming kids have computer<br />
skills. Although, kids nowadays get acquainted with computers much earlier than<br />
previous generations, it is very likely that children of such a young age get easily<br />
confused in a game that requires more skills then they have. Moreover, the scope of<br />
“Math <strong>for</strong> Kids” is not to make children computer experts, but to offer an easy to use<br />
4
tool <strong>for</strong> the training of mathematics. There<strong>for</strong>e, all games are designed to have only<br />
mouse input. Multiple choices are predominantly used [6].<br />
In order to keep the attention of the child, bright colors are used. Furthermore, games<br />
use icons representing things that children are familiar with and trigger their interest,<br />
such as cars, flowers ice-creams. Each game has a single theme, some addressing<br />
more the boys than the girls and some the opposite.<br />
Games are simple. The general idea is to be given an operation such as “5+3=?” and<br />
to choose from a set of possible and available answers by mouse clicking.<br />
Last but not least, the retaining of the child’s motivation is taken much into consideration.<br />
Although implementing competition is difficult in one-user games, the design<br />
of the “Race” game [7] uses a second car, apart from the one the child is “in”. In the<br />
game the child’s car precedes as long as the child answers correctly the questions<br />
posed. Small awards within the game are also implemented. For example, in the<br />
“Bloem” game [8], whenever the child answers right a few times, a water-can waters<br />
the small pots and the flowers grow.<br />
Those techniques are used to motivate and encourage children while playing. However,<br />
the final award at the end of the game is also important. This should not be<br />
something irrelevant with the game, such as a text, but should instead be linked with<br />
the whole game process. For example, in the “Race” game cars reach the final line,<br />
and in the “Bloem” game flowers finally bloom. These are to be shown with the help<br />
of a small movie clip, possibly with sound. Children, after all, like multi modality as<br />
it is more fascinating and enhances their experiences.<br />
4 Results and Evaluation<br />
Because of the nature of the program, that is, the main user group being split in two<br />
equally important subgroups, we will discuss the results of the evaluations in terms of<br />
“teacher’s results” and “children’s results”.<br />
4.1 Teacher’s results<br />
The first evaluation focused on the menu part of the program which is intended <strong>for</strong><br />
teacher use only. There was a S.U.S. questionnaire given with questions covering<br />
most aspects of usability. The average score reached 72.5, mainly because of the<br />
design features of “Math <strong>for</strong> Kids”, such as coherence in button labels and order.<br />
Questions referring to functionality and options availability were scored less, as the<br />
presented prototype at that moment was not yet fully developed.<br />
Teachers were further involved in development and evaluation of both the teacher<br />
and the game part as developed in later stages of the program’s prototype. Their contribution<br />
resulted in changes to both of these parts.<br />
The design of the interface of the program was from the beginning designed as simple<br />
as possible, which resulted to positive reaction towards the program. The grouping of<br />
5
items to be selected was found well implemented. The order of buttons to be presented<br />
followed the task analysis teachers provided:<br />
Choose Class > Choose Child > Choose to train/test/see results<br />
After a teacher’s suggestion the “results” button was added as an extra option in the<br />
main menu at the first page. Another suggestion we had during evaluations is the<br />
omission of the back button in the screen where children choose the particular game<br />
they will play. This feature was also corrected in the further development of the program.<br />
<strong>Final</strong>ly, taking into account that teachers are the experts to comment on children<br />
games, we had 3 primary school teachers to comment on the games <strong>for</strong> the kids. No<br />
severe comments were made, except one: Among the different games available in the<br />
program, there is one intended to teach children to read the clock. The original idea<br />
was that the child would be given an hour on an analogue clock and it would have to<br />
express the given hour by means of numbers [11].<br />
However, after discussion with the teachers this turned out to be not an adequate<br />
approach <strong>for</strong> children of that age. The reason was that reading the hour from a digital<br />
clock is not yet taught at that age, and there<strong>for</strong>e children are not familiar with expressing<br />
the hour by means of numbers. There<strong>for</strong>e, instead, we used multiple natural<br />
language expressions <strong>for</strong> the child to choose the right one from [6].<br />
4.2 Children results<br />
Children were actively involved in the design of the games, which is generally though<br />
to be important 1 . Although the games’ inner structure and function can not efficiently<br />
be evaluated by children, their overall appearance can, at least partly, align with children’s<br />
perception of things. To make this point clear, we will consider an example<br />
taken from the second evaluation’s procedure. The example refers again to the clock<br />
game mentioned above.<br />
It is clear that the structure of the game - that is what the goal will be, what the kids<br />
will have to do and how they will do it - can not be evaluated by children in an efficient<br />
way (within limited time constrains and lack of pedagogic expertise). But, the<br />
actual representation of the clock should depend on how children “see” a clock.<br />
In the second evaluation session at the school we asked 6 children to draw a clock<br />
(amongst other objects to be used in the games as well). Surprisingly, children do not<br />
visualise clocks as we would expect, that is alarm clocks on bedside tables or on the<br />
wall. Instead, the majority of the kids drew them on church towers; which makes<br />
sense, if one considers how many of these characteristic buildings can be found in<br />
Dutch cities.<br />
More of such similarities in drawings were found and were used in the games’ designing.<br />
Moreover, all games were designed to have only mouse input, in order to<br />
avoid frustration of mistyping; a usual problem with children games that assume<br />
typing skills.<br />
6
5 Conclusions and Discussion<br />
Lots of changes were made after teachers’ suggestions and comments on the program’s<br />
prototypes, <strong>for</strong> example, the addition of the results button in the first page of<br />
the menu [1], so as to enable immediate access and over children’s progress. Instead<br />
the option would be restricted to the end of each test or game and quick supervision<br />
would have been impossible.<br />
Another thing changed was the omission of the back button in the screen of games<br />
selection [4], [5]. The reason <strong>for</strong> this is that children should not be given the chance<br />
by the program to enter the teacher’s page and change <strong>for</strong> example the math type or<br />
even watch the whole class’s results of tests etc. Note that this is also the page appeared<br />
after having finished a game. It is there<strong>for</strong>e a page, in which kids will be entering<br />
numerous times. Instead of the back arrow button, another more discreet button<br />
was added in those pages at the top right of the screen [4].<br />
Other changes made referred to the knowledge of the children at that age; which if<br />
not taken into consideration the result would be a not appropriate game <strong>for</strong> these kids,<br />
and there<strong>for</strong>e unusable.<br />
During the developing process of “Math <strong>for</strong> Kids” we came to the general conclusion<br />
that, although computer games are in general welcome in schools thanks to their<br />
efficiency as teaching tools, they can also fail to be used due to their complexity of<br />
design and their lack to address the actual needs of their user group. It is of high importance<br />
to be in continuous contact with her intended user group, as the evaluations<br />
showed.<br />
Especially, when the artifact is aiming to be used as an educational tool, its requirements<br />
to fulfill are numerous and of equal weight. Teachers’ goals and expectations,<br />
children’s skills, likes and dislikes, as well as the actual role of the games within the<br />
class teaching process must be highly considered. Participatory design can make the<br />
best solutions appear and reveal aspects of the user group’s expectations one might<br />
find hard to imagine from the beginning.<br />
6 Future Work<br />
Because of the limited duration of the project, there are still a lot of things that need<br />
to be completed in “Math <strong>for</strong> Kids”, in order <strong>for</strong> it to be ready <strong>for</strong> use. First on the list<br />
is the functionality of the “adding-deleting-selecting” names page supported by a data<br />
base.<br />
Secondly, there could be all the games added. Of course this would take a long time if<br />
one considers that, up to now “Math <strong>for</strong> Kids” has buttons available <strong>for</strong> 38 different<br />
games. If we also take into account the different levels of difficulty this number is<br />
then multiplied by 4, whose outcome can also be multiplied by 4 <strong>for</strong> the 4 different<br />
classes available in the first page.<br />
7
Sound can also be added in all steps of the program and game stages, in the <strong>for</strong>m of<br />
earcons, providing feedback or as background music tallying with the game process.<br />
<strong>Final</strong>ly, but of high importance are the small movie clips during, and at the end of the<br />
game, that are mend to attract children’s interest and attention, fulfilling their need<br />
<strong>for</strong> award and encouragement.<br />
6.1 The future in the field<br />
Learning through computers, the so called e-learning, is a still developing but most<br />
promising field. <strong>Computer</strong> games <strong>for</strong> school use can be an efficient and productive<br />
tool <strong>for</strong> teachers in class, whose future can be as impressive as one can imagine.<br />
“The technologies that will vastly change in<strong>for</strong>mation and communication<br />
are auto stereoscopic display systems, 3D sound, augmented<br />
reality, virtual reality, and portable or wearable ubiquitous in<strong>for</strong>mation<br />
machines. Through any or all of these technologies, a teacher<br />
can guide or a student can present projects within the node or beyond.”<br />
2<br />
However, there are major concerns on how far this change can go without emerging<br />
drawbacks, which is one of the reasons why many schools avoid the use of computers.<br />
Many believe that computers should not be assigned the role of the unique<br />
tutor nor trigger the isolation of children in class, but instead they should be efficiently<br />
used within the classical teaching method of multiple learning processes.<br />
“We cannot truly trans<strong>for</strong>m educational practice <strong>for</strong> the better<br />
through using new technologies unless we examine the roles the computer<br />
can play in truly stimulating, supporting and favouring innovative<br />
learning interactions that are linked to conceptual development<br />
and improvements in understanding.” 3<br />
Although, juveniles’ processing in learning is mostly based on repetition and rehearsal,<br />
something on which computers are ideal to help at; there is still an imperative<br />
need of a trainer with pedagogic experience to guide this whole process. Moreover,<br />
“..In order <strong>for</strong> e-Learning to be used as successful means of education,<br />
the pedagogy of a course should be taken under consideration.<br />
The use of technology, although innovative and welcomed, can prove<br />
quite perilous; Technology in e-Learning is important in the way it is<br />
used, rather than how advanced it could be. The unsuccessful implementation<br />
of technology in e-Learning is inevitably linked with the<br />
poor implementation of pedagogy, which would ultimately make e-<br />
Learning unsuccessful as a medium of communicating knowledge.” 4<br />
8
References<br />
1. Alan Dix et al, “<strong>Human</strong>-<strong>Computer</strong> <strong>Interaction</strong>”, 1996, Pearson Education, p. 391<br />
2. http://www.technology.gov/reports/TechPolicy/2020Visions.pdf<br />
3. Ravenscroft, A. (2001). Designing E-learning <strong>Interaction</strong>s in the 21st Century: revisiting<br />
and rethinking the role of theory. European Journal of Education p. 134<br />
4. E.Gavtielidou, “Learning through interactive media”, Dissertation, 2006<br />
Appendix<br />
[1]<br />
9
[2]<br />
[3]<br />
10
[4]<br />
[5]<br />
[6]<br />
11
GAMES’ IDEAS AND DRAWING PROTOTYPES:<br />
[7] [8]<br />
[9] [10]<br />
12
[11]<br />
13
Dobbelrekenen<br />
Marian Maas, Anthony Woudenberg<br />
1 LIACS, Universiteit Leiden, Niels Bohrweg 1, Leiden<br />
mpf.maas@gmail.com, ti83magic@hotmail.com<br />
Geassisteerd door Alexander Nezhinsky & Fons Verbeek<br />
anezhins@liacs.nl, fverbeek@liacs.nl<br />
Hoofdrekenen blijkt voor veel basisschoolleerlingen een groot probleem te zijn. Zelfs in groep 8 blijkt dat<br />
de vaardigheid van het hoofdrekenen vaak nog niet goed genoeg beheerst wordt. Dobbelrekenen<br />
probeert hier verandering in te brengen door middel van een makkelijk te benaderen, snel te begrijpen<br />
spel. Door middel van een prikkelend spel gecombineerd met onderlinge competitie onder de leerlingen<br />
wordt getracht de manier van denken bij hoofdrekenen te stimuleren, en uit te bouwen tot iets natuurlijks,<br />
in plaats van iets ge<strong>for</strong>ceerds.<br />
1 Introductie<br />
Hoofdrekenen is een essentieel onderdeel van de basisvaardigheden die een basisschoolleerling<br />
zou moeten beheersen. Helaas blijkt op de middelbare school dat ruim de helft van de<br />
aanwezige brugklassers zelfs de meest elementaire wiskundige begrippen NIET genoeg<br />
beheerst om de nieuwe stof optimaal in zich op te kunnen nemen. Het leek ons daarom een<br />
goed idee om hier een oplossing voor te zoeken, temeer vanwege het feit dat het zusje van één<br />
van ons perfect in de doelgroep past. Gekozen is voor laatstejaarse basisschoolleerlingen, waar<br />
het spel voornamelijk een kwestie van herhaling zou moeten zijn, en op zich geen nieuwe<br />
begrippen leert; getracht wordt om de leerlingen beter hoofdrekenen aan te leren, ze er bekender<br />
mee te maken. Om er geen saaie oefening van te maken is gekozen voor een oud spel,<br />
genaamd Dobbelrekenen.<br />
Dobbelrekenen is een spel dat met vijf dobbelstenen gespeeld wordt. Na een worp zijn drie<br />
dobbelstenen beschikbaar om een opgave mee te maken, terwijl de twee overgebleven stenen<br />
het antwoord bepalen. Uiteraard bestaat met een willekeurige worp niet altijd de mogelijkheid om<br />
tot het juiste antwoord te komen; normaliter wordt er dan benaderd. Omdat het echter onze<br />
bedoeling is dat de kinderen er iets van op steken, hebben wij besloten de kinderen te<br />
verplichten tot een juist antwoord te komen; er is altijd minstens één manier om met de eerste<br />
drie dobbelstenen tot een antwoord te komen dat gevormd wordt door de laatste twee. Er bleek<br />
geen goede manier om te evalueren hoe goed of fout een bepaalde benadering was; deze<br />
manier garandeert een binaire manier van antwoorden; een antwoord is goed, of het is fout.<br />
Afhankelijk van het aantal pogingen en de tijd die de leerlingen er voor nodig hadden na het juist<br />
beantwoorden van een vraag, krijgen ze een highscore toebedeeld. Deze manier van beloning<br />
verschaft een manier van zelfovertreffing, en maakt het mogelijk om scores met andere<br />
leerlingen te vergelijken. De voorspelling is dat de leerlingen zullen proberen steeds sneller tot<br />
een juist antwoord te komen, en zo actief de opgaven maakt.<br />
In dit document wordt dan ook besproken welke problemen we tegenkwamen bij de realisatie van<br />
dit idee, en welke oplossingen we er voor gevonden hebben.
2 Doelgroep en bijbehorende problemen<br />
De gedachte achter Dobbelrekenen is dat de leerlingen het spel in een verloren kwartiertje<br />
kunnen spelen, wanneer ze daar zelf zin in hebben. En hoewel er tegenwoordig op de meeste<br />
scholen computers zijn waar de leerlingen zelfstandig mee op de gang kunnen werken, zijn deze<br />
verre van ideaal. Vanuit de gedachte van de huidige onderwijssituatie zijn de computers<br />
goedkoop, en daarmee verband houdend, rijkelijk oud te noemen. Een van de uitdagingen was<br />
dat we een grafisch interessant product wilden afleveren, dat toch nog speelbaar was op de oude<br />
PII's. Daarbij dienden we ook rekening te houden met de beperkte resolutie; de beeldschermen<br />
zijn net zo oud en beperkt als de systemen die ze begeleiden. Eén van de grootste en meest<br />
opvallende ergernissen op de basisschool bleek dat de beschikbare educatieve programma's<br />
slecht tot niet draaiden op de aanwezige systemen, ondanks de hoge mate van kwaliteit. Heel<br />
duidelijk bleek dat er geen rekening gehouden wordt met de beperkte faciliteiten van de<br />
hedendaagse basisschool. Het was voor ons een niet te negeren doelstelling ons programma<br />
toch op de systemen te kunnen laten draaien, zodat er gewoon gebruik van gemaakt kon worden.<br />
Om de rekenkracht zoveel mogelijk te ontzien, is er tevoren een lijst gemaakt met alle mogelijke<br />
combinaties van worpen waarbij er met de eerste drie dobbelstenen tot een antwoord gekomen<br />
kan worden. Volledig willekeurige worpen moesten namelijk in het beste geval 3, in het slechtste<br />
geval tot wel 20 keer gedaan worden voordat er een goede combinatie gevonden was. Want let<br />
wel; het was nodig exact op de doelstelling uit te komen, benadering was uitgesloten. Deze<br />
herhaling van een vrij CPU-gevoelige functie bleek te omzeilen door tevoren extra<br />
processorkracht toe te passen, en een lijst op voorhand te maken. Aan ruimte is er op de<br />
systemen slechts weinig gebrek, dus hebben we qua time/space-tradeoff gekozen voor een<br />
snellere tijd, ten koste van ruimte.<br />
In het artikel "Teaching with Games; Using commercial off-the-shelf computer games in <strong>for</strong>mal<br />
education." wordt beschreven hoe kinderen onderwezen kunnen worden met behulp van<br />
bepaalde commerciële computerspellen. Een typerend verschijnsel welke hierin niet uitvoerig<br />
behandeld wordt is dat het onderwijzende personeel vaak de software dient te bedienen. Het<br />
blijkt in de praktijk zelfs vaak nodig dat de juf dan wel meester eerst het pakket moet activeren en<br />
instellen, voordat het kind kan spelen. Dit blijkt een contraproductieve manier van aanpak, daar<br />
het kind niet op de computer kan als de juf/meester bezig is met andere zaken. Deze onnodige<br />
vorm van arbeidsintensiviteit hebben we dan ook volledig vermeden door de interface simpel te<br />
houden, zonder ellenlange lijsten met instellingen. Het kind, welke vaak beter overweg kan met<br />
computers dan de leraar, zal hierin niet de weg kwijtraken, en kan zelf het spel spelen als het<br />
daar zin in heeft.<br />
Tijdens het evalueren bleek onder andere dat de door ons in eerste instantie bedoelde aanpak<br />
met alleen de muis niet altijd even goed werkte. Twee kinderen vonden het jammer dat ze<br />
volledig afhankelijk waren van de relatief langzame muis, en niet de mogelijkheid hadden het<br />
toetsenbord te gebruiken. Om tegemoet te komen aan deze vragen, hebben we er uiteindelijk<br />
voor gekozen beide manieren van invoer te implementeren.<br />
3 Aanpak van de problemen<br />
De traagheid van de computers was één van de voornaamste problemen. De grootste<br />
uitdagingen lagen hier dan ook van in het verlengde; je kan het je niet veroorloven een<br />
geheugenlek te hebben in een programma als dit, als het systeem waarop het draait net genoeg<br />
bronnen heeft om het programma draaiende te houden. Elke versie werd dan ook getest op<br />
geheugenlekkages, en of het nog altijd werkte op de P II's. Het bleek bijvoorbeeld in de door ons<br />
gekozen ontwikkelomgeving niet triviaal om een zelfgemaakte cursor te tonen zonder dat daar<br />
elke beeldverversing expliciet intensieve berekeningen voor moeten orden uitgevoerd. Door<br />
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.<br />
Een ander probleem dat we tegenkwamen bij de op de school aanwezige programma's, was dat<br />
er op het eerste gezicht geheel niet duidelijk is wat de bedoeling is. Een vlug spelletje zit er bij die<br />
programma's simpelweg niet in. Bij Dobbelrekenen hebben we getracht om uit de interface te<br />
laten blijken wat de bedoeling is. De cursor valt direct op, en ook de knoppen spreken direct voor<br />
zich. Door het toepassen van de Gestalt wetten over perceptie en plaatsing (Johnson & Proctor,<br />
2004) op de knoppen, wordt duidelijk dat er van de speler verwacht wordt een opgave te maken.<br />
Verder is er een duidelijke klok aan de bovenzijde van het scherm, begeleid door een<br />
knippereffect als de tijd bijna op is, laat duidelijk zien dat er een tijdlimiet is. Tot slot bevindt er<br />
zich een venster waarin begeleidende in<strong>for</strong>matie wordt gegeven als de muis over een onderdeel<br />
geplaatst wordt, mocht dit nodig zijn. De "enter"-toets is groter dan de andere knoppen, opdat<br />
deze niet gemist kan worden bij het trachten de snelste tijd neer te zetten. De toetsen om een<br />
nieuw spel te starten en naar het hoofdmenu te gaan zijn vanzelfsprekend duidelijk, en ver van<br />
het speelscherm gepositioneerd om ongewenst aanklikken te voorkomen. Deze staan, niet<br />
toevallig, op exact dezelfde positie als de knoppen in het hoofdmenu, om continuiteit te<br />
garanderen. Tot slot is de flow van het programma van boven naar beneden, als de leesrichting;<br />
bovenaan de vorming van de berekening, onderaan het bevestigen ervan. Dit in<br />
overeenstemming met Norman's Pertinence Model (Ashcraft, 2002).<br />
4 Resultaten en evaluatie<br />
De kinderen hadden commentaar op de kleuren, grootte van knoppen en de wijze waarop de<br />
score berekend werd, welke na de eerste evaluatie dan ook sterk verkleind zijn. In eerste<br />
instantie werd het programma ontwikkeld op een resolutie van 1152x864px, waar alles er goed<br />
uitzag. op de testcomputer bleek uiteraard dat de knoppen explosief toenamen in <strong>for</strong>maat...<br />
De kritiek was goed te gebruiken om het ontwerp te verbeteren. Natuurlijk waren de gebruikers<br />
niet geheel tevreden met het programma dat we uiteindelijk ontwikkeld hebben, ze zijn immers<br />
wel beter gewend op de computer thuis. Toch is het resultaat van ons onderzoek positief, want<br />
het prototype maakt optimaal gebruik van de aanwezige voorzieningen en dat was het doel. Het<br />
prototype van dobbelrekenen draait momenteel op een basisschool en wordt met voorzichtig<br />
enthousiasme gebruikt. Bij installatie bleek wel dat we de computers overschat hadden,<br />
aangezien er geen muisbesturing op zat. Dit is gelukkig kundig verholpen, waarna de<br />
ingebruikname voorspoedig verliep. Hoezeer de wiskundige vaardigheden van de kinderen erop<br />
vooruit zullen gaan is helaas niet te zeggen, maar het ligt in de lijn der verwachtingen dat ze het<br />
leren door met de cijfers en operatoren te spelen.<br />
5 Conclusie en discussie<br />
referentie<br />
en hci-ers moeten vaker nadenken over de aanweizge faciliteite<br />
Het is nog te vroeg om te kunnen beoordelen of de kinderen op de lange termijn daadwerkelijk<br />
een verhoogde vaardigheid in hoofdrekenen opgedaan hebben, en of dat al dan niet afkomstig is<br />
van dit programma, maar tijdens de twee gedane evaluaties bleek wel dat, nadat de leerlingen<br />
bekend werden met het programma, steeds sneller de opgave konden maken. Waar in het begin<br />
nog meermaals de tijd bijna opraakte, werd er na een klein aantal gedane opgaven al<br />
vooruitgang geboekt. De highscore functie was door de zeer korte tijd tussen de evaluaties<br />
helaas nog niet volledig werkend ten tijde van de tweede user evaluatie, dus het zijn subjectieve<br />
metingen, maar er leken twee curven te zijn. De eerste vooruitgang in tijd was de grootste,<br />
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<br />
op de daadwerkelijke bedoeling van het spel, en werden er steeds vaker juiste antwoorden<br />
gegeven in een korter tijdsbestek. Uiteindelijk blijkt de limiet van 30 seconden teveel te zijn, maar<br />
hij is gewoon nodig om in het begin niet direct af te zijn. Voor de gevorderde maakt de tijdslimiet<br />
niet meer uit, en gaat het alleen om de verstreken tijd (welke de score bepaalt!). Deze dubbele<br />
vorm van spelplezier is een gegeven waar we toch wel trots op zijn...<br />
Er is echter ook iets opgevallen waar we minder blij zijn, veel minder blij zelfs. Een heel simpel<br />
wiskundig sommetje leert ons dat er met met twee dobbelstenen maar 36 mogelijke antwoorden<br />
zijn. Verder liggen deze ook nog een tussen de 11 en 66 (ga maar na). Nu is het aantal<br />
antwoorden beperkt, maar het aantal opgaven dat gemaakt kan worden is (mede hierdoor) vele<br />
malen beperkter. De kans dat je met een deling nog valt in het interval van [11,66] EN geen van<br />
beide cijfers van het getal hoger dan een 6 of lager dan een 1 is, is heel erg klein. Veel kleiner<br />
dan de kans dat je dat met een vermenigvuldiging lukt... Evenzo met sommen en verschillen. Bij<br />
het genereren van de lijst hebben we de volgende statistieken gevonden;<br />
///////////////////////////////////////////////////////<br />
// Total amount of equations tried: 3456 //<br />
// Total amount of valid equations found: 483 (=14%) //<br />
// //<br />
// Additions: 312 //<br />
// Subtractions: 74 //<br />
// Multiplications: 371 //<br />
// Divisions: 38 //<br />
///////////////////////////////////////////////////////<br />
Dit is de uitkomst na het proberen van 6*6*6 dobbelsteenconfiguraties, vermenigvuldigd met 4*4<br />
operatoren, inclusief haakjes. De getallen geven weer hoeveel opgaven minstens één of meer<br />
keer die operator bevatten. Hier is heel goed te zien dat de verhouding tussen incrementele<br />
operatoren sterk scheef is ten opzichte van de verkleinende operatoren (- en /). Dit is vanwege<br />
het feit dat de uitkomst een geheel getal moet zijn (de meeste delingen vallen al af), en in het<br />
geval van aftrekken, er op 1 optie na een vermenigvuldiging aan vooraf moet gaan. Bij een<br />
benadering van het te behalen getal zou dit probleem veel minder zijn; ook dit is echter weer een<br />
probleem op zich.<br />
6 Verdieping<br />
Deze versie van Dobbelrekenen is bewust minimaal gehouden, om hem zo efficiënt<br />
mogelijk in de schoolomgeving te kunnen laten gebruiken. Er kan echter nagedacht<br />
worden over een variant voor thuis, die wat meer mogelijkheden biedt, zoals het<br />
bijhouden van een persoonlijke lijst, naast de reguliere highscore lijst die voor alle<br />
gebruikers geldt. Dit vereist echter een vorm van inloggen die we in deze versie niet<br />
wilden gebruiken; het kost meer tijd om een spel te starten, meer ruimte voor de sterk<br />
toegenomen hoeveelheid lijsten, en bleek uiteindelijk niet nodig. Daarbij zou de leraar<br />
moeten ingrijpen als een kind de harde schijf vervuilt met telkens een verschillende<br />
inlognaam; iets waar we niet zonder meer vanuit kunnen gaan dat dat tot de kennis van de<br />
leraar behoort.<br />
Voor deze versie hebben we gekozen voor een heel specifieke doelgroep kinderen, welke<br />
de meest elementaire wiskundige operatoren kent. Helaas behoren machtsverheffingen en<br />
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<br />
operaties toegevoegd kunnen worden. Ook zou er geëxperimenteerd kunnen worden met<br />
het aantal dobbelstenen; zou de oplossing nog te zien zijn met vier dobbelstenen? Of zou<br />
dit teveel zijn om binnen redelijke tijd exact op te kunnen lossen? Er kan nagedacht<br />
worden over een marathon, waar men enkele opgaven maakt, waarna de tijd genotuleerd<br />
wordt. Dit geeft een nauwkeuriger gemiddelde tijd, maar gaat ten koste van het idee dat<br />
je even snel een potje kan doen. Ook hier zou onderzoek naar gedaan kunnen worden, of<br />
het wel wenselijk is.<br />
Bij het eigenhandig testen op de computer verbaasde we ons over het feit dat de muis<br />
enorm gevoelig was voor zelfs maar de kleinste beweging die we maakten. Navraag bij<br />
de leraar leerde ons dat dat de instellingen van de computer waren, maar dat ze geen idee<br />
had hoe dit te veranderen. Een gegeven waar de kinderen al aan gewend leken, maar voor<br />
ons als secundaire testers een gegeven was waar we ons kapot aan zouden ergeren bij<br />
langdurig gebruik. In een applicatie voor gebruik op een basisschool wilden we dan ook<br />
pleiten voor enkele, minder gebruikelijke opties, waaronder dus de gevoeligheid van de<br />
muis. Een simpel schuifbalkje zou zoveel helpen, waardoor zowel het kind als de leraar<br />
op gemakkelijke wijze de spelervaring sterk kan vergroten.<br />
Er kan wellicht zelfs nagedacht worden over een wat volwassener versie, gericht op<br />
volwassenen die het rekenen wat beter moeten gaan beheersen dan ze gewend zijn. We<br />
denken hierbij aan PABO studenten, welke niet lang geleden weer in het nieuws waren<br />
wegens hun beperkte wiskundige kennis, en beginnend(e) caissières en horeca-personeel.<br />
We denken niet dat het een zelfstandig product zou kunnen vormen, maar in combinatie<br />
met andere, kleine programma's zou het wellicht het hoofdrekenen positief kunnen<br />
beïnvloeden.<br />
Bronvermelding<br />
1. Richard Sand<strong>for</strong>d, Mary Ulicsak, Keri Facer and Tim Rudd, Teaching with Games;<br />
Using commercial off-the-shelf computer games in <strong>for</strong>mal education, Futurelab, 2006.<br />
2. Alan Dix et al, <strong>Human</strong> <strong>Computer</strong> <strong>Interaction</strong> (3rd edition), Pearson-Prentice Hall, 2003.<br />
3. Mark H. Ashcraft, Cognition (3rd edition), Pearson-Prentice Hall, 2002.<br />
4. Addie Johnson and Robert W. Proctor, Attention: Theory and practice, Sage<br />
Publications, 2004
PuzzleMath<br />
Tim van Meurs, Ioannis Panagiotou<br />
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
tvmeurs@liacs.nl, bone.jp@gmail.com<br />
supervised by Yun Bei, Fons Verbeek.<br />
ybei@liacs.nl & fverbeek@liacs.nl<br />
Abstract. How do we design interfaces <strong>for</strong> children? In this paper we discuss<br />
the process of making an educative game <strong>for</strong> children focused on their mathskills.<br />
Usability and functionality play a big part in this process. The curiosity<br />
of children is an important thing to keep in mind during the creation of a program<br />
like this.
1. Introduction<br />
1.1 A general approach<br />
The last years we see a lot of games <strong>for</strong> children on the Internet. A lot of the games<br />
do not help the kid to develop any skill, that could help him/her in mathematics and,<br />
in general, most of them do not have any pedagogic purpose. On the other hand, the<br />
games that have a pedagogic purpose or somehow help kids to develop their math<br />
skills, after a while become really boring and children do not want to use them anymore.<br />
1.2 Our approach<br />
Our approach was to create a game that can combine those two things, attractiveness<br />
and education. PuzzleMath is didactic, but in the same time not a boring game<br />
and triggers the attention of the kid. PuzzleMath makes children to improve their<br />
math skills. Fundamentally it helps kids to practice their already knowledge, like<br />
adding, subtracting, multiplying and dividing, so as to start solving problems of multiple<br />
equations and practice mathematical reasoning.<br />
The main game consists with a grid of icons; each icon represents a number which<br />
is “hidden”. Additionally each line and column has a specific given sum. The player<br />
has to calculate the “hidden” numbers, represented by icons, given the position of the<br />
icons in the grid and the sums of each line and column. This way the kid starts getting<br />
acquainted with solving equations, in its ef<strong>for</strong>t to calculate the right number that corresponds<br />
to each icon.<br />
1.3 The outline<br />
In this paper we will describe the problems that we encountered during the design<br />
process, our intended user group and its needs. In addition we will demonstrate how<br />
all these play a significant role in our decisions. <strong>Final</strong>ly we will discuss its possible<br />
impacts in future development of didactic games.
2. Math: the headache of kids<br />
2.1 Abstraction of math<br />
We all remember when we were kids ourselves learning math, how difficult it was<br />
to connect the abstract meaning of numbers to something physical and visible – that is<br />
– the difficulty of solving equations is one of the major problems that kids face when<br />
they learn mathematics. They cannot understand the meaning of the “unknown number”<br />
that they have to find in an equation. Generally kids have difficulty in understanding<br />
how to divide, add, multiply or subtract numbers, in order to find something<br />
“unknown”, although that is simply another number.<br />
2.2 User group<br />
Our main user group is consisted of kids from 9 to 10 years old. This is the age<br />
where kids start learning unlimited adding and subtracting, multiplication, division<br />
and the use of brackets (2) . We also focus in kids of higher ages, such as 11 and 12,<br />
because there are a lot of kids in these ages that need help to improve their skills and<br />
apply their already gained knowledge in an easy and fun way.
3. Icons do the work<br />
In PuzzleMath we use icons, which are kid friendly, to represent numbers. We<br />
found that this helps kids to solve equations, because the unknown number is now not<br />
something abstract but something visible. A lot of games (1) use a system like this to<br />
help children in improving their math-skills.<br />
Moreover we tried different types of icons to see which one is more enjoyable <strong>for</strong><br />
a kid but in the same time not distracting.<br />
Our design changed completely after our first evaluation. It seems that too much<br />
color does not help kids to focus in the main game area. Moreover, we tried to keep<br />
our game as minimal as possible and focus in it being tangible.<br />
We have put three levels of difficulty: easy, medium and hard. This makes the<br />
game suitable <strong>for</strong> more children with different levels of math skills. In addition, it<br />
does not get boring but keeps on challenging kids.<br />
We have also put a hint button that reveals the position of each number that is been<br />
filled in as the corresponding number <strong>for</strong> an icon. This way kids know what is where<br />
and minimize the chance of mistakes and misunderstandings.<br />
Moreover, we have included a tutorial part to help kids to learn how to play the<br />
game.<br />
This way beginners will not have to guess how the game works, but will be properly<br />
introduced in the philosophy of the game.
4 Results and Evaluation<br />
In this section we will walk through different elements of our design and explain<br />
how and why they changed through-out the building of various prototypes. We will<br />
be talking about the first, second and final evaluation. Screenshots of each evaluation<br />
are added in the appendix.<br />
4.1 Buttons<br />
Our first prototype featured a number of buttons with various sizes and colors below<br />
and above the puzzle. Evaluations showed us that the buttons were not perceived<br />
as logical and it took a lot of time <strong>for</strong> users to find the button they were looking <strong>for</strong>.<br />
In the second prototype we chose to make one sort of button to use through-out the<br />
program. This turned out to be a gray button that shows an pushing-down effect when<br />
clicked on. The function of the button was shown as text inside the button and a little<br />
icon/picture was added to each button to further clarify the actions.<br />
4.2 Pictures<br />
The pictures used in the first prototype didn't get very good response in the first<br />
evaluation. Kids didn't really like them. So <strong>for</strong> the second and final prototype we<br />
decided to use our second set of pictures we created <strong>for</strong> the paper design. These got<br />
better response in the evaluation.<br />
4.3 Hint-system<br />
The biggest problem while making the program was creating a system that could<br />
give hints to players if they were stuck in solving the puzzle. We thought of a number<br />
of different options, of which some were proposed by other students while doing our<br />
presentation. For the first prototype we chose the simplest option to implement, which<br />
was to give the children a number they didn't guess yet as a hint to solve the rest of<br />
the puzzle.<br />
While doing the evaluation we were shown that children are fairly clever in figuring<br />
this out which ended up in users clicking the hint-button 4 times and through that<br />
solving the puzzle. That is why, <strong>for</strong> the second and final prototype, we chose to make<br />
a system where the numbers that were already filled in were shown in the puzzle over<br />
the pictures. This way, users had a better representation of the numbers in the puzzle<br />
and were able to solve the puzzle more easily without having a system that gives<br />
away correct answers.
4.4 The checking-system<br />
In the puzzle is a button called 'controleer' which is Dutch <strong>for</strong> 'check'. This is used<br />
to see whether the filled in answers are correct. The first prototype had a button<br />
which didn't do anything unless the puzzle was solved correctly. This lead to frustration<br />
if a user had filled in a wrong answer and the system didn't do anything. Also,<br />
when a user would have figured out an answer but had it wrong, there was no clue to<br />
tell them, so they could be puzzling <strong>for</strong> several minutes because their first answer was<br />
incorrect. In the second and final prototype we changed the system so that the program<br />
shows the user which answers are correct and which are incorrect so the user<br />
can go back to his/her incorrect answers and check them instead of getting frustrated.<br />
4.5 Menu<br />
We found that the buttons shown below and above the puzzle in the first prototype<br />
were confusing to children. That is why we chose to make a sort of menu on the right<br />
side of the program <strong>for</strong> the second prototype. In the bottom of the menu were the<br />
same two buttons that always stay there. Above that are the buttons that are used <strong>for</strong><br />
that specific part of the program and above that is the info of the player that is using<br />
the program at that point. We found that users can find the buttons more easily when<br />
they are all together in a separate part of the program. To even more clarify the menu<br />
we chose to change the background color of the menu to differ from the backgroundcolor<br />
of the rest of the program in the final prototype.<br />
Overall, we think that through making a first prototype which was kind of a disaster<br />
we could make a second and final prototype which is way better in usage due to<br />
better consistency, color-use, etc.
5 Conclusion and Discussion<br />
We found that it is possible to create in interface <strong>for</strong> a children's-game that is easy<br />
to use and easy to learn. A user-group of children is both fun and stimulating. They<br />
can do very unexpected things and can be very inventive in finding out stuff.<br />
The choice to use Flash turned out to be a good one. Actionscript supported all the<br />
options we wanted to add and it was easy to use with a background of PHP and C++.<br />
It took some time to figure out some options, but was definitely the right choice <strong>for</strong><br />
making a program as we did.<br />
The user evaluations showed us that consistency is important if inexperienced<br />
computer-users use your program. They can more easily find the buttons if they are in<br />
the same place and look the same every time.<br />
We think we created a program that well suits our intended user-group and could<br />
eventually be used in schools.
6 Future Work<br />
We found that teachers and parents of children that used the program are very interested<br />
in the results of the children to see whether they make any progress. An option<br />
<strong>for</strong> this is to add some functionality which stores info about the time it took to<br />
complete a puzzle and the number of times an answer was checked and the hint was<br />
used in a database. Teachers and parents are then able to see the progress a child<br />
makes and compare this progress to the progress of other kids to see whether they<br />
need extra guidance in their math-skills.<br />
Another option would be to add some extra games in the same kind of interface<br />
where it is again possible to follow children's progress with the same database. This<br />
way, a big program can be created where kids are able to improve their math-skills<br />
and teachers and parents are able to follow their per<strong>for</strong>mance.
References<br />
1. Rekenweb – Rekenmaar<br />
http://www.fi.uu.nl/rekenweb/rekenmaar/leerlingen/index.html<br />
2. Wikipedia – rekenen<br />
http://nl.wikipedia.org/wiki/Rekenen<br />
3. Huiswerkweb rekenen<br />
http://www.huiswerkweb.nl/rekenpakket.htm
Appendix<br />
Figures<br />
Prototype 1:<br />
Prototype 2:
Prototype 3 (final):
Mobile Learning<br />
Tiago Borges Coelho, Frank Takes<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
borges@consola.org, ftakes@liacs.nl<br />
supervised by Alexander Nezhinsky, <strong>HCI</strong> Course Administration<br />
anezhins@liacs.nl & fverbeek@liacs.nl<br />
This project is an attempt to combine the fun that<br />
children experience while playing games on their mobile<br />
phones with the aid of computer programs in the<br />
educational process. We have developed a tool called<br />
‘Mobile Learning’ which allows children in Dutch primary<br />
school to play a game on their mobile phone and<br />
meanwhile learn the English language. Children will<br />
enjoy the application, because it has all the characteristics<br />
of a real game: animation, audio, rewards<br />
and different levels of difficulty.<br />
1 Introduction<br />
Nowadays, virtually every child of age ten and older has<br />
a mobile phone. The specifications of these phones in<br />
terms of CPU power and multimedia capabilities have increased<br />
rapidly over the past few years. This allows<br />
children to play relatively advanced and - in their eyes<br />
- ‘cool’ games on their phones. However, up until now,<br />
these games were mostly aimed at fun, and sometimes skill,<br />
and the field of education has not yet been widely introduced.<br />
We intend to combine the fun of a mobile phone<br />
with the educational process that can be stimulated<br />
through the concept of ‘fun’.<br />
In this paper we will describe the development of ‘Mobile<br />
Learning’, an application <strong>for</strong> mobile phones that<br />
teaches Dutch children in primary school the English language,<br />
while having fun. We will start with in<strong>for</strong>mation<br />
regarding both mobile phones and several <strong>for</strong>ms of education,<br />
after which we will evaluate what kind of users we<br />
are aiming at. After the general in<strong>for</strong>mation mentioned<br />
above, we will elaborate on our application, and provide<br />
some results of the evaluations that we did. We will present<br />
the conclusions of our project, and conclude this<br />
paper with several possible future work topics.
2 ‘‘The mobile phone as an educational<br />
multimedia plat<strong>for</strong>m’’<br />
2.1 Games<br />
The fact that children enjoy playing games has been known<br />
<strong>for</strong> hundreds of years. In addition to the traditional<br />
board games, computer games have become extremely popular<br />
during the last few decades. Relatively recently, a new<br />
dimension has been given to computer games. New mobile<br />
phones have sufficient capacity to play games with color,<br />
animation and sound. This is due to the fact that nowadays<br />
a phone has roughly the same specifications as a six<br />
year old computer. This fairly new fully capable multimedia<br />
plat<strong>for</strong>m offers some interesting possibilities.<br />
2.2 Education<br />
Schools and education are extremely important <strong>for</strong> any<br />
country. Luckily, we live in a country where education is<br />
at quite a high level. Because the standard needs such as<br />
schoolbooks and paper educational material have been<br />
around <strong>for</strong> such a long time, we can now focus on new media<br />
to increase the education experience. Video and audio<br />
have been in use <strong>for</strong> several decades, and over the last<br />
ten to fifteen years, personal computer has also been<br />
used <strong>for</strong> educational purposes 1 . The mobile phone is a new<br />
plat<strong>for</strong>m, which has not yet been excessively used to enhance<br />
the educational experience.<br />
2.3 User analysis<br />
Our project aims at children in 7 th<br />
grade of Dutch primary<br />
school. Their age varies between nine and eleven years<br />
old. At this point in their primary education, they start<br />
learning English <strong>for</strong> the first time. They have not had<br />
any other language courses, and learning a new language<br />
is not a familiar concept to them. Because they hear English<br />
in their every-day world, they are often eager to<br />
learn the language. English is often seen as one of the<br />
more interesting classes, and is the favorite of quite a<br />
few of the more intellectual children. A large portion of<br />
these children already has a mobile phone. We expect that<br />
in the nearby future, almost all of these children will<br />
have a mobile phone with extensive multimedia possibili-
ties. They mainly use their telephones <strong>for</strong> calling, sending<br />
text messages and playing games.<br />
2.4 Bringing it all together<br />
Our project brings together the three subjects described<br />
above. We give the use of the mobile phone a new dimension,<br />
as children will be able to play educational games<br />
on their phone. They will like the game, because it is<br />
fun to play. In the next section we will try to describe<br />
why our game is ‘fun’ and how we came to our final product.<br />
We will also try to explain why we made certain decisions<br />
during the design of our prototype.<br />
3 ‘‘Learn by playing’’<br />
Our problem statement was how to design an interactive<br />
application <strong>for</strong> improving child knowledge using the mobile<br />
plat<strong>for</strong>m. The human activity to be supported is<br />
learning. Our approach can be described as a Star lifecycle<br />
model, as we wanted to have working prototypes that<br />
were constantly evaluated by the target group. We did<br />
want our tasks to be iterated, as it leads to the refinement<br />
of our product. Moreover our goal was to design an<br />
application that is centered on the user.<br />
As there is not much in<strong>for</strong>mation pertaining to the design<br />
of mobile teaching applications, our product had to rely<br />
on feedback from the users to refine and improve the user<br />
experience. The result was that our application progressed<br />
immensely from one prototype to the other, as the<br />
feedback received from one prototype was implemented on<br />
the next. This approach and solution <strong>for</strong> our problem led<br />
to effective evaluation sessions with our target group,<br />
as with the working prototypes the children could effectively<br />
test the product and report on issues like af<strong>for</strong>dability,<br />
visibility and usability.<br />
3.1 Simple and fun to use<br />
Our usability requirements called <strong>for</strong> a simple and engaging<br />
interface. The learnability of the system had to be<br />
straight<strong>for</strong>ward as our intended audience is notorious <strong>for</strong><br />
the lack of patience. Also such a system had to be efficient<br />
in per<strong>for</strong>ming the task intended by the users. Fi-
nally the user must have a sense of satisfaction towards<br />
the system.<br />
These goals were reached by the constant improvement of<br />
the system, through the iterated steps of prototyping.<br />
Letting the users review and provide feedback <strong>for</strong> improvement<br />
was the best solution <strong>for</strong> implementing our solution,<br />
and making sure it has all the characteristics of<br />
a useful product.<br />
4. Results and Evaluation<br />
Our end product is a mobile application, fully compatible<br />
with cellphones that support Flashlite, the mobile version<br />
of Flash. It con<strong>for</strong>ms to the best practices <strong>for</strong> mobile<br />
application development as it occupies very little<br />
disk space on the phone, and because all images are vectorial,<br />
it reproduces fast and shows no delays in the<br />
framerate. The use of mobile devices’ native features,<br />
such as the vibrating mode and audio, turned it into<br />
gratifying experience <strong>for</strong> the user, as it gives visual,<br />
audio and haptic feedback to the user, making <strong>for</strong> a more<br />
submerging experience.<br />
All of this makes <strong>for</strong> a satisfying solution <strong>for</strong> our problem<br />
statement.<br />
These conclusions were reached fundamentally through our<br />
user evaluations and the feedback provided by the assistant<br />
and the colleagues during the development process.<br />
The user evaluations were done in two main sessions. Our<br />
user group consisted of 9 to 11 year old children who are<br />
currently in the 7th grade of primary school and are just<br />
starting to learn the English language. Their native language<br />
is Dutch. We have provided them with a Dutch introductory<br />
presentation on what we were doing, why we were<br />
making the tool, and that we needed their help to test it.<br />
After they were done experimenting with the tool, the<br />
children were given some questions to answer. These were<br />
all related the usability of the system, the af<strong>for</strong>dance<br />
of the buttons and the appearance.<br />
The resulting answers all tended towards a satisfying experience,<br />
with the navigation being deciphered quite immediately,<br />
as the children started pressing all the buttons<br />
to see what happens. Once they spotted the buttons<br />
that af<strong>for</strong>ded actions they immediately started using the<br />
tool as intended, hence the learnability of the system<br />
was a success.<br />
Some issues were presented regarding the overall aspect<br />
of the application, yet this was not common to all users,<br />
and was interpreted by us as divergence in taste.<br />
Strangely the small size of the screen, and consequently
of the GUI was not referenced as an hindrance, probably<br />
due to the habituation <strong>for</strong> such a constrain. The elements<br />
in the interface were all perceptive, as we strived <strong>for</strong><br />
having simple and immediately recognizable shapes, arranged<br />
in such a way as to allow <strong>for</strong> space between them.<br />
We were also able to test our product during the class<br />
presentation, where we collected feedback from our colleagues,<br />
assistants and teachers. As they were not our<br />
intended target audience, the feedback provided was<br />
mostly subjective impressions. Still some ideas were implemented,<br />
while others were not.<br />
It was suggested that we use the vibration method in a<br />
coherent way, following some methodology. We decided to<br />
have the vibration be more subtle as the user approached<br />
the end. The reason <strong>for</strong> this was so that the user would<br />
perceive an evolution in the gameplay.<br />
Another suggestion was that by detecting the right answer,<br />
the user could be presented with a voice reading of the<br />
word, a valuable feedback <strong>for</strong> apprenticeship. Yet we<br />
later discovered that our work plat<strong>for</strong>m did not support<br />
the use of audio recordings. Flashlite has limited sound<br />
<strong>for</strong>mats, with MIDI being the standard. As this <strong>for</strong>mat<br />
does not support voice sounds it was impossible to implement<br />
this feature.<br />
Also it was suggested that we use some sort of dynamic<br />
recording of a score, so that the user could in the end<br />
be presented with a result. We decided not to implement<br />
this as our objective was not to have an application that<br />
fosters competitiveness, as this can be harmful <strong>for</strong> child<br />
relationships with one another.<br />
5 Conclusion and Discussion<br />
The goal of our project was to create a fun game <strong>for</strong><br />
children in primary school that would teach them the English<br />
language. We think that we succeeded in our goal,<br />
because we got positive results from the children of our<br />
user group. The use of a mobile phone as educational<br />
plat<strong>for</strong>m is worth investigating further, as there are<br />
many possibilities in this field of study. There are however<br />
several limitations that have to be kept in mind<br />
when designing educational mobile applications.<br />
There is no QUERTY keyboard available, so you can only<br />
use arrow navigation or number-mapping. In all cases it
should be really clear how the program is to be navigated.<br />
During our evaluations we had quite some problems with<br />
the different kinds of mobile phones. Even though most<br />
phones meet the hardware specifications, not all phones<br />
have the same API when it comes to navigation, sound<br />
playback and visual display. This makes the design of a<br />
real (educational) multimedia application that works on<br />
different kinds of mobile phones hard, because the designer<br />
has to take plat<strong>for</strong>m-dependent settings into account.<br />
Yet, with all the limitation mobile phones present features<br />
that are of interest <strong>for</strong> application developers.<br />
Firstly the portability, which allows users to hold the<br />
device in the hand, and can then carry it anywhere. This<br />
allows <strong>for</strong> <strong>HCI</strong> to occur anywhere, and it is something<br />
that can be explored. Secondly all the supporting features<br />
in these devices, such as built-in cameras and<br />
speakers, can be used by any application, allowing <strong>for</strong><br />
dynamic interaction between the users and the device. By<br />
using the vibrating function, we brought more interest to<br />
our application, as the users were pleased by this solution.<br />
In conclusion, the mobile plat<strong>for</strong>m, aside from all incompatibilities<br />
and constant evolution and change can be an<br />
interesting plat<strong>for</strong>m <strong>for</strong> application development, as it<br />
presents different and effective Input/Output solutions.<br />
6 Future Work<br />
Looking at our specific prototype, we could of course upgrade<br />
our product with additional words. However, a whole<br />
dimension could be given to the program, by having sentences<br />
where the user fills in a certain word. Or the<br />
user could be provided with a sentence, and has to find<br />
the spelling error (if any). This would make the program<br />
not only more interesting, but also more suitable <strong>for</strong><br />
older children that already have more experience with the<br />
English language. But our project is only one example of<br />
the many possibilities that the mobile plat<strong>for</strong>m offers on<br />
the educational field. It can <strong>for</strong> example also be used in<br />
mathematics, or as a questionnaire <strong>for</strong> classes like history,<br />
geography and biology.<br />
As cellphones tend to integrate new technologies and<br />
evolve to process more in<strong>for</strong>mation and have more resources,<br />
we are constantly thinking of new ways to adapt<br />
this tool to become a teaching plat<strong>for</strong>m <strong>for</strong> people.
References<br />
1. Sand<strong>for</strong>d, Richard et all, FutureLabs (2005). Teaching<br />
with games.
The Music Man<br />
Anton Hunsucker, Sifferina de Jong<br />
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
antipasta@gmail.com, sifferina@gmail.com<br />
supervised by Yun Bei, Fons Verbeek.<br />
ybei@liacs.nl & fverbeek@liacs.nl.<br />
Abstract. We designed a product which will allow children aged 11 or 12 years<br />
old to individually learn about musical concepts in an interactive manner using<br />
the computer. A musical instrument will be unnecessary as it will make use of<br />
the computer keyboard. As children with these ages have a short attention span<br />
and are bored by dull in<strong>for</strong>mation the program needed ways to be able to retain<br />
attention. We have shown that by chunking the in<strong>for</strong>mation in small proportions<br />
and keeping it clear and simple children are very well able to keep paying<br />
attention. Also to stimulate them to learn more we used several concepts from<br />
computer games, such as unlocking songs and competitiveness, which has<br />
turned out to be very successful.<br />
1 Introduction<br />
These days a lot of children aged 11 or 12 have no or a little experience in musical<br />
concepts. At that age they don’t mind, but when they get older they pity that they<br />
never learnt more on this subject. A lot of people don’t know much about the different<br />
notes, the score they are on, what they sound like or what they look like. Also<br />
knowledge about different composers and their music is scarce. There<strong>for</strong>e we tried to<br />
design a program which will teach children about these basic musical concepts. As<br />
children within this age group are very eager to learn, curious and competitive the<br />
program needed to take advantage of these characteristics.<br />
Also children spend about one and a half hours behind a computer, mostly entertaining<br />
themselves or using it <strong>for</strong> other purposes such as studying. Children like to spend<br />
their time behind a computer in a social manner, which is, doing it together with a<br />
friend or playing against a friend.¹. Most computer programs designed to teach about<br />
musical concepts are dull and only focus on the things to be taught, they are not designed<br />
<strong>for</strong> a specific age group but <strong>for</strong> a specific group that has already decided they<br />
want to learn more about music. There<strong>for</strong>e these programs aren’t able to keep children<br />
entertained and to stimulate them to learn more. In this paper we introduce innovative<br />
ways to solve this problem. The program we designed will be a way <strong>for</strong> children<br />
to learn about music, to stimulate them to learn more about music and to prepare<br />
them <strong>for</strong> real music lessons when they want to start playing a musical instrument.
Also the program will be a way <strong>for</strong> parents to check if their child has a talent <strong>for</strong><br />
music and likes to play music, be<strong>for</strong>e they invest in an expensive instrument of which<br />
they don’t know it will be used <strong>for</strong> a long time. Firstly we will start by defining our<br />
problem and introducing an extensive user analysis, after that we will give an approach<br />
to solving the problem. Next we will discuss the results and user evaluations<br />
and finally we will draw our conclusion and discuss this.<br />
2 Short Subject Background and problem definition<br />
2.1 Discrepancies in music<br />
Music has been known and enjoyed, in some <strong>for</strong>m or another, by virtually every people<br />
on the planet, since the dawn of history. While it is considered “elementary” or<br />
even “natural” (compare birdsong), music’s principles and inner workings are not –<br />
they require development and understanding of abstract and concepts, which are<br />
certainly not deemed “natural” at first. While listening to music is an experience requiring<br />
a minimal expense of ef<strong>for</strong>t on the listener’s behalf, producing music can only<br />
be achieved by skill and training, a time-consuming, cerebral exercise. It is hence not<br />
surprising that only a small portion of listeners are actually able to create music on<br />
their own.<br />
2.2 Learning music at an early age<br />
2.2.1 Introduction<br />
This skill is best fostered at an early age, as is widely known. It is not uncommon <strong>for</strong><br />
parents to encourage their children to take piano lessons, <strong>for</strong> instance. However, as<br />
argued above, learning music, like learning to read and spell, requires the student to<br />
deal with abstract concepts that seem to have little connection with reality at first.<br />
2.2.2 Excerpts from User Analysis<br />
Young children appear mentally ill-equipped <strong>for</strong> learning these concepts: they have a<br />
short attention span, fewer intellectual capabilities, no knowledge of the mathematics<br />
or physics pertaining to music theory and are generally not accustomed to thinking on<br />
an abstract level. As opposed to an adult striving to learn music, a child has very little<br />
basic knowledge to start with. Furthermore, often are they not studying music of their<br />
own volition.<br />
When using computerized teaching methods, children do have some valuable experience:<br />
most, if not all, are familiar with Windows, have played videogames and are<br />
compelled to use this knowledge in other fields.<br />
2.2.3 Additional issues<br />
Additionally, as music is rarely thought “just” as a concept – most often, it goes handin-hand<br />
with learning to play an instrument. Hence, not only does the student has to<br />
learn a lot of difficult theory, he/she has to overcome the motorical challenges of<br />
mastering the xylophone, piano, or guitar at the same time! Without an instrument,<br />
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,<br />
and is a financial obstacle <strong>for</strong> many a parent. Also, is there an “ideal” instrument <strong>for</strong><br />
learning music?<br />
2.3 Challenges in teaching music & alternative methods<br />
All this introduces several unique challenges <strong>for</strong> the teacher. Difficult, “dry” knowledge<br />
must be circumvented (or thoroughly simplified) at first, until the child’s expertise<br />
has advanced to level deemed adequate <strong>for</strong> introduction. The child’s musical<br />
learnings should be kept at pace with his/her mastery of the instrument. The child<br />
must persevere in the course of several years in order to be truly acquainted with the<br />
inner workings of music. Often this is accomplished by, <strong>for</strong> instance, hiring a piano<br />
teacher who teaches the child <strong>for</strong> several years. While this personal approach deals<br />
with issues such as attention span and allows the student to learn at his/her preferred<br />
pace, it is arguably very expensive, even more so if a piano has to be bought. Sending<br />
children to a music school is more af<strong>for</strong>dable, but reduces the time the teacher can<br />
allot <strong>for</strong> each child, and individual children risk falling behind. All the while the child<br />
must remain motivated; even more so <strong>for</strong> self-study, which is certainly the cheapest<br />
possibility.<br />
2.4 (Short) Conclusion<br />
We feel that by using interactive, multimedial teaching techniques in our application<br />
can remedy part of the problem: most children play videogames, or are at least acquainted<br />
with the use of a computer. By incorporating analogous elements (interactivity,<br />
a scoring system, and reward) in our program we strive to keep the student motivated,<br />
and he/she can repeat any part of the course at his/her leisure.<br />
3 Introducing Multimedial and Interactive Teaching Techniques<br />
In order to be able to teach children about musical concepts our program should first<br />
of all correspond to a Windows user environment as children in this age group are<br />
most skilled using Windows. There<strong>for</strong>e the buttons in our interface have names that<br />
resemble names of buttons in Internet Explorer. Furthermore we designed our icons<br />
in a way that they resemble icons with a similar meaning in Windows. Also the saving<br />
progress should be automatic, since children of this age can decide in an instance<br />
to exit the program. The program should be able to make children keep paying attention,<br />
and as they have a short attention-span this is difficult. We tried to do this by<br />
chunking the in<strong>for</strong>mation in small proportions presented in simple comprehensible<br />
language and offering pictures and exercises regularly throughout the theoretical parts.<br />
When children have a difficult time trying to play an exercise they can press a button<br />
<strong>for</strong> an example and the program will show them how to play the notes, and what it<br />
should sound like.<br />
To make sure children were stimulated to learn more and wouldn’t quit using the<br />
program we tried to introduce aspects from the gaming world into our program. As<br />
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<br />
a popup will appear with the notification that another musical piece has<br />
been unlocked <strong>for</strong> playing. This will be part of a competitive element in the program<br />
as children can brag about the total number of songs that they have unlocked.<br />
Also children can keep track on their progress in order to be able to compare themselves<br />
with others. With this another competitive element is also incorporated in the<br />
program. Children can thus brag about their achievements to their friends who are<br />
also using the program. Also they can play against each other and compare their mistakes.<br />
This way children can also stimulate each other to try harder on practicing a<br />
specific part of the program. Next to that there is an option in the program where<br />
children can just play and enjoy themselves without having to read about the theoretical<br />
part of making music. In this option we did choose to display the notes played on<br />
the computer’s keyboard so children learn without noticing it. The program is also<br />
designed to make children curious after music they wouldn’t naturally listen to, such<br />
as classical music. An encyclopedia on classical music is included in the program so<br />
they can read about the composer that composed the music they <strong>for</strong> example have just<br />
unlocked.<br />
The usability requirements we set at the onset of our program were that the software<br />
should be suitable <strong>for</strong> the task, thus allowing users to complete tasks efficiently without<br />
presenting unnecessary problems or obstacles and since we were dealing with<br />
children this is a very important aspect. Also due to the fact we were dealing with<br />
children our program should be easy to use. It should be easy to learn, intuitive, and<br />
appropriate to the user's abilities which we have stated earlier. We realized this by<br />
giving the program simple controls which are also used on the internet and in Windows,<br />
such as back, next and head menu buttons and selection bars. We also made<br />
sure that playing the notes on the keyboard would be easy, there<strong>for</strong>e we concluded it<br />
would be best to make use of the piano key configuration since this has been the same<br />
<strong>for</strong> centuries. We actually did have a problem here, as a computer keyboard isn’t as<br />
wide as a piano keyboard. We had to split the piano keyboard in two and used the<br />
upper two rows of the computer keyboard <strong>for</strong> the lower part of the piano keys and the<br />
lower two rows of the computer keyboard <strong>for</strong> the higher part of the piano keys. Also<br />
we chose simple names <strong>for</strong> other buttons so they would explain themselves through<br />
their name. We also wanted the users to enjoy themselves using the program that it<br />
looked nice and that users would be tranquil and relaxed while using the program as<br />
to create a good learning environment. Important is that users wouldn’t be irritated by<br />
the design of the program.<br />
Another usability requirement is that the system's speed of response to commands and<br />
instructions should be immediately shown on screen, and should be appropriate to the<br />
task and the workers abilities. When a user hits a key or a button there should be<br />
immediate response of the software to show the systems state to the user. A user<br />
should always be able to know in what state a system is to prevent confusion, there<strong>for</strong>e<br />
feedback is very important. When a button is pressed or a key has been hit something<br />
should happen, we realized this by giving direct response in the shape of a<br />
popup balloon or a sound.
The software should also prevent the users from errors and allow error recovery. The<br />
program doesn’t require save operations as of how far the pupil has progressed in the<br />
program, this is done automatically. Also buttons disappear when they have no function.<br />
When doing an exercise a pupil can press the opnieuw button which will allow<br />
him or her to start over.<br />
4 Results and Evaluation<br />
During the development of our program we have made a lot of adjustments and<br />
changes. These were mostly due to feedback we received from multiple resources and<br />
the result of our user evaluations. When you take a look at our first paper design<br />
(figure 1) you will notice it had a lot of color. One comment on this was that it was<br />
too distracting and looked too cluttered. To keep it a simple and organized learning<br />
environment we then decided to cut back on the colors. When you take a look at the<br />
final prototype (figure 2) it is neat and uncluttered. Also the buttons are child friendly,<br />
it looks like a nice program that you will enjoy to use.<br />
We kept the color scheme of light yellow and blue throughout the program which<br />
takes care of the coherency in the program. This way we minimize on confusion: a<br />
button always has the same colors. To minimize clutter we also cut down on the number<br />
of popups that were used to in<strong>for</strong>m users. The program now only shows a popup<br />
when a song has been unlocked. Where buttons used to stay visible in the old version<br />
when they didn’t have a function, we made sure that now they disappear. Users were<br />
confused by the error sounds they heard when they clicked these buttons, and after a<br />
while it became irritating, since they couldn’t see that a button wasn’t active, they<br />
kept on clicking them and thus hearing the error sound. Another button that was<br />
unclear was the scrollbar. As there was more on a page to be viewed, the use of a<br />
scroll bar was important; we made the scrollbar in the style of the buttons and added a<br />
flashing arrow at the end of a page that reminds users that there is more on a page to<br />
be read.<br />
Since users in our age group are very playful an important aspect in our program is<br />
playfulness. In the first version there wasn’t an opportunity to just hit keys, make<br />
noise and just play. During the user evaluation we found that children missed this<br />
aspect in the program. We have taken care of that by changing the recognition of<br />
notes, which didn’t add much to the program, into free playing. Here users are able to<br />
make noise, but they still learn since the program shows the note they play on the<br />
screen. To make the program more adapted to our users this was an improvement.<br />
A lot of users didn’t understand how to play the notes, which was more due to the<br />
difficulty of the note system itself rather than to the interface itself. We built in an<br />
example button, which can be clicked when users don’t understand how to play the<br />
notes. The program then shows when to play which note and what the tune should<br />
sound like. This makes the program more self-explanatory and more resistant to errors.<br />
Since our program isn’t meant to teach children piano, but more to teach children to<br />
read notes and general musical concepts, we chose not to make an association between<br />
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<br />
computer keyboard, when they progressed with the lessons in the program it became<br />
natural to them. We made the decision not to put the A on the A key because it would<br />
make playing songs on the keyboard very hard when the different notes are scattered<br />
over the keyboard.<br />
The changes we made on behalf of the user requirements turned out to be very successful.<br />
We tested them during user evaluations. The controls were clear; no questions<br />
were raised by using them. The names of the buttons were self-explanatory most<br />
of the times, but in some cases they weren’t clear. We there<strong>for</strong>e decided to add<br />
mouseovers in the head menu to solve that problem. The system’s speed of response<br />
is perfect. The state of the system is clear all the time. Though the program asks a lot<br />
of processing, it responds well on a computer with the speed of these days. The<br />
measures we have taken to prevent errors also turned to work out well. When an error<br />
has been made it is always possible to return to the last state and start over, which is a<br />
perfect way to learn music. Learning music is done by practicing, making mistakes<br />
and starting over again. Most of the users enjoyed using the program, and were interested<br />
to have it on their home computer. A lot of the children never thought about<br />
taking on music lessons and were motivated, due to the use of the program, to learn<br />
more.<br />
Due to the time we had <strong>for</strong> this project we weren’t able to finish a progress page, thus<br />
this function has been disabled in the program.<br />
5 Conclusion and Discussion<br />
At the onset of our project we stated that children aged 11 or 12 didn’t know much<br />
about music. This turned out to be true. From the 14 children we asked only one was<br />
taking music lessons and another had had music lessons. Most children weren’t interested<br />
to learn about music. The idea about learning music mostly contains having<br />
lessons at a music school, buying an instrument and thus deciding what instrument to<br />
choose. Also it is an expensive and time consuming activity and a lot of parents aren’t<br />
sure their child will enjoy her- or himself doing it. We have concluded that our program<br />
is a good way to see if a child likes to learn about music and has a talent <strong>for</strong> it.<br />
Besides that a lot of children don’t know what it is like to learn about music. They<br />
think they don’t like it but after haven spent some time with the program a lot of<br />
children actually were motivated to learn more. Thus by handing them a way of learning<br />
music which uses the right techniques, they are very well able to get motivated<br />
and are even enthusiastic about it. Our program also results in competitiveness between<br />
children who both use the program, which also works stimulating. Users experience<br />
the use of the program as a kind of playing. They know they are learning<br />
something, but enjoy doing it, which is the best way to get into contact with new<br />
things. After finishing the whole curriculum a child should be motivated enough to<br />
take on real music lessons with a real instrument.
6 Future Work<br />
Since we were limited in the time we could spend on the project we couldn’t develop<br />
all the things we first planned. One of these things is building in user profiles. Together<br />
with the progress option in the program this would be a nice new way <strong>for</strong> users<br />
to compare their progress and to realize more competitiveness through the program as<br />
to stimulate users to learn more and try harder. Also this would make playing together<br />
more fun. The lessons in the program aren’t complete. We only attend to the first<br />
three notes of a music curriculum. To make this program complete it should attend to<br />
at least one whole stave, but a lower and a higher stave would be even better. Another<br />
option that could be built in the program is a way to record the music a user has made,<br />
in paper sheet as well as in a <strong>for</strong>m of music, <strong>for</strong> example mp3 or midi. A nice option<br />
that would add value to the project would be to build in an option to maintain a database<br />
to which the user can add more music to play with the program.<br />
References<br />
1. http://www.opvoedadvies.nl/computerspel.htm<br />
Appendix<br />
Figures<br />
Music Man!<br />
Leren en Oefenen<br />
Welkom bij Music<br />
Man! Met dit<br />
programma kan je<br />
Liedjes<br />
noten leren lezen,<br />
liedjes leren spelen,<br />
noten leren<br />
Noten Herkennen<br />
herkennen en kennis<br />
maken met<br />
verschillende<br />
bekende<br />
Encyclopedie<br />
componisten.<br />
Maak een keuze<br />
door<br />
op de verschillende<br />
Voortgang<br />
opties te klikken.<br />
Hallo, typ eerst je naam:<br />
OK<br />
Stoppen<br />
Figure 1: old layout of the head menu Figure 2: current layout of the head menu
Music Maestro! – The input of a conducting program <strong>for</strong> children<br />
Loren Roosendaal and Petr Kresk<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
magicmystery1@hotmail.com and kresk10@post.cz<br />
supervised by Yun Bei, <strong>HCI</strong><br />
yunbei@gmail.com<br />
“Music Maestro!” is a conducting program that lets children conduct a virtual orchestra more intuitively<br />
than comparable programs allow. Its aim is to make children feel in charge like Maestros and stimulate a<br />
future interest in the creative and intuitive aspects of music. The program contains two novel interface<br />
features: an input method by motion tracking and a feedback consisting of interactive cartoons. This report<br />
focuses on tracking motion to influence the volume and pace of a virtual orchestra. Our motion tracking<br />
system proves to be more robust <strong>for</strong> children than conventional input methods such as infrared batons<br />
[1]. Another report by group 22 shows how an output consisting of interactive 3D cartoon instruments can<br />
contribute to experiencing the program. Both novelties were combined to encourage children in musical<br />
expression through physical exercise.<br />
General introduction<br />
The primary goal of “Music Maestro!” is to engage children in the process of expressing their own feelings<br />
about songs through physical exercise, thus encouraging them to continue exploring the world of music in a<br />
playful way. The program tracks motion to influence a virtual 3D orchestra visually and audibly. In the setting<br />
of a beautiful concert hall, cartoon-like instruments characterize the interaction of the child with the<br />
music. The gestures children are used to determine both the pacing and volume. The project does not focus<br />
on factual knowledge or very precise musical skills. The aim of this project is to make the child feel as<br />
though (s)he is conducting an actual piece of music and to stimulate a future interest in the creative and<br />
intuitive aspects of music. The visual feedback of “Music Maestro!” is described in another paper and the<br />
input in this one. The input is a novelty, as more conventional input methods are replaced by intuitive motion<br />
tracking input without requiring any additional input devices, this is especially suited <strong>for</strong> children that are<br />
about eight years old.<br />
Problem, approach and outline of this paper<br />
Our main research question is how conducting programs <strong>for</strong> children can be both robust and enjoyable. We<br />
considered an intuitive approach essential, as we don’t expect the children to have prior experience with<br />
similar programs or the desire to study a manual of any kind. We first explain the general background of<br />
conducting programs and why we have chosen our approach <strong>for</strong> the input. Our solution to our research problem<br />
concerning the input is to use motion tracking <strong>for</strong> the entire program. This <strong>for</strong>m of input not only allows<br />
<strong>for</strong> highly intuitive conducting, but it is also used to navigate the actual program, so children can work with<br />
the program easily and autonomously. After an overview of the user evaluation, we will draw conclusions<br />
based on our observations from individual and group sessions with our target group.<br />
2 How can intuitive conducting programs be both robust and enjoyable <strong>for</strong> children?<br />
New interaction methods <strong>for</strong> digital music and other multimedia are a hot topic in today’s research community,<br />
and since Nintendo introduced the Wii in 2006 the general public has been introduced to the first steps<br />
towards new <strong>for</strong>ms of digital interaction. We hope our novel methods of multimedia interaction with motion<br />
tracking and interactive cartoons encourage children to explore music.
The background of conducting programs<br />
The conducting programs have so far never been used with bare hands as there was always some extra device<br />
involved. Three technical solutions were found <strong>for</strong> tools to help the computer to keep track of the input. The<br />
most successful has been the infrared baton (the stick conductors use to lead an orchestra), but there were<br />
also colored gloves and even a jacket. Nintendo introduced the first interactive animated orchestra in 2006.<br />
The jacket was the least successful, as only one article mentions this research tool and this was in<br />
2000 [2]. 16 sensors were put in a conductor’s jacket to track his movements. More efficient methods were<br />
needed <strong>for</strong> extracting this data.<br />
Gloves of a particular color were worn by a conductor of a virtual orchestra in 1999 to track the<br />
conductor's hands by searching <strong>for</strong> the color of the gloves via a process known as color thresholding [3].<br />
Once the gloves were extracted from each video frame, further processing determined the instantaneous location<br />
of the gloves. About three years later in 2002, this tracking could be done by inexpensive cameras and<br />
some actual gestures could be recognized [4].<br />
Though the gloves may look as an attractive alternative <strong>for</strong> tracking actual hand gestures, the most<br />
successful tool in this research is the baton, the same tool a real conductor would have. The infrared baton<br />
was first mentioned <strong>for</strong> the purpose of conducting devices in 2000 [5]. The positions of the baton and conductor’s<br />
hand were identified in a sequence of images from a pair of cameras, and tracked in 3D space. In<br />
2001 and 2002 an exhibit was held in the house of music Vienna, using an infrared baton to conduct an audio/video<br />
recording of the Vienna Philharmonic [6]. The infrared signal was tracked by a computer and converted<br />
to influence the music output. The system didn’t tolerate bad conducting, so it wasn’t useful <strong>for</strong> commercial<br />
purposes in every day life. However, it was a successful exhibit until a certain breakthrough was<br />
established in 2004 when a cheap infrared baton was used to make children conduct a virtual orchestra, allowing<br />
the user more freedom <strong>for</strong> making mistakes with an inexpensive tool [1]. This was also presented in<br />
an exhibit at a museum, but this time <strong>for</strong> children. As these systems with infrared batons were exhibited, the<br />
feedback had to be attractive. Big screens showed actual footage of a real orchestra. This movie could speed<br />
up or slow down a little as this was the visual output the user would get. Though the exhibit in 2004 was<br />
especially <strong>for</strong> children at the children’s museum in Boston, the same feedback was given: they used footage<br />
of a real orchestra and no cartoons.<br />
This system with the infrared baton was put into a commercial product by Nintendo in September<br />
2006, the Wii. This little “remote control” is not only used <strong>for</strong> conducting music, but also <strong>for</strong> other gaming<br />
activities. The feedback if the Wii consist of an animated hall with cartoon musicians. This is the only animated<br />
concert of which children (actually whole families) are able to influence the tempo. In 2006 the Wii<br />
costs about $250 and could be a “trendsetting” product of which some features are still to be improved.<br />
Figure 1: Exhibit at the Children’s Museum in<br />
Boston in 2004. The input is given by an infrared<br />
baton and the screen shows footage of an actual<br />
orchestra that speeds up and slows down with the<br />
conducted music.<br />
Figure 2: The infrared device Wii by Nintendo shows similar<br />
intentions as “Music Maestro!” but our system uses motion tracking<br />
to enhance more intuitive conducting <strong>for</strong> children. Though the<br />
Wii uses cartoon characters, we felt their approach was more <strong>for</strong> a<br />
whole family than <strong>for</strong> young children on their own.
Why we used motion tracking input<br />
The report of the output group proves that our cartoon instruments supply both enjoyable feedback during the<br />
conducting process and guidamce throughout the entire program, allowing a child to operate the program<br />
autonomously. This report however focuses on the motion tracking input we used in our program. We developed<br />
an input system that, using only a webcam, gathered in<strong>for</strong>mation about the speed of the gestures and the<br />
width of the gestures being made by the child. As children tend to be very active and experimental while<br />
using the program, no <strong>for</strong>m of traditional conducting input, such as infrared batons [1], is suitable <strong>for</strong> them.<br />
Because of the rapid changes in the conducting behaviour of the children the response time of the program<br />
had to be fast, otherwise children would overcompensate as they would feel that they’d have to conduct even<br />
slower or even faster since the music wouldn’t respond in time. Gesture tracking systems such as batons [1]<br />
or even full body sensors [2] require too much time to relate a motion/gesture to an intended change in the<br />
music. Another benefit of our input method is the fact that the system and it’s users can be physicaly separated<br />
and as such there’s no risk of breaking any (expensive) devices.<br />
Our target group: children of about eight years old<br />
“Music Maestro!” was developed <strong>for</strong> children of about eight years old. Though the ages of users may vary<br />
greatly, we focused on these young children.<br />
Eight year old children are in the process of mastering physical skills, and they enjoy playing many<br />
kinds of games. This includes everything from small muscle skills like handling a pencil to large muscle<br />
skills like catching a ball. Because these skills are not yet polished, craft projects often end up messy, <strong>for</strong><br />
example with crooked nails and too much glue.<br />
Children at this age are eager to learn and master new knowledge in a playful way. When confronted<br />
with potentially interesting experiences, they are curious and open to new challenges. With their increased<br />
ability to think and reason, they enjoy several types of games with simple rules. They usually start their activities<br />
with bursts of energy and are constantly active. Their emotions, however, change quickly. It is impossible<br />
<strong>for</strong> them to concentrate on one thing <strong>for</strong> a long time.<br />
Making friends becomes easier at this age and the children have fun and excitement by playing together.<br />
Interactive communication is very important <strong>for</strong> their social lives.<br />
Children at this age are often not capable of using computers by using a mouse or keyboard accurately<br />
and proficiently yet. However, they begin to develop their own interests in different areas, among which<br />
music could be an attractive one. Eight year old children do not have much conducting experience and their<br />
conducting gestures are quite different from an expert with musical knowledge. It’s not easy <strong>for</strong> them to give<br />
accurate rhythmic responses. Here are some characteristics of their conducting behavior:<br />
- Children show a wide range of movements. They like making their own gestures according to their feelings<br />
about the music. Expecting you can restrict them to conduct in a specific way is not realistic.<br />
- When children make beat-like gestures, these beats are often not synchronous with the beats of the music.<br />
This means that children may make repetitive gestures, but these gestures don’t have the same beat as the<br />
original music.<br />
- Children enjoy pushing the limits of how quickly or slowly they can make the orchestra play. It is natural<br />
<strong>for</strong> children to experiment while conducting. They like changing their gesture speed suddenly either making<br />
it very fast or very slow to see what will happen.<br />
3 Motion tracking and sound stretching<br />
Solutions <strong>for</strong> the interaction with children<br />
One goal of our project is to provide opportunities <strong>for</strong> children to practice physical skills that are not too<br />
complex, but still challenging enough. For example swinging arms and positioning hands, without any precise<br />
requirements <strong>for</strong> the movement of fingers, is likely to be completed successfully even by beginners.<br />
Learning how to conduct our virtual orchestra would be within the range of doable yet challenging tasks <strong>for</strong><br />
them. It is probable that the children remember basic and simple rules after a brief and clear intro program.<br />
The music used in our project is simple enough <strong>for</strong> children to conduct, containing recognizable melodies<br />
(<strong>for</strong> example popular classical music). A beautiful concert hall with cartoon-like characterized instruments is<br />
attractive <strong>for</strong> the children, especially if the instruments interact with the conductor. The conducting program<br />
is also suitable <strong>for</strong> groups (see our user evaluation report, appendix 1). The children have no problem conducting<br />
in turns and watch others; they even encourage each other. Eight year old children get bored or impatient<br />
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<br />
children’s movements immediately, allowing the output team to show visual feedback in real-time. Also a<br />
special welcome to attract the child’s attention in the first place, would be a smart move. Luckily our motion<br />
tracking setup is perfectly suitable <strong>for</strong> achieving this.<br />
Technical solutions<br />
Children without any computer skills are able to use our program. Our gesture recognition system should be<br />
robust to their wide range of (unexpected) movements. If this would not be the case, the changes oheard in<br />
the music would sound awkward; noise and stepping artifacts would arise from the rapid changes in volume<br />
and tempo. One way to make this auditory feedback more robust is to set minimum and maximum values <strong>for</strong><br />
the speed and volume, <strong>for</strong> example 30 % difference from the original values. The gestures of the children<br />
usually don’t have the same beat as the original music. Our system adopts a simple velocity-based scheme,<br />
decoupled from the “beats” that children make. This way, children can make their movements in every beat<br />
they like, but the program only looks at the speed and size of their gestures over a short time without paying<br />
much attention to the beat of the individual movements. This means that the speed of the program can not<br />
vary too radically, especially when absolute minimum and maximum values are used <strong>for</strong> the tempo and volume<br />
of the music. Minimum and maximum values can also be set <strong>for</strong> relative changes in volume and speed<br />
over a short time. We use this mechanism to smoothly blend between changes in tempo and volume instead<br />
of making radical changes. This way the music stays recognizable without the child loosing much freedom to<br />
experiment.<br />
Conclusions<br />
The complete system feedback is attractive and interactive <strong>for</strong> children. The output consists of clear real-time<br />
musical feedback and interactive cartoons. The children hear and see immediate response to their actions.<br />
The musical pieces are easily recognized by the children and the method of conducting is experienced as both<br />
intuitive and powerful. The final response time achieved by the input system is much faster then the response<br />
time of the users and as such offers a smooth experience. Both volume and tempo changes are perceivable<br />
within 50 milliseconds at most and are in full effect within around 200 milliseconds, slightly faster then the<br />
average human response time.<br />
The interface is simple and easy to understand. There are only two simple rules to remember concerning<br />
the conducting, that all have immediate feedback and are practiced with physical activities. First rule:<br />
the conducting speed influences the pace. Second rule: the size of the gestures influences the volume. The<br />
rest is understood by simply listening to the cartoon trumpet that guides users through the program. A short<br />
and interactive introduction program is needed to make sure the children understand the possibilities of the<br />
program, especially if they are using it <strong>for</strong> the first time. Children are generally not capable of remembering a<br />
lot of instructions at once and we wanted to keep the use of our program suitable <strong>for</strong> their playful attitude.<br />
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. Instead<br />
of giving instructions about the whole program at once, pieces of in<strong>for</strong>mation are given carefully during<br />
the program with the help of audio, images and physical exercise. That is why we decided to make a cartoon<br />
trumpet introduce the program to children while running it. As soon as somebody comes near the webcam,<br />
the cartoon trumpet asks the child to help the orchestra that needs a conductor. Next the trumpet offers an<br />
introduction program in case the child has no experience with the program. It is possible to conduct music<br />
right away if the webcam tracks no movement. Appendix 3 shows a storyboard with screenshots of the program<br />
to demonstrate this. If the child waves, the introduction begins. This is all the child will hear about the<br />
program in general. All instructions <strong>for</strong> specific parts of the program are given at those parts themselves. The<br />
task analysis in appendix 2 and especially the storyboard in appendix 3 show the flow of the program that is<br />
designed to give in<strong>for</strong>mation piece by piece in an enjoyable and interactive way through physical exercise to<br />
appeal to young children.
4 Results and Evaluation<br />
Research setup<br />
Our research took place in two Dutch “fifth grades” (children there usually are eight or nine years old). The<br />
approach of the second user evaluation resembled the first one, except that an improved program was used,<br />
as described in the user evaluation report in appendix 1. We also showed both programs to a whole class to<br />
see group responses and get extra comments. We decided to make a cartoon trumpet to guide the children<br />
through the program while running it, so the children can use the program autonomously. The trumpet’s<br />
instructions are stated in appendix 1 and 3.<br />
Our setup <strong>for</strong> both user evaluations contained the following features:<br />
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.<br />
- A camera recorded the reactions of the children on our program <strong>for</strong> further analysis.<br />
- The program was individually tested by two children per user analysis; four in total. The estimated<br />
time <strong>for</strong> one child to play with the program was about 10 minutes. The children didn’t see each other<br />
conduct and were tested in a quiet separate room.<br />
After the individual tests, the program was taken to two classes <strong>for</strong> about 15 minutes to see how the children<br />
would respond in groups. About sixty children in total tested the program.<br />
These are the main questions <strong>for</strong> this user evaluation:<br />
- Is the program attractive and enjoyable <strong>for</strong> the children?<br />
- Do the children get the general idea of the program, especially influencing volume and tempo?<br />
- Is the response time of the program correct?<br />
- Does the music give clear audible feedback, but does it stay recognizable?<br />
(With “recognizable” is meant that the original version of the music is still obvious, so there are limits to<br />
the change in speed and volume and the sound-stretching works.)<br />
Individual testing<br />
Once the children started interacting with the program, they became less aware of their environment<br />
and started to experiment enthusiastically. The program really captured their attention. Though the<br />
children were enthusiastic during the first evaluation, we found some points that needed<br />
improvement.<br />
- The applause at the end of a song proved to be clear feedback that a song had ended. This<br />
was much nicer <strong>for</strong> the children than the indication at the bottom of the screen, which also<br />
showed the conducted volume and tempo. They were so much into their playful conducting,<br />
that they did not have the desire <strong>for</strong> anticipation such as these indication bars allowed.<br />
We were surprised at this, because we thought they would like extra feedback. This was<br />
also suggested at the presentations of the evaluations in class. However, it turned out the<br />
children preferred the program without the bars. The cartoon instruments were enough<br />
visual feedback <strong>for</strong> them. So we removed the bars from the program, as they distracted the<br />
children.<br />
- One child did not understand that he could choose from more than one song and conducted<br />
the same song three times in a row. The trumpet said there were three songs, but<br />
children often can’t remember a lot of instructions at the same time. So instead of showing<br />
one picture at the time, three pictures are shown in the menu at the same time. The song<br />
that can be chosen is highlighted and presented by the cartoon trumpet.<br />
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of<br />
hearing a beep after choosing a song, the child will be told that the conducting can begin.<br />
- At the beginning the instructions were a little too fast. The cartoon trumpet has to speak a<br />
bit slower.<br />
No problems were experienced with the input and sound components, the children enjoyed their ability to<br />
change the tempo and volume of the music in every possible way.<br />
During the second evaluation the reactions were very positive and the children did not mention anything to<br />
improve. Though we looked <strong>for</strong> possible improvements in the recordings of the reactions, it really seems like<br />
the comments of the children were sincere. So no improvements were asked <strong>for</strong> after the second prototype.
Group testing<br />
Both prototypes were tried by thirty children after the individual sessions (three groups of about ten children<br />
at the time). The children tried the program one at the time while the others observed the one that was playing.<br />
New conclusions could be drawn from the observed group behavior.<br />
- Both the general flow of the program and the specific elements were understood very well by the<br />
groups. The children were helping and telling each other what to do. The more chaotic environment<br />
did not decrease the capacity to understand the program. On the contrary: the reactions were more<br />
spontaneous.<br />
- The children seemed more relaxed in groups. On their own the children could look a little tense and<br />
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.<br />
A lot of children felt free to experiment in unexpected manners.<br />
- Both during the individual and the group testing, the children could deal with the program autonomously.<br />
They probably found the instructions clear. Moreover, they seemed to like the program <strong>for</strong><br />
the high degree of freedom to experiment with their movements <strong>for</strong> direct feedback.<br />
- In the groups the children looked both at the screen and at each other.<br />
Conclusions based on the user evaluation<br />
Based on the results of the user evaluations the following conclusions were drawn:<br />
- For children of this age it’s essential to have motion tracking and not gesture recognition, because<br />
they love the feedback they get on their unexpected experimental movements. The children tried all<br />
kinds of unexpected movements, so we are glad to have used motion tracking instead of gesture recognition.<br />
- An extra tempo or volume indication is not appreciated, as children do not pay attention to them,<br />
don’t understand their function or are annoyed by them. We thought the children would like the extra<br />
feedback about tempo, volume and remaining time (this was suggested to us at the presentations<br />
of the user evaluations), but instead we removed the indication bars from our program.<br />
- To our surprise the program is remarkably suitable <strong>for</strong> groups of children, as children often experience<br />
no extra distraction in the chaos of the remarks of their peers, but encouragement. In this setup,<br />
one child conducts and the others watch. We suspect that an important aspect of the fact that the<br />
others don’t mind watching is the combination of feedback of sound and cartoon characters.<br />
- The children enjoyed the program unanimously. In groups they even shouted how much they liked<br />
the program even though we had not asked any questions. One girl conducted <strong>for</strong> about 15 minutes<br />
straight– a long time to stay focused <strong>for</strong> an eight year old. After 15 minutes we had to ask her to stop<br />
and it was only then that she noticed how tired her arms were because of all the conducting.<br />
- And finaly, the most important results <strong>for</strong> this paper. The instructions by the cartoon trumpet are attractive<br />
and capture the children’s attention, just like the conducting itself. Our method of using a<br />
cartoon to guide children through the program proves to be effective and enjoyable <strong>for</strong> our target<br />
group. The children went through the program without reading a word; they just listened to the<br />
instructions of the cartoon. The instructions were easily understood by most children and they<br />
enjoyed learning how to use the program. Our research shows that cartoons can be used in<br />
conducting programs <strong>for</strong> educational purposes and entertainment at the same time. Both the general<br />
flow of the program and the specific elements are easily understood. As soon as a child stands in<br />
front of the webcam, it can deal with the program autonomously because the cartoon trumpet tells<br />
them what to do. The children understood the menu function at once. Little supervision and no extra<br />
instructions our remarks from our side were necessary.<br />
The second prototype of the program was fully understandable and enjoyable <strong>for</strong> children and there were no<br />
indications that improvements were necessary where <strong>HCI</strong> was concerned.<br />
5 Conclusion and Discussion<br />
Our main research question is how intuitive conducting programs can be both robust and enjoyable <strong>for</strong> children.<br />
With “intuitive” is meant in this case that the child can use the program without any prior knowledge of<br />
computers or conducting and that the child can go through the program autonomously without any difficulty.<br />
This means that the program has to be robust, as any average child of about eight years old can understand<br />
and enjoy all the aspects of the program on its own. For this reason the system works with cartoon instruments<br />
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<br />
input system. The child doesn’t need to handle any device and doesn’t have to make specific gestures, which<br />
stimulates the use of a wide range of physical expressions to conduct the music. Because of the fast response<br />
time the children don’t experience any problems selecting menu options or conducting. The sound stretching<br />
used to change the tempo of the music runs smoothly and doesn’t stetch the music too far, which could make<br />
it sound like strange noise rather then music. The entire input system is also robust in that it adapts well to the<br />
environment, even in the case of sudden changes, like turning on a light.<br />
Reactions of about sixty children show that they enjoyed the program unanimously (see the user<br />
evaluation in appendix 1). All main questions <strong>for</strong> our user evaluation were answered positively with the second<br />
prototype. The program is attractive and enjoyable <strong>for</strong> our target group. The quick response times are<br />
vital <strong>for</strong> the enjoyment of the program. The children watch the screen with concentration and eagerly respond<br />
to the combination of music and cartoons. The children intuitively understand the effect of their motions and<br />
gestures and picking a song by waving is easy, while the children can still move around and talk without<br />
triggering the song selection unintentionaly. The children understand and enjoy the conducting of the instruments,<br />
especially in little groups as they like to encourage each other. But on their own they also like to explore<br />
a lot physical activities as they experiment in how to conduct. They have no problem conducting a song<br />
they have already heard. They even enjoy learning the songs, perhaps so they can anticipate the the music<br />
better. In all cases we had to ask the children to stop, as they never seemed to get bored by themselves, at<br />
least not within 15 minutes.<br />
Our overall conclusion about “Music Maestro!” is that it does reach its primary goal to engage children<br />
in the process of expressing their own feelings using songs and through physical exercise. Hopefully<br />
this will encourage them to continue exploring the world of music in a playful way.<br />
Though the results of our research are satisfactory, we there is always room <strong>for</strong> improvement in the input<br />
department. For example the use of stereovision, which would allow us to detect the depth of the conducting<br />
gestures as an extra component of the input. The detection of some specific gestures that children make intuitively<br />
could also improve their experience, if we had enough time to study and record children in order to<br />
gather these gestures. Moreover, our program had minimum and maximum values, so the feedback would<br />
always be correct and understandable. Do children like that or would they enjoy “messing up” the program?<br />
And how would this affect the educational value of the program? If more detailed music data was made<br />
available to us we could test this by allowing certain instruments to play off key <strong>for</strong> example.<br />
6 Future Work<br />
Having explored realtime music conducting there is still a wide array of possible expansions and improvements<br />
in this field, such as more advanced gesture and posture recognition; detecting conductors facial expressions<br />
<strong>for</strong> a major/minor effect on the music and using stereovision to obtain depth in<strong>for</strong>mation which<br />
could be used to add even more possible factors influencing the music. We believe these techniques hold<br />
great promise, as children showed tended to make faces at the program, showing a wide range of emotions.
References<br />
1. E. Lee, T. M. Nakra, J. Borchers (2004). You’re The Conductor: A Realistic Interactive Conducting<br />
System For Children. New Interfaces <strong>for</strong> Musical Expression NIME04-68 – NIME04-73.<br />
2. Teresa Marrin Nakra (2000). Inside the Conductor.s Jacket: Analysis, Interpretation and Musical<br />
Synthesis of Expressive Gesture; M.I.T. Media Laboratory Perceptual Computing Section Technical<br />
Report No. 518<br />
3. Michael T. Driscoll (1999). A Machine Vision System <strong>for</strong> Capture and Interpretation of an Orchestra<br />
Conductor's Gestures; A Thesis Submitted to the Faculty of the Worchester Polytechnic Institute,<br />
Degree of Master of Science in Electrical and <strong>Computer</strong> Engineering<br />
4. 2002: Paul Kolesnik and Marcelo Wanderley: Recognition, Analysis and Per<strong>for</strong>mance with Expressive<br />
Conducting Gestures Proceedings of the International <strong>Computer</strong> Music Conference, pp. 367–<br />
370. International <strong>Computer</strong> Music Association.<br />
5. Jakub Segen, Joshua Gluckman, Senthil Kumar (2000). Visual Interface <strong>for</strong> Conducting Virtual Orchestra<br />
Proceedings of the International Conference on Pattern Recognition (ICPR'00) 1051-<br />
4651/00<br />
6. Jan O. Borchers, Wolfgang Samminger, Max Mtihlhi (2001). Conducting A Realistic Electronic Orchestra;<br />
tJIST 01 Orlando FLA Copyright ACM 2001 1-58113-438 -x/01/11<br />
7. Tian-Shu Wang, Heung-Yeung Shum, Ying-Qing Xu, and Nan-Ning Zheng (2000). Unsupervised<br />
Analysis of <strong>Human</strong> Gestures; Artificial Intelligence and Robotics Lab, Xi’an Jiaotong University,<br />
Xi’an; H.-Y. Shum, M. Liao, and S.-F. Chang (Eds.): PCM 2001, LNCS 2195, pp. 174–181, 2001<br />
8. Andersen, T. H. 2003. Towards novel DJ interfaces. Proceedings of the NIME 2003 Conference on<br />
New Interfaces <strong>for</strong> Musical Expression. pp. 30–35.<br />
9. Camurri, A., B. Mazzarino, and G. Volpe. 2003. “Analysis of Expressive Gesture: The EyesWeb<br />
Expressive Gesture Processing Library.” Gesture Workshop 2003 Lecture Notes in <strong>Computer</strong> Science,<br />
vol. 2915. Genova: Springer, pp. 460–467.<br />
10. Borchers, J., E. Lee, W. Samminger, M. Mühlhäuser (2004). Personal Orchestra: A realtime audio/video<br />
system <strong>for</strong> interactive conducting. ACM Multimedia Systems Journal Special Issue on<br />
Multimedia Software Engineering, 9(5): 458–465.<br />
11. E. Lee, M. Wolf, J. Borchers (2005). Improving Orchestral Conducting Systems in Public Spaces:<br />
Examining the Temporal Characteristics and Conceptual Models of Conducting Gestures. Proceedings<br />
of the CHI 2005 Conference on <strong>Human</strong> Factors in Computing Systems. pp. 731–740.<br />
12. Eric Lee, Thorsten Karrer, Jan Borchers (2006). Toward a Framework <strong>for</strong> Interactive Systems to<br />
Conduct Digital Audio and Video Streams <strong>Computer</strong> Music Journal 30(1), Spring 2006 – Preprint<br />
Draft February 9.<br />
Appendix<br />
Appendix 1: The user evaluation report of “Music Maestro!”<br />
Appendix 2: Task analysis<br />
Appendix 3: Storyboard of “Music Maestro!”
APPENDIX 1: The user evaluation report of “Music Maestro!”<br />
1 Motivation and plan<br />
Developing a program <strong>for</strong> children is especially challenging when it comes to this novel application in human<br />
computer interaction. One aspect is choosing the right age <strong>for</strong> the conducting program, apart from the question<br />
if the program is understandable and enjoyable <strong>for</strong> the chosen target group. Though documentation is<br />
available on the subjects of mental and physical development of children, only a user evaluation with the<br />
target group will prove if all intentions have been realized. Our target group consists of boys and girls of<br />
about eight years old (the reasons explained in the User Analysis of our Paper Design).<br />
These are the main questions <strong>for</strong> this user evaluation:<br />
- Is the program attractive and enjoyable <strong>for</strong> the children?<br />
- Do the children get the general idea of the program, especially influencing volume and tempo?<br />
- Is the response time of the program correct?<br />
- Does the music give clear audible feedback, but does it stay recognizable?<br />
(With “recognizable” is meant that the original version of the music is still obvious, so there are limits<br />
to the change in speed and volume and the sound-stretching works.)<br />
The user evaluations were planned in a Dutch primary school. Our research took place in two Dutch “fifth<br />
grades” (children there usually are eight or nine years old). The approach of the second user evaluation resembled<br />
the first one, except that a slightly different program was used, as will be discussed in chapter 6. We<br />
also showed both programs to a whole class to see responses of groups and get extra comments.<br />
Our setup <strong>for</strong> both user evaluations contained the following features:<br />
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.<br />
- A camera recorded the reactions of the children on our program <strong>for</strong> further analysis.<br />
- The program was individually tested by two children per user analysis; four in total. The estimated<br />
time <strong>for</strong> one child to play with the program was about 10 minutes. The children didn’t see each other<br />
conduct and were tested in a quiet separate room.<br />
- After the individual tests, the program was taken to two classes <strong>for</strong> about 15 minutes to see how the<br />
children would respond in groups.<br />
2 Instructions<br />
The first part of the evaluation consists of the scope and flow of the program. As we develop a program <strong>for</strong><br />
children, a special approach was required. For instance, children are generally not capable of remembering a<br />
lot of instructions at once and we wanted to keep the use of our program suitable <strong>for</strong> their playful attitude.<br />
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. That<br />
is why we decided to make a cartoon trumpet introduce the program to children while running it. Instead of<br />
giving instructions about the whole program at once, pieces of in<strong>for</strong>mation are given carefully during the<br />
program with the help of audio, images and physical exercise.<br />
The cartoon trumpet tells the child that an orchestra needs a conductor and asks <strong>for</strong> help. Next the trumpet<br />
offers an introduction program in case the child has no experience with the program. It is possible to conduct<br />
music right away if the webcam tracks no movement. If the child waves, the introduction begins. This is all<br />
the child will hear about the program in general. All instructions <strong>for</strong> specific parts of the program are given at<br />
those parts themselves. English instructions given by the trumpet are quoted below. (Note: the actual prototype<br />
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 <strong>for</strong> our orchestra. Please stand still if you already know<br />
how this works. In case you haven’t conducted be<strong>for</strong>e, we’ll show you how to do it if you wave to us first. So<br />
if you stand still you can begin right away. But we will teach you how to conduct if you wave now.”<br />
The second part of the evaluation deals with specific elements within the interface. We added instructions at<br />
two specific parts of the program: the introduction and the menu.<br />
Quotes of the cartoon trumpet the introduction program:<br />
“Okay, I’ll teach you how to conduct. When you make big movements, I’ll play loud. And when you make<br />
small movements, I’ll play soft music. Try it!”<br />
(The child conducts a little piece of music to practice with the volume.)<br />
“Well done! And now we’ll talk about the tempo. When you move more, the music plays faster. When you<br />
move less, the music plays slower. Let’s practice!”<br />
(The child conducts a little piece of music to practice with the tempo.)<br />
“Great! Please stand still. Now you know how to conduct the orchestra; only those two things you practiced<br />
be<strong>for</strong>e will be combined. So if your movements are big and fast, the music will be louder and faster. Now<br />
we’re going to choose a song. You can choose from three: the Mexican Hat Dance, the Bull Fighters’ Song<br />
and the Russian Dance.”<br />
Quotes of the cartoon trumpet in the menu:<br />
“If you want to play the Mexican Hat Dance, you can wave now!”<br />
“Do you want to hear the Bull Fighters’ Song? Please wave!”<br />
“Wave now <strong>for</strong> the Russian Dance!”<br />
3 Observations<br />
The observations of the user evaluations are listed in two tables below, including the research question <strong>for</strong><br />
every number of the task analysis (see appendix 1). After the observations of the first evaluation and comments<br />
on the first prototype, we will discuss the alterations we made <strong>for</strong> the second prototype. Then the results<br />
of the second user evaluation are shown. The last chapter contains the conclusions about our evaluation<br />
process.
3a Observations Table User Evaluation 1 (see Appendix 1: Revised Task Analysis)<br />
Task Research question Criteria Observations (one boy, nine years old and one girl, eight years old)<br />
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<br />
the right attention?<br />
screen.<br />
little tense because of the setting of the evaluation. They smile a little.<br />
1.2 Is the response time correct The child gets feed- Yes, the system responds immediately when it tracks movement. The child easily<br />
when a child gets into range? back in range. gets into webcam range.<br />
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<br />
nice and comprehensible? tion.<br />
the cartoon trumpet speaks slower. Most text is easily understood though.<br />
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-<br />
intro part (right after waving)? to the intro program. stands the next step.<br />
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 <strong>for</strong> all children.<br />
and go to the menu?<br />
seconds (no move). However, the skipping of the intro program worked as well as the program itself.<br />
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<br />
and comprehensible?<br />
tion.<br />
starts.<br />
2.2.1 Does the program track the The child gets imme- In all cases the children experimented with movements. The volume feedback was<br />
size of the movements right? diate volume feedback appropriate and immediate, so the children understood it (max. 100 ms).<br />
2.2.2 Does the program track the The child gets imme- In all cases the children experimented with movements. The tempo feedback was<br />
tempo of the movements right? diate tempo feedback appropriate and immediate, so the children understood it (max. 100 ms).<br />
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,<br />
toon comprehensible?<br />
tion.<br />
because no interaction is required here, but they seem to listen to the cartoon.<br />
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<br />
toon comprehensible?<br />
what to do.<br />
obvious that the children could choose from three songs.<br />
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<br />
if the child waves?<br />
diate song feedback. gets direct feedback.<br />
3.3 Does the program handle the The child gets feed- The children made a lot of unsuspected movements to experiment. Luckily the pro-<br />
conducting gestures right? back on movements gram works with motion tracking instead of gesture recognition; works <strong>for</strong> this age!<br />
3.4 What does the child do at the (Is the child eager <strong>for</strong> The children are pleased with the applause, which seems a clearer indication of the<br />
end of a song?<br />
a new song?)<br />
ending of a song than the indication bars. They are eager to conduct a next song.<br />
3.5 Does the program interrupt The child gets the This feature was never used by the children during the evaluation. Remarkably,<br />
when the child wants this? wanted interruption. they have no problem conducting a song more than once.<br />
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<br />
the program smooth enough? ruptions of program. never a problem during the group evaluation.)<br />
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<br />
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic<br />
results. Instead some simple open questions were asked to the children and remarks were noted.<br />
Questions Nr Answers of the children<br />
How did you like the 1 It’s fun!<br />
program? 2 It’s very nice and funny.<br />
Were there some things 1 I really liked the music.<br />
you especially liked? 2 I liked that the cartoons did things when I moved. I liked the last song.<br />
Were there some parts 1 Yes, I did not understand I could choose from different songs.<br />
that made you doubt? 2 Yes, the cartoon spoke a bit fast in the beginning. And these strange<br />
colored bars (tempo, volume) on the bottom of the screen.<br />
Were there some parts 1 This strange thing on the bottom of the screen (the volume and tempo<br />
you didn’t like?<br />
indications that showed how far the song was).<br />
2 I didn’t like the Russian Dance, but I liked the other songs.<br />
The first prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).<br />
The children were not very talkative when it came to the open questions. However, we observed their reactions<br />
during the first evaluation. The children were very positive about the playful interactive elements of our program.<br />
They were shy at the beginning, facing three adults on their own. This was because we observed the children<br />
while they conducted. But once they started interacting with the program, they became less aware of their<br />
unusual environment and started to experiment enthusiastically. The program really captured their attention once<br />
they were not shy anymore. Though the children were enthusiastic during the first evaluation, we found some<br />
points that needed improvement.<br />
5 The first and second prototype<br />
The first prototype was tested on a laptop that was connected with a webcam and additional speakers. This<br />
prototype is available on DVD. It contained the following features:<br />
- A motion tracking system <strong>for</strong> the input of the program: the position of the movements influenced the<br />
volume and the quantity influenced the tempo.<br />
- An introduction screen with a cartoon trumpet that gave instructions according to the movements.<br />
- An introduction program to experiment with the volume and the tempo separately.<br />
- A menu that was introduced by the trumpet and showed one image about the theme of a song at the<br />
time the song was presented.<br />
- Three songs to choose from the menu and the conduct with tracked movements. There was applause<br />
after each song.<br />
- A virtual orchestra and bars that showed the change in tempo, volume and how much time was left of<br />
the song on the bottom of the screen.<br />
With the observations and remarks of the first evaluation, the following improvements were designed <strong>for</strong> the<br />
second prototype:<br />
- The applause at the end of a song proved to be clear feedback that a song had ended. This was <strong>for</strong> the<br />
children much nicer than the indication at the bottom of the screen, which also showed the conducted<br />
volume and tempo. They were so much into their playful conducting, that they did not have the desire<br />
<strong>for</strong> anticipation such as these indication bars allowed. So we removed the bars from the program, as<br />
they were only distraction <strong>for</strong> the children.<br />
- One child did not understand that he could choose from more than one song and conducted the same<br />
song three times in a row. The trumpet said there were three songs, but children can often not remember<br />
a lot of instructions at the same time. So instead of showing one picture at the time, three pictures<br />
are shown in the menu at the same time. The song that can be chosen is highlighted and presented by<br />
the cartoon trumpet.<br />
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of hearing a<br />
beep after choosing a song, the child will be told that the conducting can begin.<br />
- 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)<br />
Task Research question Criteria Observations<br />
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<br />
the right attention?<br />
screen.<br />
little tense because of the setting of the evaluation. They smile a little.<br />
1.2 Is the response time correct The child gets feed- Yes, the system responds immediately when it tracks movement. The child easily<br />
when a child gets into range? back in range. gets into webcam range.<br />
1.3 Is the welcome by the cartoon The child pays atten- The children pay attention and are curious. The instructions are easily understood.<br />
nice and comprehensible? tion.<br />
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<br />
intro part (right after waving)? to the intro program. the next step.<br />
1.5 Does the program skip the Response in a few This item was not used in the evaluation as the program was new <strong>for</strong> all children.<br />
intro and go to the menu? seconds (no move). However, they did understand the intro choice, so probably also the skipping.<br />
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<br />
and comprehensible?<br />
tion.<br />
starts.<br />
2.2.1 Does the program track the The child gets imme- In all cases the children experimented with movements. The volume feedback was<br />
size of the movements right? diate volume feedback appropriate and immediate, so the children understood it (max. 100 ms).<br />
2.2.2 Does the program track the The child gets imme- In all cases the children experimented with movements. The tempo feedback was<br />
tempo of movements right? diate volume feedback appropriate and immediate, so the children understood it (max. 100 ms).<br />
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,<br />
toon comprehensible? tion.<br />
because no interaction is required here, but they seem to listen to the cartoon.<br />
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<br />
cartoon comprehensible? what to do.<br />
from three songs.<br />
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<br />
if the child waves?<br />
diate song feedback. gets direct feedback.<br />
3.3 Does the program handle the The child gets feed- The children made a lot of unsuspected movements to experiment. Luckily the pro-<br />
conducting gestures right? back on movements gram works with motion tracking instead of gesture recognition; works <strong>for</strong> this age!<br />
3.4 What does the child do at the (Is the child eager <strong>for</strong> The children are pleased with the applause. They are eager to conduct a next song.<br />
end of a song?<br />
a new song?)<br />
The feedback bar <strong>for</strong> volume and tempo allowed <strong>for</strong> more anticipation.<br />
3.5 Does the program interrupt The child gets the This feature was never used by the children during the evaluation. Remarkably, they<br />
when the child wants this? wanted interruption. have no problem conducting a song more than once.<br />
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<br />
the program smooth enough? ruptions of program. never a problem during the group evaluation.)<br />
Green = evaluated positively Grey = no reliable result available
4 Comments of the children on the second prototype<br />
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic<br />
results. Instead some simple open questions were asked to the children and remarks were noted. The children<br />
do not seem to be very inventive in their answers. Luckily observations and records were made about the<br />
children’s behavior to gather more in<strong>for</strong>mation. Their reactions were very positive and they did not mention<br />
anything to improve. Though we looked <strong>for</strong> possible improvements in the records of the reactions, it really<br />
seems like the comments of the children were sincere. So no improvements were asked <strong>for</strong> after the second<br />
prototype.<br />
Questions Nr Answers of the children<br />
How did you like the 1 Yes, it’s really fun!<br />
program? 2 It’s a lot of fun!<br />
Were there some things 1 I liked the cartoons and what they did when I moved.<br />
you especially liked? 2 I liked that I could move to make things happen. The applause is nice.<br />
Were there some parts 1 No, I understood everything.<br />
that made you doubt? 2 No, there were not.<br />
Were there some parts 1 No, I liked everything.<br />
you didn’t like? 2 No.<br />
The second prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).<br />
6 Group behavior<br />
Both prototypes were tried by thirty children (three groups of about ten children at the time). So the program<br />
was tested by sixty children in total. This happened after the individual testing. We do not add another observations<br />
or comments table, because the children tried the program one at the time while the others observed<br />
the one that was playing. The remarks of the individuals in the groups were like the ones obtained by individual<br />
testing. However, some new conclusions could be drawn from the group behavior.<br />
- Both the general flow of the program and the specific elements were understood very well by the<br />
groups. The children were helping and telling each other what to do. The more chaotic environment<br />
did not decrease the capacity to understand the program. On the contrary: the reactions were more<br />
spontaneous.<br />
- The children seemed more relaxed in groups. On their own the children could look a little tense and<br />
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.<br />
A lot of children felt free to experiment in unexpected manners.<br />
- Both during the individual and the group testing, the children could deal with the program autonomously.<br />
They probably found the instructions clear. Moreover, they seemed to like the program <strong>for</strong><br />
the high degree of freedom to experiment with their movements <strong>for</strong> direct feedback.<br />
- In the groups they looked both at the screen and at each other.<br />
7 Analysis<br />
For children of this age it’s essential to have motion tracking and not gesture recognition, because they love<br />
the feedback they get on their unexpected experimental movements. The children tried all kinds of unexpected<br />
movements, so we are glad to have used motion tracking instead of gesture recognition. An extra<br />
tempo or volume indication is not appreciated, as children do not pay attention to them, don’t understand<br />
their function or are annoyed by them. To our surprise the program is remarkably suitable <strong>for</strong> groups of children,<br />
as children often experience no extra distraction in the chaos of the remarks of their peers, but encouragement.<br />
The instructions by the cartoon trumpet are attractive and capture their attention, just like the conducting<br />
itself. Both the general flow of the program and the specific elements are easily understood. As soon<br />
as a child stands in front of the webcam, it can deal with the program autonomously because the cartoon<br />
trumpet tells what to do. In the second evaluation, the children understood the menu function very well at<br />
once. Little supervision and no extra instructions our remarks from our side were necessary. The second<br />
prototype of the program was fully understandable and enjoyable <strong>for</strong> children and there were no indications
that improvements were necessary where <strong>HCI</strong> was concerned. However, we could think about three alterations<br />
that could increase the enjoyment of the visual feedback, but we not sure to realize them. The instruments<br />
can provide a more realistic output by connecting them to specific areas within the spectrum of the<br />
music. The lights could dim and spotlights shine to increase the suspense of the scene. We could also create<br />
five instruments instead of three to make the visual feedback more fun.
APPENDIX 2: Task analysis<br />
Both prototypes have this task decomposition. The second prototype is practically the final product, as the<br />
user evaluation showed little to improve.<br />
Task decomposition<br />
0. conduct virtual orchestra of “Music Maestro!”<br />
1. start program<br />
1.1 pay attention to introduction screen<br />
1.2 get into webcam range<br />
1.3 listen to cartoon<br />
1.4 wave or move<br />
1.5 stand still<br />
2. go through intro program<br />
2.1 listen to cartoon<br />
2.2 experiment with conducting orchestra<br />
2.2.1 pace gestures <strong>for</strong> volume music<br />
2.2.2 size gestures <strong>for</strong> speed music<br />
2.3 listen to cartoon<br />
3. conduct orchestra<br />
3.1 listen to cartoon<br />
3.2 wave to choose song<br />
3.3 make correct movements<br />
3.4 after song return to menu<br />
3.5 stand still to interrupt song<br />
4. stop program; go out of range webcam<br />
Plan 0.<br />
Do 1<br />
Plan 1.<br />
If user is inexperienced<br />
1.1 – 1.2 – 1.3 – 1.4<br />
If user is experienced<br />
1.1 – 1.2 – (1.3 –) 1.5<br />
Plan 2.<br />
2.1 – 2.2 – 2.3<br />
Plan 2.5.<br />
2.2.1 – 2.2.2<br />
Plan 3.<br />
3.1 => 3.2 => 3.3 => when 3.4 OR 3.5 => back to 3.1<br />
Note: it the webcam receives no motion <strong>for</strong> a little while, it will go to the menu (3.5).<br />
If it receives no motion <strong>for</strong> a longer while (<strong>for</strong> example because the child walked away), the introduction<br />
screen appears (4).<br />
This task decomposition resulted in the hierarchical task analysis on the next page.
APPENDIX 3: Storyboard of “Music Maestro!”<br />
Page 1 - the numbers in the text boxes refer to the task analysis of appendix 2<br />
1.1 – 1.2 Nobody stands in front of the webcam<br />
the right way: the welcome screen shows a cartoon<br />
trumpet that moves a little. A child pays<br />
attention and comes closer. As soon as a child<br />
gets in front of the webcam the program uses this<br />
in<strong>for</strong>mation to gain the child’s interest.<br />
1.4 The child waves or moves and the introduction<br />
program starts (2.1).<br />
2.1 – 2.2 – 2.2.1 The introduction program: the<br />
cartoon trumpet says: “Okay, I’ll teach you how to<br />
conduct. When you make big movements, I’ll play loud.<br />
And when you make small movements, I’ll play soft<br />
music. Try it!” The child hears a piece of music<br />
and experiments with the volume.<br />
1.3 The cartoon explains the purpose of the program:<br />
“Hello, could you help us? We need a conductor<br />
<strong>for</strong> our orchestra. Please stand still if you already<br />
know how this works. In case you haven’t conducted<br />
be<strong>for</strong>e, we’ll show you how to do it if you wave to us<br />
first. So if you stand still you can begin right away. But<br />
we will teach you how to conduct if you wave now.”<br />
1.5 The child doesn’t move. The introduction<br />
program is skipped and the optional songs are<br />
shown (3.1).<br />
2.2 – 2.2.2 After the experiment with the volume<br />
the cartoon trumpet says: “Well done! And now<br />
we’ll talk about the tempo. When you move more, the<br />
music plays faster. When you move less, the music<br />
plays slower. Let’s practice!” The child hears a<br />
piece of music and experiments with the tempo.
APPENDIX 3: Storyboard of “Music Maestro!”<br />
Page 2 - the numbers in the text boxes refer to the task analysis of appendix 2<br />
2.3 The cartoon trumpet says: “Great! Please stand<br />
still. Now you know how to conduct the orchestra; only<br />
those two things you practiced be<strong>for</strong>e will be combined.<br />
So if your movements are big and fast, the music<br />
will be louder and faster. Now we’re going to choose a<br />
song. You can choose from three: the Mexican Hat<br />
Dance, the Bull Fighters’ Song and the Russian<br />
Dance.” The program goes to 3.1<br />
3.2 The child waves or moves when the preferred<br />
song is pointed out by the icons and announced<br />
by the cartoon trumpet.<br />
3.4 – 3.5 When the song ends or in case the child<br />
stands still (and doesn’t conduct) the program<br />
goes back to the song menu automatically.<br />
3.1 The song menu is shown with three icons that<br />
are pointed out one by one every time they are<br />
introduced by the cartoon trumpet: “If you want to<br />
play the Mexican Hat Dance, you can wave now! Do<br />
you want to hear the Bull Fighters’ Song? Please<br />
wave! Wave now <strong>for</strong> the Russian Dance!”<br />
3.3 The cartoon trumpet says the child can conduct.<br />
The music begins. The child influences the<br />
volume and tempo by moving in front of the<br />
webcam.<br />
4. If the camera does not detect any motion <strong>for</strong><br />
some time, the welcome screen is shown and the<br />
program is ready to start the process again.
Music Maestro! – The feedback of a conducting program <strong>for</strong> children<br />
Karen Sam and Xuan Wang<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
karensam@hotmail.com, colleewx@hotmail.com<br />
supervised by Yun Bei, <strong>HCI</strong><br />
yunbei@gmail.com<br />
“Music Maestro!” is a conducting program that lets children conduct a virtual orchestra more intuitively<br />
than comparable programs allow. Its aim is to make children feel in charge like Maestros and stimulate a<br />
future interest in the creative and intuitive aspects of music. The program contains two novel interface<br />
features: an input method by motion tracking and a feedback consisting of interactive cartoons. This report<br />
about the output focuses on the 3D cartoon instruments that change in volume and pace to characterize<br />
the interaction between child and music. We show how interactive cartoons give enjoyable and attractive<br />
feedback in this conducting program <strong>for</strong> children. The report about the input proves our motion tracking<br />
system to be more robust than conventional input methods such as infrared batons [1]. Both novelties<br />
were combined to encourage children in musical expression through physical exercise.<br />
1 Introduction<br />
General introduction<br />
The primary goal of “Music Maestro!” is to engage children in the process of expressing their own feelings<br />
of songs through physical exercise, thus encouraging them to continue exploring the world of music in a<br />
playful way. The program tracks motion to influence a virtual 3D orchestra visually and audibly. In the setting<br />
of a beautiful concert hall, cartoon-like instruments characterize the interaction of the child with the<br />
music. The gestures children are used to determine both the pacing and volume. The project does not focus<br />
on factual knowledge or very precise musical skills. The aim of this project is to make the child feel as<br />
though (s)he is conducting an actual piece of music and to stimulate a future interest in the creative and intuitive<br />
aspects of music. The input of “Music Maestro!” is described in another paper and the feedback in this<br />
one. The feedback is a novelty, as more conventional output methods are replaced by playful cartoon characters<br />
especially <strong>for</strong> children of about eight year old.<br />
Problem, approach and outline of this paper<br />
Our main research question is how conducting programs <strong>for</strong> children can be both robust and enjoyable. We<br />
considered an intuitive approach essential, as we don’t expect the children to have prior experience with<br />
similar programs or the desire to study a manual of any kind. We first explain the general background of<br />
conducting programs and why we have chosen our approach <strong>for</strong> the visual feedback. Our solution to our<br />
research problem concerning the visual feedback is to use cartoon instruments. These cartoon instruments are<br />
not only enjoyable <strong>for</strong> children, but also guide them through the program, so children can work with the<br />
program autonomously. After an overview of the user evaluation, we will draw conclusions based on our<br />
observations from individual and group sessions with our target group.<br />
2 How can intuitive conducting programs be both robust and enjoyable <strong>for</strong> children?<br />
New interaction methods <strong>for</strong> digital music and other multimedia are a hot topic in today’s research community,<br />
and since Nintendo introduced the Wii in 2006 the general public has been introduced to the first steps<br />
towards new <strong>for</strong>ms of digital interaction. We hope our novel methods of multimedia interaction with motion<br />
tracking and interactive cartoons encourage children to explore music.
The background of conducting programs<br />
The conducting programs have so far never been used with bare hands as there was always some extra device<br />
involved. Three technical solutions were found <strong>for</strong> tools to help the computer to keep track of the input. The<br />
most successful has been the infrared baton (the stick conductors use to lead an orchestra), but there were<br />
also colored gloves and even a jacket. Nintendo introduced the first interactive animated orchestra in 2006.<br />
The jacket was the least successful, as only one article mentions this research tool and this was in<br />
2000 [2]. 16 sensors were put in a conductor’s jacket to track his movements. More efficient methods were<br />
needed <strong>for</strong> extracting this data.<br />
Gloves of a particular color were worn by a conductor of a virtual orchestra in 1999 to track the<br />
conductor's hands by searching <strong>for</strong> the color of the gloves via a process known as color thresholding [3].<br />
Once the gloves were extracted from each video frame, further processing determined the instantaneous location<br />
of the gloves. About three years later in 2002, this tracking could be done by inexpensive cameras and<br />
some actual gestures could be recognized [4].<br />
Though the gloves may look as an attractive alternative <strong>for</strong> tracking actual hand gestures, the most<br />
successful tool in this research is the baton, the same tool a real conductor would have. The infrared baton<br />
was first mentioned <strong>for</strong> the purpose of conducting devices in 2000 [5]. The positions of the baton and conductor’s<br />
hand were identified in a sequence of images from a pair of cameras, and tracked in 3D space. In<br />
2001 and 2002 an exhibit was held in the house of music Vienna, using an infrared baton to conduct an audio/video<br />
recording of the Vienna Philharmonic [6]. The infrared signal was tracked by a computer and converted<br />
to influence the music output. The system didn’t tolerate bad conducting, so it wasn’t useful <strong>for</strong> commercial<br />
purposes in every day life. However, it was a successful exhibit until a certain breakthrough was<br />
established in 2004 when a cheap infrared baton was used to make children conduct a virtual orchestra, allowing<br />
the user more freedom <strong>for</strong> making mistakes with an inexpensive tool [1]. This was also presented in<br />
an exhibit at a museum, but this time <strong>for</strong> children. As these systems with infrared batons were exhibited, the<br />
feedback had to be attractive. Big screens showed actual footage of a real orchestra. This movie could speed<br />
up or slow down a little as this was the visual output the user would get. Though the exhibit in 2004 was<br />
especially <strong>for</strong> children at the children’s museum in Boston, the same feedback was given: they used footage<br />
of a real orchestra and no cartoons.<br />
This system with the infrared baton was put into a commercial product by Nintendo in September<br />
2006, the Wii. This little “remote control” is not only used <strong>for</strong> conducting music, but also <strong>for</strong> other gaming<br />
activities. The feedback if the Wii consist of an animated hall with cartoon musicians. This is the only animated<br />
concert of which children (actually whole families) are able to influence the tempo. In 2006 the Wii<br />
costs about $250 and could be a “trendsetting” product of which some features are still to be improved.<br />
Figure 1: Exhibit at the Children’s Museum in<br />
Boston in 2004. The input is given by an infrared<br />
baton and the screen shows footage of an actual<br />
orchestra that speeds up and slows down with the<br />
conducted music.<br />
Figure 2: The infrared device Wii by Nintendo shows similar<br />
intentions as “Music Maestro!” but our system uses motion tracking<br />
to enhance more intuitive conducting <strong>for</strong> children. Though the<br />
Wii uses cartoon characters, we felt their approach was more <strong>for</strong> a<br />
whole family than <strong>for</strong> young children on their own.
Why we used our visual feedback<br />
The report of the output proves our motion tracking system is more robust than any infrared device <strong>for</strong> conducting,<br />
especially when used by children. This report however focuses on the animated feedback that accompanies<br />
the conducted music. If Nintendo has developed a virtual orchestra <strong>for</strong> conducting, why should<br />
we bother to make our own animated feedback?<br />
First of all, we feel that the orchestra of the Wii is rather <strong>for</strong> the whole family and not especially <strong>for</strong><br />
young children; it’s a compromise. The animation resembles a normal concert hall and the movements and<br />
characters are less explicit than we intended to make them to capture the attention of children. We decided to<br />
make the instruments characters themselves in a magical scene.<br />
Second, and most important, we wanted to avoid conventional menu options where reading and user<br />
experience are usually required. Our program requires no reading and no prior knowledge about the program<br />
or menu options. A cartoon instrument guides the child through the program step by step with audio feedback.<br />
Our target group: children of about eight years old<br />
“Music Maestro!” is developed <strong>for</strong> children of about eight years old. Though the ages of users may vary<br />
greatly, we focused on these young children.<br />
Eight year old children are in the process of mastering physical skills, and they enjoy playing many<br />
kinds of games. This includes everything from small muscle skills like handling a pencil to large muscle<br />
skills like catching a ball. Because these skills are not yet polished, craft projects often end up messy, <strong>for</strong><br />
example with crooked nails and too much glue.<br />
Children at this age are eager to learn and master new knowledge in a playful way. When confronted<br />
with potentially interesting experiences, they are curious and open to new challenges. With their increased<br />
ability to think and reason, they enjoy several types of games with simple rules. They usually start their activities<br />
with bursts of energy and are constantly active. Their emotions, however, change quickly. It is impossible<br />
<strong>for</strong> them to concentrate on one thing <strong>for</strong> a long time.<br />
Making friends becomes easier at this age and the children have fun and excitement by playing together.<br />
Interactive communication is very important <strong>for</strong> their social lives.<br />
Children at this age are often not capable of using computers by using a mouse or keyboard accurately<br />
and proficiently yet. However, they begin to develop their own interests in different areas, among which<br />
music could be an attractive one. Eight year old children do not have much conducting experience and their<br />
conducting gestures are quite different from an expert with musical knowledge. It’s not easy <strong>for</strong> them to give<br />
accurate rhythmic responses. Here are some characteristics of their conducting behavior:<br />
- Children show a wide range of movements. They like making their own gestures according to their feelings<br />
about the music. Expecting you can restrict them to conduct in a specific way is not realistic.<br />
- When children make beat-like gestures, these beats are often not synchronous with the beats of the music.<br />
This means that children may make repetitive gestures, but these gestures don’t have the same beat as the<br />
original music.<br />
- Children enjoy pushing the limits of how quickly or slowly they can make the orchestra play. It is natural<br />
<strong>for</strong> children to experiment while conducting. They like changing their gesture speed suddenly either making<br />
it very fast or very slow to see what will happen.<br />
3 Interactive cartoons guide children step by step<br />
Solutions <strong>for</strong> the interaction with children<br />
One goal of our project is to provide opportunities <strong>for</strong> children to practice physical skills that are not too<br />
complex, but still challenging enough. For example swinging arms and positioning hands, without any precise<br />
requirements <strong>for</strong> the movement of fingers, is likely to be completed successfully even by beginners.<br />
Learning how to conduct our virtual orchestra would be within the range of doable yet challenging tasks <strong>for</strong><br />
them. It is probable that the children remember basic and simple rules after a brief and clear intro program.<br />
The music used in our project is simple enough <strong>for</strong> children to conduct, containing recognizable melodies<br />
(<strong>for</strong> example popular classical music). A beautiful concert hall with cartoon-like characterized instruments is<br />
attractive <strong>for</strong> the children, especially if the instruments interact with the conductor. The conducting program<br />
is also suitable <strong>for</strong> groups (see our user evaluation report, appendix 1). The children have no problem conducting<br />
in turns and watch others; they even encourage each other. Eight year old children get bored or impatient<br />
very easily if the activity is not that attractive. As a result, the user interface must be carefully designed<br />
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<br />
attract the child’s attention in the first place, would be a smart move. Cartoons are very suitable <strong>for</strong> this purpose.<br />
Technical solutions<br />
Children without any computer skills are able to use our program. Our gesture recognition system should be<br />
robust to their wide range of (unexpected) movements. If this would not be the case, the size and movements<br />
of the instruments would look awkward; some parts of instruments would become too big and the movements<br />
too nervous. One way to make this visual feedback more robust is to set minimum and maximum values <strong>for</strong><br />
the speed and volume, <strong>for</strong> example 30 % difference from the original values. The gestures of the children<br />
usually don’t have the same beat as the original music. Our system adopts a simple velocity-based scheme,<br />
decoupled from the “beats” that children make. This way, children can make their movements in every beat<br />
they like, but the program only looks at the speed and size of their gestures over a short time without paying<br />
much attention to the beat of the individual movements. This means that the speed of the program can not<br />
vary too radically, especially when absolute minimum and maximum values are used <strong>for</strong> the speed and volume<br />
of the cartoons. Minimum and maximum values can also be set <strong>for</strong> relative changes in volume and speed<br />
over a short time. This way the instruments stay easily recognizable and aesthetically pleasing without the<br />
child loosing much freedom to experiment.<br />
Conclusions<br />
The visual feedback is attractive and interactive <strong>for</strong> children. The output consists of interactive cartoons and<br />
clear real-time musical feedback. The children see and hear immediate response to their actions. The cartoons<br />
appear on a screen and look like the 3D cartoons children are used to. The cartoons make little movements to<br />
attract attention. The screenshots in the storyboard of appendix 3 give an idea how the cartoon instruments<br />
give visual feedback in the program; only in the program they move and blink with their eyes to make a more<br />
realistic and friendly impression.<br />
The interface is simple and easy to understand. There are only two simple rules to remember concerning<br />
the conducting, that all have immediate feedback and are practiced with physical activities. First rule:<br />
the conducting speed influences the pace. Second rule: the size of the gestures influences the volume. The<br />
rest is understood by simply listening to the cartoon trumpet that guides users through the program. A short<br />
and interactive introduction program is needed to make sure the children understand the possibilities of the<br />
program, especially if they are using it <strong>for</strong> the first time. Children are generally not capable of remembering a<br />
lot of instructions at once and we wanted to keep the use of our program suitable <strong>for</strong> their playful attitude.<br />
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. Instead<br />
of giving instructions about the whole program at once, pieces of in<strong>for</strong>mation are given carefully during<br />
the program with the help of audio, images and physical exercise. That is why we decided to make a cartoon<br />
trumpet introduce the program to children while running it. The cartoon trumpet always moves a little to keep<br />
the attention in a subtle way. As soon as somebody comes near the webcam, the cartoon trumpet asks the<br />
child to help the orchestra that needs a conductor. Next the trumpet offers an introduction program in case the<br />
child has no experience with the program. It is possible to conduct music right away if the webcam tracks no<br />
movement. Appendix 3 shows a storyboard with screenshots of the program to demonstrate this. If the child<br />
waves, the introduction begins. This is all the child will hear about the program in general. All instructions<br />
<strong>for</strong> specific parts of the program are given at those parts themselves. The task analysis in appendix 2 and<br />
especially the storyboard in appendix 3 show the flow of the program that is designed to give in<strong>for</strong>mation<br />
piece by piece in an enjoyable and interactive way through physical exercise to appeal to young children.<br />
4 Results and Evaluation<br />
Research setup<br />
Our research took place in two Dutch “fifth grades” (children there usually are eight or nine years old). The<br />
approach of the second user evaluation resembled the first one, except that an improved program was used,<br />
as described in the user evaluation report in appendix 1. We also showed both programs to a whole class to<br />
see group responses and get extra comments. We decided to make a cartoon trumpet to guide the children<br />
through the program while running it, so the children can use the program autonomously. The trumpet’s<br />
instructions are stated in appendix 1 and 3.<br />
Our setup <strong>for</strong> both user evaluations contained the following features:
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.<br />
- A camera recorded the reactions of the children on our program <strong>for</strong> further analysis.<br />
- The program was individually tested by two children per user analysis; four in total. The estimated<br />
time <strong>for</strong> one child to play with the program was about 10 minutes. The children didn’t see each other<br />
conduct and were tested in a quiet separate room.<br />
After the individual tests, the program was taken to two classes <strong>for</strong> about 15 minutes to see how the children<br />
would respond in groups. About sixty children in total tested the program.<br />
These are the main questions <strong>for</strong> this user evaluation:<br />
- Is the program attractive and enjoyable <strong>for</strong> the children?<br />
- Do the children get the general idea of the program?<br />
- Do the children understand how to choose a song?<br />
- Do the children understand and enjoy the conducting of the instruments?<br />
Individual testing<br />
Once the children started interacting with the program, they became less aware of their environment<br />
and started to experiment enthusiastically. The program really captured their attention. Though the<br />
children were enthusiastic during the first evaluation, we found some points that needed<br />
improvement.<br />
- The applause at the end of a song proved to be clear feedback that a song had ended. This<br />
was much nicer <strong>for</strong> the children than the indication at the bottom of the screen, which also<br />
showed the conducted volume and tempo. They were so much into their playful conducting,<br />
that they did not have the desire <strong>for</strong> anticipation such as these indication bars allowed.<br />
We were surprised at this, because we thought they would like extra feedback. This was<br />
also suggested at the presentations of the evaluations in class. However, it turned out the<br />
children preferred the program without the bars. The cartoon instruments were enough<br />
visual feedback <strong>for</strong> them. So we removed the bars from the program, as they distracted the<br />
children.<br />
- One child did not understand that he could choose from more than one song and conducted<br />
the same song three times in a row. The trumpet said there were three songs, but<br />
children often can’t remember a lot of instructions at the same time. So instead of showing<br />
one picture at the time, three pictures are shown in the menu at the same time. The song<br />
that can be chosen is highlighted and presented by the cartoon trumpet.<br />
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of<br />
hearing a beep after choosing a song, the child will be told that the conducting can begin.<br />
- At the beginning the instructions were a little too fast. The cartoon trumpet has to speak a<br />
bit slower.<br />
During the second evaluation the reactions were very positive and the children did not mention anything to<br />
improve. Though we looked <strong>for</strong> possible improvements in the recordings of the reactions, it really seems like<br />
the comments of the children were sincere. So no improvements were asked <strong>for</strong> after the second prototype.<br />
Group testing<br />
Both prototypes were tried by thirty children after the individual sessions (three groups of about ten children<br />
at the time). The children tried the program one at the time while the others observed the one that was playing.<br />
New conclusions could be drawn from the observed group behavior.<br />
- Both the general flow of the program and the specific elements were understood very well by the<br />
groups. The children were helping and telling each other what to do. The more chaotic environment<br />
did not decrease the capacity to understand the program. On the contrary: the reactions were more<br />
spontaneous.<br />
- The children seemed more relaxed in groups. On their own the children could look a little tense and<br />
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.<br />
A lot of children felt free to experiment in unexpected manners.<br />
- Both during the individual and the group testing, the children could deal with the program autonomously.<br />
They probably found the instructions clear. Moreover, they seemed to like the program <strong>for</strong><br />
the high degree of freedom to experiment with their movements <strong>for</strong> direct feedback.<br />
- In the groups the children looked both at the screen and at each other.
Conclusions based on the user evaluation<br />
Based on the results of the user evaluations the following conclusions were drawn:<br />
- For children of this age it’s essential to have motion tracking and not gesture recognition, because<br />
they love the feedback they get on their unexpected experimental movements. The children tried all<br />
kinds of unexpected movements, so we are glad to have used motion tracking instead of gesture recognition.<br />
- An extra tempo or volume indication is not appreciated, as children do not pay attention to them,<br />
don’t understand their function or are annoyed by them. We thought the children would like the extra<br />
feedback about tempo, volume and remaining time (this was suggested to us at the presentations<br />
of the user evaluations), but instead we removed the indication bars from our program.<br />
- To our surprise the program is remarkably suitable <strong>for</strong> groups of children, as children often experience<br />
no extra distraction in the chaos of the remarks of their peers, but encouragement. In this setup,<br />
one child conducts and the others watch. We suspect that an important aspect of the fact that the<br />
others don’t mind watching is the combination of feedback of sound and cartoon characters.<br />
- The children enjoyed the program unanimously. In groups they even shouted how much they liked<br />
the program even though we had not asked any questions. One girl conducted <strong>for</strong> about 15 minutes<br />
straight– a long time to stay focused <strong>for</strong> an eight year old. After 15 minutes we had to ask her to stop<br />
and it was only then that she noticed how tired her arms were because of all the conducting.<br />
- And finaly, the most important results <strong>for</strong> this paper. The instructions by the cartoon trumpet are attractive<br />
and capture the children’s attention, just like the conducting itself. Our method of using a<br />
cartoon to guide children through the program proves to be effective and enjoyable <strong>for</strong> our target<br />
group. The children went through the program without reading a word; they just listened to the instructions<br />
of the cartoon. The instructions were easily understood by most children and they enjoyed<br />
learning how to use the program. Our research shows that cartoons can be used in conducting programs<br />
<strong>for</strong> educational purposes and entertainment at the same time. Both the general flow of the<br />
program and the specific elements are easily understood. As soon as a child stands in front of the<br />
webcam, it can deal with the program autonomously because the cartoon trumpet tells them what to<br />
do. The children understood the menu function at once. Little supervision and no extra instructions<br />
our remarks from our side were necessary.<br />
The second prototype of the program was fully understandable and enjoyable <strong>for</strong> children and there were no<br />
indications that improvements were necessary where <strong>HCI</strong> was concerned.<br />
5 Conclusion and Discussion<br />
Our main research question is how intuitive conducting programs can be both robust and enjoyable <strong>for</strong> children.<br />
With “intuitive” is meant in this case that the child can use the program without any prior knowledge of<br />
computers or conducting and that the child can go through the program autonomously without any difficulty.<br />
This means that the program has to be robust, as any average child of about eight years old can understand<br />
and enjoy all the aspects of the program on its own. For this reason the system works with motion tracking.<br />
The child doesn’t need to handle any device and doesn’t have to make specific gestures, which stimulates<br />
physical expressions on music. However, this paper describes another aspect of the program that makes it<br />
both robust and enjoyable: the cartoon instruments that guide the child through the program.<br />
This research proves that the flow of our program is easily understood by both individual children<br />
and groups. Essential <strong>for</strong> this success is the use of cartoon characters that guide the children through the program.<br />
As soon as the child gets into the range of the webcam, the program responds; the cartoon starts to talk<br />
to the child to attract its attention. Next the child can choose to go to the introduction program or straight to<br />
the conducting part. The child never has to read a word; every instruction is audible. Moreover, paying attention<br />
to the instructions is attractive <strong>for</strong> the children as the words seem spoken by the cartoon that moves<br />
around a little and blinks its eyes. The child gives feedback to the program through physical exercise with the<br />
help of instructions by a cartoon. Avoiding the conventional menu by using a cartoon that tells the child how<br />
to conduct and when, makes the program robust enough to let children deal with the program autonomously.<br />
This is our main criteria <strong>for</strong> the robustness of the visual feedback that accompanies the music and <strong>for</strong>ms a key<br />
element in the workflow of the program. Because our target group consists of children of about eight years<br />
old, this means they both have to understand and enjoy the program. If the program is not understood, the<br />
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<br />
evaluation in appendix 1). All main questions <strong>for</strong> our user evaluation were answered positively with the second<br />
prototype. The program is attractive and enjoyable <strong>for</strong> our target group. The animated cartoon instruments<br />
are vital <strong>for</strong> the enjoyment of the program. The children watch the screen with concentration and<br />
eagerly respond to the combination of music and cartoons. The children get the general idea of the program<br />
because they are guided by a cartoon that explains the intention of the program and offers an introduction<br />
with the basic principles of the program. The cartoon also guides the children through a menu of songs. The<br />
children understand how to choose a song, because the cartoon encourages them in their feedback. None of<br />
the childen had any problems with understanding the menu. The children understand and enjoy the conducting<br />
of the instruments, especially in little groups as they like to encourage each other. But on their own they<br />
also like to explore a lot physical activities as they experiment in how to conduct. They have no problem<br />
conducting a song they have already heard. They even enjoy learning the songs, perhaps so they can anticipate<br />
the the music better. In all cases we had to ask the children to stop, as they never seemed to get bored by<br />
themselves, at least not within 15 minutes.<br />
Our overall conclusion about “Music Maestro!” is that it does reach its primary goal to engage children<br />
in the process of expressing their own feelings using songs and through physical exercise. Hopefully<br />
this will encourage them to continue exploring the world of music in a playful way.<br />
Though the results of our research are satisfactory, we still remain with the question about extra feedback. If<br />
indication bars with the tempo, volume and remaining time are not appreciated by children, is there any <strong>for</strong>m<br />
of extra feedback they would like? What methods could be used to give children improved feedback without<br />
reducing the simplicity and ease of use of the program or cluttering its interface as bars and graphs apparently<br />
easily do <strong>for</strong> children?<br />
Moreover, our program had minimum and maximum values, to the feedback would always be correct<br />
and understandable. Do children like that or would they enjoy “messing up” the program? And how<br />
would this affect the educational value of the program?<br />
6 Future Work<br />
Having explored cartoon instrument visualization there is still a wide array of possible expansions and improvements<br />
in this field, such as more advanced cartoon expressions. For example, facial expressions and<br />
more precise reactions to the beat and frequency spectrum of the music can be added to the program. Should<br />
track splitting be implemented to separate instruments, even more advanced and specific visualizations would<br />
be possible. Other fields <strong>for</strong> future experiments include (stage) lighting, showing a real conductor and 3D<br />
camera movements to highlight specific points of interest.
References<br />
1. E. Lee, T. M. Nakra, J. Borchers (2004). You’re The Conductor: A Realistic Interactive Conducting<br />
System For Children. New Interfaces <strong>for</strong> Musical Expression NIME04-68 – NIME04-73.<br />
2. Teresa Marrin Nakra (2000). Inside the Conductor.s Jacket: Analysis, Interpretation and Musical<br />
Synthesis of Expressive Gesture; M.I.T. Media Laboratory Perceptual Computing Section Technical<br />
Report No. 518<br />
3. Michael T. Driscoll (1999). A Machine Vision System <strong>for</strong> Capture and Interpretation of an Orchestra<br />
Conductor's Gestures; A Thesis Submitted to the Faculty of the Worchester Polytechnic Institute,<br />
Degree of Master of Science in Electrical and <strong>Computer</strong> Engineering<br />
4. 2002: Paul Kolesnik and Marcelo Wanderley: Recognition, Analysis and Per<strong>for</strong>mance with Expressive<br />
Conducting Gestures Proceedings of the International <strong>Computer</strong> Music Conference, pp. 367–<br />
370. International <strong>Computer</strong> Music Association.<br />
5. Jakub Segen, Joshua Gluckman, Senthil Kumar (2000). Visual Interface <strong>for</strong> Conducting Virtual Orchestra<br />
Proceedings of the International Conference on Pattern Recognition (ICPR'00) 1051-<br />
4651/00<br />
6. Jan O. Borchers, Wolfgang Samminger, Max Mtihlhi (2001). Conducting A Realistic Electronic Orchestra;<br />
tJIST 01 Orlando FLA Copyright ACM 2001 1-58113-438 -x/01/11<br />
7. Tian-Shu Wang, Heung-Yeung Shum, Ying-Qing Xu, and Nan-Ning Zheng (2000). Unsupervised<br />
Analysis of <strong>Human</strong> Gestures; Artificial Intelligence and Robotics Lab, Xi’an Jiaotong University,<br />
Xi’an; H.-Y. Shum, M. Liao, and S.-F. Chang (Eds.): PCM 2001, LNCS 2195, pp. 174–181, 2001<br />
8. Andersen, T. H. 2003. Towards novel DJ interfaces. Proceedings of the NIME 2003 Conference on<br />
New Interfaces <strong>for</strong> Musical Expression. pp. 30–35.<br />
9. Camurri, A., B. Mazzarino, and G. Volpe. 2003. “Analysis of Expressive Gesture: The EyesWeb<br />
Expressive Gesture Processing Library.” Gesture Workshop 2003 Lecture Notes in <strong>Computer</strong> Science,<br />
vol. 2915. Genova: Springer, pp. 460–467.<br />
10. Borchers, J., E. Lee, W. Samminger, M. Mühlhäuser (2004). Personal Orchestra: A realtime audio/video<br />
system <strong>for</strong> interactive conducting. ACM Multimedia Systems Journal Special Issue on<br />
Multimedia Software Engineering, 9(5): 458–465.<br />
11. E. Lee, M. Wolf, J. Borchers (2005). Improving Orchestral Conducting Systems in Public Spaces:<br />
Examining the Temporal Characteristics and Conceptual Models of Conducting Gestures. Proceedings<br />
of the CHI 2005 Conference on <strong>Human</strong> Factors in Computing Systems. pp. 731–740.<br />
12. Eric Lee, Thorsten Karrer, Jan Borchers (2006). Toward a Framework <strong>for</strong> Interactive Systems to<br />
Conduct Digital Audio and Video Streams <strong>Computer</strong> Music Journal 30(1), Spring 2006 – Preprint<br />
Draft February 9.<br />
Appendix<br />
Appendix 1: The user evaluation report of “Music Maestro!”<br />
Appendix 2: Task analysis<br />
Appendix 3: Storyboard of “Music Maestro!”
APPENDIX 1: The user evaluation report of “Music Maestro!”<br />
1 Motivation and plan<br />
Developing a program <strong>for</strong> children is especially challenging when it comes to this novel application in human<br />
computer interaction. One aspect is choosing the right age <strong>for</strong> the conducting program, apart from the question<br />
if the program is understandable and enjoyable <strong>for</strong> the chosen target group. Though documentation is<br />
available on the subjects of mental and physical development of children, only a user evaluation with the<br />
target group will prove if all intentions have been realized. Our target group consists of boys and girls of<br />
about eight years old (the reasons explained in the User Analysis of our Paper Design).<br />
These are the main questions <strong>for</strong> this user evaluation:<br />
- Is the program attractive and enjoyable <strong>for</strong> the children?<br />
- Do the children get the general idea of the program?<br />
- Do the children understand how to choose a song?<br />
- Do the children understand and enjoy the conducting of the instruments?<br />
The user evaluations were planned in a Dutch primary school. Our research took place in two Dutch “fifth<br />
grades” (children there usually are eight or nine years old). The approach of the second user evaluation resembled<br />
the first one, except that a slightly different program was used, as will be discussed in chapter 6. We<br />
also showed both programs to a whole class to see responses of groups and get extra comments.<br />
Our setup <strong>for</strong> both user evaluations contained the following features:<br />
- Because of mobility the program was shown on a laptop with a webcam and extra loudspeakers.<br />
- A camera recorded the reactions of the children on our program <strong>for</strong> further analysis.<br />
- The program was individually tested by two children per user analysis; four in total. The estimated<br />
time <strong>for</strong> one child to play with the program was about 10 minutes. The children didn’t see each other<br />
conduct and were tested in a quiet separate room.<br />
- After the individual tests, the program was taken to two classes <strong>for</strong> about 15 minutes to see how the<br />
children would respond in groups. About sixty children in total tested the program.<br />
2 Instructions<br />
The first part of the evaluation consists of the scope and flow of the program. As we develop a program <strong>for</strong><br />
children, a special approach was required. For instance, children are generally not capable of remembering a<br />
lot of instructions at once and we wanted to keep the use of our program suitable <strong>for</strong> their playful attitude.<br />
Besides, simply letting them hear (or worse: read) multiple instructions could easily result in boredom. That<br />
is why we decided to make a cartoon trumpet introduce the program to children while running it. Instead of<br />
giving instructions about the whole program at once, pieces of in<strong>for</strong>mation are given carefully during the<br />
program with the help of audio, images and physical exercise.<br />
The cartoon trumpet tells the child that an orchestra needs a conductor and asks <strong>for</strong> help. Next the trumpet<br />
offers an introduction program in case the child has no experience with the program. It is possible to conduct<br />
music right away if the webcam tracks no movement. If the child waves, the introduction begins. This is all<br />
the child will hear about the program in general. All instructions <strong>for</strong> specific parts of the program are given at<br />
those parts themselves. English instructions given by the trumpet are quoted below. (Note: the actual prototype<br />
of the program had to be in Dutch as the program was tested by Dutch children.)<br />
“Hello, could you help us? We need a conductor <strong>for</strong> our orchestra. Please stand still if you already know<br />
how this works. In case you haven’t conducted be<strong>for</strong>e, we’ll show you how to do it if you wave to us first. So<br />
if you stand still you can begin right away. But we will teach you how to conduct if you wave now.”<br />
The second part of the evaluation deals with specific elements within the interface. We added instructions at<br />
two specific parts of the program: the introduction and the menu.
Quotes of the cartoon trumpet the introduction program:<br />
“Okay, I’ll teach you how to conduct. When you make big movements, I’ll play loud. And when you make<br />
small movements, I’ll play soft music. Try it!”<br />
(The child conducts a little piece of music to practice with the volume.)<br />
“Well done! And now we’ll talk about the tempo. When you move more, the music plays faster. When you<br />
move less, the music plays slower. Let’s practice!”<br />
(The child conducts a little piece of music to practice with the tempo.)<br />
“Great! Please stand still. Now you know how to conduct the orchestra; only those two things you practiced<br />
be<strong>for</strong>e will be combined. So if your movements are big and fast, the music will be louder and faster. Now<br />
we’re going to choose a song. You can choose from three: the Mexican Hat Dance, the Bull Fighters’ Song<br />
and the Russian Dance.”<br />
Quotes of the cartoon trumpet in the menu:<br />
“If you want to play the Mexican Hat Dance, you can wave now!”<br />
“Do you want to hear the Bull Fighters’ Song? Please wave!”<br />
“Wave now <strong>for</strong> the Russian Dance!”<br />
3 Observations<br />
The observations of the user evaluations are listed in two tables below, including the research question <strong>for</strong><br />
every number of the task analysis (see appendix 2 of the final report of “Music Maestro!”). After the observations<br />
of the first evaluation and comments on the first prototype, we will discuss the alterations we made <strong>for</strong><br />
the second prototype. Then the results of the second user evaluation are shown. The last chapter contains the<br />
conclusions about our evaluation process.
3a Observations Table User Evaluation 1 (see Appendix 1: Revised Task Analysis)<br />
Task Research question Criteria Observations (one boy, nine years old and one girl, eight years old)<br />
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<br />
the right attention?<br />
screen.<br />
little tense because of the setting of the evaluation. They smile a little.<br />
1.2 Does the child understand the The child gets into The child easily gets into webcam range. The audible feedback makes this rather<br />
webcam range?<br />
webcam range. clear. However, the good result may partly be due to the setting of the evaluation.<br />
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<br />
nice and comprehensible? tion.<br />
cartoon trumpet speaks slower. Most text is easily understood though.<br />
1.4 Does the child understand the The child waves inten- Yes, the children wave intentionally to begin the introduction. They seem curious<br />
intro choice?<br />
tionally.<br />
after the invitation of the cartoon trumpet.<br />
1.5 Does the child understand the The child stands still. This item was not used in the evaluation as the program was new <strong>for</strong> all children.<br />
skip intro choice?<br />
However, they did understand the intro choice, so probably also the skipping.<br />
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<br />
and comprehensible?<br />
tion.<br />
starts.<br />
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-<br />
volume intro? Enough time? playing with speed. ments influences the volume. In all cases they experimented with movements.<br />
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-<br />
speed intro? Enough time? playing with volume. ments influences the tempo. In all cases they experimented with movements.<br />
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,<br />
toon comprehensible? attention.<br />
because no interaction is required here, but they seem to listen to the cartoon.<br />
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<br />
cartoon comprehensible? what to do.<br />
obvious that the children could choose from three songs.<br />
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<br />
how to wave <strong>for</strong> a song?<br />
should be clearer when a child can start conducting when the song starts.<br />
3.3 Does the child understand the The child moves right, The children made a lot of unsuspected movements to experiment. Luckily the pro-<br />
conducting gestures?<br />
likes to pay attention. gram works with motion tracking instead of gesture recognition; works <strong>for</strong> this age!<br />
3.4 What does the child do at the (Is the child eager <strong>for</strong> The children are pleased with the applause, which seems a clearer indication of the<br />
end of a song?<br />
a new song?)<br />
ending of a song than the indication bars. They are eager to conduct a next song.<br />
3.5 Does the child use / under- The child stands still This feature was never used by the children during the evaluation. Remarkably, they<br />
stand interruption?<br />
to interrupt.<br />
have no problem conducting a song more than once.<br />
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<br />
the program smooth enough? ruptions of program. never a problem during the group evaluation.)<br />
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<br />
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic results.<br />
Instead some simple open questions were asked to the children and remarks were noted.<br />
Questions Nr Answers of the children<br />
How did you like the 1 It’s fun!<br />
program? 2 It’s very nice and funny.<br />
Were there some things 1 I really liked the music.<br />
you especially liked? 2 I liked that the cartoons did things when I moved. I liked the last song.<br />
Were there some parts 1 Yes, I did not understand I could choose from different songs.<br />
that made you doubt? 2 Yes, the cartoon spoke a bit fast in the beginning. And these strange<br />
colored bars (tempo, volume) on the bottom of the screen.<br />
Were there some parts 1 This strange thing on the bottom of the screen (the volume and tempo<br />
you didn’t like?<br />
indications that showed how far the song was).<br />
2 I didn’t like the Russian Dance, but I liked the other songs.<br />
The first prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).<br />
The children were not very talkative when it came to the open questions. However, we observed their reactions<br />
during the first evaluation. The children were very positive about the playful interactive elements of our program.<br />
They were shy at the beginning, facing three adults on their own. This was because we observed the children while<br />
they conducted. But once they started interacting with the program, they became less aware of their unusual<br />
environment and started to experiment enthusiastically. The program really captured their attention once they were<br />
not shy anymore. Though the children were enthusiastic during the first evaluation, we found some points that<br />
needed improvement.<br />
5 The first and second prototype<br />
The first prototype was tested on a laptop that was connected with a webcam and additional speakers. This prototype<br />
is available on DVD. It contained the following features:<br />
- A motion tracking system <strong>for</strong> the input of the program: the position of the movements influenced the volume<br />
and the quantity influenced the tempo.<br />
- An introduction screen with a cartoon trumpet that gave instructions according to the movements.<br />
- An introduction program to experiment with the volume and the tempo separately.<br />
- A menu that was introduced by the trumpet and showed one image about the theme of a song at the time<br />
the song was presented.<br />
- Three songs to choose from the menu and the conduct with tracked movements. There was applause after<br />
each song.<br />
- A virtual orchestra and bars that showed the change in tempo, volume and how much time was left of the<br />
song on the bottom of the screen.<br />
With the observations and remarks of the first evaluation, the following improvements were designed <strong>for</strong> the second<br />
prototype:<br />
- The applause at the end of a song proved to be clear feedback that a song had ended. This was <strong>for</strong> the<br />
children much nicer than the indication at the bottom of the screen, which also showed the conducted volume<br />
and tempo. They were so much into their playful conducting, that they did not have the desire <strong>for</strong> anticipation<br />
such as these indication bars allowed. So we removed the bars from the program, as they were<br />
only distraction <strong>for</strong> the children.<br />
- One child did not understand that he could choose from more than one song and conducted the same song<br />
three times in a row. The trumpet said there were three songs, but children can often not remember a lot of<br />
instructions at the same time. So instead of showing one picture at the time, three pictures are shown in<br />
the menu at the same time. The song that can be chosen is highlighted and presented by the cartoon trumpet.<br />
- Perhaps there should be more clarity about when a child is supposed to conduct. Instead of hearing a beep<br />
after choosing a song, the child will be told that the conducting can begin.<br />
- 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)<br />
Task Research question Criteria Observations<br />
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<br />
the right attention?<br />
screen.<br />
little tense because of the setting of the evaluation. They smile a little.<br />
1.2 Does the child understand the The child gets into The child easily gets into webcam range. The audible feedback makes this rather<br />
webcam range?<br />
webcam range. clear. However, the good result may partly be due to the setting of the evaluation.<br />
1.3 Is the welcome by the cartoon The child pays atten- The children pay attention and are curious. The instructions are easily understood.<br />
nice and comprehensible? tion.<br />
1.4 Does the child understand the It raises its hands Yes, the children wave intentionally to begin the introduction. They seem curious<br />
intro choice?<br />
right.<br />
after the invitation of the cartoon trumpet.<br />
1.5 Does the child understand the The child stands still. This item was not used in the evaluation as the program was new <strong>for</strong> all children.<br />
skip intro choice?<br />
However, they did understand the intro choice, so probably also the skipping.<br />
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<br />
and comprehensible?<br />
tion.<br />
starts.<br />
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-<br />
volume intro? Enough time? playing with speed. ments influences the volume. In all cases they experimented with movements.<br />
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-<br />
speed intro? Enough time? playing with volume. ments influences the tempo. In all cases they experimented with movements.<br />
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,<br />
toon comprehensible? tion.<br />
because no interaction is required here, but they seem to listen to the cartoon.<br />
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<br />
cartoon comprehensible? what to do.<br />
from three songs.<br />
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<br />
how to wave <strong>for</strong> a song?<br />
children know they can start conducting when the song starts.<br />
3.3 Does the child understand the The child moves right, The children made a lot of unsuspected movements to experiment. Luckily the pro-<br />
conducting gestures?<br />
likes to pay attention. gram works with motion tracking instead of gesture recognition; works <strong>for</strong> this age!<br />
3.4 What does the child do at the (Is the child eager <strong>for</strong> The children are pleased with the applause. They are eager to conduct a next song.<br />
end of a song?<br />
a new song?)<br />
The feedback bar <strong>for</strong> volume and tempo allowed <strong>for</strong> more anticipation.<br />
3.5 Does the child use / under- The child stands still This feature was never used by the children during the evaluation. Remarkably, they<br />
stand interruption?<br />
to interrupt.<br />
have no problem conducting a song more than once.<br />
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<br />
the program smooth enough? ruptions of program. never a problem during the group evaluation.)<br />
Green = evaluated positively Grey = no reliable result available
4 Comments of the children on the second prototype<br />
Because our target group consists of children, it was not recommendable to use questionnaires to get realistic<br />
results. Instead some simple open questions were asked to the children and remarks were noted. The children<br />
do not seem to be very inventive in their answers. Luckily observations and records were made about the<br />
children’s behavior to gather more in<strong>for</strong>mation. Their reactions were very positive and they did not mention<br />
anything to improve. Though we looked <strong>for</strong> possible improvements in the records of the reactions, it really<br />
seems like the comments of the children were sincere. So no improvements were asked <strong>for</strong> after the second<br />
prototype.<br />
Questions Nr Answers of the children<br />
How did you like the 1 Yes, it’s really fun!<br />
program? 2 It’s a lot of fun!<br />
Were there some things 1 I liked the cartoons and what they did when I moved.<br />
you especially liked? 2 I liked that I could move to make things happen. The applause is nice.<br />
Were there some parts 1 No, I understood everything.<br />
that made you doubt? 2 No, there were not.<br />
Were there some parts 1 No, I liked everything.<br />
you didn’t like? 2 No.<br />
The second prototype was tested by one boy, nine years old (1) and one girl, eight years old (2).<br />
6 Group behavior<br />
Both prototypes were tried by thirty children (three groups of about ten children at the time). So the program<br />
was tested by sixty children in total. This happened after the individual testing. We do not add another observations<br />
or comments table, because the children tried the program one at the time while the others observed<br />
the one that was playing. The remarks of the individuals in the groups were like the ones obtained by individual<br />
testing. However, some new conclusions could be drawn from the group behavior.<br />
- Both the general flow of the program and the specific elements were understood very well by the<br />
groups. The children were helping and telling each other what to do. The more chaotic environment<br />
did not decrease the capacity to understand the program. On the contrary: the reactions were more<br />
spontaneous.<br />
- The children seemed more relaxed in groups. On their own the children could look a little tense and<br />
concentrated at the beginning. However, in the groups they encouraged each other and laughed more.<br />
A lot of children felt free to experiment in unexpected manners.<br />
- Both during the individual and the group testing, the children could deal with the program autonomously.<br />
They probably found the instructions clear. Moreover, they seemed to like the program <strong>for</strong><br />
the high degree of freedom to experiment with their movements <strong>for</strong> direct feedback.<br />
- In the groups they looked both at the screen and at each other.<br />
7 Analysis<br />
For children of this age it’s essential to have motion tracking and not gesture recognition, because they love<br />
the feedback they get on their unexpected experimental movements. The children tried all kinds of unexpected<br />
movements, so we are glad to have used motion tracking instead of gesture recognition. An extra<br />
tempo or volume indication is not appreciated, as children do not pay attention to them, don’t understand<br />
their function or are annoyed by them. To our surprise the program is remarkably suitable <strong>for</strong> groups of children,<br />
as children often experience no extra distraction in the chaos of the remarks of their peers, but encouragement.<br />
The instructions by the cartoon trumpet are attractive and capture their attention, just like the conducting<br />
itself. Both the general flow of the program and the specific elements are easily understood. As soon<br />
as a child stands in front of the webcam, it can deal with the program autonomously because the cartoon<br />
trumpet tells what to do. In the second evaluation, the children understood the menu function very well at<br />
once. Little supervision and no extra instructions our remarks from our side were necessary. The second<br />
prototype of the program was fully understandable and enjoyable <strong>for</strong> children and there were no indications<br />
that improvements were necessary where <strong>HCI</strong> was concerned. However, we could think about three alterations<br />
that could increase the enjoyment of the visual feedback, but we not sure to realize them. The instruments<br />
can provide a more realistic output by connecting them to specific areas within the spectrum of the<br />
music. The lights could dim and spotlights shine to increase the suspense of the scene. We could also create<br />
five instruments instead of three to make the visual feedback more fun.
APPENDIX 2: Task analysis<br />
Both prototypes have this task decomposition. The second prototype is practically the final product, as the<br />
user evaluation showed little to improve.<br />
Task decomposition<br />
0. conduct virtual orchestra of “Music Maestro!”<br />
1. start program<br />
1.1 pay attention to introduction screen<br />
1.2 get into webcam range<br />
1.3 listen to cartoon<br />
1.4 wave or move<br />
1.5 stand still<br />
2. go through intro program<br />
2.1 listen to cartoon<br />
2.2 experiment with conducting orchestra<br />
2.2.1 pace gestures <strong>for</strong> volume music<br />
2.2.2 size gestures <strong>for</strong> speed music<br />
2.3 listen to cartoon<br />
3. conduct orchestra<br />
3.1 listen to cartoon<br />
3.2 wave to choose song<br />
3.3 make correct movements<br />
3.4 after song return to menu<br />
3.5 stand still to interrupt song<br />
4. stop program; go out of range webcam<br />
Plan 0.<br />
Do 1<br />
Plan 1.<br />
If user is inexperienced<br />
1.1 – 1.2 – 1.3 – 1.4<br />
If user is experienced<br />
1.1 – 1.2 – (1.3 –) 1.5<br />
Plan 2.<br />
2.1 – 2.2 – 2.3<br />
Plan 2.5.<br />
2.2.1 – 2.2.2<br />
Plan 3.<br />
3.1 => 3.2 => 3.3 => when 3.4 OR 3.5 => back to 3.1<br />
Note: it the webcam receives no motion <strong>for</strong> a little while, it will go to the menu (3.5).<br />
If it receives no motion <strong>for</strong> a longer while (<strong>for</strong> example because the child walked away), the introduction<br />
screen appears (4).<br />
This task decomposition resulted in the hierarchical task analysis on the next page.
APPENDIX 3: Storyboard of “Music Maestro!”<br />
Page 1 - the numbers in the text boxes refer to the task analysis of appendix 2<br />
1.1 – 1.2 Nobody stands in front of the webcam<br />
the right way: the welcome screen shows a cartoon<br />
trumpet that moves a little. A child pays<br />
attention and comes closer. As soon as a child<br />
gets in front of the webcam the program uses this<br />
in<strong>for</strong>mation to gain the child’s interest.<br />
1.4 The child waves or moves and the introduction<br />
program starts (2.1).<br />
2.1 – 2.2 – 2.2.1 The introduction program: the<br />
cartoon trumpet says: “Okay, I’ll teach you how to<br />
conduct. When you make big movements, I’ll play loud.<br />
And when you make small movements, I’ll play soft<br />
music. Try it!” The child hears a piece of music<br />
and experiments with the volume.<br />
1.3 The cartoon explains the purpose of the program:<br />
“Hello, could you help us? We need a conductor<br />
<strong>for</strong> our orchestra. Please stand still if you already<br />
know how this works. In case you haven’t conducted<br />
be<strong>for</strong>e, we’ll show you how to do it if you wave to us<br />
first. So if you stand still you can begin right away. But<br />
we will teach you how to conduct if you wave now.”<br />
1.5 The child doesn’t move. The introduction<br />
program is skipped and the optional songs are<br />
shown (3.1).<br />
2.2 – 2.2.2 After the experiment with the volume<br />
the cartoon trumpet says: “Well done! And now<br />
we’ll talk about the tempo. When you move more, the<br />
music plays faster. When you move less, the music<br />
plays slower. Let’s practice!” The child hears a<br />
piece of music and experiments with the tempo.
APPENDIX 3: Storyboard of “Music Maestro!”<br />
Page 2 - the numbers in the text boxes refer to the task analysis of appendix 2<br />
2.3 The cartoon trumpet says: “Great! Please stand<br />
still. Now you know how to conduct the orchestra; only<br />
those two things you practiced be<strong>for</strong>e will be combined.<br />
So if your movements are big and fast, the music<br />
will be louder and faster. Now we’re going to choose a<br />
song. You can choose from three: the Mexican Hat<br />
Dance, the Bull Fighters’ Song and the Russian<br />
Dance.” The program goes to 3.1<br />
3.2 The child waves or moves when the preferred<br />
song is pointed out by the icons and announced<br />
by the cartoon trumpet.<br />
3.4 – 3.5 When the song ends or in case the child<br />
stands still (and doesn’t conduct) the program<br />
goes back to the song menu automatically.<br />
3.1 The song menu is shown with three icons that<br />
are pointed out one by one every time they are<br />
introduced by the cartoon trumpet: “If you want to<br />
play the Mexican Hat Dance, you can wave now! Do<br />
you want to hear the Bull Fighters’ Song? Please<br />
wave! Wave now <strong>for</strong> the Russian Dance!”<br />
3.3 The cartoon trumpet says the child can conduct.<br />
The music begins. The child influences the<br />
volume and tempo by moving in front of the<br />
webcam.<br />
4. If the camera does not detect any motion <strong>for</strong><br />
some time, the welcome screen is shown and the<br />
program is ready to start the process again.
Blind typing <strong>for</strong> seniors<br />
Job de Reus, Sander van der Vlugt<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
jobplain@planet.nl, sander1986@wanadoo.nl<br />
supervised by Sander van der Maar, Fons J. Verbeek.<br />
svdmaar@liacs.nl<br />
Abstract. There are circulating many types of courses in blind typing. These<br />
courses can be followed either on the internet or at a physical place somewhere.<br />
We have made an online blind typing course especially <strong>for</strong> seniors. Many courses<br />
are made <strong>for</strong> children or young adults. The most are very boring. Our goals <strong>for</strong><br />
this project were to make a course <strong>for</strong> seniors with some novelties. We have done<br />
this by making more options and features in the course. Seniors can change the<br />
font size and the colour. To make it less boring we have create 2 games. After the<br />
evaluations we have noticed that our course isn’t boring. They like the<br />
configuration part.<br />
1 Introduction<br />
Blind typing has a major value <strong>for</strong> a person. The biggest advantage is the profit in time.<br />
An e-mail message with 500 characters can be written in 2 minutes with blind typing.<br />
A person without blind typing skills has needed at least 4 minutes <strong>for</strong> the same e-mail.<br />
That is a waste of time. There are a lot of advantages. We will pronounce some<br />
advantages.<br />
• There is no need to look down (<strong>for</strong> the keyboard) with the head. This will<br />
degrease the complaints about the neck.<br />
• The movement with the head is minimal. The head is only pointed to the<br />
screen.<br />
• What is typed can be read directly. Because of this the mistakes in typing a<br />
character can be revised at the moment.<br />
• The head is only pointed to a book or paper (<strong>for</strong> instance) when typing text<br />
from these objects, otherwise the head must move from the book or paper to<br />
screen, from the screen to the keyboard.<br />
• If the skills <strong>for</strong> blind typing are very good, the brains don’t need to “think”<br />
more then needed. The process of typing is like an automatic pilot. There is no<br />
need to look <strong>for</strong> a particular character, because of this, there is no waste of<br />
intellectual energy. All the energy goes to the actual job. This results (if the<br />
text must be creative) in a better text (more quality).<br />
Blind typing is very handy. Because of this there are a lot of courses, but we haven’t<br />
found any blind typing course <strong>for</strong> seniors. We created one. In particular those with an<br />
age of 50 and above.<br />
At this age, the so-called old age starts. This is a disease with very real symptoms. This<br />
disease is also known as senectus.We want to make something clear. We want to say<br />
that not every senior has symptoms. Only a few percents have these symptoms. That is<br />
our user group. There are also seniors without symptoms and they like our course a lot.<br />
We have made this course especially <strong>for</strong> seniors with these symptoms. Fortunately,<br />
every senior can do this course too.<br />
How can we create a user interface <strong>for</strong> persons with these symptoms? There are lot of<br />
website with in<strong>for</strong>mation about guidelines and golden rules <strong>for</strong> making a user interface.
We have tested our design by persons with these symptoms. They gave us some very<br />
good feedback.<br />
We have used Flash <strong>for</strong> creating the course. We have made the course very interactive<br />
(mouse-over effects, direct manipulation, games). That is easy to do (a big advantage<br />
of Flash).<br />
2 Problem Definition<br />
What is the difference between “normal” users and seniors? In our introduction we<br />
mentioned about symptoms <strong>for</strong> seniors. We describe these symptoms here.<br />
• Loss of sight<br />
• Loss of memory<br />
• Reduced muscle strength<br />
• Decreased ability to concentrate and react<br />
• Some seniors may also have heavier emotions.<br />
These are typical senior problems. We have used this point to investigate in our design.<br />
There are many websites and courses on the internet. What are the most obliging<br />
problems <strong>for</strong> this user group (and maybe more people) when they are on a website.<br />
• Crowded, chaotic pages<br />
• Small and indistinct fonts<br />
• To much text on the screen<br />
• The text colour on a website contrasts not enough with the background colour.<br />
• The navigation is very vague.<br />
It is very important to take attention to these problems. The “computer” generation is<br />
more flexible than the generation of people with an age of 60.<br />
What are the direct problems <strong>for</strong> our user interface with these points?<br />
The loss of sight is usually enacted by having problems with reading small fonts and<br />
distinguishing colours. For a typing course this is a problem, as this leaves out colour<br />
codes to show whether a user is right or wrong. Moreover, not being able to read the<br />
letters is a big problem, because it is all about reading characters.<br />
The loss of memory is also very important, because the users need to remember what<br />
they learned in the course. This isn’t a course you can do in just one hour. To learn a<br />
new skill, you need to focus on it. If you can’t concentrate you might just be able to do<br />
the practical part, but it won’t teach you anything. We had to find a way to keep<br />
attention to our course.<br />
The navigation is very important. If a senior don’t know where he or she is they will be<br />
very frustrated. We have a lot of pages. The structure of our course must be very clear<br />
with an obvious navigation. There is some theory, there are lessons with different steps<br />
and a final, and there are some games.<br />
It’s not only learning how to move the finger to the specific key. The theory part must<br />
support the practical part. If a user learns it wrong is very difficult to change that. A<br />
separate section must be available <strong>for</strong> the theory. With the aid of pictures it is possible<br />
to make it clear how they have to hold their fingers. We have already mentioned it.<br />
Most blind typing courses are boring. It must be more attractive with interesting things<br />
to do (games).<br />
We are making a blind type course <strong>for</strong> older people. We expect that our user group<br />
knows a little bit from computers, e-mail and the internet (by all means some skills)<br />
Otherwise, there would be no reason <strong>for</strong> them to do this course computer skills.
3 Approach<br />
Here you can read about our approach. Which problems occur and how have we solved<br />
them. Guidelines are very important to make a user interface. There are tons of<br />
guidelines. Our approach was to find the correct guidelines and articles.<br />
3.1 Other Blind Typing Courses<br />
Our blind typing course has been based on a real blind typing course. One of us had a<br />
blind typing course 8 years ago (1998). It was a very satisfying course. We have used<br />
the following parts of this course.<br />
• Begin with the simplest characters (d and k, then the e and i).<br />
• Repetition and repetition. This is very important. Each character is used at<br />
least in 5 lessons. You can’t learn a character in 1 lesson.<br />
• Don’t show the next characters. Only show the character they have to type at<br />
that moment. Otherwise they want to type to fast. Speed isn’t important in the<br />
beginning. They have to know the location of the character.<br />
• In the game “Speed” the whole sentence can be seen on the screen. A user can<br />
automatically reading <strong>for</strong>wards. This increased the speed and this is more<br />
natural. If a user types something from a paper, the user can see the whole text.<br />
Don’t show the next characters in a lesson, but in a game like “Speed” it is<br />
very useful.<br />
We have looked on the internet <strong>for</strong> other courses. We have learned the following points<br />
from other blind typing courses.<br />
• Use random characters in a lesson. If a user wants to do a lesson again, he<br />
doesn’t know which characters he can expect. It is always different.<br />
• In the game “Speed” the whole sentence can be seen on the screen. A user can<br />
automatically reading <strong>for</strong>wards. This increases the speed and this is more<br />
natural. If a user types something from a paper, the user can see the whole text.<br />
• The most blind typing courses were very boring. Only a text field where a<br />
user has to fill in some characters. There was no error detection.<br />
• In the beginning we already wanted to use games in our course. We haven’t<br />
found cool games to play in other courses. This is a real novelty in our course.<br />
3.2 Websites <strong>for</strong> Seniors<br />
There are some websites especially <strong>for</strong> seniors. SeniorWeb is an example we have used<br />
<strong>for</strong> our project. Seniors can read news, in<strong>for</strong>mation and events. It is like a start page <strong>for</strong><br />
seniors (like a portal). There is a <strong>for</strong>um where seniors can discus about internet and<br />
their hobbies. We have posted a link to our course. Un<strong>for</strong>tunately, there was almost no<br />
feedback and response. One person was angry about our course because he wants that<br />
we see seniors as normal persons. He hates all the software products which have been<br />
made especially <strong>for</strong> seniors in particular. He thinks that seniors are equal with younger<br />
people. We can agree a little bit with this, but on the other hand, there are a lot of<br />
seniors who finds this course very pleasant to work. We have made options to change<br />
the font size and the colour. He doesn’t have to do that. Seniors can also do this course<br />
without any physical or mental problems.<br />
3.3 Font<br />
We want the best readably text. The font is very important. There are many fonts to use.<br />
In an article [1], they have tested the most used fonts (Arial, Times New Roman,<br />
Verdana and Franklin). The results are that Verdana and Arial are the most legible<br />
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<br />
different fonts. Of the fonts studied, Verdana appears to be the best overall font choice.<br />
Besides being the most preferred, it was read fairly quickly and was perceived as being<br />
legible.<br />
3.4 Font Size<br />
Some seniors have worse eyes then others. We have made 4 versions with different<br />
font sizes. The smallest font is the standard font size of the most websites. The biggest<br />
one is 2 times bigger. The seniors can choose which one they prefer. We are using<br />
Flash; this means that it is impossible to change the font size in the browser. Flash<br />
doesn’t use HTML. That’s why we have chosen <strong>for</strong> this solution.<br />
3.5 Navigation<br />
Our structure is very clear. There are 4 main sections, home, theory, practice and<br />
games. A senior can go to every part of the website within 3 clicks. There are a lot of<br />
shortcuts and the buttons are very clear with obvious text within. The user always<br />
knows where he or she is. The top of the content part shows the page where the user is<br />
at that moment (<strong>for</strong> example: Practice – Lesson 14 – Step 3). We have used standard<br />
guidelines <strong>for</strong> this part.<br />
A nice thing we have made is the shortcut to the next step in a lesson. After a step the<br />
user can see the results, if he want to go to the next step, the user has to press on the<br />
“Next step” button with the mouse. The hands are already on the keyboard. We have<br />
made it possible that a user only has to press the “Enter” key to go to the next step.<br />
They can go faster to a new step and another benefit is that it prevents RSI (a little bit).<br />
3.6 Colour<br />
Here are guidelines we have followed [3].<br />
• A white background with black text is considered the best possible <strong>for</strong>mat <strong>for</strong><br />
website and printed copy.<br />
• Use of colours within your website should stay consistent. Otherwise, if you<br />
use colours that are completely different on every page, how will your visitors<br />
know that they are still on your website? If you ever want your visitors to<br />
recognize your website, having a consistent look and feel is important.<br />
We have only used 4 different colours <strong>for</strong> our main lay-out. These are yellow, orange,<br />
grey and blue. These are safe colours. There was a reason why we have used these<br />
colours. This is mentioned in the following guideline [4].<br />
• A possible solution is to design in black and white, and adding colour only <strong>for</strong><br />
emphasis since colour should never be the only visual cue <strong>for</strong> anything. If<br />
colours must really be used to distinguish items, then use blue, yellow, white<br />
and black. These combinations are less likely to be confused than others<br />
There is also a black-white version of our website. We have done this by the following<br />
reasons [5].<br />
• What colours work on the web and what don't? Black and white work best, of<br />
course. The colour issue doesn't come into play if everything is in greyscale,<br />
so design your site in black and white first. This is a good idea, even without<br />
considering colour-blind people, because you should never rely solely on<br />
colour.<br />
• Most colour-blind people see black and white accurately.<br />
The human visual system produces sharper images with achromatic colours
These are the reasons why we have a black-white version <strong>for</strong> our website. There is<br />
another reason. We have used the websites http://www.drempelsweg.nl and<br />
http://www.seniorenweb.nl <strong>for</strong> in<strong>for</strong>mation about usability. These websites can also be<br />
turned into a black-white version. They have done this with the same reasons we have<br />
described.<br />
There are also many colour blind people. The most obliging colour blindness (7 to 10%)<br />
is the combination red-green [6]. We only use this colour to see if a character is typed<br />
correct (then green, otherwise red). If a person doesn’t see the difference between a<br />
correct or incorrect character, then this person can change to the black-white version<br />
We have used the colour grey to determine whether it is good or not. We have placed<br />
two extra lines in the square to make it clear that the correct key is pressed.<br />
3.7 Consistence<br />
This is a very important point in our design. Our course is very consistence. The<br />
buttons are all the same. We have always used the same font and font size. All the<br />
buttons have the same effect. This is no matter of following guidelines. This has more<br />
to do with decent programming. Don’t create buttons when you need them. Determine<br />
the longest text in a button. Make all the buttons that length. Otherwise there are at the<br />
end 10 different buttons. We have made 2 buttons. Small buttons <strong>for</strong> text with only 1 or<br />
2 words and larger buttons <strong>for</strong> more words. The buttons are always placed at the same<br />
place.<br />
3.8 Games<br />
We have developed two games. The game “Degrease the circle” is a real game. This is<br />
a circle that grows slowly. If a user enter the correct key (what is placed in the middle<br />
of the circle), the ball will shrink a little bit. Then it grows again. The circle must be<br />
smaller than a certain size, otherwise the player is game over. The concept of this idea<br />
comes from an old project. One of us had made this game in another language and only<br />
with numbers. We haven’t consulted any source <strong>for</strong> aid. We had enough Flash skills to<br />
make this. Although it took much more time then we thought in the beginning. This is<br />
because the code was complex and there were always difficult bugs to solve.<br />
3.9 Help<br />
There is a help page where seniors can go if they don’t understand something. We have<br />
made a FAQ (Frequently Asked Questions) where seniors hopefully can find their<br />
problem. For example, it is possible that seniors press the “Caps lock” key. Every<br />
character will be a capital so that every input will be incorrect. They can read in the<br />
“Help” how to turn of this feature.<br />
3.10 Bugs<br />
The code (actionscript) was more complex than we thought in the beginning. We have<br />
consulted many Flash websites to find particular answers <strong>for</strong> our problems. Most time<br />
whether we had an answer <strong>for</strong> a problem, a new problem occurred. It was very difficult<br />
to make it bug free.
4 Evaluation and results<br />
We first start with the evaluations.<br />
4.1 Evaluation<br />
We had two evaluations. These were very useful <strong>for</strong> our project. They liked especially<br />
the novelty parts and the visual parts in the course. These novelties make the difference<br />
among other blind typing courses. Here is a positive reaction from our evaluation.<br />
• The games provide <strong>for</strong> variation and are nice to try. This makes it more<br />
attractive. The games are chosen very well. Nice exercises and nice to do.<br />
They can measure how fast they can type. Everyone wants to know how fast<br />
they can type. Certainly if they are learning and they want to see their<br />
improvements.<br />
Here is a positive reaction in relation to the visual parts.<br />
• Clear and nice way to make it obvious which keys they can expect in a certain<br />
lesson. The pictures in the lessons are a nice extra support <strong>for</strong> learning blind<br />
typing.<br />
The users can change the configuration immediately if they enter the course. They<br />
don’t have to search.<br />
• I like the home page where you can change the colour and font size. Seniors<br />
don’t need to search <strong>for</strong> these things.<br />
• It is very good that you can change the colours and font size immediately<br />
when you arrive on the website.<br />
The main issue: How is the usability? Here are some reactions about our usability.<br />
• Quiescent layout with a clear view.<br />
• You have ordered the in<strong>for</strong>mation at a good manner. Clear text and not too<br />
extensive (theory part).<br />
• It looks good and professional.<br />
• We like the colours. The colour orange makes it happily and lively. (otherwise<br />
it was a little bit boring). The white background in the middle of the screen is<br />
nice.<br />
• We can read everything. We like it to increase the font size with 1 step. It is<br />
very nice that we can configure that. We like the font too.<br />
• They are clear with nice icons. Every button is circa the same. The colour and<br />
font (and that blue effect) are the same, only the length of the button can<br />
change.<br />
• There are a lot of back buttons. There is always a back button and the main<br />
menu is always visible. We hadn’t any problems with it.<br />
• The lessons are very nice. They are very logical.<br />
There was a lot of feedback from our testers. We have used a lot of this feedback to<br />
improve our course. We haven’t used all the feedback because we disagree some<br />
feedback (see Evaluation rapport). A nice thing with this user group was that we hadn’t<br />
expected all these feedback. We are students with a lot of knowledge about computers,<br />
design and that kind of stuff. How was it possible <strong>for</strong> them that they can see things in<br />
our design we didn’t see already by ourselves. We had convinced them be<strong>for</strong>e the<br />
evaluation that we have a lot of design and technical skills but we are no seniors and<br />
that some parts in the course are logical <strong>for</strong> us, but not <strong>for</strong> people with less computer<br />
experience (like them). They have listened to us and give us some good feedback.
4.2 More Feedback<br />
Our team assistant has given us some feedback. He thought that games are a real<br />
addition <strong>for</strong> the course. We agree, the games are making the difference with normal<br />
blind typing courses. We have spent a lot of time in creating these games.<br />
Some ideas weren’t a good idea. We wanted to make the course that there was no need<br />
to use a mouse. Everything could be controlled with the keyboard. It was a nice idea<br />
but it isn’t a real addition. This was the feedback of our team assistant.<br />
• That they don't have to use a mouse with your software is a nice touch<br />
(although it conflicts with the part where they have to click on "finish"), but I<br />
don't consider it an innovation. I think the game part will count as such.<br />
We had also some feedback after our presentation 1.5 months be<strong>for</strong>e the deadline..<br />
Do the seniors know that the buttons are really buttons? We think that the buttons look<br />
like buttons. They have a roll-over effect and the text is very clear in the button. We<br />
have already mentioned it, we think that our user group has enough computer skills to<br />
understand the buttons.<br />
We showed the concept version of the game “speed”. They gave us some good<br />
feedback to improve this.<br />
4.3 Results<br />
We have made a good product. There isn’t a URL available at the moment but we are<br />
going to do that. The course has been completed and works perfectly. We haven’t find<br />
bugs and everything works well. They can go to the help <strong>for</strong> aim. They can change the<br />
colour of font size. In the theory part is many in<strong>for</strong>mation available about blind typing.<br />
The games are working perfectly and lesson 1 till lesson 30 is available.<br />
5 Conclusion and Discussion<br />
Our conclusion is that we have reached all our goals concerning the usability. We have<br />
made a very clear and plain user interface. Especially the games make it very attractive<br />
to do this course. Together with the possibility to change the colour and font size we<br />
reach not only our user group but many people.<br />
We even think that our course is so good that there are some plans to make it<br />
commercial (see Future Work).<br />
We haven’t spent time to investigate how many seniors are interesting in a blind typing<br />
course (this wasn’t our goal). There is a chance that we are going to investigate this<br />
because we want to make it commercial (we have already mentioned it). We don’t<br />
know how much the need is <strong>for</strong> a blind typing course <strong>for</strong> seniors. Maybe there are<br />
already glad that they can work with a computer. Why is it necessary to learn blind<br />
typing? Our generation has grown up with computers. It is possible that our generation<br />
have to work with computers in the future <strong>for</strong> our work. For our generation, it is much<br />
more important that we have these skills. It’s less important <strong>for</strong> seniors, although there<br />
are a lot of benefits to have these skills. We hope that there is a good market <strong>for</strong> these<br />
user group in this particular field.
6 Future Work<br />
The course can be expanded by a lot of things.<br />
6.1 Speed<br />
With the game “Speed”, someone can measure his own typing speed. This is only<br />
possible if a senior knows all the characters. There are a couple of stories. These stories<br />
use all the characters. It would be nicer if there are some levels. Level 1 contains only<br />
the first 10 characters of the alphabet. Level 2 contains the first 18 characters. Now, a<br />
senior can play this game a lot earlier.<br />
6.3 Video’s<br />
We have used pictures to see how a senior has to place his hands to type a character.<br />
This can be improved by using real videos of the hand. In this movie you can actually<br />
see the moving finger. Now, there is no indistinctness how they have to type a certain<br />
character.<br />
6.4 Commercial<br />
This course can be followed on the internet. Everyone is allowed to follow it. There is<br />
no registration system; this means that everyone can use it <strong>for</strong> free. This could be<br />
otherwise. It is very simple to make it commercial with a registration system. This<br />
means that people have to pay 5 euro (<strong>for</strong> instance). It is possible to make this in Flash.<br />
There are some extra advantages by using a registration system.<br />
• Storing of personal data (high scores in games, last lesson practised, personal<br />
settings, score in the final of a lesson)<br />
• A hall of fame. A place with the highest typing speed of all the users.<br />
• They have to pay 5 euro (<strong>for</strong> instance) be<strong>for</strong>e they get access to the course.<br />
References<br />
1. Sheedy JE, Subbaram MV, Zimmerman AB, Hayes JR: Text legibility and the letter<br />
superiority effect. HUMAN FACTORS 47 (2005): 797-815<br />
2. Michael Bernard, Bonnie Lida, Shannon Riley, Telia Hackler, & Karen Janzen: A<br />
Comparison of Popular Online Fonts: Which Size and Type is Best?. (2002) [Online].<br />
http://psychology.wichita.edu/surl/usabilitynews/41/onlinetext.htm<br />
3. A guide to top color combinations in web design [Online].<br />
http://www.allwebdesignresources.com/colorusageinwebdesign.html<br />
4. Burca Karagol-Ayan: Color vision confusion, University of Maryland (2001) [Online].<br />
http://www.otal.umd.edu/UUPractice/color/<br />
5. Mario Parise: Color theory <strong>for</strong> the color-blind (2005) [Online]. http://www.digitalweb.com/articles/color_theory_<strong>for</strong>_the_colorblind/<br />
6. Color blinness [Online]. http://en.wikipedia.org/wiki/Color_blindness<br />
7. Job de Reus, Sander van der Vlugt (2007). Blind typing <strong>for</strong> seniors. Journal 8 pages
Learning elderly to use the mouse<br />
Joppe Kroon, Alex Reuneker<br />
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
joppekroon@hotmail.com, alex@reuneker.nl<br />
Supervised by Mounia Belmamoune, Fons Verbeek.<br />
mounia@liacs.nl, fverbeek@liacs.nl.<br />
This project aims to teach elderly to use the mouse. Many introductory<br />
computer courses <strong>for</strong> elderly start by explaining the interface and functions,<br />
neglecting the fact that their users may not know how to use the mouse. We<br />
have shown that our product improves their experience, and makes using the<br />
mouse easier. We are the first ones that focus on elderly with this approach,<br />
while a lot of similar products focus on children and are not suitable <strong>for</strong> elderly.<br />
1 Introduction<br />
The group of people with an age of 65 or higher is rapidly expanding in Holland.<br />
Elderly are very fond of contact with other people, but are not always as able to travel<br />
that well. There<strong>for</strong>e computers and the internet could help them getting into contact<br />
with others, entertain them and give them the opportunity to connect to the whole<br />
wide world. It is a pity that a lot of elderly are easily scared by computers, and don't<br />
know how to use them. The idea is to make it as easy an entertaining as possible to<br />
introduce elderly into the world of computers. A lot of courses and books <strong>for</strong> elderly<br />
involving the first steps in computing, directly begin to explain how the computer<br />
works, and how to do the desired actions, completely neglecting the fact that some of<br />
the participants or readers don’t even know how to use the mouse.<br />
This is where our product comes in. The interactive, game-like interface, will help<br />
elderly use the mouse. In our experience it is quite hard to first learn to work the<br />
mouse, because the mapping of the mouse does not directly correspond to the pointer<br />
on the screen (horizontal movements VS vertical feedback on the screen). The<br />
innovation of our project is that it is aimed at elderly. The idea of mouse training is<br />
not new. There are some programs on the Internet that do the job, but most of them<br />
are aimed at young children and the rest is aimed at middle-aged people. The<br />
knowledge, learning ability and use of language is completely different <strong>for</strong> these user<br />
groups than <strong>for</strong> elderly people. Because of this, the existing products are not suitable<br />
<strong>for</strong> our user group.
This paper gives an overview of not only the capabilities, functionalities and<br />
possibilities of the product, but also gives a view on the evaluation and the<br />
development trajectory of the product.<br />
2 Short subject background and problem definition<br />
Today’s world is becoming increasingly technological. You can't turn a corner without<br />
bumping into a computer. This is great <strong>for</strong> whiz kids, but those who haven't learned to<br />
use this new technology are left behind more and more. This group consists mainly of<br />
senior citizens. There<strong>for</strong>e a lot of books on computer use are aimed specifically at this<br />
user group of the digitally challenged. However, every one of these books overlook<br />
one little thing...<br />
2.1 An outline of the problem and our solution<br />
Let’s take a look at the situation to improve our insight. There are elderly who want to<br />
learn how to use the computer, and have bought a book to this effect. After reading the<br />
first few pages they sit down in front of a computer and try to complete the first task in<br />
the book. But they find they cannot complete even the simplest task, because they do<br />
not know how to use the mouse or even what it's supposed to do. Frustratingly there's<br />
no chapter in the book explaining how this thing operates. At this point they may<br />
already give up, or ask someone if they can help them out. That someone else<br />
probably will just explain how to complete the current task, which leaves the person in<br />
question having to ask <strong>for</strong> help every time a new function is introduced.<br />
Having to ask someone to help increases the feeling of inadequacy and that puts the<br />
point of giving up nearer and nearer. We do not want our senior citizens dropping out,<br />
so we will have to improve this process of getting acquainted with the computer.<br />
That's where our product comes in. In stead of the “someone else” explaining the<br />
workings of the mouse, the user will first use our product to gain experience with the<br />
mouse. From here the elderly are introduced to the mouse step by step, learning<br />
everything there is to know to use mouse. After which he or she will be able to<br />
complete the tasks in the textbook with confidence.<br />
2.2 Alternatives<br />
There are several alternatives to our solution which you can split in two groups:<br />
• The Internet solution<br />
• The Microsoft solution
The Internet solution consists of websites or programs which are typically available<br />
through the Internet. These introduce the user to the mouse and give them a few tasks<br />
to complete, much like our solution. Individual problems aside, there's one problem<br />
they all have in common. They do not target elderly specifically, most of them even<br />
target children. And that means the elderly user will be intimidated by the colors and<br />
language, and give up be<strong>for</strong>e they have even begun.<br />
The Microsoft solution on the other hand relies on the games provided with every<br />
windows distribution. Every game uses just a subset of mouse functions and are<br />
there<strong>for</strong>e very well suited to introduce the mouse to a new user. However, these<br />
functions are not explained be<strong>for</strong>ehand, which means someone else has to come in and<br />
explain these functions <strong>for</strong> every new game. Besides that, there are added difficulties<br />
<strong>for</strong> elderly users. For example the size of the game elements, or the fast graphics.<br />
2.3 An insight into the elderly user<br />
Our research has shown that the elderly user is one with its own special demands <strong>for</strong> a<br />
product. The main difficulty when dealing with an elderly user is that they are easily<br />
intimidated by technology. There<strong>for</strong>e they do not use trial and error while working<br />
with a computer, they are actually afraid they will break it as if they are pushing a self<br />
destruct button. Furthermore, many have decreased ability on one or more areas, and<br />
are not able to position the mouse, read, or hear as you would expect from any other<br />
user. Next to this, the mouse is, at first use, an illogical piece of machinery. It does not<br />
clearly communicate how you should operate it, and when you do find out that moving<br />
over a surface provokes a response, it probably is not the one you would expect.<br />
Moving sideways, moves the pointer sideways on the screen. However, a <strong>for</strong>ward<br />
motion moves the pointer up and a backward motion moves it down. A typical user<br />
would trial and error his way through but, as said be<strong>for</strong>e, most elderly users do not use<br />
trial and error.<br />
3 From problem to solution<br />
Be<strong>for</strong>e solving the problem, it was necessary to address the right problem. And as<br />
important: who’s problem is it? First we addressed the problem, the following<br />
statement is used:<br />
‘Many elderly don’t know how to use the mouse, or never used it. Because most of the<br />
introductory courses designed <strong>for</strong> elderly focus on using programs, there is a gap<br />
between the present knowledge of elderly and the knowledge needed to start with<br />
these courses.’
We deliberately made a problem description, to be able to fall back on this, and to be<br />
able to test if we succeeded in our goal: solving this problem. We speak of elderly in<br />
this problem description. There<strong>for</strong>e we needed to clarify this user group:<br />
‘The intended user group consists of elderly people in Holland. Some characteristics<br />
are: age of 65 and up, Dutch speaking (and none, or little English speaking), no or<br />
little understanding of computers, no or little experience with both computers,<br />
standard software (Microsoft Windows) and the internet, good but slow hand eye<br />
coordination, a high percentage of the group with bad sight.’<br />
Because we differed very much from our user group, we first wrote some scenario’s,<br />
and did task analysis trying to capture the experience of our intended user group. After<br />
that we wanted to test on which level our user group was operating the mouse. We<br />
used a null test <strong>for</strong> this (see the results in appendix). This way we could determine on<br />
what level to begin teaching the elderly. From these results we set up our usability<br />
requirements. Our usability requirements focus on understandability, readability and<br />
af<strong>for</strong>dance of the interface. The goals in these are to have an understandable interface<br />
which relates to the world of elderly, readable text <strong>for</strong> elderly with possible bad sight<br />
and af<strong>for</strong>dance not only of the software interface elements, but also the af<strong>for</strong>dance of<br />
the mouse. What can they do with it, how does it work and how is it manipulated.<br />
These usability requirements are tested in the final user evaluation. We decided that<br />
the product should involve a large portion of gaming, so the learning curve of the<br />
product would be disguised by the gaming aspect. After presenting the paper design<br />
interface to elderly and discussing it with them, we developed the actual product.<br />
During this development we had problems trying to find a way go give in<strong>for</strong>mation to<br />
the user about how to play the games using the mouse. Just presenting text would not<br />
encourage the user to read it, and text would not be sufficient to give examples. We<br />
chose to use movies to explain working with the mouse and give examples of how to<br />
play the game. This gave us the opportunity to use both speech and visualization to<br />
explain our product.<br />
4 Results and Evaluation<br />
After developing the product, a final test was needed. In this final test we had to find<br />
out whether our solution solved the stated problem or not. We have done this by first<br />
letting the test subjects use or product. After this we presented them with our null test<br />
program (note that these test subjects are NOT the same as the original null test or<br />
first evaluation subjects. This is the only way to come up with valid conclusions), and<br />
we recorded the time they needed to complete the null test. The next logical step was<br />
to compare these results to the initial results we had from the beginning of the project.<br />
When the average time needed after using our program would be lower than the<br />
average time needed be<strong>for</strong>e using our program, we could conclude that we had solved<br />
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<br />
last on a scientific level we would have to run a test with a larger test group.<br />
Our hypothesis, that no test subject would need more than 20 minutes to complete the<br />
tasks, is found to be right. The conclusion, based on the figures and numbers as<br />
outcome of the test as shown below is summative, as said in the goal of the user<br />
evaluation. There<strong>for</strong>e a short conclusion can be given, which is:<br />
‘Our products works, it decreased the time needed to complete the null test (from an<br />
average of 16.4 minutes to an average of 6.5 minutes, which is a 60 percent<br />
decrease).’<br />
Because of the small test groups this outcome is to be taken very light. One or two<br />
very good or bad participants significantly influence the numbers. The percentage of<br />
decreased time could be lower. However the test results indicate that the product<br />
works significantly well. Further research is needed to calculate the precise decrease<br />
of time needed to learn using the mouse.<br />
The product could be improved on several aspects, which came <strong>for</strong>ward during the<br />
second user evaluation.<br />
• All the users in our test group had an incorrect grip of the mouse. This<br />
problem had been encountered in the previous test and we had tried to solve<br />
it by explaining how to grip the mouse in a movie.<br />
• The explanatory movies were too fast paced.<br />
• The sensitivity of the mouse proved a problem <strong>for</strong> most users however, and<br />
often caused the pointer to be positioned on the ‘begin’ button.<br />
• Most of the test subjects saw clicking the mouse as a solution to everything,<br />
provoking the wrong computer reactions.<br />
• Clicking often resulted in dragging, because the mouse was clicked too long<br />
and moved in between pressing and releasing.<br />
The <strong>for</strong>mative part of the evaluation, the usability scores, have given us the<br />
opportunity to draw the following conclusions:<br />
• People are neutral in using the program, they don’t especially like or dislike<br />
it. We should improve the gaming aspect to increase the entertainment value.<br />
• The program is found to be complex. Improvement needed.<br />
• The program is founded to be moderately easy. No improvement needed.<br />
• People think they need technical assistance. This is probably caused by fear,<br />
which the product should take away.<br />
• The options in the product were not always easy to find and use.<br />
Improvement is needed here.<br />
• The program was found not consistent enough. We don’t know the reason<br />
behind this yet, but improvement is needed.
• The test subjects don’t know if other people will learn using the mouse with<br />
this program easily. This must be improved in order to see it being used by<br />
more elderly.<br />
• People found the product fast enough to use. No improvement needed.<br />
• Most people felt certain when using the product. No improvement needed.<br />
• People thought they had to learn (ask) things be<strong>for</strong>e using the program.<br />
Improvement is needed here, by explaining more in the beginning of the<br />
product.<br />
We focused on understandability, readability and af<strong>for</strong>dance:<br />
• The metaphors were interesting enough to the elderly to draw a line between<br />
their own world and the computer. This can be concluded from the reactions<br />
of the test subjects during the tests.<br />
• The font used was of right type and size, no ‘difficult’ words or sentences<br />
came up during the evaluation.<br />
• The af<strong>for</strong>dance was of such a level that the elderly not always knew what to<br />
do with the interface objects. This must be improved.<br />
• The visibility is not good enough yet. The game characters were to small <strong>for</strong><br />
some of our test subjects. There<strong>for</strong>e we need to improve this.<br />
During the development our assistant helped us with feedback on prototypes and<br />
documents. The most important feedback we got was that we had lost sight of the<br />
gaming aspect. Our first prototype existed of only explanation of the working of the<br />
mouse. The reason <strong>for</strong> this was that the results of the null test were so bad that we lost<br />
sight of the fun aspect, and were challenged to come up with a product that improved<br />
this bad results. As we look back now we think we had a useful null test, and we<br />
should not be scared of the results next time in a similar project. We used the<br />
feedback of our assistant to rapidly change our prototype to more of a gaming<br />
environment, where learning by playing was exploited more. Nevertheless the<br />
gaming aspect should be improved even more.<br />
5 Conclusion and Discussion<br />
The overall conclusion is that we succeeded in significantly decreasing the time<br />
needed to learn elderly how to use the mouse, but the product could be capable of<br />
decreasing it even more and giving the elderly more pleasure while learning by<br />
improving the above mentioned usability aspects. As mentioned be<strong>for</strong>e, elderly are a<br />
special user group with it's own special demands <strong>for</strong> a product. This can be daunting<br />
<strong>for</strong> any developer, enough to prevent developers to target elderly with their products.<br />
This however is quite unfair <strong>for</strong> the many elderly users that could benefit from<br />
working with a computer. Besides that, it's also a big economical problem, because<br />
costs could be saved by investing in a particularly clear and robust interface, but now<br />
a large percentage of potential customers is shut out. Our product has proven to be an<br />
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<br />
stimulate other developers to actually develop applications specifically <strong>for</strong> the elderly,<br />
gaining them a new market, and gaining the elderly better software.<br />
Our product fills a void in the chain of products helping elderly users acquire<br />
computer skills. It provides the very first step to get acquainted with the computer that<br />
was missing until now.<br />
6 Future Work<br />
Work in the near future would consist of:<br />
• Improve the explanatory movies by slowing them down and implementing<br />
fast <strong>for</strong>warding and rewinding options. Also the quality and angle of the<br />
movies must be improved.<br />
• Give hints during the game to clear up the game play.<br />
• Improve the interface. The erratic mouse movements and clicks caused a lot<br />
of buttons to be clicked on the interface. It seems that this problem can only<br />
be addressed by removing all elements and displaying the game full screen.<br />
• Improve the gaming aspect to increase the entertainment value.<br />
• Improve the interface in such a way that it eliminates the thought of the<br />
elderly that they need technical assistance, which they do not.<br />
• Improve visibility.<br />
This future work could decrease the time needed to complete the null test even more,<br />
and there<strong>for</strong>e elderly would be able to use the mouse in less time and ef<strong>for</strong>t.<br />
When we look at the further future, we can say that nowadays practically everyone is<br />
growing up with computers, and learns how to use at young age. There<strong>for</strong>e our<br />
program serves a need right now: there are a lot of elderly who never used a computer,<br />
but probably will not be needed anymore in the not so near future (30 years or more).<br />
However, there will always be elderly and there will always be new things to learn. It<br />
can be expected that the problems elderly encounter now will be similar to the<br />
problems we will encounter when we are old. That means that the product itself<br />
hopefully will not be necessary in the future, but all insights gained while making the<br />
product will be instruments in creating future products aimed at elderly.<br />
References<br />
1. Digital Equipment Corporation (1986), System Usability Scale.<br />
2. Joel Sposky (2000) ,Designing <strong>for</strong> programmers,<br />
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html.<br />
3. R.J.H. Tolido (1996), IAD: Evolutionary development of In<strong>for</strong>mation Systems.
4. Redmond-Pyle & Moore (1995), Graphical User Interface Design and Evaluation.<br />
5. Bell & Parr (2002), Java <strong>for</strong> students.<br />
Appendix<br />
Screenshot of lesson 1: Cleaning up Bruno’s droppings<br />
Screenshot of lesson 2: Reach the bridge by scaring sheep away
Table of initial null test results (null test held on 2 november 2006)<br />
Control group (first null test) time in minutes<br />
Task User 1.1 User 1.2 User 1.3 User 1.4 User 1.5<br />
1 7 10 4 4 7<br />
2 3 2 1 3 2<br />
3 6 5 3 6 7<br />
4 4 3 1 1 3<br />
Total 20 20 9 14 19<br />
Mean 16,4<br />
Table of null test results after using the product (second evaluation held on 10<br />
january 2007)<br />
Test group (second user evaluation) time in minutes<br />
Task User 1.1 User 1.2 User 1.3 User 1.4<br />
1 1 1 1 1<br />
2 1 1 1 2<br />
3 1 1 3 3<br />
4 2 1 4 2<br />
Total 5 4 9 8<br />
Mean 6,5
Visual Memory Game<br />
Stijn de Gouw, Elena Gavrielidou<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
cdegouw@liacs.nl & vitabr3vis@hotmail.com<br />
supervised by Yanju Zhang, Fons Verbeek<br />
yanju@liacs.nl & fverbeek@liacs.nl<br />
Abstract: The rapid rise in Internet gaming and the recent popularity of the<br />
Casual Game genre have shown that the major contributor to this market is the<br />
‘Baby Boomers’, users of ages 40 to 60. One of the main concerns of this<br />
group, is Memory loss, Memory training and Memory retrieval, as shown by<br />
the rise in the sales of this genre of games. Our aim was to develop such a game<br />
to open a new market of educational Casual Gaming by creating a Visual<br />
Memory Game <strong>for</strong> this particular target market. By creating a Memory Game<br />
<strong>for</strong> the PC, we emulated the success of similar games on restricted gaming<br />
plat<strong>for</strong>ms, and in this way, addressing a much wider audience. As shown from<br />
game evaluations we per<strong>for</strong>med, the 40 to 60 year olds embraced and<br />
appreciated the creation of a Memory Game <strong>for</strong> their most popular gaming<br />
plat<strong>for</strong>m, the Personal <strong>Computer</strong>.<br />
1. Introduction:<br />
<strong>Computer</strong>s, video games and the Internet have become ingrained features of our<br />
everyday lives. <strong>Computer</strong> use has come to be a major source of fun and<br />
entertainment. For most people, computer use and video game play has long been<br />
established as an integrated part of daily life, in a balanced healthy manner.<br />
As memory loss and memory training seem to be the current trend in games<br />
development, we see an emerging pattern in the fabrication of games claiming to aid<br />
your memory. The most popular brain training game at the moment is ‘Dr<br />
Kawashima's Brain Training: How Old Is Your Brain?’ developed by Nintendo and<br />
intended <strong>for</strong> the Nintendo Dual Screen (DS) console. Brain Training is not just a<br />
game; it’s a pop culture phenomenon, a brain stimulator and a daily obsession.<br />
Unsurprisingly, the game has recently won a BAFTA award in the United Kingdom,<br />
in the category of innovation. Dr Kawashima's Brain Training comprises a variety of<br />
mini-games designed to give brains a workout.<br />
Following Nintendo’s success, other companies are also trying to capitalize on this<br />
opportunity. Mobile phone developer Upstart Games is creating “IQ Academy",
which marks the player's per<strong>for</strong>mance in various tasks of recognition, logical<br />
prediction and spatial resolution. It then rates the player and mixes up the puzzles<br />
offered next time, promoting further improvement. Whereas Nintendo's games use<br />
the DS's stylus and touch screen, IQ Academy employs a simple multiple-choice<br />
system, which make it accessible to anyone with a mobile phone.<br />
The issue at hand is that there is shortage of credible memory testing games <strong>for</strong> the<br />
computer plat<strong>for</strong>m. Although such computer games exist, the plethora is CD-ROM<br />
based, and this poses problems of mobility, accessibility and time-management. A<br />
CD-ROM game can only be accessed from the user’s home at specific times, as it is<br />
not very handy to carry the CD-ROM around and play whenever he or she feels like.<br />
From our preliminary research we have realized that those of the games that are<br />
trying to target the on-line market, all comprise of a repetition of one specific<br />
memory game, namely identifying a pair of playing cards from a pack of cards turned<br />
upside down. This genre of games does not target the specific problem we face,<br />
which is to find the most effective means of creating an educational online game that<br />
comprises of credible, usable and successful exercises which will make it attractive to<br />
a specified user group, which will be discussed later on in this paper.<br />
In order to tackle the problem of creating an utterly efficient online memory game,<br />
we need to identify the environment in which this game will evolve. There<strong>for</strong>e two<br />
important aspects need to be established; the general background and advances in<br />
computer gaming, and most significantly, the audience <strong>for</strong> such games. In addition,<br />
there needs to be a clear connection between this specific audience and their<br />
consequent need <strong>for</strong> such a game, in order to determine the target audience this game<br />
is constructed <strong>for</strong>. These issues will be discussed in the second section of this paper.<br />
After having recognized the environment and target audience, the most effective<br />
technique <strong>for</strong> addressing this audience must be identified, and this is what the third<br />
part of this paper will consist of. Implementing the relevant <strong>HCI</strong> theories <strong>for</strong> the<br />
correct output of the game is crucial, if the game is to become successful, and its<br />
innovative aspects will be discussed in order to show how it will survive with the<br />
current competitors.<br />
Furthermore, the usability tests the game has undergone in order to ensure its<br />
credibility will be analysed in the fourth section of this paper. This will certify that<br />
the theories have been implemented in an appropriate manner, so as to make the game<br />
a success within its preferred audience.<br />
Future developments in relation to this game, and plans <strong>for</strong> further expansion, in<br />
terms of other markets or even in terms of perfecting its prototype status, will be<br />
discussed in the fifth part.<br />
<strong>Final</strong>ly, conclusions and personal reflections on the development process and the<br />
deliverables of this artifact will be analysed in the conclusive part of this paper.
2. Casual Gamers, Baby Boomers, and Memory Loss:<br />
Memory and concentration problems are common with age, including difficulties in<br />
focusing and in maintaining attention. Some problems are more serious than others.<br />
People with more severe memory lapses may be suffering from one of a series of<br />
conditions of the brain known as dementia, or Alzheimer’s disease. Dementia affects<br />
your ability to carry out normal and usually easy daily activities. Problems can occur<br />
at any age, although due to increased fragility and vulnerability the ability to encode<br />
new memories of events or facts and working memory shows decline in people over<br />
40. People over 60 show more rigorous symptoms if these are not prevented or<br />
treated by nutritional rebalancing or mental mind-mapping exercises.<br />
The aim of creating this game is to target this exact age group of 40 to 60 year olds,<br />
who are concerned with their abilities of concentration, and their need to focus on<br />
particular tasks without being distracted over a period of time. This is the age group<br />
that tends to <strong>for</strong>get things that one would automatically and easily recall. As memory<br />
gives you the ability to store in<strong>for</strong>mation and events <strong>for</strong> later recollection, the brain<br />
that controls these processes could be viewed as a muscle itself, which, if not properly<br />
exercised, will eventually lose its power. The target group has already expressed the<br />
need <strong>for</strong> such brain exercise, as is shown by the rising sales of Nintendo’s ‘Brain<br />
Training Game’. There<strong>for</strong>e, the underlying problem we face is developing a game <strong>for</strong><br />
an already established target market in need, but addressing it in its widest <strong>for</strong>m,<br />
namely, creating a memory game that will be accessible to everyone who doesn’t<br />
have access to handheld consoles such as the Nintendo DS.<br />
In addition to being prone to memory loss, this particular age group surprisingly<br />
holds a total of 20% of the online usage market, as opposed to the group who would<br />
be expected to have the majority (the 18 to 24 year olds) who hold a humble 17.8%<br />
of the online usage market:<br />
“The analysis also shows that 45- to 64-year olds surf the Internet<br />
more frequently, stay there longer, and check out more Internet pages<br />
than even their college-age counterparts” [Lispman (2002)]<br />
While establishing the target group <strong>for</strong> the memory game we realised that potential<br />
users must be defined in terms of what they want, or will accept, what kind of<br />
distribution will be most convenient <strong>for</strong> them and through what channels of<br />
communication they can be best reached, as well as what the want from the final<br />
product itself. A further aspect of importance when designing with the user in mind is<br />
realising the group’s competency in terms of computer and Internet usage. The results<br />
of our research stunned us once again, when we realized that the target group, also<br />
known as ‘Baby Boomers’ whose computer knowledge was perceived highly<br />
unlikely, is indeed quite computer literate, due to the amount of time they spend<br />
online:<br />
“While most adults age 50 or above are more likely to be intermediate<br />
Internet users testing the waters of the Internet, their heavy online<br />
habits have set them on a fast track to become fully accustomed to the<br />
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<br />
longer and view 178.7 more unique pages per month.”[Lispman (2002)]<br />
Furthermore, this certain age group seems to be quite active in the realm of ‘Casual<br />
Gaming’. It is a necessity today <strong>for</strong> almost every person who spends most of his/her<br />
day working in front of a computer screen, to find ways that will enable him to<br />
escape, even <strong>for</strong> five minutes, from whatever preoccupies his mind. One of the most<br />
popular and frequent solutions to this, are quick, addictive games, which can be found<br />
online.<br />
The expression ‘Casual Game’ came to be used to refer to a category of electronic or<br />
computer games targeted at a mass audience, with no particular computer skills. The<br />
main characteristic of Casual Games is that they have a few simple rules and an<br />
engaging and addictive game design, making it easy <strong>for</strong> a new player to begin<br />
interacting with the game in just moments.<br />
“According to research firm IDC, the online gaming population alone is set to reach<br />
256 million people by 2008. The firm estimates that the U.S. market <strong>for</strong> primarily<br />
casual downloadable games will grow to more than US$760 million in 2007.” [Early,<br />
(2005)]<br />
The fact that Casual Games require no long-term time commitment or special skills<br />
from the user, combined with the fact that there are comparatively low production<br />
and distribution costs <strong>for</strong> the producer, makes them such a popular part of the gaming<br />
market, and consequently make them a good choice of style <strong>for</strong> launching our own<br />
online game.<br />
Consumers progressively rate home computers as a means of a multiple range of uses,<br />
including Internet and e-mail services, games, and educational and work uses. The<br />
driving <strong>for</strong>ce behind this is the availability of hardware that is both smaller in size and<br />
more stylish in design nowadays, making the PC an even more acceptable addition to<br />
the living room.<br />
As technology barriers are falling, and computers start to penetrate our everyday lives<br />
faster than be<strong>for</strong>e, the average age of online Casual Gamers is increasing. The ‘Baby<br />
Boomers’ are becoming computer literate, and as they experience the world of the<br />
computer, they become more interested in Casual Gaming, since this generation is<br />
less likely to own game consoles, as it is evident in Figure 1(See Appendix).<br />
There<strong>for</strong>e the problem at hand will be tackled thus: Creating an online ‘casual game’<br />
to help prevent or treat Memory Loss, and addressing the age group of 40 to 60 year<br />
olds, <strong>for</strong> primarily two reasons: they hold the largest share in the online ‘Casual<br />
Game’ and Internet usage market, and are constantly interested in solutions to battle<br />
with memory loss.
3. Visual Memory Game: the Online Solution<br />
The interface design of the game was set up according to ‘Schneiderman's 8 golden<br />
rules of design’[Skaalid (1999)]. To improve the game’s usability, it is important to<br />
have a well-designed interface.<br />
The fact that this game will be online means that the users will never be constrained<br />
in any way; playing it is possible at any time from anywhere, as long as a computer<br />
with an internet connection is present.<br />
The primary attributes of the design, are, that it must have a consistent, intuitive and<br />
simple interface that is intended in aiding the users in navigating through, by means<br />
of intuitive, constant and consistent navigation and buttons, that the users can<br />
familiarise themselves with easily. This layout design provides an innovative<br />
solution <strong>for</strong> a market segment that is essentially a driving <strong>for</strong>ce of the market, yet few<br />
products are designed with this target group in mind!<br />
Furthermore, by offering error prevention and easy reversal throughout the game, the<br />
user will be able to distinguish the navigational process from the feedback provided<br />
through the buttons. This will also give the functionality to frequent players, as the<br />
familiar environment will make it easy to play the game several times: The entire<br />
game is a linear exercise consisting of eight smaller parts, each one aiming to train a<br />
different aspect of the brain. Concise instructions at the beginning of each sub-level<br />
guide the user through the exercises. The game was designed in a user-friendly<br />
manner, meaning the user makes all decisions with the OK button, which is handily<br />
situated next to the answer bar. Functionally, this model aims to give the user group<br />
the confidence to navigate through the game without feeling lost or confused in any<br />
of the levels. When the user reaches the final screen, the score will be displayed,<br />
giving the desired feedback that the game promises through out its adventure-style<br />
linearity.<br />
The main philosophy of this game, is that it must be straight<strong>for</strong>ward and simple <strong>for</strong><br />
novice users, but also be functional enough <strong>for</strong> more experienced users to be able to<br />
navigate through it consistently. This is accomplished by giving the user an interface<br />
that does not require elaborate thinking to navigate through. Also, it is important to<br />
stress that besides being an entertaining game, this product offers beneficial<br />
knowledge to its end users, in an easily accessible ‘Casual Game’ manner, which is a<br />
technique that has not been explored in depth by the game producing market.<br />
This game aims to evolve as a natural consequence of reliable and appropriate<br />
handling of the in<strong>for</strong>mation known about user preferences, and their implementation<br />
in a functional game. There will be a strong, consistent visual hierarchy, within which<br />
important elements such as navigational buttons are emphasised. Furthermore, the<br />
content is organised logically and predictably.<br />
Employing the ‘Gestalt’ [Saw, (2000)] theory, we will create an overall graphic<br />
balance and organisation in the game, to draw the user to the content, which is the<br />
crucial goal of the design interface. This balance between attracting the eye with<br />
visual contrast will consequently provide the website with a perceived sense of<br />
organisation.
<strong>Final</strong>ly, the graphics that will be used throughout the page will be optimised <strong>for</strong> web<br />
use, which means that they will be small in size (in megabytes), so that the game can<br />
load into browsers quickly, even when accessed by users with slow Internet<br />
connections. The goal of this design scheme is essentially to transmit internal<br />
in<strong>for</strong>mation and to communicate with potential users and the general casual gamer<br />
public.<br />
Essentially, we are taking Nintendo’s concept of ‘Dr. Kawashima’s Brain Training<br />
game”, which has already been a proven success, on the constrained DS console and<br />
opening it to a wider on-line audience, a target market that has yet to see an<br />
innovative educational game as such.<br />
4. Results and Evaluation:<br />
Two separate evaluations were conducted. The first was mostly concerned with the<br />
design layout and ensuring that the target group focusing on was the optimal one. The<br />
second dealt with the functionality of the game, the improved design layout, and rated<br />
the confidence with which the users interacted with various aspects of the game.<br />
The results derived from these evaluations were truly positive. Evaluators commented<br />
and complimented the simplicity of the layout. In terms of functionality, the font size<br />
and button size was found to provide the users with confidence to navigate through<br />
the various levels of the game.<br />
The main issue faced by the users when first playing the game was the functionality<br />
of answer boxes. Initially some users were not sure as to how these were to be used<br />
and consequently special care was given to the timing of the games, as well as the<br />
way in which buttons were disabled during movie clips and instructions shown on<br />
screen, and this is something the users thought would be very helpful in making the<br />
functionality of the answer boxes clearer. The consistent positioning of the buttons at<br />
the right side of the screen proved to be a choice favoured by the users, who<br />
commented on the fact that this allowed them to focus on the game screen and<br />
confidently move from level to level.<br />
The colour scheme employed was evaluated as giving a ‘serious’ note to the actual<br />
game, which the users found inspiring when playing. This was said to enable them to<br />
concentrate to the goal of the game, which was to obtain a high score.<br />
In terms of feedback, the users did not appreciate a result screen at the end of each<br />
game. The overall opinion on this, was that by seeing a score result after each level,<br />
the attention was shifted from the game towards the scores, and this is something that<br />
we altered <strong>for</strong> the final working prototype, where the score is only displayed at the<br />
end of the final level. The evaluators also commented that they quickly became<br />
familiar with the interface, due to the consistent positioning of the minimal functions<br />
in each game.
5. Conclusion and Discussion:<br />
When attempting to create an interactive game to be implemented on an electronic<br />
plat<strong>for</strong>m, it is extremely important to design with the user in mind. The fact that the<br />
Visual Memory Game appealed to its intended audience mainly results from the<br />
careful consideration of the user group, and the precise understanding of this groups<br />
needs in terms of computer games. It was also important to realise that this segment<br />
of the market holds the first place in terms of computer and Internet usage, and<br />
there<strong>for</strong>e we wanted to fabricate a game that would suit their needs as novice to<br />
intermediate users.<br />
Trying to implement <strong>HCI</strong> theories <strong>for</strong> the creation of a user specific game was a<br />
challenging task, especially when this game had as a particular purpose to tackle with<br />
a problem that this user group faces, namely, Memory loss. This was an issue that had<br />
to be approached with care, and target within this user group the specific need to<br />
resolve this issue, by presenting a game they would indeed find credible. For this, we<br />
had to create an atmosphere of reliability and consistency, which would boost the<br />
users’ confidence and enable them to view this game as an educational and fulfilling<br />
experience.<br />
In addition, the creation of this game aimed to open a new market of Educational<br />
Casual Games, having in mind that this specific user group is interested in Casual<br />
Games, yet, no one has been creating them <strong>for</strong> the purpose of aiding and educating<br />
this particular target group. By creating this game, and evaluating it with real users,<br />
we came to the conclusion that venturing on the creation of such educational Casual<br />
Games <strong>for</strong> this specific market is a feasible move, as the target audience has<br />
responded very well to this first game of this genre.<br />
6. Future Work:<br />
The trends of the market reveal that there is huge potential <strong>for</strong> growth in new, nonretail,<br />
distribution channels <strong>for</strong> games – the internet games market – which is growing<br />
at over seven times the pace of the traditional, retail-based games market. The goal<br />
of successfully implementing this game does not only aim to benefit from the market<br />
trends, but also pave the way in a new category of educational games that will be<br />
particularly tailored <strong>for</strong> online use. With the rise in the popularity of e-learning, the<br />
potential of producing inexpensive educational games <strong>for</strong> casual use is enormous.<br />
We would like to further develop this genre by creating a series of different games <strong>for</strong><br />
the specific age group, that would not only aim to tackle with their memory issues,<br />
but also help them advance their computer skills and general knowledge. In the future<br />
we would also like to expand the age group, and concentrate on creating educational<br />
games <strong>for</strong> other target markets, with the same philosophy and <strong>HCI</strong> theories in mind.
References<br />
1. Lispman, Andrew (2000) U.S. Baby Boomers and Seniors are Fastest Growing<br />
Internet Demographic Group, New York – Last Accessed January 2007<br />
[http://www.comscore.com/press/release.asp?id=181]<br />
2. Early, Chris (2005) Casual Gaming Gets Serious, Washington – Last Accessed<br />
January 2007<br />
[2http://www.microsoft.com/presspass/features/2005/jul05/0719CasualGaming.msp]<br />
3. Skaalid, Bonnie (1999) Shneiderman’s Principles of <strong>HCI</strong> Design, New York – Last<br />
Accessed January 2007<br />
[http://www.usask.ca/education/coursework/skaalid/theory/interface.htm]<br />
4. Saw, James (2000) Design and Composition: Gestalt, Last Accessed January 2007<br />
[http://daphne.palomar.edu/design/gestalt.html]<br />
Appendix<br />
Figure 1: Casual Gaming Age Distribution
Figure 2: Game Level 1<br />
Figure 3: Game Level 2
Online Flower Shop<br />
Sjaak Wolff, Ella Keijzer<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
sjaakwolff@hotmail.com, ella.keijzer@gmail.com<br />
supervised by: Sander van der Maar, Fons J. Verbeek.<br />
svdmaar@liacs.nl & fverbeek@liacs.nl<br />
Abstract:<br />
Our project is based on all those online shops at the world wide web. We designed<br />
one specially <strong>for</strong> elderly people. Elderly people most of the time feel uncom<strong>for</strong>table<br />
buying something on the internet. The novelty in this project is<br />
'Heidi', the saleswoman who leads you trough the website, if you want. She tries<br />
to make you feel com<strong>for</strong>table and give you in<strong>for</strong>mation about the website. In<br />
our user evaluation we saw this worked quite well. Our subjects feel com<strong>for</strong>table<br />
and want to come back to the shop.<br />
1 Introduction<br />
Nowadays buying something on the internet is <strong>for</strong> a lot of people a normal thing to<br />
do. It is not difficult <strong>for</strong> those who work a lot with the computer to understand the<br />
structure and the procedure of an online shop. There are a lot of different shops all<br />
over the internet. For the course <strong>Human</strong> <strong>Computer</strong> <strong>Interaction</strong> by F. Verbeek; we<br />
made an online flower shop.<br />
We did not make a usual flower shop. We made it <strong>for</strong> a special user group. Our user<br />
group is the group that doesn’t work with the computer very often. Although they<br />
might not be really old, they are most of the time older then 40. It is often very difficult<br />
<strong>for</strong> those elderly people (you can read elderly as: people who are not grown up<br />
with computers) to buy something from the internet.<br />
Our idea was to make an online-flower shop, which is very accessible <strong>for</strong> people<br />
who are not very familiar with the computer. In this shop you can order al sorts of<br />
flowers. You can order (mourning-, birth-) bouquets, plants and you can also choose<br />
from a collection of vases. We made our whole project in Flash; which enables us to<br />
make an eye catchy design. To access our shop, you need to know how to work with<br />
the mouse.<br />
The structure of our paper is as follows: first we tell something about the background<br />
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<br />
and a short view on the future.<br />
2 Short Subject Background and problem definition<br />
First of all it is nice to have a online shop which is very intuitive. There are many<br />
shops on the internet, but they are most of the time very confusing. We made a shop<br />
'just as the one in your neighborhood'; small and nice.<br />
Most important <strong>for</strong> our design is the user analysis. Our user group consists of the<br />
so called elderly people. Elderly people are most of the time not grown up with computers.<br />
You have to think on people born be<strong>for</strong>e 1960. Even in their jobs, they seldom<br />
use a computer.<br />
People who are not grown up with computers are most of the time very uncom<strong>for</strong>table<br />
with them. They do not understand a directory structure or even a mouse. Also<br />
they do not really trust or like the computer. Sometimes they have bad eyes which<br />
make it difficult <strong>for</strong> them to read large texts from the screen. We want our user group<br />
to feel com<strong>for</strong>table by buying something on the internet. Those older people like human<br />
contact, they must have the feeling there is a 'ask-possibility', as in a 'real-life'<br />
shop. Compare the dislike of older people <strong>for</strong> ticket-machines, cash-machines etcetera.<br />
Those people are used to go to a shop. In the future they might not be as mobile as<br />
they are now and there<strong>for</strong>e are not always able to go outside. It would be very nice if<br />
they get more used to use the internet, they then can spare a lot of time and energy<br />
with that.<br />
So our program has to be easy to use and understand, without losing the functionality<br />
of the ‘bigger’ online shops.<br />
For our program, the only thing you need is a mouse. Our user group is maybe not<br />
used to use a computer, but they have to understand how a mouse works.<br />
3 Heidi, the saleswoman<br />
To make the elderly feel com<strong>for</strong>table with buying something on the internet we introduce<br />
Heidi. Heidi is our saleswoman, just as the one you know from your neighborhood<br />
shop. She guides you trough the website; but only if you Want to be guided. She<br />
will say unambiguous things. She says her things in a text balloon, so you can read it.<br />
This is because our elderly can relax while reading the text; they can read on their own<br />
tempo. Also when they are distracted, they do not miss important in<strong>for</strong>mation. If Heidi<br />
asks you a question, you can choose and click your answer (see appendix pictures).<br />
It is also interesting to mention why we chose to set the menu on the left. It is really<br />
obvious to do so, because everyone does. People know already were to look, compared<br />
to the F-pattern by eye tracking 2 . Although our user group is not used to the internet, it<br />
is nice <strong>for</strong> 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<br />
Simplicity” 1 . (Worth reading <strong>for</strong> <strong>HCI</strong> interested people).<br />
4 Results and Evaluation<br />
User evaluations<br />
First user evaluation<br />
In our first user evaluation, we asked our subjects several question, while showing<br />
them a raw draft of the shop. In the prototype we gave Heidi three sentences to say.<br />
She really spoke; <strong>for</strong> this prototype we had made a computer voice. But most of the<br />
people get confused by that. Not everyone had enabled his audio boxes, and some of<br />
them want to talk back to Heidi. If they were distracted, they did not follow where the<br />
site was about anymore. After this, we decided to make the text Heidi was going to<br />
say, not audible, but in a text balloon (see appendix pictures).You can see how that<br />
looks on the screen shots in the appendix.<br />
Furthermore, we find that our subjects had some problem with the shopping cart.<br />
They didn’t really understand what the icon meant, so we did a test and made several<br />
icons and the one being used now came out best. (see appendix pictures)<br />
Second user evaluation<br />
In this user evaluation we didn’t only do a questionnaire, but we also did some observations.<br />
We saw that most of the subjects chose to get help from Heidi by entering<br />
the shop. From this we concluded that Heidi is a good concept to lead people trough a<br />
site.<br />
In the questionnaire our users reported us that they feel com<strong>for</strong>table. They talked<br />
about Heidi as if she was the nice girl next door.<br />
Their feeling of com<strong>for</strong>t was not only because of Heidi, but also because of the nice<br />
design of the shop, which they liked. After this evaluation, we just made a few little<br />
changes.<br />
Remarks from Presentation<br />
During our presentation in class, someone gave us the advise to make the cash desk<br />
inside the 'scrapbook', which is located on the right. This looked to us as a good idea.<br />
But finally, we did not apply it because of lack of space, and stylistic prospective. Our<br />
user group understood how it works anyway. Some of them even said: 'It felt natural,<br />
as if I was going physical to the cash desk'.<br />
Another remark was that you were able to compose a bouquet of your own. We<br />
thought that was a good idea, so that’s another thing we added to our final product.<br />
Someone recommended us to use some special software <strong>for</strong> designing Heidi and let<br />
her talk. <strong>Final</strong>ly we didn’t use it because we changed the whole concept about the<br />
talking of Heidi.
5 Conclusions and Discussion<br />
Our solution to use Heidi, worked quite well. We learned from our user evaluations<br />
and changed some major things.<br />
We thought that a speaking (with sound) saleswoman would be a good idea; we<br />
saw it on several big sites. But in our case it didn’t work quite well.<br />
Furthermore, the shopping car icon was a problem at first, so we made a few test<br />
icons, and we let the users choose which they thought are the best. Although the current<br />
one came out best we still think this is a part that could be improved.<br />
Another point of discussion is that right now we based it on a small collection of<br />
items which can be sold. If you would have a very large collection of items in the shop<br />
it would require a lot of enhancement to effectively find what product you’re looking<br />
<strong>for</strong>.<br />
6 Future Work<br />
When it is more common to have a speaker (which is on) and a microphone on your<br />
computer; it will be very nice if Heidi really speaks to you, and you can answer with<br />
your voice. There<strong>for</strong>e you need a very good and stable voice recognition system.<br />
Composing a bouquet could be more clear. For example, you really can see your<br />
bouquet composed, so if you add a flower you see the bouquet grow.<br />
Heidi is now just a static picture with a text balloon. But it might be nice if she<br />
would be more dynamic, had some facial expressions, so she would be more like a<br />
‘real’ person.<br />
References<br />
1. John Meada The Laws of Simplicity (Simplicity: Design, Technology, Business, Life)<br />
ISBN-10: 0262134721 ISBN-13: 978-0262134729 see also: http://lawsofsimplicity.com/<br />
2. http://www.useit.com/alertbox/reading_pattern.html<br />
http://www.useit.com/eyetracking/ F-shaped pattern <strong>for</strong> reading a webpage; Jakob<br />
Nielsen and Kara Pernice Coyne
Appendix
Cashdesk:<br />
Shoppingcart icon:
Barschedule Catena<br />
Christian Detweiler, Stefan Schrama<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
cdetweil@liacs.nl, sschrama@liacs.nl<br />
supervised by Alexander Nezhinsky.<br />
anezhinsky@casema.nl<br />
Abstract: We have successfully written an online subscribing system <strong>for</strong> the<br />
barshifts on VSL Catena.
1 Introduction<br />
In the world of automated systems, there are a lot of different subscribing systems <strong>for</strong><br />
all sorts of things. One of the things that didn’t existed was an online subscribing<br />
system <strong>for</strong> the bartenders at VSL Catena. Our goal was to write such a system, both<br />
simple and with a good overview.<br />
2 “Short Subject Background and problem definition”<br />
At Catena current barshifts are being subscribed to by filling in your name in a<br />
timetable on the kitchen door or by the Head of Bartenders, who calls you and then<br />
fills in your name. This means that you don’t know who is going the be the bartender<br />
<strong>for</strong> a certain shift, unless you are physically at Catena. The Barcomity at Catena was<br />
looking <strong>for</strong> a better sollution and contacted the Networkingcomity. I, Stefan Schrama,<br />
am the president of the Networkingcomity and decided to make this assignment into<br />
my <strong>HCI</strong> project. Together with my course partner Christian Detweiler we started<br />
developing the system.<br />
3 The Approach to solve the problem<br />
A Simple Approach<br />
Simplicity is central to this project. The application has to be clear enough to be used<br />
without any explanation. To achieve the required clarity choices were made on<br />
different levels.<br />
Global layout<br />
At the highest level a distinction was made between 1) in<strong>for</strong>mation and functions<br />
related to the user, 2) in<strong>for</strong>mation and functions related to navigation, and in<strong>for</strong>mation<br />
and functions related to the bar schedule itself. The layout of these components that<br />
was chosen reflects the importance of each component to the application as a whole.<br />
The navigation component, which is the most frequently used component, is located<br />
at upper left of the screen, because this is where most of the users (who are used to<br />
reading from left to right) begin viewing. The size of the navigation component is<br />
limited, because the interactions with this component, although frequent and<br />
important, are short. The user does not have to stay focused on this component very<br />
long. Directly under the navigation component is the component <strong>for</strong> user in<strong>for</strong>mation<br />
and functions. It is located under the navigation component, because it does not<br />
require the user's immediate attention. The in<strong>for</strong>mation displayed in this component is<br />
generally in<strong>for</strong>mation the user is already aware of, and the displayed function are<br />
usually only used once per session. There<strong>for</strong>e, the component's size is limited. The
entral component of the application, both visually and functionally, is the bar<br />
schedule. It is located in the center of the screen, because it should be the point of the<br />
user's focus most of the time. For the same reason the size of the bar schedule<br />
component (about 3/5 of the screen) was chosen. Another reason <strong>for</strong> the size of the<br />
bar schedule component is the space required <strong>for</strong> the various elements of the bar<br />
schedule, which will be discussed in more detail below. Besides the placement of<br />
components based on the user's focus, the navigation component and the barschcedule<br />
component are located next to each other because actions taken by the user in the<br />
navigation component directly influence what is displayed in the navigation<br />
component to its right.<br />
Layout of the individual components<br />
In designing the components attention was paid to each component's function, and the<br />
relation of (some of) the components to one another.<br />
The navigation calendar consists of a part <strong>for</strong> navigating from month to month within<br />
the component, and a part <strong>for</strong> selecting a week <strong>for</strong> display in the bar schedule<br />
component. The part <strong>for</strong> navigating from month to month consists of a drop-down<br />
menu with the number of the month and one with the year. On the sides of the menus<br />
are arrows <strong>for</strong> navigating to previous and next months. Under the navigation section<br />
there is a calendar, in which the week displayed in the bar schedule component is<br />
shaded. When the user moves the cursor over the various weeks the cursor changes to<br />
indicate the week is 'clickable'. Also, the week under the cursor is highlighted. Weeks<br />
are selectable as a whole, because that is how they are displayed in the bar schedule<br />
component. To further emphasize the relation between the calendar component and<br />
the bar schedule component the color of the selected week in the calendar is the same<br />
as the background color of the week displayed in the bar schedule. Also the row of<br />
day names in the calendar has the same color as in the bar schedule.<br />
In the bar schedule component, the days of the week are displayed vertically (as<br />
opposed to horizontally in the calendar). Although this may seem counterintuitive, it<br />
is consistent with the layout of the "paper version" of the bar schedule currently in use<br />
at Catena, so it is familiar to the users. The content of the bar schedule depends on the<br />
role of the user, which can be Head Bartender, Bartender, or Normal User. If the user<br />
is a Head Bartender, the barschedule will contain the names of people signed up to<br />
tend bar during each of the three shifts that are available every day of the week. If the<br />
user clicks on a name, in<strong>for</strong>mation about that user is displayed on top of the schedule.<br />
Next to the name is a button to send a reminder (or other message) to that person. A<br />
simple <strong>for</strong>m with which to send the mesage is displayed over the schedule, so the user<br />
doesn't have to navigate away from the schedule. If a shift is not full, the word<br />
“nobody" is displayed instead of a name, with a button next to it to send a message to<br />
all Bartenders encourage them to sign up <strong>for</strong> that shift. Again a simple mail <strong>for</strong>m is<br />
displayed over the schedule. If the user is a Bartender, a green button with the label<br />
"sign up" is displayed <strong>for</strong> all empty slots, a red "sign out" button is displayed in all<br />
slots the user has already signed up <strong>for</strong>, and a user name is displayed <strong>for</strong> all slots<br />
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<br />
important functions of the application. To further enhance clarity, changes to the<br />
schedule are immediately visible, instead of appearing after the page has reloaded, as<br />
is often the case in web-based applications. If the user is a Normal User, only<br />
bartender names are displayed in filled slots.<br />
The user in<strong>for</strong>mation component (under the calendar component on the left) displays<br />
user in<strong>for</strong>mation such as name and role, as well as a "log out" link. A link was used<br />
instead of a button, because in logging out the user navigates to a page away from the<br />
application - all other buttons have effects within the application. If the user is a<br />
Bartender, there is a button labeled "view all of your shifts", which, when clicked<br />
upon, causes an overview of all the users entries in the bar schedule database to be<br />
displayed (again on top of the bar schedule) so the user does not have to view every<br />
week seperately to see if he or she has signed up <strong>for</strong> a shift.<br />
4 Results and Evaluation<br />
The evaluation went smoothly, the main reason <strong>for</strong> this is that the system is almost<br />
finished. Logging in was easy, although I found out that my data in the Catena<br />
database wasn’t filled in correctly. The weekview looks really good and is easy to use.<br />
The monthview made it very easy to select a different week. –Pim, experienced<br />
bartender<br />
The presentation raised two big questions. The first one was about our<br />
weeknumbernavigation just above the weekview. Remarks about confusion with the<br />
monthnavigation on the left side of the interface were taken into consideration and we<br />
removed the navigation on top of the weekview and moved all navigation in the<br />
calendarlike monthnavigation, wich now also includs week selection. The second<br />
question was about the fact that you had to fill in your name if you wanted to<br />
subscribe <strong>for</strong> a barshift, this when you were already logged in and your name is<br />
known by the system. This was a good remark and that’s why we just made a<br />
subscribe-button, wich fills in your name automatically.<br />
The questions at the presentation influenced our design positively. The evaluation<br />
didn’t really help us, it just made sure we made a good system.<br />
5 Conclusion<br />
We are very happy we succeeded in making a simple system with a great overview on<br />
barshifts, despite all the functionality the system has. Ofcourse we ran into some<br />
problems, but that’s just part of the process. All problems were, in the end, fixed so<br />
we were able to turn in the project be<strong>for</strong>e the deadline.
6 Future Work<br />
There is room <strong>for</strong> some expansion in the system, <strong>for</strong> instance we could add a page <strong>for</strong><br />
subscribing to a cocktailbar shift or the daily mensa at Catena. Maybe the users of the<br />
system think of something nice to implement. Anyhow, the system has all the<br />
functionality the Barcomity expected, but there is always room <strong>for</strong> improvement.<br />
Appendix<br />
De interface
Police Academy :<br />
Training Tactical Actions<br />
of the Police<br />
By Eric Kuijl<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
erickuijl@tiscali.nl<br />
supervised by Sander van der Maar and Fons Verbeek.<br />
svdmaar@liacs.nl & fverbeek@liacs.nl<br />
Abstract. To make our society a safer place it is very important that police officers<br />
get good education and that they keep their knowledge up to date. I designed<br />
a program that makes learning and training easier <strong>for</strong> the police students<br />
and their supervisor(s). With this program police students –individually or in a<br />
team- can train their knowledge of the law and of police authority in a more<br />
motivating way than they are used to now. The fact that students can level the<br />
questions in difficulty and the fact team training can be done can be considered<br />
innovative in this area. After being reviewed by current police students the program<br />
seems to be quite useful and attractive to them.<br />
1 Introduction<br />
These days public safety is a hot item but lack of money and expertise resulted in<br />
chaotic and old fashioned ways of educating police officers. To support the authorities<br />
with educating their personnel in a better and more up-to-date way I thought of a system<br />
which gives police students the opportunity to train and update their knowledge.<br />
I created a program that police students (rookies or police officers who need to update<br />
their knowledge and/or update their skills after several years on duty) can use to learn<br />
specific knowledge so they know what to do in certain situations. These situations will<br />
be realistic situations which the police officer might run into during his daily work.<br />
The program can be used as training to test the knowledge of a police officer individually<br />
but also <strong>for</strong> <strong>for</strong>mal evaluating of police officers (exam).<br />
In this paper the general background of the current situation is described as well as the<br />
users involved. Furthermore I describe my solution to the problem,. the program and<br />
the evaluation with potential users. I conclude this paper with possible discussion topics,<br />
conclusions and possible future work.<br />
1
2 Background and problem definition<br />
2.1 Background<br />
Since I work daily with police officers and police students I noticed a lot of those police<br />
students and officers being unhappy with the current situation regarding police education.<br />
At this moment education methods specifically focused on gaining knowledge<br />
of the law and police authorities on the street is very outdated. Police students have to<br />
work with questions on paper (mostly multiple choice questions) and studying in<br />
books. Since I think it is very important that police officers are well educated I<br />
thought of ways of improving the way police students can learn the law and police authorities.<br />
A safe society is partly a result of well educated police officers!<br />
There are other developments regarding police education but they do not focus on<br />
knowledge gaining but more on specific skills. For example the police already use<br />
shooting simulators <strong>for</strong> teaching police students when and how to use fire arms. These<br />
skills are labeled as ‘competences’ by the Dutch police academy. Knowledge gaining<br />
is mostly done by the police students in their own time and during lectures. They only<br />
visit the police academy to visit lectures, to learn skills (competences) and to do exams.<br />
As stated earlier the problem is mostly experienced by the police students themselves.<br />
They want to have a better way to gain knowledge necessary <strong>for</strong> police work and to<br />
pass the exams of the police academy.<br />
2.2 User analysis<br />
The user group consists of male and female police students and supervisors. Most of<br />
the police students just started with the police education and have an age between 18<br />
and 30 years old. Also older police officers would want to train long <strong>for</strong>gotten knowledge.<br />
The age of these officers will be between 45 and 60 years old. The police students<br />
with lower ages usually have more experience with computers but most of the<br />
older officers will not have that much experience in computer use. All of these users<br />
are familiar with using simple computer desktop environments (like word processing)<br />
since that is necessary <strong>for</strong> basic police work. For a large part of the users this is almost<br />
the only thing they do with computers so the interface must be usable with the<br />
greatest ease.<br />
The student supervisors will only use the program to add or delete questions or categories,<br />
to create exams and to do other administrative tasks. The supervisors will<br />
mostly be older than 30 years old since you can only become a supervisor when you<br />
are an experienced police officer yourself.<br />
2
3 Police training<br />
3.1 General<br />
Since I focused primarily on the police students gaining knowledge I had to find a way<br />
to make them learn easily and quickly. This should also be possible at another place<br />
than the police academy <strong>for</strong> instance the home of the police student since the police<br />
academy states that studying in own time is important.<br />
I chose to trans<strong>for</strong>m the original pieces of paper with multiple choice questions to a<br />
computer program in which the police student has to answer multiple choice questions<br />
of a specific category like arresting suspects, traffic, using violence et cetera. These<br />
questions are chosen randomly by the program and the student can –after answering<br />
the question- chose a difficulty level to evaluate that specific question. If he thinks that<br />
this question was very difficult the program will ask the student more questions about<br />
that specific subject and/or repeat that question later on in training. I chose this approach<br />
because by using the difficulty level the police student can easily train himself<br />
and find the gaps in his or her knowledge and train that specific topic more often. Also<br />
training <strong>for</strong> an exam of a certain category can easily be achieved. If the student chooses<br />
the wrong answer a message will be showed that the answer he chose is the wrong<br />
answer. If the police student gives the correct answer a sound will be played and an<br />
explanation will be showed why the answer is correct. By using this method the student<br />
does not only know that he answered the question correctly but also knows some<br />
more of the why and how and eventually learn theory without a lot of reading from a<br />
book.<br />
I also thought of implementing a team aspect in the program. It seems quite useful to<br />
train team capacities with a program which students can use in their own time. This<br />
can be achieved by sketching situations in which the student works together with other<br />
people and has to make decisions within the team. The program can be used on a computer<br />
network at the police academy but this might also be possible from the student’s<br />
home using the Internet to communicate with other students.<br />
Another option in the program is an exam mode. The students can log into the system<br />
and do an exam made by the supervisor. This time they do not have the possibility to<br />
level the question in difficulty and all the questions are time driven since police officers<br />
also have to make these choices on the streets quickly.<br />
The last option in the program is the administration mode <strong>for</strong> the supervisors. In this<br />
mode a supervisor can select questions he wants to ask the students at an exam, add<br />
and delete questions from the database and other administrative tasks.<br />
3
3.2 Requirements<br />
The program should be very approachable, as the intended goal is to learn, and nothing<br />
in the interface should be anyhow directing away from this goal. There<strong>for</strong>e the<br />
user-interface is Windows based of which police students are all familiar with. Also<br />
the user-interface is usable as simply as possible without losing essential functionality.<br />
The program should work intuitive so that a student does not need much time to understand<br />
what is on his or her screen. This means that the student does not need a lot<br />
of explanation or help from someone else when using the program. Like this all police<br />
students will be able to work with the system and feel com<strong>for</strong>table using it.<br />
4 Results and Evaluation<br />
4.1 Presentation of paper design<br />
During the presentation of the paper design <strong>for</strong> my fellow students I took note of some<br />
comments and suggestions they had. One of the comments was that the logo of the<br />
system was quite big and distracting because of the colors used. I agreed with that<br />
comment and I made the logo a bit smaller and less fancy so the attention of the user<br />
would stay at the question part of the screen.<br />
Another suggestion was to look at the time it takes <strong>for</strong> the user to answer a question to<br />
see if the user does not know the answer and just takes a gamble. Since I did not really<br />
saw the purpose of implementing such a thing in this program I did not agree. The system<br />
is meant <strong>for</strong> the police student who needs to train <strong>for</strong> an exam and he is not saved<br />
by a system who tracks it if he takes a gamble. Also during an exam the correct answer<br />
counts, disregarding if you take a gamble or not. So I did not implement this in the<br />
program.<br />
After the presentation a discussion started between me and some of the students about<br />
the team training part of the system. Fellow students thought that it would be a good<br />
idea to make it scenario based. After discussing this idea with police students later on<br />
it became clear that team training is done in real life with actors and that this part of<br />
police education is something of which most police students are fairly happy with. According<br />
to some of the police students it could be possible to implement team play in<br />
the program but then it should be presented as a (theoretical) preparation <strong>for</strong> actual<br />
team training. It was clear that most of the police students think that especially gaining<br />
theoretical knowledge is the most important part which can be improved compared to<br />
the current educational methods. Since it is not very clear if team training is really<br />
something the police students want and because I did not have sufficient time <strong>for</strong> implementing<br />
it within this project, I decided to not implement a team training part in<br />
this system but keep it open <strong>for</strong> future discussion. It will be mentioned in the prototype<br />
but is not available (yet).<br />
4
4.2 Evaluation of paper design<br />
With the first user evaluation I wanted to get feedback from the evaluator concerning<br />
the learning process used in the program, the layout of the screens, the colors used in<br />
the screens, the questions asked to the user in the program, the specific texts used in<br />
the program and interaction possibilities. I wanted the evaluator to look at the screens<br />
and think aloud about good and bad things he saw or thought. I was seated next to the<br />
evaluator and wrote down what he said. I took note of the physical reactions of the<br />
evaluator (<strong>for</strong> instance expression on the face) and wrote that down. Images of the<br />
screens can be found in Appendix A.<br />
The evaluator was a male person between 25 and 30 years old and was at that moment<br />
a student at the Dutch police academy. He just started his 2 nd year at the police academy<br />
and had basic knowledge about computers (word processing) and using the Internet.<br />
The first reactions of the evaluator were positive. He thought that the screens looked<br />
professional and nice. He did have some suggestions to make the screens more user<br />
friendly and police officer proof. For example he said that during training time driven<br />
questions are not needed since it is training; during exam time driven questions might<br />
be an option. He also thought that it is a bit strange that a Dutch program has an English<br />
name (which at that time was ‘Open Learning Environment <strong>for</strong> Law Agencies<br />
aka OLELA) so he suggested to use a Dutch name <strong>for</strong> the system. He promised to give<br />
me a list of questions and answers that are used at the Dutch police academy. I agreed<br />
with his comments. Eventually I changed the name of the system into Training Tactisch<br />
Optreden Politie (TTOP) (In English : Training Tactical Actions of the Police).<br />
4.3 Evaluation of prototype<br />
The second user evaluation took place with the same evaluator. With the second evaluation<br />
I wanted to get feedback from the evaluator concerning the usability of a working<br />
prototype. There<strong>for</strong>e I used a questionnaire in which the System Usability Scale<br />
(SUS) is used. I showed the evaluator a set of questions and the evaluator had to give<br />
a value to different parts of the prototype. After having the evaluator work with the<br />
prototype and after he answered the questions we had a personal conversation about<br />
things that the evaluator was not able to answer in the questions. It is possible that the<br />
evaluator had more comments than was arranged <strong>for</strong> in the questions so with the free<br />
discussion the evaluator got the opportunity to give that specific feedback.<br />
First of all the SUS questionnaire gave a result of 9.5 which shows that the evaluator<br />
is very enthusiastic about the usability of the prototype. Since the evaluator also did<br />
evaluation 1 it might be wise to let some other evaluators fill in the questionnaire as<br />
well. There might be change there since these evaluators are totally new to the prototype.<br />
Since not enough time was available within this project more questionnaires can<br />
be done at a later time. The SUS questionnaire filled in by the evaluator can be found<br />
in appendix B.<br />
5
Secondly the evaluator had some comments like the fact that it would be more attractive<br />
to show the grading of difficulty of the question after the questions has been answered.<br />
Like that focus will change more clearly from the question to grading the<br />
question. He also thought that it is better if more explanation is given why the answer<br />
the user gave is correct. Also he added that it would be useful if the user can chose be<strong>for</strong>ehand<br />
which category he wants to get questions from. He said that it would also be<br />
nice if the user can choose more than one category or simple choose all of them. And<br />
again, I agreed with these comments.<br />
I did not agree with his comment that after answering a question you should not immediately<br />
see if the answer is correct or not. I think it is clear that a person first thinks<br />
about the question be<strong>for</strong>e answering it so be<strong>for</strong>e answering the question the user<br />
should always make up his mind. Since it is training and not an exam it is not a disaster<br />
when the user at the first question makes this kind of mistake. After that it is clear<br />
to him how it works and will not make the same mistake again.<br />
During the discussion –while talking about education at the Dutch police academy- I<br />
decided to not implement sounds in the system. The computers at the police academy<br />
are in one computer room so the use of sound would be very annoying <strong>for</strong> other people.<br />
Also most computers at the police academy are not equipped with headphones or<br />
speakers.<br />
5 Conclusion and Discussion<br />
As a conclusion I can say that the police student I had contact with, was very happy<br />
with the TTOP system. He thought that the design was clear, good color use (blue<br />
background as ‘police color’) and a professional look. He felt com<strong>for</strong>table using the<br />
system and he thought that he would use a final version of the TTOP system in the future.<br />
The SUS result of 9.5 underlines this conclusion.<br />
Looking back at the evaluation moments it is clear that these moments have been very<br />
valuable <strong>for</strong> developing the TTOP system. Lots of time you –as the designer of the<br />
program- think about things from your own point of view. You think of what a user<br />
might think of the several aspects of the system but it is much better to ask the users<br />
themselves.<br />
The comments and suggestions given by fellow students and the evaluator regarding<br />
the prototype were very useful and I agreed with most of them. It also opened discussions<br />
and made me think about specific parts of the system in a more detailed way.<br />
For example the team training part of TTOP seemed quite simple to me in the beginning<br />
but turned out to be much more complex. Together with police students I could<br />
not find a good way how to implement such a thing and there wasn’t even consensus<br />
about a team training part being useful.<br />
6
6 Future Work<br />
In the future some more work can be done related to the team part of the system. Research<br />
can be done to see how team training works at the Dutch police academy at this<br />
moment. With that in<strong>for</strong>mation and in cooperation with potential users it might be<br />
possible to determine if and how team work can be attached to the TTOP system.<br />
Also some more user evaluations can be done (like the SUS questionnaire) to gain<br />
more insight views about the usability of the TTOP system according to new potential<br />
users.<br />
References<br />
1. Bevan, N, Kirakowski, J and Maissel, J, 1991, What is Usability?, in H.-J. Bullinger,<br />
(Ed.). <strong>Human</strong> Aspects in Computing: Design and use of interactive systems and work<br />
with terminals, Amsterdam: Elsevier.<br />
2. Brooke, J. SUS – A quick and dirty usability scale.<br />
3. Dix, A., Finlay, J., Abowd, G.D., Beale, R. <strong>Human</strong>-<strong>Computer</strong> <strong>Interaction</strong> (3 rd edition,<br />
2004).<br />
4. Kirakowski, J and Corbett, M, 1988, Measuring User Satisfaction, in D M Jones and<br />
R Winder (Eds.) People and <strong>Computer</strong>s IV. Cambridge: Cambridge University Press.<br />
5. Pratchett, T., 1990 Moving Pictures. London: Gollancz<br />
7
Appendix A<br />
8
Appendix B<br />
SUS Questionnaire<br />
1. I think that I would like to<br />
use this system frequently<br />
2. I found the system unnecessarily<br />
complex<br />
3. I thought the system was easy<br />
to use<br />
4. I think that I would need the<br />
support of a technical person to<br />
be able to use this system<br />
5. I found the various functions in<br />
this system were well integrated<br />
6. I thought there was too much<br />
inconsistency in this system<br />
7. I would imagine that most people<br />
would learn to use this system<br />
very quickly<br />
8. I found the system very<br />
cumbersome to use<br />
9. I felt very confident using the<br />
system<br />
10. I needed to learn a lot of<br />
things be<strong>for</strong>e I could get going<br />
with this system<br />
Strongly Strongly<br />
disagree agree<br />
X<br />
X<br />
X<br />
X<br />
X<br />
X<br />
1 2 3 4 5<br />
1 2 3 4 5<br />
1 2 3 4 5<br />
1 2 3 4 5<br />
X<br />
X<br />
1 2 3 4 5<br />
1 2 3 4 5<br />
X<br />
1 2 3 4 5<br />
1 2 3 4 5<br />
X<br />
1 2 3 4 5<br />
1 2 3 4 5<br />
9
Seek the thrill<br />
Fee Yun Wong, Kees Koffeman, Maja Jakóbik<br />
LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
fwong@liacs.nl, kees@koffeman.net, mjakobik@yahoo.com<br />
supervised by Mounia Belmamoune<br />
mounia@liacs.nl<br />
Abstract. An existing non-commercial website <strong>for</strong> searching in<strong>for</strong>mation about<br />
the items on the book list of Vrij Nederland is redesigned during our project.<br />
The very valuable in<strong>for</strong>mation should be found and presented in an easier and<br />
more attractive way. Splitting the in<strong>for</strong>mation and functionality over a number<br />
of tabs and using different kinds of search methods makes our site different<br />
from the old one. It also differs from the most commercial sites. Hopefully it is<br />
easier to use and more attractive <strong>for</strong> the users. Moreover the maintenance site<br />
has taken into account and made consistent with the site <strong>for</strong> search engine.<br />
1 Introduction<br />
Vrij Nederland (VN) is a Dutch weekly magazine featuring critical articles on current<br />
events and unveiling interviews. Political issues, national and world news, business,<br />
society and so on are discussed in the magazine. Since 1980 VN has been releasing a<br />
detective and thriller guide which is an extensive list of titles obtainable in Dutch,<br />
every summer. The 27 th edition has been published on 2006 June 3.<br />
A database <strong>for</strong> the list of detectives and thrillers has been set up by W. A. Kosters<br />
and H. J. Hoogeboom. Its interface design must be improved, as it is not very user<br />
friendly. A lot of in<strong>for</strong>mation has been gathered on one page which makes the website<br />
visually and its usage not pleasant. To solve this problem the product is renewed and<br />
evaluated in order to build a basis <strong>for</strong> further development in the future.<br />
2 Redesigning an existing website<br />
As the in<strong>for</strong>mation in the database is very valuable, the makers of the site would like<br />
to strive <strong>for</strong> as many visitors as possible. We have investigated another approach to
make the site easier and more attractive, what hopefully results in an increasing<br />
popularity of the site.<br />
The present site gives too much in<strong>for</strong>mation on one page. The structure of the<br />
in<strong>for</strong>mation is not very clear which makes it confusing. The legibility of the text is<br />
very low. Besides that the combination of the used colors makes the interface not very<br />
appealing.<br />
On the other hand, we have taken a look at the commercial sites, like<br />
www.kooyker.nl, www.bol.com, or www.amazone.co.uk.<br />
All of them concentrate on giving as much in<strong>for</strong>mation at once as possible.<br />
Trying to catch the visitors’ attention <strong>for</strong> promotions and bestsellers which ends up in<br />
an interface full of in<strong>for</strong>mation, many colors, flicking text, pictures and animations.<br />
The search part of their sites is quite the same – an area with a few fields to fill in the<br />
search criteria surrounded with all the other distracting in<strong>for</strong>mation.<br />
It is very difficult to determine what is easy and attractive <strong>for</strong> a very large and<br />
much differentiated group of people. We cannot concentrate on only the gender, age,<br />
religion or skin color. We merely know that our users can read Dutch (or came on our<br />
site by accident and will not stay <strong>for</strong> long) and are interested in reading, especially in<br />
thrillers and/or detectives. The rest of the characteristics we can only guess.<br />
The maintenance of the database is also very important. It still has to be done by<br />
retyping the in<strong>for</strong>mation from the list published by VN. Assistance during this<br />
important yet dull task should be given, so there will be less chance of errors and<br />
faster to recover them.<br />
This task is done by an expert in computer science and a frequent user of the<br />
Internet. The work of a data typist is not a task which can hold his interest <strong>for</strong> long,<br />
thus it must be done quickly and efficiently. More time and energy can then be put in<br />
searching <strong>for</strong> other in<strong>for</strong>mation such as interesting facts about the concerning authors,<br />
titles, movies based on the books etc.<br />
3 Seek the thrill<br />
As we are not designing a commercial site, we do not have to catch the users’<br />
attention <strong>for</strong> the best selling titles or the lowest prizes (figure 1). We can concentrate<br />
on providing a few good approaches <strong>for</strong> searching, as we expect it could be<br />
interesting <strong>for</strong> the users. In addition splitting the background in<strong>for</strong>mation from the<br />
search functionality and splitting the different search approaches supply the user more<br />
rest and it is still easy to reach and to find (figures 4, 5, 6, 7, 8 and 9).<br />
Keeping it simple makes the site easy to use, even <strong>for</strong> new visitors. We had to<br />
make assumptions that the user will know a few basic things. When you would like to<br />
search <strong>for</strong> books of a particular author, you will probably be asked to type in his/her<br />
Seek the thrill 2
name. And that will be probably on a tab or a field with text “Author” as description.<br />
An idea of tabs is also assumed as broadly known and used one.<br />
The user is free to choose the way he wants to search <strong>for</strong> in<strong>for</strong>mation. Whether all<br />
titles of a particular author are desired or more search criteria are expected, it is<br />
possible and easy to find. Because of this our search engine provides users a lot of<br />
flexibility.<br />
As we provide the user with a lot of lists, we prevent the user <strong>for</strong> making mistakes.<br />
Naturally a slip is still possible (e.g. selecting a wrong item in the list which was in<br />
the neighbourhood of the desired item), but it is easy to recover and gives the user a<br />
clear view of the possibilities. He can efficiently give the criteria <strong>for</strong> searching by<br />
genre, period or series.<br />
The attitude is the most subjective usability aspect. How do you make sure your<br />
users will not become frustrated or bored when using your site? What to do to let<br />
them keep visiting it again? How to make sure they feel com<strong>for</strong>table, interested and<br />
satisfied? We must think about aesthetics as much as about the correct working<br />
program. We have chosen <strong>for</strong> rest, survey ability and easiness. Soft colors, not too<br />
much text on one tab, no flicking or moving objects – that is our approach. We hope<br />
that the users will not miss those aspects and that the provided in<strong>for</strong>mation with extra<br />
interesting facts will keep the attention.<br />
On the other site a person will do the maintenance task. This part is secured by a<br />
login (figures 10, 11, 12 and 13). The rest of this site is kept quite consistent with the<br />
search part. The different approaches are on different tabs, lists are provided where it<br />
is possible. The possible errors should be easy to recover.<br />
4 Results and evaluation<br />
The first prototype has been evaluated by a few persons. We concluded that dividing<br />
the in<strong>for</strong>mation over tabs and giving the different search approaches especially, were<br />
found both attractive and easy to use. Based on the reactions of our testers we think<br />
that learnability and flexibility targets has been met. The fact that no mistakes were<br />
made, suggests that also efficiency is satisfied. But the attitude still asks <strong>for</strong> more<br />
attention. Our testers found the site boring and sober. The colors were not vivid<br />
enough. Moreover the impression of the presentation of the results of search part was<br />
called not well-organized. Our second prototype deals with the question of colors but<br />
we have found it very difficult to present the search results in a different way. The<br />
in<strong>for</strong>mation is very difficult, perhaps even impossible to structure as it contains a lot<br />
very different aspects and facts.<br />
For the maintenance we used the walk-through evaluation method with talking<br />
aloud. Our conclusion was that the site is easy to learn and to use. Here, other aspects<br />
of usability are important. The feedback of actions, not loosing the track of actions,<br />
Seek the thrill 3
finding and correcting the made errors are as much important as making it both easy<br />
and efficient as possible.<br />
5 Conclusion and discussion<br />
As we got through the possible tasks and the analysis of the users, we found it quite<br />
easy to find a good surveyable way <strong>for</strong> implementation. Functionality, especially <strong>for</strong><br />
the search part, is quite easy and mostly already exists. But we still have difficulty<br />
with finding the satisfactory balance between de boring rest and screaming vivacity.<br />
We as designers found that soft and bright colors are better fitting, but our testers<br />
found it boring and sad. The same story applies to the maintenance part. We wanted<br />
to emphasize the feedback of success or failure of the taken actions, but using red and<br />
green makes it very sharp, especially in contrast with the sober background we prefer.<br />
You do not want to look at it longer than <strong>for</strong> a few moments.<br />
Another interesting point of discussion is the presentation of the search results.<br />
Now the testers found it very chaotic. At the first impression it is ordered by author,<br />
indented <strong>for</strong> titles, but after that there is a lot of different in<strong>for</strong>mation about a book,<br />
which is very difficult to present in a different and more structured way. And yet the<br />
same story holds <strong>for</strong> maintenance. How to make it easy and surveyable to get as much<br />
structure as possible when inserting all those in<strong>for</strong>mation? And how to make it a more<br />
attractive task? After all it is data typing, not really a creative task (and it will stay this<br />
way, as long as there will be no other way of input, like an electronical file is handed<br />
over by VN, which perhaps needs just inserting some extra in<strong>for</strong>mation). Even<br />
searching <strong>for</strong> extra in<strong>for</strong>mation or struggling with names and original titles in strange<br />
languages makes it not very exciting task to do.<br />
6 Future work<br />
The design of the site gives space <strong>for</strong> future additions and changes. As we have seen,<br />
some ideas to make the site more fun can be explored. Perhaps the pictures of covers<br />
by the titles (or when “boring” cover, a picture from the book) could be added.<br />
Perhaps more and different search criteria could be provided. A bit of data mining<br />
could be done, by presenting the top 100 most searched titles or most appreciated<br />
titles by readers. The possibility to give an own opinion about titles could be made<br />
and the results analyzed. And the open issues from this moment could be solved.<br />
There could be also an extending <strong>for</strong> DVD, CD-ROM etc., but this part depends<br />
more of what plans has VN.<br />
Seek the thrill 4
References<br />
1. Search prototype, http://koffeman.net/hci/2/<br />
2. Maintenance prototype, http://www.koffeman.net/hci/2/admin/<br />
3. Dr. Ir. Fons J. Verbeek: <strong>HCI</strong> <strong>Practical</strong> Assignment, LIACS (2006)<br />
4. Dr. Ir. Fons J. Verbeek: <strong>HCI</strong> Lecture slides, LIACS (2006)<br />
5. Alan Dix et al.: <strong>Human</strong> <strong>Computer</strong> <strong>Interaction</strong>, 3 rd edition, Pearson-Prentice Hall,<br />
(2003)<br />
6. VN Detectives en Thrillergids … 10000 titels,<br />
http://www.liacs.nl/~kosters/vnster.html<br />
7. Vrij Nederland VN, http://www.vn.nl/vn/show<br />
8. Kooyker site, http://www.kooyker.nl<br />
9. Amazone site, http://www.amazone.co.uk<br />
10.Bol.com site, http://www.bol.com<br />
Appendix<br />
Search part<br />
Figure 1: Home<br />
Seek the thrill 5
Figure 2: Help<br />
Figure 3: Contact<br />
Seek the thrill 6
Figure 4: Search title<br />
Figure 5: Search author<br />
Seek the thrill 7
Figure 6: Search genre<br />
Figure 7: Advanced search<br />
Seek the thrill 8
Figure 8: Browse<br />
Figure 9: Quick search<br />
Seek the thrill 9
Maintenance part<br />
Figure 10: Login<br />
Figure 11: Author main screen<br />
Seek the thrill 10
Figure 12: Edit author<br />
Figure 13: Add new author<br />
Seek the thrill 11
Whiteboard<br />
Kerem Denizmen, Sjoerd Kranendonk<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
kdenizme@gmail.com, sjoerd.kranendonk@gmail.com<br />
supervised by Yun Bei, Fons Verbeek.<br />
ybei@liacs.nl & fverbeek@liacs.nl<br />
The Whiteboard project was conceived specifically <strong>for</strong> the liacs faculty to provide<br />
a uni<strong>for</strong>m structure <strong>for</strong> every course website, unlike blackboard, focusing<br />
more on the interface than on functionality. The main goal of the project was to<br />
incorporate an easy to understand structure <strong>for</strong> student to per<strong>for</strong>m there school<br />
tasks and gather in<strong>for</strong>mation about the course and its content. The innovation<br />
that Whiteboard brings is more the sum of its parts then a single idea, the cupboard<br />
structure, tabs and Q&A sections all contribute to this. We have shown<br />
that there are much more pleasant interface alternatives to blackboard and that<br />
data can be nicely organized so that it can be used <strong>for</strong> every course.<br />
1 Introduction<br />
The Leiden university incorporates a data organization website called Blackboard<br />
[1], where course sites and other functionality are gathered in a uni<strong>for</strong>m way <strong>for</strong> the<br />
students. The interface of Blackboard course sites were in our opinion lacking in<br />
organization and interface design while incorporating many (useful) functions. Also,<br />
the liacs (Leiden institute of advanced computer science) [2] faculty members don’t<br />
use the blackboard as there portal <strong>for</strong> course sites but rather use there own websites<br />
<strong>for</strong> course data, which results in different websites <strong>for</strong> every course with some being<br />
better than other. The Whiteboard project was conceived to offer a better alternative<br />
to Blackboard course websites, and also unifying the structure of the liacs faculty<br />
course sites. In general, our approach to the problem was very user centered, what<br />
would the students like to see on the course sites, and what are the most used features<br />
of a course site that students use. Combined with suggestions from teachers, we believe<br />
we achieved our goal of offering a basis <strong>for</strong> liacs course website design. Our<br />
paper will discuss the methods used <strong>for</strong> Whiteboard website organization and overall<br />
approach to the problem of organizing course data.
2 “Short Subject Background and problem definition”<br />
The Whiteboard project was not meant to be a groundbreaking innovation, but more a<br />
guideline <strong>for</strong> how course data organization should be handled <strong>for</strong> the liacs faculty.<br />
Other goals of our project was to make students more efficient(and feel more pleasant)<br />
with using course sites and give teachers a nice framework to organize there data.<br />
Uni<strong>for</strong>m course data organization can be difficult because there are many different<br />
courses with different requirements <strong>for</strong> every course. Because of this, there should be<br />
clear categorization between various course needs. A uni<strong>for</strong>m course website should<br />
address all these needs in the basic design, even though it will probably not be used<br />
by some courses. Categorizing various course needs was one of the most difficult part<br />
of the Whiteboard project, this was because we wanted the site to be elegant and<br />
simple, yet incorporating everything that all teachers need <strong>for</strong> there courses. The look<br />
of the site was also made to feel more pleasant than that of Blackboard, because we<br />
feel that this is also important in motivating students to use the course sites more, and<br />
of course to give a more professional feel to the liacs faculty.<br />
3 Tabs, cupboards and style.<br />
The General idea <strong>for</strong> Whiteboard was that students could find data efficiently and<br />
prevent the screen from being cluttered. The look of the site was also one of the main<br />
subject we paid attention to, with the intention of it being simple yet elegant. We<br />
intentionally kept the site simple and didn’t want it to have very much functions like<br />
Blackboard, we felt that this could be confusing and a lot of the features would probably<br />
not be used.<br />
Our approach to the look of the site has been consistent with what we want to achieve,<br />
and attractive looking site which is <strong>for</strong>mal yet functional and doesn’t have unnecessary<br />
colors or other paintjobs. We didn’t want to fill the screen with too much text<br />
either cause this can hurt the design [3]. The design was meant to be more appealing<br />
to the students (the younger generation), although it can surely be improved, the<br />
established look of the site is certainly better than we expected.<br />
3.1 General design:<br />
Our main approach to data organization in course websites were tabs. This was<br />
mainly because we needed a good solution to categorize the main topics found in<br />
course websites. The tabular approach gave the students a more efficient way to navigate<br />
the course site and also gave the course site more style than other alternatives.<br />
The tabs were designed to have a good visibility (big) while not being distracting <strong>for</strong><br />
the student, also, we wanted the tabs to look good but not distract, so we chose <strong>for</strong> an<br />
“apple” look <strong>for</strong> our tabular structure.<br />
The tabs categorize the course site in many different subjects. The subjects that are<br />
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<br />
cupboard metaphor. Students can open each of the cupboards and take out data, the<br />
cupboards close when another cupboard is opened, this to prevent clutter and to prevent<br />
making the page unnecessarily long. The cupboards are of course just big buttons<br />
(blocks) which can be clicked, when clicked, they open up and a field appears in<br />
front of the user, which can hold links, text or pictures. This approach of cupboards<br />
resulted in a compact site where very little scrolling has to be done to get in<strong>for</strong>mation.<br />
We felt that by keeping everything compact with tabs and cupboards, the user would<br />
be able to be more efficient than on Blackboard. The cupboard metaphor is consistent<br />
within all course pages and this makes navigating the site much easier. The cupboard<br />
does have disadvantages of course, in some instances it can be useful to have data<br />
organized in a table which we have done with the schedule. The schedule is more<br />
clear in a table <strong>for</strong>m because one can see the complete schedule with one look at the<br />
page. If we had tried to be fully consistent with all pages, we would have traded off<br />
ease of use <strong>for</strong> consistency but we decided that consistency was not important enough<br />
to dismiss ease of use in this particular instance.<br />
New announcements are presented to the user in a red box so that it catches attention.<br />
This could of course be expanded later on so that the teacher can decide which color<br />
the announcement will appear. We wanted new announcements to appear at the top of<br />
each page, and that they were disposable. By clicking on the x button, the announcements<br />
can be discarded and can be alter found on the news page.<br />
The Quick jump buttons were intended <strong>for</strong> pages that stretch longer than the current<br />
page size. To prevent scrolling, the quick jump buttons were implemented so that the<br />
user can jump to a cupboard in an instance. Even though it is meant <strong>for</strong> long pages,<br />
we found that this feature was also used a lot on single screen pages, so it also ads<br />
flexibility in the way the user wants to interact with the site.<br />
3.2: catogories<br />
One of the more difficult parts of the design was to categorize the different headings<br />
and also the cupboards. Many changes have been made to the category part of Whiteboard.<br />
As mentioned earlier, we categorized the main headings into General, News<br />
Lectures, Schedule, Lab, Practice, and Q&A tabs. Cupboards within the tabs were<br />
also categorized, with most being straight <strong>for</strong>ward like course lecture numbers the<br />
General tab was the most difficult to categorize the cupboards as we didn’t want too<br />
much data in one cupboard, but we also didn’t want it to be near empty.<br />
The General page is the default page that loads up, here Students can see new announcements,<br />
course in<strong>for</strong>mation and contact in<strong>for</strong>mation, all organized in cupboards<br />
and clear headers. Links to emails are provided in the contact header.<br />
The news page is where all the past announcements are going to be placed, as of the<br />
writing of this report, it is still undecided how the in<strong>for</strong>mation is going to be presented,<br />
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<br />
<strong>for</strong>m because this seems to be the best way to present a schedule <strong>for</strong> a course. We<br />
decided to implement the schedule page after the implementations after we had some<br />
comments about how that was the best way to present schedules. The schedule has<br />
links to the lecture page, where students can download course files from that lecture<br />
and see general in<strong>for</strong>mation about the lecture. The schedule is meant to have a quick<br />
look at what is coming and what the topics are.<br />
The Lectures and Lab pages are the pages that the student will probably use the most,<br />
they contain the cupboard style and let students click on the cupboards to download<br />
lectures, papers and Lab work. Its pretty much consistent with the rest of the course<br />
site and there is nothing out of the ordinary about it.<br />
The Practice page is meant to be a page where the students test there knowledge and<br />
practice <strong>for</strong> the exams. Quizzes and exams are presented as links. When a student<br />
clicks on the Quiz links, they are sent to the corresponding quiz page which is again<br />
using the cupboard style of web design. Students answer questions in a multiple<br />
choice <strong>for</strong>mat and get the results of there quiz after they fill out all questions. The<br />
exam links send them to the exam page, which again complies to the cupboard style,<br />
this time in an exam question and answer <strong>for</strong>m. This was done intentionally so that<br />
students can see the answer to the corresponding question whenever they want on the<br />
same page. It is cumbersome to switch pages all the time to check the question and<br />
answer of the exams on some other liacs course sites. If the teacher wants, it could<br />
still link the exams to PDFs.<br />
In the Q&A page we wanted to give students feedback as to who answered the question<br />
and which questions are still pending. We decided to have pictures of the assistants<br />
and lecturer posted be<strong>for</strong>e every answer. This was because a picture can be very<br />
effective in quickly showing in<strong>for</strong>mation and is also handy <strong>for</strong> students to recognize<br />
there assistants/teachers clearer. Pending questions are hidden away in the bottom<br />
cupboard which students can use to see if they don’t ask questions that are already<br />
pending to be answered.<br />
4 Results and Evaluation<br />
The users that evaluated our prototype were all rather positive, this seems to be partly<br />
because of disliking the current systems (blackboard, liacs site), but the overall tendency<br />
is also positive about the prototype in particular.<br />
At the time of the first user evaluation there was not much to evaluate, except <strong>for</strong> the<br />
general look and feel of the design and a first evaluation of the cupboard' style of<br />
presenting in<strong>for</strong>mation. This evaluation was done with only the standard SUS <strong>for</strong>m.<br />
There was also not much to get out of the evaluations, <strong>for</strong> instance the fact that all<br />
three considered the prototype at that time somewhat inconsistent was probably because<br />
it was not nearly finished, but rather sketchy.
The second evaluations were done with more students (of different universities) and<br />
generated more results in terms of possible improvement. Overall this evaluation was<br />
also very positive, but we must consider that part of this is because all evaluators<br />
know (either of) us in one way or the other. For the results of this evaluation and the<br />
things we decided to implement be<strong>for</strong>e the final presentation please check the second<br />
evaluation report. Currently some of the changes have already been implemented but<br />
some have yet to be done.<br />
The things that are most visibly implemented in our solution (final prototype) are<br />
taken from the various comments we asked our evaluators to provide. We also received<br />
some usable advice in the 'open' comments. The way we set up evaluations<br />
gave us what we wanted: direct critical comments on specific aspects of the prototype<br />
and an overall grading of the prototype. This general grading was to see if we were<br />
on the right track or if certain tab categories needed more improvement than the others.<br />
We did not come up with new features on our own, but did implement some features<br />
we previously skipped, <strong>for</strong> instance the announcements. We originally had this in the<br />
design, but when we were told to focus and narrow down our functionality, it got<br />
(temporarily) dropped. It was mentioned in the evaluations so now it it implemented<br />
after all.<br />
Screen shots are as an appendix, but the prototype can also be visited at the test site<br />
[4].<br />
The feedback from the assistant was not always clear, but this may have in part been<br />
due to our project proposal and paper designs not being clear enough. This has however<br />
resulted in some loss of time in figuring out what was expected from us in various<br />
stages of the project. During the course of this project there were a few times<br />
where we were not sure to continue with our own proposal or to switch to a new,<br />
similar project, but our own proposal appealed the most to us so as you can see we<br />
stuck to it.<br />
From the start to the end there were some conceptual changes made. Initially we<br />
wanted to just make the student part of the site, with a part <strong>for</strong> logged in and a part <strong>for</strong><br />
not logged in visitors. Obviously the part <strong>for</strong> logged in users would have more functionality<br />
and customization options. After this proposal we were told to also think of<br />
the other user group, the teachers, since they have to provide all the data the students<br />
will want to use. Then after making a paper design concerning these three user groups:<br />
not logged in visitors, logged in students and logged in teachers, we were told to<br />
focus on one thing since it would be too much work to implement everything. This<br />
lead us to the design that is active on the a<strong>for</strong>e mentioned location [4]. The final prototype<br />
is just a proof of concept because it lacks login functionality, edit functionality<br />
and concerns just one course. Although the prototype is not fully functional we think<br />
as a proof of concept it is still successful, as the user evaluations have pointed out.<br />
The way of presenting all the course related data in a tabbed design in one page is<br />
liked by all evaluators, especially in contrast with the current situation of scattered<br />
data over various sources and pages (Blackboard, <strong>Liacs</strong> pages, PDF's etc.).
The usability requirements or specifications <strong>for</strong> the prototype are mostly unchanged<br />
since the paper design, with exception of the compatibility regarding web browsers.<br />
Internet Explorer is not supported in the final prototype, even if that is a much requested<br />
feature by the user group (since I.E. Is a browser that is often used). We have<br />
decided to focus (as stated in the evaluations) on the features and functionality of the<br />
site instead of making it fully compatible. From experience we know that everything<br />
we have done should be possible <strong>for</strong> both browsers and even <strong>for</strong> some more rare<br />
browsers. We have just chosen to use our time <strong>for</strong> the functionality instead of compatibility.<br />
The site is still usable with FireFox and a regular pc or mac with keyboard and mouse.<br />
5 Conclusion and Discussion<br />
From the evaluations and positive reactions to Whiteboard, it is clear that we made<br />
the right choices <strong>for</strong> uni<strong>for</strong>m course website design. Students would welcome a<br />
course in<strong>for</strong>mation structure that would present all related course data in one place<br />
and on virtually one screen. Preventing clutter and giving the site an appealing and<br />
simple look was one of our main goals <strong>for</strong> the project, and we had this planned even<br />
within the infancy phases of the Whiteboard project. The cupboard style, tabs and<br />
other functions all help in maintaining this view of simple and compact data organization.<br />
Although Whiteboard is not a project about adding lots of functionality like<br />
Blackboard, it still succeeds in implementing the necessary functions <strong>for</strong> students to<br />
enjoy there coursework. Whiteboard also intentionally left out functionality to keep it<br />
as simple as possible and prevent confusion. This project has no stand alone innovations<br />
but is more an innovation in the sum of its parts, and was meant to be a guideline<br />
<strong>for</strong> future liacs course site design. We feel that after the evaluations that our prototype<br />
is even more improved and functional, even if we had to drop a lot of features<br />
because of time pressure.<br />
6 Future Work<br />
Future work on Whiteboard could include better communications and more evaluations<br />
with the teachers to understand how they would like the site to be set up and<br />
what kind of topics it should encapsulate. Other useful work would be a message<br />
board, as we wanted to do this but had no time to finish it. Also we thought about<br />
certain options <strong>for</strong> users like turning off the closing cupboard functions and let them<br />
stay open when clicked on. We would have liked to spend more time on the announcements<br />
and the General page, so this could be a good beginning <strong>for</strong> future work<br />
on the site. The biggest improvement would be to make a backend of the site so that<br />
teachers could easily edit there site and put in content. Our beginning goal <strong>for</strong> our<br />
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<br />
<strong>for</strong> registered students, so that they could customize the functionality of the site and<br />
maybe personalize there site but again due to time constraints wasn’t implemented<br />
and left <strong>for</strong> future work.<br />
References<br />
1. http://blackboard.leidenuniv.nl/webapps/portal/frameset.jsp.<br />
2. www.liacs.nl<br />
3. <strong>Human</strong> <strong>Computer</strong> <strong>Interaction</strong> (3 rd edition) Alan Dix et al Pearson-Prentice Hall<br />
4. http://mffonline.com/whiteboard/ firefox only
Appendix: Screenshots<br />
(taken from http://mffonline.com/whiteboard, viewed in FireFox 2.0 <strong>for</strong> Mac)
Cargo Export Security Management Optimizer<br />
Eyal Halm 1 , David van Paesschen 1<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
eehalm@zonnet.nl, david.vanpaesschen@gmail.com<br />
supervised by Mounia Belmamoune<br />
mounia@liacs.nl<br />
Abstract. The security department of a cargo airline has the task to make sure<br />
no bombs are being flown disguised in commercial shipments. The supervisor<br />
of a security department has to manage each pallet through the appropriate<br />
security procedures be<strong>for</strong>e it is loaded onto the aircraft. Nowadays this complex<br />
and error-sensitive management task is done with the use of several sheets of<br />
paper. In order to make cargo export security management more efficient, safer<br />
and easier to handle we have developed a software tool named CESMO.<br />
Working with this tool has shown to be more efficient, less error-sensitive and<br />
very easy.<br />
1 Introduction<br />
Automation comes in degrees. In the most extreme <strong>for</strong>m, automation is making a<br />
certain process fully automated, i.e. the process will be no longer human-driven but it<br />
will be working completely on its own. In a much weaker <strong>for</strong>m, automation stands <strong>for</strong><br />
doing a particular piece of work normally done by hand, with the help of a computer.<br />
In many industrial branches there is a tendency <strong>for</strong> using fully automated processes as<br />
much as possible. Some tasks, however, we aren’t yet willing to hand over to the<br />
computer. Security procedures are typically tasks we don’t want to loose control of.<br />
In security it is of vital interest everything goes according to a well thought out, well<br />
defined plan. The supervisor of a security department has the difficult task to manage<br />
this. For such supervisors, the use of the computer as a tool can be more than<br />
welcome.<br />
1.1 Problem Introduction<br />
The security department of a cargo airline has the task to make sure no bombs are<br />
being flown disguised in commercial shipments. Shipments arrive from various<br />
places and will be exported on cargo flights. The security has to take care that no<br />
objects are being flown that can cause danger when an aircraft is in the air. At the<br />
head of the security department there is a supervisor, who is in control of all the<br />
procedures within the department. He has to be sure every shipment is fully checked
e<strong>for</strong>e it is loaded onto an aircraft. The job of a supervisor is one in which no<br />
mistakes are allowed; a small mistake can be fatal.<br />
Doing such a task by pencil and paper – taking into account that every piece of paper<br />
with important in<strong>for</strong>mation goes from hand to hand and that every security worker<br />
that fills in the papers, has his own handwriting – is asking <strong>for</strong> trouble. Using the<br />
computer to keep track of all the in<strong>for</strong>mation is not only more convenient, it is also<br />
more efficient, but most of all … much safer.<br />
In the security department one of the writers of this paper worked <strong>for</strong>, there is no<br />
good software system to assist the supervisor. Our aim was to develop a software tool<br />
<strong>for</strong> optimizing the management of a cargo export security department.<br />
1.2 Paper Outline<br />
The remaining part of this paper is divided in five sections (sections 2 – 6). In section<br />
2 we will explain the exact problem we wanted to solve, in context to its background.<br />
Furthermore we will describe what is done in a cargo export security department and<br />
we will analyze what a supervisor is like. In section 3 we show in detail our approach<br />
to solving the defined problem, our expectations and requirements. Section 4 yields<br />
the results of our developed solution and the evaluation of the intended users of<br />
CESMO. Also, we will discuss the development towards our solution and we will<br />
review our expectations and the usability requirements. Section 5 summarizes our<br />
findings and discusses the results. In the last section, section 6, we will look to the<br />
future and mention some future developments related to our research.<br />
2 Background and Problem Definition<br />
Cargo airlines are airlines dedicated to the transport of goods. These airlines are also<br />
threatened by terrorist attacks. As said earlier, the security department of such an<br />
airline has to make sure no bombs are being flown disguised in commercial<br />
shipments.<br />
2.1 Background of the Problem<br />
As the shipments arrive by truck to the export warehouse of the airliner, they are<br />
being thoroughly checked by the security department. The shipments are then being<br />
built on pallets – the basic units that are being loaded onto a cargo aircraft. The<br />
supervisor of the department has to take each pallet through the appropriate security<br />
procedures to make sure it is safe to load it onto the aircraft.<br />
Managing the whereabouts of every pallet is nowadays done with some lists of pallets<br />
on separate sheets of paper. The progress of the security handling <strong>for</strong> each pallet is<br />
updated in these lists. At a certain point an amount of about 50 pallets is assigned to a<br />
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<br />
board an aircraft.<br />
The current way <strong>for</strong> managing the security procedures of each pallet is quite<br />
complicated and is said to yield human errors every now and then. These errors<br />
usually have to be solved with last-moment remedies, which cause delays in<br />
exporting the pallets to their destination.<br />
Safety and speed are the two most important properties of a well-functioning cargo<br />
export security department. First of all, you have to be sure there are no bombs being<br />
flown in the shipments; it is clear that it is of vital interest that certain errors aren’t<br />
made. Second, you want to deliver the goods on time, which means that the security<br />
system has to be very efficient. The present-day method is not the most safe, efficient<br />
and easy way to manage the export security. With the use of a software tool it could<br />
be a lot more optimized.<br />
2.2 Problem Definition<br />
The problem we want to solve is quite clear:<br />
Design an easy-to-learn software tool to assist the supervisor of a cargo export<br />
security department to make his work more efficient, and more error-free.<br />
2.3 User Analysis<br />
CESMO is about to be used only by the supervisor of a cargo export security<br />
department. There<strong>for</strong>e we designed the interface purely to the qualities and needs of<br />
such a supervisor.<br />
I. A supervisor has at least a low-level experience with computers.<br />
II. Our user is a highly trained security worker and is fluent with all the security<br />
procedures that have to be followed in a process.<br />
III. Under his supervision are workers who per<strong>for</strong>m security tasks.<br />
IV. The supervisor has to be in complete control of the whereabouts of all the<br />
pallets in the system.<br />
V. Because a security department has to deal with many pallets and all these<br />
pallets have to be fully checked, a supervisor works under great pressure.<br />
Our tool will be used by supervisors only if it will introduce an improvement.<br />
There<strong>for</strong>e, we have to keep in mind what the innovation of the system is, what our<br />
intended users expect and what their motivation could be to use the tool.<br />
The main innovation would be that the software application frees the supervisor of<br />
paperwork by offering all the in<strong>for</strong>mation he needs on a single computer-screen. The<br />
intended user would at least expect more speed and efficiency, less errors and (if<br />
errors are made) an optimized error-handling. More efficiency, increased safety and<br />
lower workloads could be motivations to use the application.
3 Intuitive One-Screen Interface: From Paper to the Screen<br />
Because one of the most important demands of a supervisor is to have a quick and<br />
clear overview of where every pallet is and what their security state is at a particular<br />
moment, we decided to design a one-screen interface. The main tasks the new system<br />
assists are to obtain in<strong>for</strong>mation of a certain pallet quickly and to update the<br />
in<strong>for</strong>mation if required. CESMO keeps all the in<strong>for</strong>mation of all the pallets in the<br />
warehouse transparent and easy to update.<br />
3.1 Set-up of the In<strong>for</strong>mation Representation<br />
A certain pallet, let’s say x can be in one of the following three states:<br />
I. Pallet x is being on the way to the warehouse.<br />
II. Pallet x is being present in the warehouse.<br />
III. Pallet x is being loaded onto an aircraft.<br />
When a pallet is on the way to the warehouse it is already known if the pallet is<br />
immediately RTF (Ready to Fly) or first needs a long security program (LP). (This is<br />
also true <strong>for</strong> pallets that are being built in the warehouse itself.) So, pallets that are on<br />
the way can be subdivided in two lists:<br />
Ia. Needs LP<br />
Ib. Is RTF<br />
In the warehouse, a pallet can still have the status of needing LP or of being RTF.<br />
Pallets that run in a long security program are checked in pressure tanks. Let’s say<br />
there are two tanks, a new and an old pressure tank (respectively NPT and OPT). The<br />
pallets in the warehouse are in one of the following four lists:<br />
IIa. Needs LP<br />
IIb. Is being checked in NPT<br />
IIc. Is being checked in OPT<br />
IId. Is RTF<br />
When a pallet is RTF is can be assigned to one of the cargo flights. If a cargo airline<br />
has a maximum of three flights at a certain time, a pallet can be assigned to one of<br />
these flights. So, in the last state there are three lists:<br />
IIIa. Is assigned to flight 1<br />
IIIb. Is assigned to flight 2<br />
IIIc. Is assigned to flight 3<br />
To be able to show all the possible in<strong>for</strong>mation on one screen we just needed nine<br />
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 <strong>for</strong> a screenshot of the<br />
main screen of CESMO.)<br />
As you maybe notice, we represent the in<strong>for</strong>mation in such a way that it is close to the<br />
real security process. The lists are placed in an intuitive left-to-right, chronological<br />
order. A pallet starts at the left of the screen (being on his way to the warehouse) and<br />
ends at the right (being assigned to a flight).<br />
3.2 Updating In<strong>for</strong>mation<br />
The supervisor has to be able to add pallets to the lists, update their in<strong>for</strong>mation or<br />
status and delete them.<br />
A pallet can be added to the system either as being on its way to the warehouse, or as<br />
being created in the warehouse itself. Using buttons to add pallets to the system, a<br />
pallet can appear in the lists Ia, Ib, IIa and IId (see paragraph 3.1).<br />
To update the status of a pallet, a pallet has to move from one list to the other. If, <strong>for</strong><br />
example, a pallet was on its way to the warehouse (being RTF) and is now present at<br />
the warehouse, the pallet has to move from list Ib to list IId. Moving a pallet from one<br />
list to the other is made possible by buttons between the lists (where a move is<br />
possible). If a pallet can move from a certain list to another list, there is also a line<br />
drawn between the two lists. It is always clear which moves are possible.<br />
Pallets that are in list IIa (need long program) can be moved to the lists IIb (new<br />
pressure tank) and IIc (old pressure tank). The supervisor can enter the start and end<br />
time <strong>for</strong> both pressure tanks, with the use of text boxes.<br />
Pallets that are in list IId (present in the warehouse and RTF) can be moved to the<br />
flight lists (IIIa, IIIb and IIIc). There are two buttons between list IId and every flight<br />
list (so a total of six buttons), one <strong>for</strong> assigning a pallet to the lower deck of an<br />
aircraft, one <strong>for</strong> assigning a pallet to the main deck.<br />
The supervisor can give each flight its corresponding number with the use of a text<br />
box. When an aircraft has left to transport the pallets, the supervisor can delete the<br />
pallets of the flight list, one-by-one using the flown button.<br />
3.3 Adding Speed and Error-Handling<br />
It is clear that updating in<strong>for</strong>mation by clicking a button is much faster than updating<br />
pallet in<strong>for</strong>mation by crossing out and rewriting. But the biggest gain in speed, using<br />
a software tool, comes from the fact that computers are much better in searching than<br />
we humans are. Imagine you have a pile of papers with lists of pallets on it and I ask<br />
you to find me pallet x. Ask a computer to find pallet x and it shows you the result<br />
immediately.<br />
If a supervisor wants to see the in<strong>for</strong>mation of a particular pallet in the system, but he<br />
does not know in which state (list) the pallet is, he can find the pallet easily with the<br />
use of a search function. He simply instructs CESMO to find a certain pallet and it<br />
will output the result within milliseconds.<br />
Replacing the handwritten lists with lists in a one-screen computer interface – in<br />
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 per<strong>for</strong>ming a task.<br />
Decreasing the error-rate is one of the main improvements we achieved with the<br />
development of CESMO. Making errors however, can never be fully prevented.<br />
We can distinguish two kinds of errors: slips and mistakes. Someone makes a slip,<br />
when he or she has the appropriate goal, but messes up the actions. Someone makes a<br />
mistake, when he or she <strong>for</strong>ms the wrong goal. In order to handle the ‘slip-sensitivity’<br />
in the tool, we designed the interface in such a way it is quite impossible to per<strong>for</strong>m<br />
the wrong action given a certain goal. The buttons are clear and the user is restricted<br />
to per<strong>for</strong>m those actions that are actually possible in the real security procedure.<br />
Because of the intuitive location of all the lists and buttons between them, the system<br />
is not more ‘mistake-sensitive’ than the paperwork method. But a big improvement is<br />
the error-handling in the new system. If an error is made, it is relatively easy to undo<br />
the action immediately using the well-known ‘undo’ button.<br />
For errors consisting of more than one action, or errors made some time ago we<br />
added a mode that makes it possible <strong>for</strong> the supervisor to reverse his actions. All the<br />
buttons that are used to move pallets from the left of the screen to the right become<br />
buttons that move pallets from the right of the screen to the left. E.g., the button that<br />
makes it possible to move a pallet from list IIa to IIb becomes a button that does the<br />
reverse action, moving a pallet from IIb to IIa. If, by mistake, a pallet is assigned to a<br />
flight when it actually is being checked in one of the pressure tanks, the supervisor<br />
can bring the pallet back to the list where it actually belongs.<br />
There are two extra functions in this ‘reverse’ mode (which we will called Panic<br />
Mode, see Appendix A, Fig. A2 <strong>for</strong> a screenshot): one that shows the history of a<br />
pallet and one that deletes a pallet from the list (<strong>for</strong> example, when it is broken).<br />
Because deleting a pallet is an action that should not be made by mistake, a dialog<br />
box appears when you push the button to delete a pallet. The dialog box asks the user<br />
whether he is sure he wishes to delete the pallet and then <strong>for</strong>ces the user to click on<br />
the ‘yes’ button in order to actually delete it. If a supervisor still managed to delete a<br />
pallet by mistake, the deletion can also be undone.<br />
Making an error is human, but a good design is one that prevents as many errors as<br />
possible and that – when errors are made – provides the user with easy error-handling.<br />
In the next session we show how we evaluated our design.
4 Results and Evaluation<br />
To evaluate our design we first needed to define the specifications <strong>for</strong> the usability<br />
testing in detail about the goals we are trying to reach with the use of CESMO. We<br />
wanted to test the learnability, throughput and flexibility of the system and the user’s<br />
attitude towards it. See Appendix B <strong>for</strong> the detailed description.<br />
4.1 Evaluation Sessions and Results<br />
Next, we set up two evaluation sessions with two supervisors from the Cargo Export<br />
Security Department. At the time of the evaluations, our CESMO prototype was fully<br />
functional so we could actually check the per<strong>for</strong>mance of the user being given tasks<br />
that simulate the daily work in a shift.<br />
A session consisted of two parts, one to measure the learnability, throughput and<br />
flexibility of the system and one to get to know the attitude of the users. In the first<br />
part the evaluator was given a series of tasks to per<strong>for</strong>m (see Appendix C), of which<br />
the time and error-rate were measured. We taped the evaluators doing the tasks to be<br />
able to obtain a precise measurement. The results of the first part of both evaluations<br />
are shown in Fig. 1. In the second part we gave our subjects a questionnaire using the<br />
System Usability Scale (SAS) to test their attitude towards CESMO. These<br />
questionnaire and its results can be found in Appendix D.<br />
Time (secs)<br />
45<br />
40<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
Time per Task<br />
1 2 3+4 5 6 7 8 9 10 11 12 13 14 15 16<br />
Task #<br />
Worst<br />
Evaluation 1<br />
Evaluation 2<br />
Fig. 1. Graph showing worst acceptable time to per<strong>for</strong>m a certain task, the best possible time<br />
and the time actually measured in the evaluation sessions<br />
Best
4.2 Conclusions and Improvements<br />
With the evaluation sessions we wanted to test learnability, throughput, flexibility and<br />
attitude. With the results of both sessions we can conclude several things:<br />
Learnability. The evaluators’ first impression is that CESMO is very easy to learn. In<br />
the results we can see that in general there is a positive learning curve – the more they<br />
get to “play” with CESMO, the better the per<strong>for</strong>mance becomes.<br />
From the results of these evaluations we conclude that the evaluators can easily make<br />
the analogy between the real-world process and what CESMO represents in the nine<br />
lists. In task 15 the subject was asked to get extra in<strong>for</strong>mation on a certain pallet. This<br />
is done by double-clicking on a pallet. This function is the only function in the system<br />
that lacks analogy to the real-world and is not – in fact – intuitive. In the first<br />
evaluation they were just told how to find the extra in<strong>for</strong>mation, in the second<br />
evaluation we didn’t remind them of it. They per<strong>for</strong>med badly, but – as they told us –<br />
double-clicking <strong>for</strong> extra in<strong>for</strong>mation is something simply learned after using<br />
CESMO <strong>for</strong> a couple of times.<br />
Throughput. As can be seen in Fig. 1. no task reached the worst acceptable time.<br />
Most of the tasks were actually per<strong>for</strong>med in a highly acceptable time. Furthermore,<br />
the first eight tasks as well as the fourteenth and sixteenth show an improvement in<br />
per<strong>for</strong>mance in the second evaluation.<br />
The speed decrease of tasks 11, 12 and 13 are due to an improvement we made<br />
between the two evaluation sessions. In the version used <strong>for</strong> the first session the<br />
supervisor was able to inverse actions (using Panic Mode) without giving a reason <strong>for</strong><br />
the movement. For the second version we added a pop-up textbox asking <strong>for</strong> the<br />
reason of the inverse action. Typing a message adds up to the time used to act in<br />
Panic Mode. The erratic result of task 15 is already explained in the section on<br />
learnability.<br />
Flexibility. The Panic Mode proved to be a very powerful solution <strong>for</strong> the flexibility<br />
of CESMO. In most of the cases the evaluator understood when he had to switch to<br />
this mode in order to do certain actions. After the first evaluation we improved the<br />
af<strong>for</strong>dability of the extra functions in Panic Mode (showing the history of a pallet and<br />
deleting a pallet) by showing the buttons of Panic Mode also in the main screen, but<br />
greyed out. This makes it easier to see when to switch to Panic Mode.<br />
Attitude. As said be<strong>for</strong>e we used a System Usability Scaled questionnaire to test the<br />
attitude of the subjects. The subjects seemed very satisfied with the system. During<br />
the first evaluation one of the subjects advised us to use a larger font, which we did in<br />
the new design. In CESMO the supervisor has to move every pallet one by one from<br />
one list to another. It takes more time than moving a group of pallets at once, but –<br />
and the users agreed – it is much safer this way. If you select a whole group of pallets<br />
to move the chance a pallet gets selected that does not have to be moved is bigger<br />
than when you select and move the pallets one by one.<br />
In general the tested users were very satisfied with the design. Our project supervisor<br />
advised us to use a different colour setting as strong colours have a negative effect on<br />
the user, especially when the shifts of a security supervisor are long. We adjusted the<br />
colours <strong>for</strong> the final design to desaturated and less bright colours.
5 Conclusions and Discussion<br />
We developed CESMO in order to make the work of the supervisor more efficient<br />
(faster) and safer (lower error-rate / optimized error-handling). As shown in the<br />
previous section, we succeeded. Using CESMO simply makes managing the security<br />
procedures a lot more efficient and thanks to a clear structured and intuitive onescreen<br />
interface also produces a lower error-rate.<br />
We started the design of CESMO with a clear picture of how to present all the<br />
in<strong>for</strong>mation on one screen. We never deviated from that picture, because what we<br />
thought of was an intuitive logical set-up of the in<strong>for</strong>mation. At the start of the first<br />
evaluation it became clear that the set-up was indeed very easy to understand. In<br />
general, the adjustments we made after evaluating the system weren’t very large-scale.<br />
However, both evaluations were of great importance to the development of CESMO<br />
as the resulting adjustments were improvements to the system.<br />
We started our project with the thought of optimizing the management work of a<br />
supervisor by automating the list updating. During the project and with thanks to the<br />
feedback given by class members after presenting them our progress we realised this<br />
tool is just the tip of the iceberg when it comes to the automation of security<br />
management.<br />
6 Future Work<br />
As CESMO is only a tool that provides an overview of the state and whereabouts of<br />
every pallet in the warehouse, the supervisor keeps in charge of passing the right<br />
in<strong>for</strong>mation to the security workers. In addition, the supervisor is the only one that<br />
can enter and update in<strong>for</strong>mation, in<strong>for</strong>mation that is given to him by other<br />
departments, transport companies or security workers. We started this paper with a<br />
few words on automation, saying that it comes in degrees. CESMO is a tool that just<br />
starts the automation process of cargo export security handling management. A<br />
possible next step could be providing every security worker with a PDA or handheld<br />
PC with CESMO running on it and a barcode scanner. Every pallet bears a barcode<br />
and it could be possible to enter a pallet to the system by simply scanning its barcode.<br />
This way you automate the input that is still handwork in the developed version of<br />
CESMO.<br />
With the use of PDA’s or handheld PC’s, communication between the workers and<br />
their supervisor can become more streamlined. The workers use the barcode scanners<br />
to generate the input to the system; the supervisor can change the in<strong>for</strong>mation and<br />
then send it back to the PDA’s or handheld PC’s of the security workers.<br />
<strong>Computer</strong>ized security work still demands lots of human intervention, but concerning<br />
the management of the process, it seems that there is still more to develop.
Appendix A. Screenshots of CESMO<br />
Fig. A1. Screenshot of CESMO’s main screen. The screen is clearly divided into three parts:<br />
the left <strong>for</strong> pallets on the way, the middle <strong>for</strong> pallets present in the warehouse and the right <strong>for</strong><br />
pallets assigned to a flight. Solid lines between lists show which movements of pallets can be<br />
made, the buttons show the direction (in main screen mode always from left to right). Dashed<br />
lines show were pallets can be entered. In the bottom there is the “Search Pallet” and the<br />
“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 <strong>for</strong> reverse actions,<br />
the buttons <strong>for</strong> creating a pallet and the “Flown”-buttons aren’t present here. All the movement<br />
buttons are reversed (pointing from right to left) and the “Delete Pallet”-button and “Show<br />
History”-button are active now
Appendix B. Specification <strong>for</strong> Usability Testing<br />
Learnability<br />
The ease of learning the system can be measured by checking the results of tasks<br />
examined several times. We can even check <strong>for</strong> improvement within one evaluation,<br />
because some tasks demand quite similar actions.<br />
We think the interface is quite intuitive, so we expect a very fast learning. The only<br />
aspect of the interface we think can take some time is learning where to look <strong>for</strong> the<br />
right list and see the analogy between the interface and the real world.<br />
Throughput<br />
We will check the throughput of the interface with the help of a list of tasks,<br />
measuring speed and error rate. In an evaluation session we measure the user’s<br />
per<strong>for</strong>mance on the tasks. The ‘worst’ acceptable time and error-rate are chosen to be<br />
the time and error-rate of the tasks per<strong>for</strong>med in the old-fashioned way (without<br />
CESMO, using paperwork). We plan per<strong>for</strong>mances to be the ‘best’ possible time *<br />
1.2 and free of errors.<br />
Flexibility<br />
CESMO is made <strong>for</strong> a particular sort of user. We don’t distinguish between novices,<br />
regular users or experts. All supervisors should be able to handle this interface to its<br />
deepest functions. When a mistake is made, it is best if it is corrected as soon as<br />
possible, preferably by the same supervisor. We will check if our solution <strong>for</strong><br />
flexibility (Panic Mode) is indeed sufficient. To be able to check this, we introduced<br />
some Panic Mode tasks in the list of tasks.<br />
Attitude<br />
We will provide our users a SAS-questionnaire (see Appendix D) to get an indication<br />
of their attitude towards our product.
Appendix C. Tasks Evaluated<br />
1. A fax arrived from LHR.<br />
Add these pallets to CESMO:<br />
Fax from LHR<br />
Pallet Dest Class<br />
P5F 0012 TLV LP<br />
P6P 5619 TLV LP<br />
P6A 8122 TLV LP<br />
AQ6 0001 TLV RTF<br />
2. We got a list of built pallets from the builder.<br />
Add these pallets to CESMO:<br />
Builder <strong>for</strong>m – Pallets built in AMS<br />
Pallet Dest Class<br />
P6P 6112 BKK RTF<br />
P6P 6114 BKK RTF<br />
P6P 6116 BKK RTF<br />
P6A 8729 TLV LP<br />
3. + 4. Truck from LHR arrives in AMS.<br />
Move these pallets:<br />
Pallet Dest Class<br />
P5F 0012 TLV LP<br />
P6P 5619 TLV LP<br />
P6A 8122 TLV LP<br />
AQ6 0001 TLV RTF
5. Put pallets in the NPT.<br />
Move these pallets to the NPT:<br />
P5F 0012<br />
P6P 5619<br />
P6A 8122<br />
P6A 8729<br />
Update NPT In and Out times (14:00 – 17:00).<br />
6. Put pallets in the OPT.<br />
Move these pallets to the OPT:<br />
P5F 1234<br />
P6P 2011<br />
Update OPT In and Out times (15:00 – 20:00).<br />
7. Open the NPT.<br />
Move the 4 pallets in the NPT.<br />
8. Open the OPT.<br />
Move the 2 pallets in the OPT.
9. You got an uplift from the export.<br />
Create flight 810.<br />
Move the pallets to the flight 810.<br />
Flight 810 – 30/11/2006<br />
AMS → TLV<br />
Pallet From Dest<br />
P5F 0012 LHR TLV<br />
P6P 5619 LHR TLV<br />
P6A 8122 LHR TLV<br />
AQ6 0001 LHR TLV<br />
P6A 8729 AMS TLV<br />
P6P 6112 AMS BKK<br />
P6P 6114 AMS BKK<br />
P6P 6116 AMS BKK<br />
P5F 1234 FRA TLV<br />
P6P 2011 FRA TLV<br />
10. Pallet moved by mistake.<br />
Click on the pallet AQ6 0002.<br />
Move it to the RTF list (by mistake).<br />
Undo the last action.<br />
11. Pallet AQ6 0003 found open in the system.<br />
Move it to the OPT.<br />
Fill in Time In and Time Out (23:00 – 3:00).<br />
12. A phone call from the export.<br />
They ask you what the whereabouts of pallet P6P 1357 are.<br />
Where can you find it?<br />
They tell you it’s a mistake – the pallet is <strong>for</strong> sure still on the way to AMS.<br />
Move this pallet to the On The Way LP list.
13. Pallet P6P 6112 is broken down.<br />
Delete it.<br />
14. Searching <strong>for</strong> a pallet.<br />
Look <strong>for</strong> pallet P6P 6116.<br />
15. More info about a pallet.<br />
Ask <strong>for</strong> extra info about the pallet P6P 6114.<br />
16. Flight 810 has left AMS.<br />
Move the pallets from CESMO with the “Flown”-button.
Appendix D. System Usability Scale Questionnaire with Results<br />
1<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9<br />
10<br />
I think that I would like to use<br />
this system frequently<br />
Strongly<br />
Disagree<br />
I found the system unnecessarily<br />
complex x<br />
I thought the system was easy to<br />
use<br />
I think that I would need the<br />
support of a technical person to<br />
be able to use this system<br />
I found the various functions in<br />
this system were well integrated<br />
Strongly<br />
Agree<br />
1 2 3 4 5<br />
x<br />
I thought there was too much<br />
inconsistency in this system x<br />
I would imagine that most people<br />
would learn to use this system<br />
very quickly<br />
I found the system very<br />
cumbersome to use x<br />
I felt very confident using the<br />
system<br />
I needed to learn a lot of things<br />
be<strong>for</strong>e I could get going with this<br />
system<br />
x<br />
x<br />
x<br />
x<br />
x<br />
x
Inzage medicatiedossier voor patienten<br />
Roald de Vries, Maarten Groeneweg<br />
1 LIACS, Leiden University, Niels Bohrweg 1, Leiden, The Netherlands<br />
r.a.de.vries.2@umail.leidenuniv.nl, mgroenew@liacs.nl<br />
supervised by Mounia Belmamoune, Fons Verbeek<br />
mounia@liacs.nl, fverbeek@liacs.nl<br />
Abstract. The aim of this project has been to build a user friendly interface <strong>for</strong><br />
patients to their medication file ('medicatiedossier'). The interface has to provide<br />
possibilities to view certain medication data, which is necessary <strong>for</strong> legal<br />
reasons, and possibilities <strong>for</strong> patients to give feedback on the use of medication<br />
as an interesting added value <strong>for</strong> treating party.<br />
1 Introduction<br />
In recent years, the medical world has heavily computerized itself. On hospital level,<br />
but also on national level. A recent case indicating ongoing development in this direction<br />
is the decision of the government to introduce burgerservicenummers (abbreviated<br />
'BSN', a unique civilian service numbers).<br />
The medical automation has resulted in national databases containing general in<strong>for</strong>mation<br />
on medication, and hospital-wide databases containing <strong>for</strong> example patient<br />
in<strong>for</strong>mation and treatment history. Hospitals now use computer systems as a primary<br />
mean to keep track of patients' medical history, presence and future (in the sense of<br />
prescribed medication). On a national scale there are protocols <strong>for</strong> interchanging in<strong>for</strong>mation,<br />
and the BSN should help to streamline this interchangeability.<br />
According to the 'wet op geneeskundige behandelovereenkomst' (abbreviated<br />
'WGBO', a law on medical treatment agreement), every patient has the right to examine<br />
his own dossier. The 'Nederlandse Patienten Consumenten Federatie' (abbreviated<br />
'NPCF', the dutch federation <strong>for</strong> patients) stresses <strong>for</strong> the rights of these patients, and<br />
has thus requested the development of an interface to medication dossiers <strong>for</strong> patients.<br />
The Leiden University Medical Center has initiated a project (reference [2]) to develop<br />
an interface offering these requirements as stated by the NPCF, and more. They<br />
have added the requirement that the patient should be able to add feedback on what<br />
medication was taken when, and on possible side effects of medication. In the context<br />
of the human computer interaction course 2007 (reference [1]), we have decided to<br />
build this interface (reference [3]).
2 "Please state the nature of the medical emergency"<br />
Where in the old way of prescribing medication this was always done in a way that<br />
the patient could check – think of a doctor writing notes that the patient takes to the<br />
pharmacy – in the new way, with automated prescriptions, this is not automatically<br />
possible. As explained in the previous section though, it is required. That means that<br />
<strong>for</strong> ongoing automation in medical care, a patient interface to his medication dossier<br />
has to be available.<br />
The only program that resembles this patient interface, is the specialist variant, Medicator<br />
(see attachment [4]). It is a locally used (within one hospital <strong>for</strong> example) very<br />
extended interface in which the medication of all patients can be managed. Moreover<br />
it assumes that its users are familiar with specialist terminology.<br />
The user assumptions of Medicator, obviously, don't apply to the users of the interface<br />
to construct. The users are so different, that Medicator can only serve as inspiration,<br />
instead of as an example. We will now first evaluate the interface users, and then<br />
in the next section specify our way to address their needs.<br />
User analysis<br />
The interface is targeted to be used by patients with prescribed medications, who<br />
wish to keep an overview of their medical records and keep track of their medicine<br />
use. They are normally only consumers of health care and will not have any specific<br />
medical knowledge.<br />
Experience with computers is not something that can be counted on, especially with<br />
persons of older ages. On the other hand, premise <strong>for</strong> using the interface is starting it<br />
up – which implies some (maybe very basic) computer knowledge. The interface,<br />
there<strong>for</strong>e, will have to be usable <strong>for</strong> those with only very basic computer use skills. A<br />
web browser based interface will be used <strong>for</strong> ease of use and to allow access from<br />
home computers without having to install new software.<br />
3 A task oriented approach<br />
Since the requirements of the interface come down to a limited number of tasks that<br />
the user has to be able to fulfill, we have decided to choose a task oriented approach.<br />
The tasks that are required are:<br />
view personal medication history<br />
give feedback on medication use (when, how much)<br />
give feedback on medical state, specifically side effects of medication<br />
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<br />
per task. Below, the tabs are described one by one.<br />
1. view personal medication history<br />
In the first tab, a complete list of prescribed medication can be found. A special role<br />
in this list is played by still active medication. Any record in this list can be selected,<br />
and <strong>for</strong> a selected medication record, extra in<strong>for</strong>mation on this medication will be<br />
shown – like an extended description, and side effects. Another important item <strong>for</strong>m<br />
the pictures. Using images of both packages of the medication and of the medication<br />
itself, it should be made clear which name relates to which medication in the patients<br />
hands, in the real world.<br />
2. add in<strong>for</strong>mation on medication use<br />
In the third tab, the patient can add feedback on the actual use of medication <strong>for</strong> any<br />
item appearing in the list of active medications on tab 1. The date to which this feedback<br />
applies can be entered using a 'date picker' only, so that an incorrect date can<br />
never be entered. The default date is always 'today'.<br />
3. add in<strong>for</strong>mation on medical state<br />
In the third tab, the patient can add any in<strong>for</strong>mation on his health state. The date is<br />
handled in a similar way as on the first tab (see previous paragraph). Special attention<br />
goes to side effects of the currently prescribed medication. In a drop-down-box, all<br />
side effects mentioned in the medication list will be options. For flexibility, it has to<br />
be possible <strong>for</strong> a patient to enter this feedback in a text field without any restrictions,<br />
so also 'anything else' will be an (and the default) option in the side effects dropdown-box.<br />
4. view logs<br />
In the fourth tab, the user can view <strong>for</strong> every inspection of his records, when it was<br />
done, by which institution, and what in<strong>for</strong>mation was viewed.<br />
One element is not part of these tabs, and that is the help button on the top right.<br />
Clicking on it will open a new window; in the interface, though, it is without content.<br />
It seems out of the scope of this project to provide a complete help file. Moreover it<br />
would be an illusion to think that any interface innovation can be made in that, building<br />
it as a side project along with the rest of the interface.<br />
We have decided to provide an login screen <strong>for</strong> the site. On entering the site, one of<br />
the four tasks described above can be chosen. Be<strong>for</strong>e this can actually be per<strong>for</strong>med,<br />
the user has to login, which happens in the login screen. From there the user is directed<br />
to the right tab.
Expected result<br />
The expected result depends on the extend to which the interface has been explained<br />
to the patients. We may assume that it will be explained verbally to some extent, and<br />
that patients will get a folder explaining it. On the other hand it would be naive to<br />
think that they remember a verbal explanation well, and many people will never read<br />
the folder.<br />
It is crucial that the patient understands how to find in<strong>for</strong>mation on his medication.<br />
This is the primary reason of existence of this site. The usability of <strong>for</strong>ms is less important<br />
since they merely add value <strong>for</strong> the health care provider (and there<strong>for</strong>e the<br />
patient). As far as finding in<strong>for</strong>mation is concerned, the patient should be able to find<br />
what medicine he should use <strong>for</strong> how long and in what quantities. He should also be<br />
able to find out which health care providers have viewed his medical history when.<br />
As far as the <strong>for</strong>ms in the interface are concerned, it is important that they are so clear<br />
that doubt on the patient's side won't lead to not using the interface.<br />
4 Results and Evaluation<br />
To test <strong>for</strong> the expected results we've done two usability tests. The first one being an<br />
expert user evaluation, the second an end user evaluation. The <strong>for</strong>m of the expert user<br />
evaluation was very open. We just asked experts to give their opinion on the site as it<br />
was. That has resulted in the attached expert evaluations (attachment [3]). The user<br />
evaluations were done with a question list, and are attached to this document. All<br />
usability tests were in dutch. Below we'll give an English summary of the expert user<br />
evaluations. The states of the interface during these evaluations and of the final state<br />
can be found in appendix A<br />
Expert user evaluations summary<br />
Evaluator 1 has suggested the addition of a start page, from which any of the three<br />
(three at the time, now four) tabs can be selected to start in and adding a description<br />
of the interaction between medications. He also thinks navigation within the site is<br />
clear, but boring.<br />
Evaluator 2 has suggested to make the text of the medication history tab longer, to<br />
better describe everything that can be done there. He didn't understand why the medication<br />
name should be repeated in the medication use feedback <strong>for</strong>m. It was not clear<br />
what the difference between the two feedback <strong>for</strong>ms was. Evaluator 2 has also suggested<br />
to include help functionality.
Effects of expert evaluations<br />
Expert user 1 has suggested to introduce a starting screen. We have added it even<br />
be<strong>for</strong>e the login screen, so that patient know what they're going to login <strong>for</strong>.<br />
We believe we have also addressed the problem of the site being boring, at least partially,<br />
by making more use of icons.<br />
Most of the other feedback from expert user 1 are due to the development stage of the<br />
project.<br />
Expert user 2 has suggested to rename tab 1 to reflect that also feedback on medication<br />
use can be given. We have decided not to rename it, but to add tool tips to the<br />
tabs <strong>for</strong> a more extensive explanation.<br />
Expert user 2 also mentioned that (1) the added value of the second tab was not clear<br />
having a feedback <strong>for</strong>m also in the first tab and (2) the medication name was superfluously<br />
repeated in the <strong>for</strong>m on the first tab. We've handled this by separating the<br />
first tab in an in<strong>for</strong>mation tab without a feedback <strong>for</strong>m, and a medication use feedback<br />
<strong>for</strong>m on a separate tab.<br />
Also after this second expert user evaluation we have introduced the help button.<br />
Second user evaluations round<br />
As mentioned be<strong>for</strong>e the second user evaluations round was different in setup. We've<br />
created a document with an explanation of the site, and a few tasks to fulfill. The first<br />
user (attachment [1]) has done this well, which means no reasons <strong>for</strong> concern, and has<br />
suggested some useful things. First is to make entries in the <strong>for</strong>ms editable. We've<br />
added this functionality. The second is to allow a user to give a time span <strong>for</strong> a side<br />
effect instead of a single date. We think that this is not really important, and might<br />
lead to more confusion rather than clarity, so we have rejected it.<br />
In the second user evaluation (attachment [2]) we had some problem with the fact that<br />
it had not been made clear what functionality the interface did and didn't offer. This<br />
lead to confusion entering feedback into the interface. It appears, though, that the user<br />
has always tried the correct way of entering certain in<strong>for</strong>mation first, and then started<br />
searching <strong>for</strong> other ways.<br />
User 2 says it wasn't possible to indicate that a certain side effect was caused by a<br />
certain medication. This is because the relation normally is not clear. Of course intuitions<br />
on this can be put in the 'opmerkingen' field below the side effects. He also suggests<br />
to merge the two feedback <strong>for</strong>ms into one on the second tab. We believe that<br />
this will only make the confusion bigger.
5 Conclusion and Discussion<br />
We may conclude that the task oriented approach to this interface is a good one. In<br />
general, the user evaluations have been satisfactory. Especially the tabbed navigation<br />
seems to work well.<br />
This interface is a first step towards a real web application. At some stage, it might be<br />
extended and more functionality might have to be offered. It will have to turn out<br />
whether or not the tabbed approach will still be the right one, if a multitude of tasks<br />
has to possible to be fulfilled.<br />
6 Future Work<br />
The obvious future work is implementation of the back-end <strong>for</strong> this interface. But<br />
also the interface itself can be further developed to offer more functionality, as it will<br />
eventually have to.<br />
References<br />
1. <strong>HCI</strong> website; hci.liacs.nl<br />
2. Project; http://www.liacs.nl/~fverbeek/courses/hci/exampleprojects2006.pdf project<br />
(1)<br />
3. final version of the interface; rdv.homelinux.net/hciproject<br />
Attachments<br />
1. Usability_test(1).pdf<br />
2. Usability_test(2).pdf<br />
3. expert_user_evaluation.pdf<br />
4. Artsen Handleiding Medicator.pdf
Appendix A<br />
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.