Mobile Testing of Cognitive Function
A tool for assessment of cognitive abilities in an everyday environment using a handheld device
KIM FOUCHENETTE
Master’s Thesis at ICT
Supervisor/Examiner: Fredrik Kilander
TRITA xxx yyyy-nn
Abstract
The unit of Cognitive Developmental Neuroscience at Karolinska Institutet have developed a method for measuring cognitive performance with handheld devices, which resulted in a mobile application for the iPod Touch. The ap- plication was previously used in a clinical trial with individuals suffering from chronic stress disorder, but had to be further developed. The application, which consisted of cognitive tests and questionnaires, required improvements that could be divided into three parts: (1) a long-term memory test, (2) presenta- tion of results and progress, and (3) an interface comprehensible to individuals with cognitive impairments.
The work of this thesis was to process a requirement specification and re- search the areas of long-term memory testing, data presentation, and usability.
The findings were used to come up with design suggestions for the application, and eventually implement them. The application was developed using C# and the MonoTouch sdk, to make it run on the iPod Touch. Distributed to physical devices, the application was finally evaluated to make sure the requirements were satisfied. Presentation and evaluation of the application were done with people from Karolinska Institutet.
The results from the long-term memory test suggested it was sometimes too easy remembering items, and in a few cases even a ceiling effect appeared.
However, the future target group, which was individuals with cognitive impair- ments, would likely perform less well on the test, and the test was therefore kept after discussion with the unit of Cognitive Developmental Neuroscience.
The presentation of results as well as the navigation system were received with positive feedback.
Acknowledgements
I want to thank my supervisor at Karolinska Institutet, Torkel Klingberg, for the opportunity to do this thesis project. Thanks also to my supervisor at KTH, Fredrik Kilander, for support and help during the work of the thesis. Many thanks to Jonas Beckeman, who has been of great help during the development of the application, and to the Department of Linguistics at Stockholm University for helping out with the word lists. Thanks also to my opponent, Tommy Marshall.
Finally, I want to thank the people at the lab, friends and my brother Niklas, who all helped me test the application and gave valuable feedback during the whole project.
List of Abbreviations
AOT Ahead-Of-Time
API Application Programming Interface CIL Common Intermediate Language
CLR Common Language Runtime
GUI Graphical User Interface HTML HyperText Markup Language HTTP HyperText Transfer Protocol
IDE Integrated Development Environment
JIT Just-In-Time
LIFO Last In, First Out
LTM Long-Term Memory
MS Multiple Sclerosis
MT MonoTouch
PNG Portable Network Graphics SDK Software Development Kit SQL Structured Query Language XML eXtensible Markup Language
List of Figures
2.1 The mathematics test . . . 6
2.2 The working memory test . . . 7
2.3 The attention test . . . 8
2.4 MonoTouch . . . 10
3.1 Model of memory . . . 14
4.1 Possible orientations . . . 25
5.1 Response phase of the ltm test . . . 31
5.2 Displaying results . . . 33
5.3 The application: Version 1 vs. Version 2 . . . 34
6.1 Time spent on the ltm test . . . 39
6.2 Score on the ltm test . . . 39
Contents
Acknowledgements v
List of Abbreviations vii
List of Figures ix
1 Introduction 1
1.1 Background . . . 1
1.2 Problem . . . 1
1.2.1 Requirements . . . 2
1.2.2 Problem definition . . . 2
1.3 Goal . . . 2
1.4 Method . . . 2
1.5 Limitations . . . 3
1.6 Disposition . . . 3
2 Previous work 5 2.1 The existing application . . . 5
2.1.1 Questionnaire . . . 5
2.1.2 Tests . . . 6
2.1.3 Storing data . . . 7
2.1.4 A testing session . . . 8
2.2 Development environment . . . 8
2.2.1 Mono . . . 9
2.2.2 MonoTouch . . . 9
2.2.3 MonoDevelop . . . 9
2.3 iPod Touch . . . 10
2.3.1 Device specifications . . . 10
2.3.2 Shortcomings . . . 11
3 Theory 13 3.1 Memory . . . 13
3.2 Long-term memory tests . . . 13
3.2.1 Recall and Recognition . . . 14
3.2.2 Words . . . 15
3.2.3 Pictures and figures . . . 15
3.3 Target group . . . 15
3.3.1 Dementia . . . 16
3.3.2 Multiple Sclerosis . . . 16
4 Design 17 4.1 Requirement specification . . . 17
4.1.1 Test long-term memory . . . 17
4.1.2 Feedback on the user’s process . . . 17
4.1.3 An appropriate interface . . . 18
4.2 Long-term memory test . . . 18
4.2.1 Type of test . . . 18
4.2.2 Items . . . 19
4.2.3 Test-retest and ceiling effects . . . 19
4.2.4 Presentation . . . 19
4.3 Data presentation . . . 20
4.3.1 Considering the target group . . . 20
4.3.2 Presenting data . . . 20
4.3.3 Visualization design principles . . . 21
4.3.4 Decisions . . . 22
4.4 Navigation . . . 23
4.4.1 Previous layout . . . 23
4.4.2 Accessibility guidelines . . . 24
4.4.3 Apple’s guidelines . . . 25
4.4.4 Design solutions . . . 26
5 Implementation 29 5.1 Long-term memory test . . . 29
5.1.1 Corpus . . . 29
5.1.2 Managing the word list . . . 29
5.1.3 Storing the words . . . 30
5.1.4 Result . . . 30
5.2 Data presentation . . . 31
5.2.1 Graph approaches . . . 31
5.2.2 Displaying a graph . . . 32
5.3 Navigation . . . 33
5.3.1 Look and Feel . . . 33
5.3.2 Orientation . . . 34
5.3.3 Rearrangement . . . 34
5.3.4 Feedback . . . 34
5.4 Running on device . . . 35
6 Evaluation 37
xii
6.1 Weekly meetings . . . 37
6.2 Pilot . . . 37
6.2.1 Participants . . . 37
6.2.2 Equipment . . . 38
6.2.3 Environment . . . 38
6.2.4 Results . . . 38
7 Discussion and Future Work 41 7.1 Discussion . . . 41
7.1.1 Long-term memory test . . . 41
7.1.2 Data presentation . . . 42
7.1.3 Navigation . . . 42
7.2 Future Work . . . 43
7.2.1 Extended graphs . . . 43
7.2.2 User-specific layout . . . 43
7.2.3 Abuse prevention . . . 43
7.2.4 Testing on the target group . . . 43
7.2.5 Other systems . . . 44
References 45
Chapter 1
Introduction
This chapter covers the background, problem, and goal of the thesis.
1.1 Background
The research for this thesis was performed at the unit for Developmental Cognitive Neuroscience at Karolinska Institutet. In a previous study (Heil et al., 2011), they wanted to measure cognitive performance at different levels of stress. However, assessment of cognitive ability is difficult to accomplish in a laboratory setting, and would ideally be performed in a daily life setting.
In order to do this, they had an ongoing project to develop a method for mea- surement of cognitive performance with handheld devices. The participants would perform short tests on an iPod Touch, several times a day over a period of time, unsupervised and at a free choice of location. The method made it possible to mea- sure cognitive performance within individuals in their everyday environment, and map how the performance varied during the day.
In the initial clinical trial the method was evaluated using a group of individuals with chronic stress disorder. The study was also used as a feasibility test to evaluate the validity of using handheld devices for measuring everyday performance. This was done by comparing results from handheld device testing sessions with results from a classical laboratory testing session. The conclusion was that using handheld devices for cognitive testing could be considered a valid method (Heil et al., 2011).
The unit for Developmental Cognitive Neuroscience wanted to use the iPod Touch application further by applying the method on other individuals with cogni- tive impairments as the target group in a new clinical trial.
1.2 Problem
The new clinical trial was supposed to last for two workweeks, or ten days, and the tests were to be performed four times a day, giving a total of 40 testing sessions.
However, before further testing the iPod Touch application (version 1) had to be
extended with new functionality, and adapted to the target group (individuals with cognitive impairments). The unit for Developmental Cognitive Neuroscience had compiled a requirement specification for the new application (version 2).
1.2.1 Requirements
Version 2 of the application had to satisfy the following requirements:
• Be able to test long-term memory (ltm).
• Give the user feedback on his/her progress.
• Have an interface appropriate for the target group.
The requirements are further explained in section 4.1.
1.2.2 Problem definition
How could version 1 of the application be extended and improved to satisfy the stated requirements?
1.3 Goal
The goal of this thesis was to concretize a specification of requirements for mea- surement software deployed in the field, composed by the unit for Developmental Cognitive Neuroscience, and research how to satisfy the requirements. The find- ings were then to be applied to an existing application (version 1) for measuring cognitive abilities, developed in MonoTouch to run on iOS devices.
1.4 Method
The initial step was to discuss the requirement specification for the project together with the unit for Developmental Cognitive Neuroscience in order to concretize the requirements to a degree where they would be possible to implement.
Studies then followed of previous parts of the project, including documentation and source code, as well as the development environment that was used to develop the mobile application.
The thesis work consisted of three distinct parts, which were to (1) add an ltm test, (2) add feedback to the user, and (3) to improve the graphical user interface (gui). All three parts required its own literature studies and implementation, and therefore an iterative approach was used for those parts. Each iteration consisted of a design phase where studies were carried out, which resulted in ideas for design solutions that would meet the requirements. An implementation phase then followed where new functionality, based on the design ideas, was added to the software project and tested in a device simulator and eventually distributed to physical devices.
2
During the project continuous feedback was given by having weekly meetings and small testing sessions. Finally, when all parts were implemented, version 2 of the application was evaluated by running a pilot with a group of people from the unit for Developmental Cognitive Neuroscience.
1.5 Limitations
Because of the limited time, a clinical trial with individuals representing the target group was not conducted during the thesis project. Therefore, the application was only tested with people from Karolinska Institutet.
1.6 Disposition
Chapter 1 is an introduction to this thesis and includes the background, problem definition, purpose, and goal of the project.
Chapter 2 is an introduction to the application used for testing cognitive ability (version 1). The development tools used are also explained here, as well as details about the device used for testing.
Chapter 3 is a theory chapter unrelated to technology where memory and long- term memory testing are explained, as well as impairments within the target group.
Chapter 4 describes the design phase of each part that was to be added to the application. For each part, literature studies are presented from which design suggestions for the application are developed.
Chapter 5 explains the implementation phase for all parts, where different ap- proaches are looked into and an extended and improved application (version 2) is presented.
Chapter 6 describes how the evaluation of version 2 of the application was carried out.
Chapter 7 summarizes the project by discussing the results from evaluation as well as the work as a whole and suggestions for the future.
Chapter 2
Previous work
During the previous work of this thesis an application containing tests for measuring cognitive ability had been developed (referred to as version 1). The application was developed with a tool called MonoTouch and could be run on an Apple iPod Touch device. To do further work on the application, insight into the development tools of the MonoTouch project was necessary, as well as an understanding of the limitations (and possibilities) of the device. Therefore, version 1 of the application, that was supposed to be further developed, will be explained in this chapter as well as the development environment and the iPod Touch device.
2.1 The existing application
Version 1 could run on devices running Apple’s operating system iOS, such as the iPhone, iPod Touch and iPad. However, the only device that had been used in the clinical trial was the iPod Touch.
The application included a questionnaire as well as a number of tests, where the participant had to answer questions in the questionnaire before and after the testing session. Result data was saved locally on the device and could be uploaded to a web server from the main menu when necessary. The application also contained an administration section from where data could be erased, for example.
2.1.1 Questionnaire
At each testing session, before running the actual tests, the participant had to fill out questions about his/her current state by choosing among options on sliders, similar to analogue scales. The value on a slider could represent for example level of stress, sleepiness or mood. In the case of level of stress, the participant had to choose among 15 different options, ranging from very calm to very stressed.
2.1.2 Tests
Since testing was repeated several times a day, one testing session was kept relatively short and did not take more than a few minutes to complete. The application only contained three different tests that measured mathematics, working memory, and attention.
Mathematics
In the mathematics test a grid with numbers was presented. One of the numbers was highlighted and its surrounding numbers were active, whereas all other numbers were inactive. The difference between active and inactive buttons was that the latter were transparent whereas the active ones were not (see figure 2.1). The user got an instruction to add or subtract a value from the highlighted number, which was done by pressing the surrounding number that corresponded to the correct answer.
The test went on for one minute.
Working memory
The test for measuring working memory capacity was a spatial grid task imple- mented as a four-by-four grid of circled buttons. The buttons were highlighted in a random sequence that the user then had to repeat. Depending on the level, which was adapting to the performance of the user, the sequence was of different length.
The test went on for eight trials and displayed the correct as well as the wrong input
Figure 2.1: The mathematics test: +6 to the left indicates that the button saying 79 should be pressed.
6
in the end of every trial. Figure 2.2 shows a result screen from a working memory test trial.
Attention
Five arrows would appear on the screen between random time intervals, and the user had two buttons to press that said left and right. The user had to only focus on the middle arrow, and if the arrow pointed to the right the button that said right had to be pressed as fast as possible. The same applied for the button that said left and left pointing arrows. Sometimes two dots appeared slightly before the arrows were displayed, to observe whether the user reacted faster when receiving an alerting cue. Figure 2.3 displays a screenshot of the test in action.
2.1.3 Storing data
The answers from the questionnaire and results from the tests were saved locally on the device in a simple text file. The data could later be uploaded to a web server by pressing a button in the main menu, given that the device was connected to the internet. The data was then transferred via the http protocol by sending a post request to the web server, where the data was saved, and could be interpreted and presented on a webpage in raw format and in graphs. However, server side and data transfer issues were not a part of the work of this thesis.
Figure 2.2: The working memory test: the buttons from the correct sequence are lit up, where the green buttons indicate correct taps.
Figure 2.3: The attention test: the middle arrow is the one to focus on, hence the button saying right should be pressed.
2.1.4 A testing session
Before the trial started the participant was introduced to the application and the tests, which were explained in detail. Further, the participant also got to perform the tests a few times to resolve any unclarity, before the actual testing sessions started.
A typical testing session would start with the user answering a few questions about his/her current state. When the questionnaire was completed the first test started, and when a test was finished the user was automatically sent to the next.
When all tests were completed, yet another question was to be answered about distractions during the tests. The user was finally sent back to the main menu from where the data could be uploaded. A test session would take about ten minutes to complete.
2.2 Development environment
The project included further development of an application that could run on iOS, the operating system used on Apple’s handheld devices including the iPod Touch.
Normally, applications for Apple’s operating systems are written in the Objective-C programming language with the integrated development environment (ide) Xcode.
However, the existing project was instead based on Mono and MonoTouch (mt), to make distribution to several platforms possible in the future, and therefore de- veloped in C# with the MonoDevelop ide. The following sections will explain the software necessary for developing a MonoTouch application, as explained in the
8
book Professional iPhone Programming with MonoTouch and .NET/C# (McClure et al., 2010) as well as on the MonoTouch website (Novell, 2009).
2.2.1 Mono
Mono is an open source project by Novell with the purpose of making applications based on Microsoft’s .net framework run on other operating systems than Windows, and available on several systems including Mac os x.
Two important parts that Mono provides are:
• A C# compiler to convert the source code into platform-independent bytecode called Common Intermediate Language (cil).
• A virtual machine called Common Language Runtime (clr) that converts bytecode into native machine code.
The compilation from bytecode to machine code is normally performed when exe- cution of the application starts, and is therefore referred to as Just-In-Time (jit) compilation. However, compiling at runtime is a violation of the Apple license and can not be used for software development for Apple devices such as the iPod Touch.
Fortunately, Mono supports a technology called Ahead-Of-Time (aot) making it possible to compile the cil code into native code before execution. (Novell, 2004)
2.2.2 MonoTouch
MonoTouch is a software development kit (sdk) that makes it possible for developers to create iOS applications with C#, making it a convenient tool for developers coming from Microsoft’s .net world.
When preparing the application for distribution to a device, MonoTouch is com- piled into the application where it provides a bridge between the .net framework and iOS native application programming interfaces (api), as illustrated in figure 2.4. Since the application includes MonoTouch it requires more disk space than if it had been developed in Objective-C, however, despite taking more space the application behaves like any iOS application.
Furthermore, MonoTouch offers functionality to simplify the binding of Objective- C libraries, in case an Objective-C third party library needs to be used, for example to display graphs.
2.2.3 MonoDevelop
The ide used for development of the application was MonoDevelop, a cross-platform and open-source project that has many similarities with Microsoft’s Visual Studio ide. MonoDevelop on os x has support for creating iPhone projects, which can be deployed to the iPhone Simulator or physical devices for debugging/testing or distribution respectively.
.NET MonoTouch iOS
Figure 2.4: .net developers can target iOS through MonoTouch. Illustration based on figure by McClure et al. (2010)
2.3 iPod Touch
The type of handheld device that was used to run the application in the previous clinical trial was the iPod Touch (second generation) running version 3.1.3 of the operating system iOS. The same device and operating system version was used during the work of this thesis.
The iPod Touch is a portable media player and can be considered a stripped version of the iPhone, as the iPod Touch does not have phone functionality, for example. Consequently, an application targeting the iPod Touch would also work on the iPhone.
When developing for the iPod Touch a few things need to be taken into consid- eration (Mark et al., 2011):
• Screen size: The size of the display is about 5-by-7.5 cm (nearly the size of a standard playing card), not giving much room to work with.
• System resources: The iPod Touch has limited system resources compared to modern desktop computers, which might result in some tasks, like loading web pages intended for desktop computers, to be very slow.
• Touchscreen: The iPod Touch does not have physical controls like a keypad or keyboard. Instead the user interacts with the device using the touch-screen.
However, because of the small screen, high precision might be required to, for example, type on the device.
2.3.1 Device specifications
The following table shows the specifications of the second generation iPod Touch (Apple Inc., 2010a):
10
Height: 110 mm
Width: 61.8 mm
Depth: 8.5 mm
Weight: 115 grams Capacity: 8GB
Connection: Wi-Fi (802.11b/g)
Display: 3.5-inch (diagonal) widescreen Multi-Touch display Resolution: 480-by-320-pixel resolution at 163 pixels per inch 2.3.2 Shortcomings
Unfortunately, the second generation of the iPod Touch lacks functionality that is available on later generations, which could have been useful for the thesis work.
For example, the device does not have an inbuilt microphone, making e.g. voice recognition impossible without an external microphone connected to the device.
Further, no inbuilt accessibility options are supported by the second generation iPod Touch.
Chapter 3
Theory
Version 2 of the application required a long-term memory test to be implemented as well as adaptations for people with cognitive impairments. Therefore, in this chapter memory, long-term memory tests, and impairments within the target group are explained.
3.1 Memory
To give a simple explanation of memory and how it is stored in the brain, the clas- sic Atkinson-Shiffrin model can be used. The model contains three phases where the first one is the sensory registers, followed by working memory (or short-term memory1) and long-term memory. According to the model, environmental informa- tion (stimuli) first enters the sensory registers where it is processed by the brain, then enters the working memory and finally the long-term memory. The process is illustrated in figure 3.1, and also shows how at every stage some information is forgotten. (Dewey, 2007)
The working memory can hold information (around seven items according to Miller (Miller, 1956)) for a short time as long as the items are not repeated. For example, Peterson and Peterson showed that information disappears within about 20 seconds (Peterson and Peterson, 1959). The long-term memory however, may store information for a lifetime.
3.2 Long-term memory tests
When running long-term memory tests on people, common items to use are words, pictures or figures. The subject has to remember a number of items for a certain amount of time, before recognizing or recalling them. The tests are conveniently called recognition tests and recall tests respectively.
1Even though Dewey points out that some researchers argue for a distinction between working memory and short-term memory (Dewey, 2007), they will not be separated in this case in order to keep the model simple.
Sensory
memory Working
memory Long-‐term
memory
Forge2ng Environmental input
Figure 3.1: Information passes through three memory stages according to the Atkinson-Shiffrin model, and some information is forgotten on the way. The il- lustration is based on the Atkinson-Shiffrin model diagram from Psychology: An Introduction, chapter 6 (Dewey, 2007).
3.2.1 Recall and Recognition
Two main ways to access memory are by recall or by recognition. Depending on what should be measured, the tests are a bit different in their design.
The first part, the stimuli phase, is often very similar despite the type of long- term memory test. The subject is presented with a number of items, all at once or one at a time, often with a time limit, and is asked to remember them.
After the stimuli phase, cognitive tasks are performed for a certain amount of time. The time span differs widely, where in some cases it is only five or ten minutes and in others 30 minutes or more, depending on the patient group (Knopman and Ryberg, 1989; Mazzoni et al., 1999; Nitrini et al., 2004; Westerberg et al., 2007).
Also the tasks differ between clinical trials and involve, for example, mathematical problems like repeatedly subtracting a constant value from a variable, or drawing (Coen et al., 1997; Folstein et al., 1975). The cognitive tasks will occupy the working memory with trivial problems, making it hard to keep track of the items. By doing so the working memory will be busy remembering new things, and the subject has to start relying on long-term memory to remember the previous items.
The cognitive tasks are followed by the second part of the long-term memory test, the response phase. If it is a recall test, the subject must try to recall the items from memory without any external aid at all. One type of recall is free recall, implying that the subject can recall the items in any order. In a recognition test however, the subject get some kind of help to remember the items. One common example, is that the old items, or a few of them, are mixed with completely new items, and the subject is supposed to tell which ones are old and which ones are new.
Recall tends to be harder than recognition according to most psychologists (Dewey, 2007), which consequently make recall tests require fewer items to remember than recognition tests in order to measure ltm ability.
14
3.2.2 Words
The subject is presented with a list of words, often high-imagery ones, like concrete nouns. They should be read aloud, and in some cases the subject is asked to put the word into a sentence (Coen et al., 1997).
In a word-recognition test where the words previously presented, or some of them, are mixed with completely new words, wrong words marked as correct and correct words marked as wrong are considered errors. The score can be calculated by, for example, adding the number of errors (Rosen et al., 1984).
The way words are presented might differ between studies. One documented approach is showing cards with four words on each to the subject, where one of them is an old word and the others are new (Coen et al., 1997). The subject has to point out the correct one. Another way is to show one word at a time where some of them are new words and some are old (Rosen et al., 1984), and the subject has to tell whether the word presented is new or old. The test can also be to point out all recognized words from a list of correct words mixed with distraction words (Calev, 1984).
In contrast to the word recognition test, the concept of word recall is to recall words from memory without any aid. The subject has to remember as many words as possible and for example write them down. One way to calculate the score is to add one point for every correctly remembered word (Parrott et al., 1998).
3.2.3 Pictures and figures
In some cases pictures (or figures) are used instead of words. Like in word tests, both recognition and recall can be used in different variations in the picture tests.
In one American study (Nickerson and Adams, 1979), the subject had to recall what a penny looked like, and draw it on a piece of paper. In another test pic- tures were presented to the subject, and later mixed with completely new pictures.
The pictures were displayed one at a time and the subject had to enter yes or no depending on whether he/she thought the picture had been displayed previously or not (Jeneson et al., 2010). In yet another study, geometric figures were to be remembered, and later drawn by the subject (Calev et al., 1987).
3.3 Target group
Future clinical trials using the application would involve people with cognitive im- pairments, which can be caused by several medical and psychiatric conditions. Cog- nitive disabilities here mean impairments in, for example, spatial reasoning skills and in short-term memory capacity. These impairments can be prominent in indi- viduals suffering from for example dementia or Multiple Sclerosis (ms).
3.3.1 Dementia
Dementia is a serious loss of cognitive ability, where a common symptom is memory loss. Also, symptoms like impaired intellectual functioning and reduced ability to solve problems are prominent within the syndrome. (NINDS, 2011)
3.3.2 Multiple Sclerosis
ms is a decease attacking the central nerve system (cns) affecting both motor and cognitive function. The most common cognitive impairments in ms are deficits in processing speed, episodic memory, and working memory, even though e.g. at- tention, perception and learning also might be affected (Julian, 2011). However, cognitive impairment varies considerably between and within individuals with ms (Hoffmann et al., 2007).
16
Chapter 4
Design
In this chapter the requirements for each part of the project are stated and analyzed in order to suggest design solutions for the implementation phase.
4.1 Requirement specification
In section 4.1 general requirements for version 2 of the application were listed, and said that the application had to: (1) be able to test long-term memory, (2) give feedback on the user’s progress, and (3) have an interface appropriate for the target group. In this section, the requirements are extended to cover all details in the requirement specification.
4.1.1 Test long-term memory
The application required a long-term memory test, which could be performed through- out the clinical trial. The test also had to be short since the participant had to perform it several times a day. Further, the participant was not supposed to make improvements by learning how the test worked. Therefore, the final requirements stated that it was important that the test could be:
• Performed at least 40 times.
• Completed within a minute.
• Repeated several times a day without too much of a test-retest effect.
4.1.2 Feedback on the user’s process
The tool had to give feedback on the user’s progress, which in turn had to be easy for the target group to understand. The results had to be presented in a way that would motivate the user, as well as make it possible to compare data from the different sessions. The feedback had to:
• Be comprehensible to the target group.
• Motivate further use of the tests.
• Allow the user to compare results.
4.1.3 An appropriate interface
The tool had to have an interface appropriate for the target group. The requirement specification said to:
• Identify possible problems using the application within the target group.
• Find ways to improve the navigation system to make it suitable for the target group.
4.2 Long-term memory test
In this section decisions about the design of the ltm test is explained, which had to satisfy the requirements mentioned in section 4.1.1.
4.2.1 Type of test
In section 3.2 two types of test are mentioned, recognition and recall, and the biggest decision when designing the test to work on a handheld touch-screen device was which to use. Despite the type of test it consists of a stimuli phase where the items to remember are presented, whereas the response phase differs depending on the test.
Recognition
A recognition test has a response phase in which the participant is presented with choices. Such a test can be designed to work on a handheld touch-screen device by displaying choices on the screen and allow the user to tap the correct answer.
The downside of a recognition test is that it is easier than a recall test, as mentioned in 3.2.1, which means that a recognition test requires more items than a recall test to become a challenge (to avoid a ceiling effect). More items consequently lead to longer tests, which could be a problem if the test has to be short.
Recall
In a recall test the response phase has no stimulus (aid), but the subject instead has to recall the items from memory. The user would therefore have to enter answers in some fashion on the device. On the iPod Touch, entering items (for example words) could be done by using one of the following input methods:
• Typing on a virtual keyboard
18
• Writing/drawing
• Speaking
The touch-screen can be used to type on a virtual keyboard or to draw, whereas using a microphone (an external microphone on the second generation iPod Touch) allows the use of speech to enter answers.
The downside of using the input methods required for a recall test is that an- swering could result in higher input error rates compared to simply tapping an option visible on the screen. Further, both typing and writing/drawing are time consuming and could be tiresome in the long run.
Decision
The requirements stated that the test had to be completed within a minute, making it important for the test to be short. Unfortunately, both recognition and recall had downsides from a time aspect, so the choice was instead based on the most simple one. Therefore, recognition became the test type of choice, since it only required tapping answers and no additional software or hardware was needed.
4.2.2 Items
In consultation with the unit for Developmental Cognitive Neuroscience it was de- cided that high imagery nouns were going to be used. For example, words like spider, sign and bus were used while words like idea and example were not. Fur- ther, to have an even difficulty level the choice of words was limited to words with a frequency of 2-50 per million and a maximum of three syllables.
4.2.3 Test-retest and ceiling effects
A test-retest effect (practice effect) had to be prevented, and to reduce such an effect repetitions were avoided by never use items more than once. Consequently, unique items for at least 40 sessions were required.
To make the test functional a ceiling effect also had to be avoided, which basically meant that the test could not be too easy. If a participant is able to remember all items every time he/she performs a test, it is not possible to measure a variance in performance. Except the type of items used, which was already decided, the ability to remember is influenced by the number of items and the allowable time to memorize them, as well as the time span between the stimuli and response phase.
The choice of these values are further explained in section 5.1.
4.2.4 Presentation
From the theory research, it was found that most tests were performed in a lab- oratory setting with a test leader attending. Presentation of items and response
therefore often involved the test leader. A test performed on a handheld device without a present test leader however, requires interaction with the device instead.
A way of presenting the words that seemed appropriate also for a handheld device was used by Jeneson (Jeneson et al., 2010). The test was performed on a computer, and had a stimuli phase where items (pictures) were displayed in the center of the screen one at a time. In the second phase, five old items were mixed with five completely new ones and displayed one at a time, like in the stimuli phase.
The subject had to answer whether the currently displayed item had been shown in the first phase or not by responding yes or no. Another computerized recognition test, similar in presentation, was conducted by Weis (Weis et al., 2011), where words were used instead of pictures and keys representing yes/old and no/new were supposed to be pressed.
On the iPod Touch, big-sized words can easily fit on the screen if displayed one at a time, and by widely separating two big buttons (yes and no) the risk of input errors is more or less non-existent. See figure 5.1 for an illustration.
4.3 Data presentation
During the first clinical trial with version 1 of the application, users reported that the tests were boring to perform in the long run because the lack of feedback. As a user you could perform tests, upload results and erase data, but actual results were never displayed. One main part of the requirement specification was therefore to find a way to present test results to the user, which required looking into possible paradigms for data presentation.
4.3.1 Considering the target group
As mentioned in section 3.3, the target group was individuals with cognitive im- pairments, like ms and dementia. However, whereas for example blind people might prefer results being presented in text for screen reader compatibility, cognitive im- pairments do not necessarily require any special adaptations. Moreover, since cog- nitive impairment vary considerably between individuals, it is difficult to point at specific requirements that must be satisfied to make the presentation of data com- prehensible. So even if people with any or all of the cognitive impairments prominent in for example ms or dementia might benefit from keeping presentation on a simple level, it would not differ from most people’s preferences. Therefore, when designing the feedback, general guidelines to make the presented data comprehensible were used.
4.3.2 Presenting data
The result data from the tests was stored in the application as strings meant for machine reading and was not appropriate to display in raw format to the user.
20
Instead, information that was redundant to the user had to be removed and the relevant data presented in a structured way.
Since no details about the presentation design were stated in the requirements (4.1.2), research in the area of presenting data was performed to find a suitable approach. Two approaches to present data, mentioned by Myatt and Johnson in Making Sense of Data II (Myatt and Johnson, 2009), are tables and graphs.
• Tables: Tables are best used for displaying exact numerical values, and also when working with small data sets as long as they can be displayed on a single page.
• Graphs: Graphs are graphical and makes the user think visually, which makes it easier to understand the context when working with large data sets.
The trial was supposed to include 40 sessions (as stated in 1.2), and as many result rows. Considering the limited screen size of the device (see section 2.3), a table would therefore eventually have required scrolling or being divided among several views. Moreover, tables would have made it difficult to compare results as the dataset grew larger.
Since data graphics would provide a good overview of the dataset as it increased, graphs were chosen as the way of displaying a user’s progress.
4.3.3 Visualization design principles
Myatt and Johnson list a few general principles for visualization design. One princi- ple is that graphs should be kept as simple as possible by removing any unnecessary visual elements. Also, data should be clearly displayed, not letting grids, tick marks, or other visual elements steal the focus. Grids for example, should preferably be light grey if used. As for colors in general, contrasting colors is to prefer for fore- ground and background, and to avoid colors that might make the data difficult to see. For example, red and green should not be used if they must be compared, since colorblind people have a problem distinguishing those colors. Moreover, bold and highly saturated colors (for example red, green, or yellow) should be used spar- ingly, whereas light, muted colors are preferred. Further, some guidelines when constructing graphs mentioned by the authors are:
• Plotting Symbol: Filled circles make a good choice unless more than one circle represents the same value, in that case they will be plotted on top of each other.
• Scale-line Rectangle: The scale-line rectangle is the area within which the data is drawn. The data labels in the interior should not interfere with the quantitative data, and other information should be kept outside the rectangle.
• Reference Lines: Mark important values by using a reference line or refer- ence grid.
• Scales: Choose the scales so that the data fills up as much of the graph as possible, but always allow for small margins. In case of quantitative values, the horizontal scale should have lower values to the left of higher values. The same goes for the vertical scale, where lower values should be below higher values.
• Tick Marks: Tick marks should include the range of data.
• Title and Caption: The title will provide the headline of the graph, whereas the caption is an explanation and should be both comprehensive and infor- mative.
However, pointed out in the book is that all rules cannot always be applied and that it may take some experimentation (and several iterations) before getting the graphs right.
4.3.4 Decisions
Based on the requirements and the theory on presenting data, several decisions were made about the content to display.
Type of data
Relevant data could easily be extracted from the raw data string, which contained both user data and test parameters, but what data to consider relevant was not obvious. Furthermore, relevant data would differ for every test, and in some cases even several variables could be used when calculating the result.
For example, in the long-term memory or working memory test both time and number of correct answers were factors that could be taken into consideration.
By using both values and apply a simple algorithm, like for example dividing the number of correct answers with the elapsed time and multiply with a constant, results could be displayed to the user as a final score. However, comprehension was important, so by considering only one variable when calculating the result for a test the graphs could be kept simple and concrete.
The following list shows how the test results for every test were calculated, when the most relevant factor had been chosen:
• Long-term memory: The number of correct answers. Pressing no when new words appeared and yes when old ones did was counted as correct answers.
• Mathematics: The number of correct answers, where a correct answer was every correctly tapped button.
• Working memory: The mean number of items remembered, giving a hint about working memory capacity. See figure 5.2 for a screenshot of graphs displaying working memory data.
22
• Attention: The mean response time of all taps. The user had to press a button within 1700 ms, or a new round would start. If a button was not pressed, the response time was also considered to be 1700 ms. The same was true if the wrong button was pressed, despite how fast the user reacted.
An important note is that the methods for calculating the result would not neces- sarily be used by the investigators during clinical trials, but were designed primarily with the user in mind.
Comparing results
To make the user able to compare results from different sessions, graphs with dots were used. On the x-axis, sessions were presented displaying a timeline, whereas the variable of interest (for example number of correct answers or response time, depending on the test) was presented on the y-axis. By connecting the dots with lines a curve was created that made it possible to see a progress trend, with the intention to motivate further use of the tests.
Appearance
When choosing colors, light and muted colors were prioritized while also taking the look and feel of the tests into consideration, This to keep the look of the application consistent. The scales would adapt to make the data fill the whole graph, always with a margin though. Filled circles was used, though the guideline points out that its not preferable when many circles can have the same value on the x-axis. To make the x-axis unique, the date was displayed for each session together with the current hour, since the user was never supposed to do a test more than once at a specific hour.
4.4 Navigation
One part of the requirement specification was to look into the navigation system of the application.
4.4.1 Previous layout
Version 1 of the application (see section 2.1) contained a number of tests, a ques- tionnaire and administration functions like uploading and erasing data. To access the content within the application, it had a quite simple and functional navigation system.
Navigating in the application never required the user to go deeper than two menu levels, and a back button was always present to take the user back to the previous screen. Nowhere in the application was the user required to enter information in any other way than simply tapping an element. Moreover, the user only had to
start filling out the questionnaire and was from there guided through the rest of the testing procedure.
However, before a new clinical trial with the new target group, problems that might arise when individuals with cognitive impairments use the application had to be identified.
To find ways to improve the navigation system, accessibility guidelines as well as Apple’s interface documentation for iOS devices (Apple Inc., 2011) (such as the iPod Touch) were looked into. Based on the findings from the research, actual design solutions were suggested.
4.4.2 Accessibility guidelines
To reduce possible problems using the mobile application for the target group, similar works of others were looked into to find out what conclusions they had drawn when making applications accessible.
Alm made a communication system using a touch screen for people with de- mentia (Alm et al., 2007), for which several dementia specialists recommended the interface to be as simple as possible while also encouraging interaction.
Kavčič’s paper from 2005 is about software accessibility in general and mentions the importance of keeping the interface simple as well, and also adds the importance of consistency and predictability (Kavčič, 2005).
Further, when designing for individuals with cognitive impairments it is impor- tant to reduce the cognitive load inflicted by the application, according to Boisvert (2009). To reduce the cognitive load, Boisvert suggests ways to do this in form of a few practical guidelines:
• Offer a Customized Experience: The cognitive impairments are unique for every person and a possibility to customize the application should therefore exist, by for example make it possible to change colors and font size.
• Give Regular System Feedback: Some kind of feedback should be given after every action, like when keys are pressed or invalid input is entered.
Several forms of feedback can be used (visual, audio and haptic) and preferably at the same time. Also, the feedback should be consistent with the action.
• Modality of the Message: Instead of using only text or only images, mul- tiple modalities can be used to communicate information.
• Error Prevention: Mobile devices induce the risk of input errors because of the small buttons and screens. Situations where errors may occur should preferably be eliminated. Also, by keeping the interface (colors, images, and the general look and feel) consistent the learning curve will be reduced and the user will be able to recognize the behavior of the application easily.
24
• Inputs: Inputs should be kept as simple as possible, by make as much as possible automated. Instead of requiring the user to input text, selectable options can be presented.
4.4.3 Apple’s guidelines
Apple has extensive documentation of how to design applications for their iOS based devices (Apple Inc., 2011). For navigation, there are several controls that can be used to make the navigation easy to comprehend. The controls can easily be modified, although Apple has guidelines for them.
Portrait and Landscape mode
Apple’s iOS devices support two types of orientation, portrait and landscape, where portrait is the default orientation on the iPhone/iPod Touch. The application should launch in the default orientation, and if the landscape orientation is accessible both landscape modes should be supported (see figure 4.1).
Navigation controller
Apple does not mention any guidelines for the navigation controller. However, navigation controllers are great for managing multiple views, and provides transition animations when switching between views.
The navigation controller can be explained as a controller that handles hierar- chical data (Mark et al., 2011, p. 255-256). Implemented as a stack, the navigation controller adds views on top of each other and removes them in the opposite order, making it a Last-In-First-Out (lifo) structure. As a practical example, if the user
Figure 4.1: Applications on the iPhone/iPod Touch can be used in portrait or landscape orientation. Depending on how the device is turned, one of two landscape modes is activated.
taps a button like Tests in the main menu, the view containing a list of tests will be displayed and added on top of the main menu view in the stack. When the user then taps Back, the last added view (the tests view) will be removed from the stack, and the user is back at the main menu.
Navigation bar
At the upper edge of the application, the navigation bar is placed, and should contain the title of the view as well as a back button to the previous view if such a view exists. The back button should display the title of the previous view according to Apple. Further, the navigation bar color could be changed if another color would make it more consistent with the look of the rest of the application, but appearance and behavior should not be altered between views. The navigation bar should preferably also not contain more than the title and back button.
View
A view can be used to display content like buttons and labels that the view contains, on the screen. A view can also contain other views, creating a hierarchy.
Even though Apple offers special views like table and text views, plain views had been used to create the navigation system in the application. However, buttons were displayed in a vertical list, making the view similar to a table view. Therefore, some guidelines concerning table views could be of interest when improving the navigation system.
Feedback should always be provided when selecting an item, by for example highlighting the item when tapped. Further, rows/items should have the same height to avoid making the table/list look cluttered.
Button
The menus of the navigation system in the application consisted of rounded rectan- gle buttons. A button has a white background that can easily be changed to make it more consistent with the look of other parts of the application being developed.
However, Apple does not provide guidelines for the buttons, other than avoiding titles that are too long.
4.4.4 Design solutions
Since the navigation system already had a simple layout the fundamentals were kept, and the focus was instead on suggesting minor improvements. The guidelines and the possibilities of iOS resulted in some ideas, which are described in this section and further explained in section 5.3.
26
Consistency
Apple suggests keeping the application consistent, which is also pointed out as important from an accessibility aspect. In version 1 the look and feel of menus and the tests were not consistent, because of different color schemes. Therefore, to create a consistency within the application the colors of the background, buttons, and the navigation bar were changed to have the same look and feel as the tests.
Feedback
When navigating in the menus (switching between views), transition animations can help to make it clear to the user whether he/she is heading up or down in the navigation tree, and were therefore implemented.
Further, notifications were added to display a message to the user when doing an action that required an internet connection, such as uploading data.
In the tests, sounds were played during a click/touch event, which was also suggested by Boisvert. Tapping a button would make it highlight as the only visual feedback, but since the button could be completely covered by the finger, adding a clicking sound made sense. Audio was not added to the navigation buttons however, since, in addition to highlighting the button, a transition animation was activated and the user was navigated to a new view when tapping a button. The visual feedback was considered clear enough as an indicator that the touch had been registered.
Keeping it simple
Spaces were added in order to separate menu elements into groups. Items were also rearranged to make sure the number of items in each menu were kept to a minimum, consequently simplifying the menus.
Chapter 5
Implementation
This chapter explains the implementation of the ltm test, feedback and navigation changes into the mt project.
5.1 Long-term memory test
To use as many words as possible while keeping the test around the one-minute mark, 30 words were picked for every test session and displayed for one second each during the stimuli phase of the test. The test was supposed to be performed four times a day at specific hours, for a period of ten days, which meant that a total of 1200 unique words were required.
5.1.1 Corpus
A list of nouns from the one million word balanced corpora Stockholm-Umeå Corpus (SUC, 2002), ordered by frequency, was received from the Department of Linguis- tics at Stockholm University. From that list all words except the ones within the previously mentioned frequency (2-50 per million) were removed.
5.1.2 Managing the word list
For the purpose of rapidly creating word lists, a script was executed to automatically format the data and pick out words with one to three syllables (vowels). The list was then manually cleared from low imagery nouns before the order of the list was randomized (“shuffled”).
Further, the script divided the list into 40 sub-lists with 30 words in each, and every word was randomly tagged with a number of 0, 1 or 2. The numbers were evenly distributed over the lists so that each contained ten 0’s, ten 1’s and ten 2’s.
The numbers symbolized three different categories: correct, stimuli distraction, and response distraction respectively. The words tagged correct and stimuli distraction became the ones the subject was supposed to remember in the stimuli phase. The
words tagged response distraction were mixed with the ones tagged correct in the response phase.
5.1.3 Storing the words
To store the words an SQLite database was used. Compared to saving data in, for example, text files, the database approach would make it easier to access, edit and sort the data.
SQLite is, as the name implies, a lightweight sql database. It was chosen for this project because it is specially designed to work well with small systems like the ones in handheld devices (SQLite, 2000), and would make it easy to edit the word lists later using an SQLite supported database editor. It further helped that MonoTouch already had inbuilt support for SQLite.
The lists were stored into a database table of words and each word was inserted together with a unique id, the category number (0, 1 or 2), and a session id. A table for the sessions was also created. Every session had a unique id, a session number and an accomplished flag. The flag was supposed to have an initial value of 0 (false) and be changed to 1 (true) when the session was completed.
5.1.4 Result
The long-term memory test was divided into a two-part test, where the first part was the initial test during a testing session. 20 words (correct words mixed with stimuli distraction words) associated with the current session were displayed one at a time, with a one second interval, and the user was instructed to read them aloud and try to remember them. The words appeared in the same order as in the database table, making the correct words appear in the same order for every participant. When the presentation was finished the user was automatically sent to the next test.
A restriction prevented the user from redoing the stimuli part. Hence, if the test was entered again, the response part would instead be loaded, and not until the response part was finished would the words from the succeeding session be accessible.
Between the two phases of the long-term memory test, the math test as well as the tests for working memory and attention had to be completed, and was executed in that specific order.
When finally the last part of the long-term memory test was reached, ten words from the first part (correct) were mixed with ten new words (response distraction).
The user had to answer whether the word appearing on the display was an old or new one by pressing the button saying yes or the one saying no. Figure 5.1 shows a screenshot of the response phase.
The result of the test was saved as a string. For every answer, the time for con- sideration in milliseconds, word id, session id, and whether the answer was correct or not were stored.
30
Figure 5.1: In the response phase of the long-term memory test the user had to press yes or no depending on whether he/she remembered the word from earlier or not. In this case the Swedish word for prince is displayed.
5.2 Data presentation
An aspect to consider when finding a tool for data visualization was that the tool had to be suitable for handheld devices (mainly the iPod Touch). Further, a design solution was to use graphs with connecting dots in order to present result data to the user, so a few approaches for drawing graphs on the iPod Touch were tested.
5.2.1 Graph approaches
Three ways to present data on the iPod Touch were considered and tested.
Binding a library
The MonoTouch sdk did not have support for any charts library directly, but by using the MonoTouch binding functionality an existing Objective-C chart library could be implemented to the mt project. However, due to the time limit, building a binding wrapper for a chart library was not considered.
Instead, an already existing binding for a plotting framework called Core Plot was tested. Unfortunately, the binding was not stable or fully functional at the time and therefore not used.
Google’s Chart API
Another approach tested was to use Google’s Chart api (Google, 2007). Datasets containing result data were sent through the api, and a png image file displaying a graph was returned. Googles api was simple to use and offered a large set of different types of charts to choose from as well as many parameter options.
However, the application, and so the device, needed to have an internet con- nection when using the api, which unfortunately could not be guaranteed. In fact, participants were not required to constantly upload their results and could do the testing anywhere, so it was unlikely that the device would be connected to the internet during testing and result presentation.
UIWebView and locally stored page
The UIWebView is part of the iOS UIKit (Apple Inc., 2010b) and could be used to display web content to the user within the application, using the inbuilt browser functionality. By storing the webpage locally on the device, no internet connection would be needed to display the page. The reason why a UIWebView was a valid approach was the ability to use a JavaScript library for drawing graphs. By using a UIWebView supported method called EvaluateJavascript(), JavaScript functions could be called from the C# code when needed. The method could be used to call a JavaScript function on the webpage with result data as argument. The javaScript function in turn could generate a graph and use the data to plot a curve. Using a UIWebView solution turned out to work as expected and therefore became the choice for presenting graphs in the application.
However, since the time span for implementing graphs was limited, no thorough comparison between JavaScript chart libraries/plugins was done. The focus was on simplicity for fast development, and the plugin finally used was jqPlot (Leonello, 2009), based on the jQuery library (Resig, 2006), which is a library designed to simplify the scripting of webpages. The flexible jqPlot plugin also made it possible to make changes fast during experimentation with graphs.
The jqPlot plugin and jQuery library was used on a regular html page, which was imported into the MonoTouch project with all required files. The html was then loaded into a UIWebView, which, by not displaying browser controls like back and forward buttons or a location bar, made the page appear to be part of the application.
5.2.2 Displaying a graph
An additional submenu was added to the main menu of the application, from which the user could access all the graphs. A screenshot of the results being accessed from the menu can be seen in figure 5.2a.
The test results were also displayed after each test, with the current session being highlighted, and a button to continue to the next test. A screenshot of a graph displaying the current result can be seen in figure 5.2b.
32
(a) Results accessed from menu (b) Results displayed after a test
Figure 5.2: The two screenshots shows the difference between accessing the graphs from the menu (5.2a) and when displayed right after a test (5.2b). Both screenshots shows the results from a few testing sessions of the working memory test. The x-axis displays the date and hour, whereas the y-axis displays the mean number of items remembered during the trial (capacity level).
Handling overflow
The user would complete 40 sessions, which would eventually make the graphs re- quire more space than the small display could offer in order to give a good overview, and not make the graphs too compressed. Therefore, a variable width based on the number of plots (sessions) was used, so when the graph would eventually extend the screen the user could scroll sideways, back and forth, to see the whole graph.
5.3 Navigation
The application consisted of a navigation system, a test base, and after the imple- mentation of a UIWebView to display graphs (see section 5.2), also result views.
Only the navigation system was supposed to be modified, whereas the look and feel of the tests were to be left intact. Therefore, the goal has been to make the look and feel of the navigation system consistent with the tests. The implementation of improvements are based on ideas from section 4.4.4, and made to run on the iPod Touch.
5.3.1 Look and Feel
The application’s look and feel was inconsistent since the navigation system used a white color scheme, whereas the tests used a beige one (see figure 5.3). To make the navigation more consistent with the tests, items like buttons, the background, and the navigation bar were given a beige color scheme to make the navigation system similar in appearance to the tests. The Admin button was also changed to a black color to give it a more serious look (Fling, 2009, p. 127), as well as to make the distinction between testing-related options and administration more clear.
(a) Version 1 (b) Version 2
Figure 5.3: The navigation system did, among other changes, get a new color scheme to match the tests.
5.3.2 Orientation
The tests were only able to run in landscape orientation, and so it was decided that the navigation system would operate in the same mode to avoid inconsistence and the need to switch between landscape and portrait mode, which could be tiresome.
However, according to Apple both landscape modes should be available if one of them are, which was not the case in version 1 of the application. This was fixed, so regardless of which way the device was turned (which landscape mode was used), the interface would adapt correctly.
5.3.3 Rearrangement
The Admin button was rarely used, so a space was inserted between the button and the rest of the objects in the main menu to have them separated. The Upload button was moved into the administration menu since it was seldom used, and the post-test questionnaire was moved from the menu containing all the tests to the main menu. Consequently, menus never contained more than five items, and still the navigation system did not require the user to go deeper than two menu levels.
5.3.4 Feedback
If the user tried to upload data without an internet connection no feedback was given, and eventually the application would crash. By checking for an internet connection, and inform the user with a short notification if the device was not connected, a crash was prevented and the user got feedback on why the action failed.
Transition animations were implemented correctly to give the user a hint about whether he/she was going up or down in the navigation tree. When going deeper into the hierarchy (adding new views to the stack) the view disappeared by sliding away to the left, and when going back through the hierarchy (removing views from the stack) the views would slide back in.
34
5.4 Running on device
To be able to test changes fast the iPhone Simulator was used, provided by the iOS sdk and accessible from MonoDevelop. When developing the graphs for data pre- sentation the Safari browser was used to make development even faster. Eventually, the application was uploaded to an iPod Touch device identical to the ones used during the actual clinical trial (see specifications in section 2.3), to see if problems would arise. However, the application did run smoothly on the device with the only exception that the graphs for data presentation were slower to load than in the simulator. Waiting for a graph to load on the device could leave a blank screen for about two seconds, whereas in the simulator the graphs would appear to load instantly. To eliminate any confusion a loading screen was added.
Chapter 6
Evaluation
In this chapter the methods for continuous testing during the work of this thesis are discussed, as well as a detailed explanation of the final pilot study.
6.1 Weekly meetings
Since the application was going to be used in yet another clinical trial, it was im- portant that all the parts of the requirement specification were comprehended and eventually implemented correctly. This was done in an iterative manner by gather- ing feedback weekly from the group at the unit of Developmental Cognitive Neuro- science, which was the same that had composed the requirement specification. The group was lead by Torkel Klingberg and consisted of, among others, psychologists and neuroscientists (Klingberg lab, 2011). The meetings were especially helpful dur- ing design phases, and influenced for example the design of the long-term memory test.
6.2 Pilot
Since no individuals representing the target group was available for the evaluation of the application, people from Karolinska Institutet did instead participate in a pilot test. The pilot was performed during two days with four participants, who performed the tests two times per day, which resulted in data from a total of 16 trial sessions. The main purpose of the pilot was to evaluate the long-term memory test as well as receiving general opinions about the navigation and data presentation of the application.
6.2.1 Participants
The participants were four volunteers from Karolinska Institutet. The individuals were women of ages 23 to 28, with a mean value of 26.5 years.
