Information needs for a wayfinding app for low-vision visually impaired persons

Information needs for a wayfinding app for low-vision

visually impaired persons

SUBMITTED IN PARTIAL FULLFILLMENT FOR THE DEGREE OF MASTER

OF SCIENCE

Remco van Swieten

11110317

M

I

S

H

C

M

F

S

U

A

August 21

_{, 2017}

1st _{Supervisor 2}nd _Supervisor Prof. dr. ir. B.J.A. Kröse D. Buzzo

Information Needs for a Wayfinding App for Low Vision

Visually Impaired Persons

Remco van Swieten

University of Amsterdam, The Netherlands

Student ID: 11110317

remco.vanswieten@student.uva.nl

ABSTRACT

Wayfinding for visually impaired persons (VIPs) is a widely studied topic. Several studies explored the requirements of VIPs, including several prototypes. However, most of these studies do not address specific needs of low-vision VIPs. As part of the “EyeBeacons: Wayfinding in public spaces” project, the research presented in this paper explores the information needs of low-vision VIPs when preparing for autonomous travel using an app during multiple-steps: a field study; scenario discussion in focus groups and a prototype evaluated in a user test. Results of the study include findings on information needs of low-vision VIPs compared to blind users and a qualitative usability evaluation. The conclusion is that although differences among requirements were found, the results also suggest that there is not one single answer for the defined group of low-vision VIPs and the participants needs are very personal.

INTRODUCTION

It is estimated that around 300.000 to 350.000 people are visually impaired in The Netherlands [14,15]. Estimates expect this number to rise to 379.000 by 2020 [14]. The Netherlands’ Social Research Institute (SCP) divides visually impaired persons (VIPs) into two groups consisting of 76.000 VIPs who are blind and 220.000 VIPs who have low vision [15]. These groups are based on definitions by the World Health Organization (WHO). According to the WHO, VIPs are considered blind when they have a visual acuity of less than 5% or a field of view of less than 10 degrees. Low-vision VIPs have a visual acuity of less than 30% or a field of vision of less than 30 degrees [14,25]. One area where VIPs experience problems in day to day life is finding their way in public spaces and transportation. These problems are caused by the way public spaces and transportation are set up to be visually oriented [8]. An example of this is signage; e.g., street name signs and direction signs. In some places such as public transport stops and public service buildings, guidance for VIPs such as tactile paving is present. However, wrong application and maintenance inconsistencies makes tactile paving less dependable [5]. To help VIPs navigate these public spaces, organizations in The Netherlands such as Bartiméus and Visio provide Orientation & Mobility (O&M) training where VIPs are trained to walk specific routes autonomously. Aside from these specific routes, however,

most VIPs prefer not to go out into unfamiliar environments or only do so after thorough preparation [10]. Although the navigation problem for VIPs has a long tradition in research [19], recent research by Szpiro et al. suggests that most studies, prototypes and products are either aimed at blind users or VIPs in general. Requirements specific to low-vision VIPs are not addressed.

Solutions currently in use by VIPs include general purpose navigation apps based on GPS. These apps are often augmented with specific apps for VIPs, like BlindSquare, to account for information often missing in general purpose apps such as points of interest and street crossings [22]. Both general purpose and VIP-targeted apps, however, suffer from limitations of GPS accuracy which leads to potentially dangerous situations [8].

The research presented in this paper is done as a part of the research project “EyeBeacons: Wayfinding in Public Spaces” (EWPS) conducted by The Amsterdam University of Applied Sciences and Saxion University of Applied Sciences. This project aims to do applied research based on off-the-shelf products, like smartphones and smartwatches, combined with Bluetooth Low Energy (BLE) beacons to address accuracy concerns of GPS. This paper aims to contribute to the EWPS project by answering the following research question:

What are the information needs of low-vision VIPs when preparing for autonomous travel in an unfamiliar environment using an app?

This paper discusses the process and outcomes of a qualitative user-centered design into information needs of low-vision VIPs. Next section presents a brief literature after which methods are discussed generally. In the sections after that, both methods and results are discussed in more detail per step in the research project: preliminary research, scenario discussion in focus groups, pilot prototype evaluation and prototype redesign evaluation.

RELATED WORK

In this section, prior studies relevant to the research question are discussed. Although not much research has been done into navigation and information needs for low-vision VIPs, there have been requirement studies as well as prototype navigation aids for blind users and VIPs in general. This section discusses studies addressing VIP

navigation requirements and research prototypes based on BLE beacons for VIPs.

VIP navigation Requirements

Multiple studies discuss wayfinding requirements for VIPs. Golledge et al. [12] conducted a telephone survey with blind participants asking their preferences. Gaunet et al. [11] conducted an experiment where blind participants were asked to give instructions based on routes familiar to them, which were then analyzed. Brock et al. [7] conducted a brainstorming session with blind and sighted participants to identify requirements for an accessible route calculation system. All three studies provide types or categories of information (appendix 3) blind participants deem necessary when travelling an unfamiliar route. These categories were used as inspiration for the scenario and prototypes created during this study. Both Golledge et al. and Brock et al. found that a pre-trip "virtual" or "simulated" walkthrough where a user is "talked through" a route, is a preferred method of preparing for travel by participants in their respective studies [7,12].

Also, Golledge et al. asked participants their preferred methods of input and output. For input, they preferred spoken, voice-based input method, followed by a standard telephone keypad, which were common at the time [12]. A study by Szpiro et al., identified the different aids used by low vision VIPs during wayfinding tasks [21]. They found that the smartphone was one of the most used aids during the study. Participants used map applications to help them orientate outdoors as well as camera applications used as a digital magnifier. This implies, for this study, that we can assume that information presented on a mobile device screen can be a viable method for low-vision VIPs.

Brock et al. [7] also identified other requirements which can be used to design a prototype, such as: saving and playing back an itinerary; saving points of interest (POIs) within a route; highlighting POIs during journey; considering public transport options according to different criteria (proximity of the station, safety, complexity to get to the station); and, comparing itineraries to different criteria (number of turns, number of crossings).

The research by Golledge et al., Gaunet et al. and Brock et al. is relevant to our research in multiple ways. Although established for blind participants they found multiple lists with of types of information with points of overlap that can be used as a starting point for our research. We can assume that a walkthrough can be a useful way to present information to help prepare users for travel. Although Golledge et al. found that voice/audio was a preferred method for input and output for blind users, Szpiro et al. found that smartphone usage for low vision VIPs during navigation consisted only of visual functions. This leads us to assume that visual presentation of the information in an app for low vision VIPs is a valid option to explore. Lastly, Brock et al. established some functional requirements which helps make such an app more useful.

BLE beacons based research prototypes

One problem the EWPS project tries to address is to achieve a better accuracy for navigation instructions using BLE beacons. Over the years, there have been several studies aimed at achieving positioning using different technologies such as Wi-Fi, RFID and Bluetooth [16]. Recently, several studies were done using BLE beacons and prototype apps to achieve some form of position information specifically intended for VIPs [1,4,10]. The NavCog project by Ahmetovic et al. studied a technical implementation of a BLE based positioning system utilizing signal strength and a machine learning algorithm. The authors claim that the system has several benefits compared to other positioning techniques: a higher accuracy than GPS or Wi-Fi-localization; no structural changes to the environment are necessary and position calculation was done on the device without sending privacy sensitive data to a server.

Both Chen et al. [10] and Van Der Bie et al. [4] used a simpler approach to applying BLE beacons. Instead of creating an infrastructure for accurate positioning, BLE beacons were placed at strategic positions such as direction signs, intersections and street crossings. This enabled them to create prototype applications that reacted to a beacon when in range, allowing them to study user’s experience and reactions to instructions and information from the app. Van Der Bie et al. [4] found supporting evidence that users felt safer and felt the application supported walking and learning new routes. They, however, received mixed responses on the length and usefulness of the instructions. Chen et al. [10] included low fidelity prototyping and user testing in their study, providing several interesting observations for the research presented in this paper. Their findings and conclusions include:

• It is better to use a flat hierarchy for app navigation. • Route descriptions are a good way to guide users. • Text- and voice entry are both important input

methods, dependent on the situation.

• The level of detail in information presented is important dependent on familiarity of the user with the route and environment in question.

• Number distances and directions (North, East, South, West) are too abstract for VIPs, clock positions (such as 11 o' clock, 3 o' clock) relative to the user's direction are a better way to indicate direction.

• Directions should be mentioned first in a navigation message.

METHODS

The research presented in this paper contributes to the EWPS project by establishing information needs and using them in the design of a user interface prototype for preparation of travel in an unfamiliar environment. Because of this, a user-centered design approach was chosen for this research. User-centered design is the practice of finding

information about users and their tasks and using this information to inform design [20]. The information on users and their tasks is obtained through observation of users performing their daily routines and by involving them in the design process.

Users were involved in the study in three different settings. First, an observation of an Orientation & Mobility (O&M) training session is conducted during the preliminary research phase. Second, users and O&M experts are involved in the focus group sessions for the wayfinding in public spaces project. Third, users are involved in evaluation of the user interface prototypes.

The project was conducted according to the following steps: 1. Preliminary study

2. Scenario discussion in focus groups 3. Prototype pilot evaluation

4. Prototype redesign evaluation

As each step builds on the previous ones, the next sections of this paper describe a more detailed approach and results grouped by each step.

PRELIMINARY STUDY Approach

As part of the preliminary research into the topic, a brief literature study was conducted into information requirements for VIPs during wayfinding. Literature used in the EWPS project proposal were used as a starting point. The results are described in the related work section. To support the literature study during the preliminary phase, a field study in the form of an observation of an O&M training session was conducted. The observation was conducted by two researchers from the project. The VIP being trained was a 41-year-old male who is blind. The location of the training session was the VIP’s home and direct environment. The training session was conducted by two professionals from Visio. One of the professionals is an O&M professional who normally conducts these training sessions. The other specializes in support on currently available digital wayfinding solutions. The goal of the training is to teach the VIP how to walk in an unfamiliar environment using an iPhone. The apps used during the training session are BlindSquare and Google Maps. The field study was conducted by observing the process of the training session with as little interruption as possible. Emerging questions for the VIP participant based on the field study were saved for after the study.

Results

The notes taken during the observation and subsequent interviews were fleshed out into a small report independently by each researcher. The observation gave us a better understanding of the workings of an O&M training session, the working and functions of an app like BlindSquare, problems experienced when walking using an app and other points regarding.

The training session starts off at the VIP’s home, where past experiences with the iPhone were evaluated and instruction on usage of the BlindSquare app was given. The second part of the training consisted of walking a route to the local community center. The VIP planned the route himself and walked the route with the assistance of the O&M expert. Since the participant owns a guide dog, the O&M expert supported the participant by holding the other side of his cane and led hem in the way a guide dog would. The purpose of a guide dog is to help a VIP to avoid obstacles, walk along safe paths and finding specific objects nearby such as a door or a street crossing. A guide dog is not supposed to navigate for the VIP.

BlindSquare was operated by the participant using touch-input and the iPhone’s built-in VoiceOver functionality. For navigation, Google Maps was used while BlindSquare provided orientation information such as: instructions based on clock directions, calling out intersections and suitable points to cross the street. BlindSquare contains the function to save certain points on the route to be called out when they are encountered the next time. The participant used this functionality to add a difficult point in the route. The verbosity of calling out points of interest can be changed in the settings. A problem that occurred was that the instructions of Google Maps and BlindSquare sometimes interfered with each other causing confusion. On some occasions, BlindSquare did not mention intersections or points of interest when the participant expected it. The participant mentioned that this made him nervous. The GPS signal was shortly discussed as a possible cause of this problem. Information that was noted as valuable for the participant included: pedestrian crossings, obstacles, side streets, points of interest, ‘natural’ guidelines (e.g. curbs, fences, shrubberies) and addresses.

The walking session also revealed an interesting practice which is taught to VIPs: the walking of so-called U-shapes when crossing streets at an intersection; instead of crossing the street at the corner of an intersection, a VIP will walk a short distance into a street before crossing the street. This way a VIP has to deal with traffic coming from two sides instead of four. It is also easier to be noticed by other traffic. After crossing, the U-shape is completed by walking back to the intersection.

SCENARIO DISCUSSION IN FOCUS GROUPS Approach

Scenario

From the information gathered in the preliminary research a scenario was created which served as an object for discussion during the focus group sessions. A scenario was chosen because of its low-fidelity character and the possibility to communicate design choices verbally to VIPs during the focus groups. The scenario during this research project served as a basis for the overall design and to bridge the boundary between the designer and the user as described by Bodker [6] and was used to help provocation

of thoughts and ideas about the subject during the focus groups.

The scenario (see appendix 1) used in the focus groups consisted of a high-level description of the system, set in a daily situation to help participants empathize with the persona’s situation. This helped getting feedback from personal experience of the participants. The scenario describes a situation where a persona named Luuk uses an app to prepare for travel from point A to point B and is presented an option to plan for a stop in between. The scenario described a description of the setting and the usage of the app, i.e., entering a starting location from a list of saved locations; entering a destination by address; adding an in-between stop; selecting preferences for routes; getting feedback from the app about the duration of the selected route; previewing the route; and selecting an alternative route.

In the scenario description, a rationale is given for each of the choices Luuk makes. The preference options described in the scenario as well as the rationale for Luuk’s choices are inspired by the results of the preliminary research.

Participants

The focus group session included 20 VIP participants divided over 4 focus groups and 1 focus group with 9 experts. The VIP focus groups were divided based on the visual acuity of the participant (see Table 1 for division per group). One focus group consisted of 2 persons due to cancelations. Participants were recruited for the EWPS project by the Oogvereniging. Experts are professionals from Visio and Bartiméus.

Focus Group Setup

Focus groups were held at the Amsterdam University of Applied Sciences. Three researchers were present during the sessions. One researcher acted as a moderator and two researchers were observing and provided a supporting role. Due to privacy concerns, participants were given a color label and were asked to address each other using this label. The focus group discussion was divided into 4 topics: 1. Problems with wayfinding in public spaces 2. Current experience with wayfinding aides 3. Preferences for new wayfinding technology 4. EyeBeacons concept evaluation

During the EyeBeacons concept evaluation the scenario was presented and evaluated to prevent biasing previous themes with researcher’s ideas. Data was collected during the focus groups using video recordings, audio recordings and researcher’s notes.

Data Analysis

Since the focus groups were conducted to serve the purposes for the EWPS project as a whole, only the relevant parts for this research were included in the transcription and coding. Topic 3 question 10 and topic 4 were transcribed from the VIP sessions. Topic 3 question 9 and topic 4 were transcribed for the expert session. Although question numbers differ for the VIP and the expert sessions, they correspond to the same question. Topic 3 address the information needs of VIPs and topic 4 consists of the EyeBeacons concept evaluation based on scenarios presented during the session.

Transcriptions were made using the open source oTranscribe software [3]. oTranscribe is a web based transcription tool. A locally installed version of the software was used to ensure no privacy-sensitive data was transferred to a third-party server. Time coded statements were then transferred into spreadsheet software and coded using a simplified process inspired by Ose [18]. Using a spreadsheet allowed us to annotate statements from participants and more easily search and sort them for analysis. Open coding was used to let the coding scheme emerge from the data.

Results

Coding scheme

Based on coding of the transcribed parts of the focus groups (see Table 3) 6 categories of information were found to be relevant for participants for navigation. The next subsections discuss the contents of these codes organized by focus group topic.

Topics 3: Information Needs

Below findings from theme 3 question 9 and 10 are summarized as they were also deemed relevant to this research.

Group # Part. Gender (#) Visual Acuity (#)

F1 4 M (3) F (1) <2% (2) <5% (2) F2 2 F (2) <10% (2) F3 5 M (2) F (3) <30% (3) >=30% (2) F4 5 M (2) F (3) <30% (4) >=30% (1) Experts 9 M (6) F (3) Unknown visual impairment (3)

Table 2. Focus group participant information Focus group Device

F1 Smartphone (3x) PC/Tablet (1x) F2 Smartphone (2x) F3 PC (2x) Tablet (2x) Smartphone (1x) F4 Smartphone (2x) Tablet (2x) Both tablet/smartphone (1x) Experts Bigger screen

Landmarks:

One important type of information that was mentioned during the focus groups are landmarks. Landmarks are features of the environment which help people orient where they are in relation to the goal. Examples mentioned are intersections, traffic lights and lampposts. Interestingly, the traffic lights and lampposts were only mentioned in F1, the focus group with participants with the most severe visual impairment. These types of landmarks were not mentioned in other focus groups including experts.

Other examples of landmarks that are consistently mentioned across the other focus groups (F2, F3, F4 and experts) are entrances and exits of larger buildings. One particular example are exits of larger public transport stations. Participants remark that they are hard to find and it is often unclear which exit is best to reach a destination. Entrances of buildings are mentioned in relation to current navigation software which navigate to an address and assumes vision to find an entrance which might be on the opposite side of the street or at the edges of a larger building instead of the center part.

Obstacles:

Participants mention obstacles as a distinct separate category. Although they seem similar to landmarks as they can sometimes be used for orientation, obstacles are dissimilar from landmarks in the sense that they get in the way of walking or might even be dangerous. The expert group also makes the distinction between ‘permanent’ (e.g. small posts) and ‘non-permanent’ obstacles (e.g. a parked bicycle). Other obstacles mentioned are height differences, such as (downward) staircases, slopes and curbs which often feel like stepping into a depth if undetected. These obstacles are specifically mentioned in focus groups with low vision VIPs because some of them make less use of a guide cane and these kinds of obstacles are difficult to see because of low difference in contrast. Obstacles mentioned in all focus groups, including experts, are objects above the waist such as awnings, balconies and tree branches. These obstacles, which are not detected when using a guide cane, are often difficult to see and can potentially wound someone walking into it.

Feedback:

The feedback are all types of information not directly related to features in the environment but help the user navigate. Several categories of feedback were mentioned: navigation instructions, environment status, direction and confirmation. Navigation instructions sometimes need to be given in different measures compared to normal navigation apps; e.g., “turn right at the fourth crossing” instead of “turn right after 200 meters.” Environment status examples that were mentioned were status of traffic lights (red or green) or mentioning of public transport stops while travelling on public transport. Directions need be given relative to the user’s orientation; e.g., “turn left” or “at 11 o’clock” instead of “travel in northeast direction.” Participants, both VIPs and experts, indicated they need confirmation or positive feedback on progression to assure users they are going in the right direction.

It is also interesting to note that multiple groups mentioned that the level of detail in this information is dependent on the person using the system, context and goal of travel. For instance, when the goal is to go shopping in a city center, it is best to have a route right through a busy street and the system mentioning all the shop locations. When traveling to a specific destination it might be best to avoid the busy streets and not mention all the shops. The same goes for the mentioning of every street crossing. The level of detail needed is dependent on the person’s vision, confidence and personal preference.

Preparation:

Information for preparing for travel was mostly obtained from reactions from the scenario in topic 4. However, some points were also mentioned during topic 3. Preparing for travel in an unfamiliar environment serves multiple goals according to participants: decision making on which route to take, visualizing the route and to establish if the route has certain features. Participants said decisions on which route to take depends on multiple factors, which are based on personal preferences; e.g., taking the fastest route or taking the ‘easier’ route. Easier was not further defined during the transcribed parts of the focus group. Visualizing a route helped with knowing what to expect and travel with more confidence. Some participants (F3) would like to have a mental image of the neighborhood such as a residential area or the type of buildings.

Next, features were mentioned that would have positive or negative impact on decision making. For instance, participants would try to avoid construction work, while guide dog users appreciated green areas in the route and the ability for the dog to drink or refresh. Lastly participants mentioned (F3) that they would not want to prepare the exact route instructions but preferred a summarized overview of a route.

Facilities for VIPs:

In group F1, participants mentioned the integration with existing facilities explicitly such as mentioning of tactile

Category Sub-category

Information

Landmarks, Obstacles, Feedback, Preparation information, Facilities for VIPs, Information about the environment Requirements Accuracy / precision, Software

Input / Output

Audio, Tactile, Visual, Speech recognition

Scenario

Positive reaction, Negative reaction, Suggestions

Device

Prefered for preparation, On the road, Requirements

pavement, acoustic traffic signals (Dutch: ‘rateltikkers’) and location of information kiosks (for instance on train platforms). Although not explicitly mentioned by participants in other focus groups, it was mentioned as an appreciated feature in the scenario evaluation.

Information About the Environment:

Information about the environment was mentioned in group F3 and the expert group. Specific aspects mentioned were: traffic and pedestrian bustle, green areas on the route, street layout such as orientation of the sidewalk in relation to bicycle lanes and motorized traffic.

Topic 4: Scenario Evaluation

The scenario was generally received positively in all focus groups including the expert group. Aspects of the scenario that were mentioned in a positive way were:

• Filtering options and the ability to avoid certain situations

• Feedback about the time the journey would take as opposed to the shortest route

• Being able to review the route and decide to plan a different route.

Participants mentioned several additions to the filtering options:

• Green areas for walking the dog • Parks and green routes

• Information about traffic such as speed limits of traffic in the area

• Railroad crossings • Slopes and stairs

• Potentially dangerous situations

One aspect that was mentioned in several focus groups was that traffic lights should be preferred instead of avoided. Participants also mentioned aspects of the scenario as extra important:

• Traffic light and audio signaling (Dutch: rateltikkers) • In-between stop planning

• Filter-options help to assess what to expect when traveling, which helps with self-confidence

• The ability to customize the route

• Being able to review the route before saving

Participants were also asked on what device they would like to prepare for travel. The results are listed in Table 2. It is interesting to note that preference towards a bigger screen device is greater among focus groups with participants with better vision. The preferred method of output mentioned in focus groups was to use audio, although in focus group 3 warned about too much audio and focus group 4 wanted both audio and visual output. A preferred method of input was only mentioned in focus group 3 where one participant would prefer to use their voice (speech-to-text) as input method. Lastly, in focus group 3 and in the expert group it was mentioned that step-by-step navigation instructions were less important during preparation and some form of a summary should be used instead.

PROTOTYPE PILOT EVALUATION Approach

Prototype Design

Prototyping is a well-established method for designers to help them answer questions and evaluate alternatives [20]. Prototypes can come in many forms from paper-based mockups (low-fidelity prototypes) to fully interactive digital prototypes (high-fidelity prototypes). Different levels of fidelity in prototypes, invite different types of feedback by stakeholders. For instance, if a prototype is clearly a sketch or a mockup, stakeholders are more likely to give feedback on that what is there such as the structure of a page or a screen or a piece of information that is present or might be missing. Whereas when a prototype seems more ‘finished’ such as a detailed design or interactive prototype, stakeholders are more likely to give feedback on details such as color, imagery or font.

The user interface design of an app for low vision VIPs presents a problem with regards to the classic low-fidelity/high-fidelity classification of prototypes. Although the nature of this research as well as the early phase of the EWPS project warrants the use of low-fidelity prototypes, the variety in nature and severity of visual impairments of the intended audience makes it difficult to create a low-fidelity prototype which is accessible to all potential participants.

The solution chosen for this project was to create a ‘mid-fidelity’ prototype using HTML, CSS and JavaScript. The visual representation of the prototype looks like a low-fidelity prototype such as a wireframe. It has, however, some high-fidelity characteristics such as that it is clickable and mimics the working of some actual functionality. The added benefit is that such a prototype can function properly with accessibility features of the mobile operating system and allows us to let participants test the prototype on their own device with accessibility settings they have enabled in their daily use.

The prototype user interface flow was based largely on the flow presented in the scenario. The aim was to strike a balance between the complexity of screens and the complexity of navigation. Because most participants in the focus groups used iPhones, the iOS pattern of a back button in the upper-left corner of the screen was chosen. The flow of the planning of a route resembles a wizard-like structure but still allows for a degree of freedom in navigation. The informational content of design follows the scenario. Filter options for a personalized route are made available before the route is presented. The route is presented using step-by-step instructions consisting of an icon and brief text. Tapping an individual instruction leads to a detail view consisting of a picture of the situation and a description in text. The text follows the structure of earlier research prototypes which were written by O&M experts [4]. The detail screen also presents the option to users to discards

this step whereby the system would hypothetically compute a new route around this point.

To make the prototype accessible with VoiceOver, the iOS built-in screen reader, the prototype was created using HTML, CSS and Javascript. For faster prototyping, the Ratchet framework was used [23]. The framework was created as a rapid prototyping tool for mobile apps and consists of common mobile UI-elements. To achieve VoiceOver accessibility the HTML are using semantic markup where possible supplemented with ARIA roles [24] where needed.

Visually, the Ratchet framework’s components were customized using CSS to create bigger buttons, more legible fonts and achieve higher contrast. To maintain a wireframe-like prototype feel, a mostly black and white color scheme was used.

Participants

The prototype was evaluated using 3 participants. The participants were focus group individuals who were interested in participating in future research. Only those who indicated to have vision of 5% or higher were approached. They were offered compensation of travel expenses and a gift card of 10 euros.

Test Setup

Participants were observed while they were given a set of tasks to complete using the prototype while thinking aloud. This protocol is a commonly used method in usability testing where participants are asked to think aloud while using a product [13]. Research on think aloud protocols suggest that the majority of usability issues with as little as 8 participants [17].

Also, the usability perception of participants was evaluated using the System Usability Scale (SUS) questionnaire. The SUS was originally introduced as a “quick-and-dirty” usability scale. Bangor et al. concluded however, that SUS is a “highly robust and versatile tool for usability professionals” even, based on analysis of 206 studies that used SUS [2]. Bangor et al. also explained what might be acceptable SUS-scores based on their research. They established that products that are at least passable have SUS-scores above 70, better products score in the high 70’s to upper 80’s and superior products score above 90. Brooke [9] argues in his retrospective of SUS that the questionnaire provides valid results with few respondents (8 to 10). The SUS-questionnaire was used as means verifying opinions that were observed during the test.

The tests were conducted using the following protocol: 1. Filling out the consent form (if not already filled

out and returned)

2. Filling out the intake questionnaire 3. Conducting the prototype test 4. Filling out the post questionnaire.

The testing consisted of task based instruction which were read to the participant and a pre-coded observation form based on the task and prototype screens. The post questionnaire consisted of the SUS-questions plus 3 questions based on a five-point Likert-scale and 4 open questions. The prototype was tested on prepared devices. The process was documented on video for future reference. Slight alternations on the prototype were done based on findings in the second test.

Results

Two out of three participants performed the tasks without much effort. One participant had significant issues with the accessibility of the app. Buttons were identified as ‘bars’ and also legibility of text and components proved to be difficult. The participant mentioned this was partly due to the smaller screen of the testing device as opposed to the participant’s own device. The participant tried to resolve this by tilting the display and trying to zoom in, which led to problems on the filter screen as the “switch” components of the Ratchet framework registered zooming gestures as taps. This broke both the zooming experience and the switching functionality. One participant had less trouble with legibility of the content but did mention ‘thin fonts’ making it more difficult to read. For the third test the prototype was slightly modified to compensate for accessibility problems found: Fonts were made thicker, borders of input components were made thicker, buttons were positioned with a larger margin from the screen edges and were changed to have more pronounced rounded corners. Lastly, the red and green buttons on the detail screen were changed to have better contrast.

In the questionnaire’s open questions participants mentioned the following positive aspects about the prototype and presented information: few steps to plan a route; limited information per screen; pictures for each step and icons. Mentioning of guidance features of the environment (such tactile paving or implicit guidance features such as curbs) was also considered important. None of the participants found information in the prototype unnecessary.

Missing information mentioned by participants were: • Bustle/crowdedness

• Road work

• Landmarks (street names, also based on sound or scent) Feedback on the presentation can be summarized as positive with aspects of simplicity being specifically mentioned. Negative aspects included legibility of fonts and components.

Filling out the SUS-questionnaire two participants scored the prototype with the maximum score of 100. One participant scored the prototype as 58 out of 100. An overview of SUS-scores of both evaluations can be found in appendix 4.

PROTOTYPE REDESIGN AND EVALUATION Approach

Prototype Design

Based on the results of the pilot evaluation the prototype was refined in the following ways.

1. The first screen was removed, current route / saved routes was moved into a tab bar at the bottom of the screen.

2. All buttons’ colors were checked and changed for better contrast, also when colors are inverted. 3. Buttons were changed to have more noticeable

rounded corners and a drop shadow to make them more recognizable.

4. All lists were changed to have borders and a margin to make content and grouping more recognizable.

5. The Ratchet framework toggle switches were replaced with regular checkboxes to prevent breaking of standard behavior such as scrolling and zooming.

6. When planning a route, user input was saved to prevent confusing participants with pre-filled in values.

The informational content in the prototype changed on two parts. One minor change was the addition of road work to the list of filter options. The second, larger, change concerned the detail screen of a navigation step. This screen was changed to replace the text description with three shorter statements: navigation instruction; information about the environment layout and accessibility features of the environment.

Test Setup

The test was performed with seven participants, recruited in the same way as the pilot evaluation.

The test procedure was changed in a couple of ways: • To include a different task-protocol (see appendix)

which contains smaller, step-by-step tasks for participants and provided a guide for asking supplementary questions. Specifically, a task was added to invite the user to view the detail of navigation app and change this part of the route.

• To help participants to think aloud, they were asked to practice with a specific everyday task: making a cup of coffee at home.

• Moderator role changed from a ‘pure’ think aloud protocol into asking participants about specifics of the prototype.

• Lastly, more elaborate instructions were given for the SUS-questionnaire to prevent confusion with the negative formulated statements and to invite more critical feedback instead of extreme (1 or 5) responses.

Results

Table 5 shows a summary of participant characteristics, vision categories and questionnaire results. This reveals no apparent relation between vision and performance on the test (SUS-score and number of errors). There seems to be a relationship between the number of errors and SUS-score; high number of errors coincide with high scores.

It is interesting to note that lowest SUS-scores seem to correspond with the highest number of usability errors during the test. Surprisingly, this also corresponds with the best diagnosed vision categories (>= 30%) of participants during the test. On the opposite side, the worst diagnosed participants (< 10%) performed rather well with little errors and gave a near-average SUS-score. One of these two participants performed the test on an Android device using no accessibility features, while the other completed the test based on an iPhone using VoiceOver output.

The think aloud protocol seemed problematic for at least one participant, who did not speak much during the testing even after reminders.

There were less accessibility issues found compared to the pilot tests. One issue was found during the only test that was completed using VoiceOver. The participant found multiple successive buttons containing the word “Route” confusing. During other tests, some issues emerged when the application flow was broken because accessibility features needed to be turned on or off. For instance, a participant using inverted colors needed to change back to normal colors to make sense of the images in the detail view. Lastly the participant using VoiceOver remarked that to make sense of the app, a lot of scrolling over UI elements was involved. It was also added that this was something that was encountered using every app and this prototype seemed relatively simple. Lastly, two participants using speech-to-text for input fields using functionality built into the iOS keyboard, experienced some confusing moments because iOS asks for a confirmation to actually enter the text. The app then asks for an extra confirmation planning the route.

Three participants experienced problems performing the task of changing an undesirable route step. One participant made remarks about uncertainty about what to do but eventually managed to perform the task. Another

Information filters # chosen / # participants

Avoid crossings 1 / 7 Traffic lights present 7 / 7 Audio signal present 6 / 7 Avoid squares 1/ 7 Separate sidewalk 4 / 7 Closest public transport stop 4 / 7 Road work 5 / 7

participant navigated back to the filter options and one participant did not succeed to perform the task. Only two participants mentioned the usage of icons in the UI, one stated they were very helpful while the other found them to be unnecessary. The pictures in the detailed view were received with mixed responses. One participant appreciated the pictures but found some of them to lack contrast. Another participant appreciated the impression they gave of the environment but found some of them confusing with regards to the instructions. A small map was suggested as an alternative.

Only two participants used VoiceOver during the test. One to complete all the tasks and one afterwards out of curiosity.

With regards to information needed to prepare for travel the following observations were made.

The filtering options chosen by participants are listed in Table 4. Summarizing this table, we can conclude that all but one participant found the option of crossings not useful since they were deemed unavoidable and not much of a problem when there are traffic lights. Related to this, all participants selected “only crossings with traffic lights” and 6 of 7 participants selected only crossings with audio signals. Squares were found to be not a big problem and mostly not selected and responses to the other options were mixed. With regards to address input, a participant

mentioned a preference for separate fields for parts of the address (e.g. street, number, city) as opposed to a single search field. The feedback of a time estimate compared to the shortest route was appreciated by most participants. With regards to the question what information in the prototype was unnecessary, 2 participants mentioned the

pictures in the detail view.

In the post test questionnaire participants indicated the following information items were missing:

• Road work (although present in the prototype) • Bustle

• Landmarks (including scents and sounds)

Statements

Mean (N=7)

STDev (N=7)

The information in the app was sufficient

3,71 1,28

The presentation of information helps with preparation for travel

4,14 0,64

It is easier to walk a route after preparation with this app.

4,00 1,41

Table 6. Participant response to additional questions. Age Gender Visual acuity Field of view Other conditions Device / Accessibility Features SUS Score # Errors during test

69 F < 30% Koker 10% lichtgevoeligheid nachtblindheid kleurenblindheid beperkte contrastgevoeligheid iPhone 6 / Kleurinversie aan 95 2 73 M >= 30% Uitval 1 oog lichtgevoeligheid nachtblindheid kleurenblindheid beperkte contrastgevoeligheid iPhone 6 / speech recognition, tilting screen 45 6 57 F >= 30% Kokervisus (onbekend) Lichtgevoeligheid nachtblindheid

beperkte contrastgevoeligheid Samsung (Android) / tilting screen 65 6

46 F < 10% Geen uitval

lichtgevoeligheid nachtblindheid kleurenblindheid

beperkte contrastgevoeligheid

(Met name 1 oog) iPhone SE /Voice Over 87,5 2

57 F < 10% Kokervisus (4 graden) lichtgevoeligheid nachtblindheid kleurenblindheid beperkte contrastgevoeligheid Samsung (Android) / None 85 0 55 F < 30% Kokervisus (8% centraal, ring 20%, perifeer < 10%) lichtgevoeligheid nachtblindheid kleurenblindheid beperkte contrastgevoeligheid

iPhone 6 plus / Custom font size, Color Inversion, Voice Over,

Siri 95 0 63 F < 30% Uitval centrumzicht Lichtgevoeligheid nachtblindheid

beperkte contrastgevoeligheid iPhone 6 / None 80 0

• Clearer instructions when crossing a street • Time indication when a route was changed

With regards to presentation of the information the following was mentioned:

• Icons on buttons can sometimes be confusing

• Colors and contrast were considered both positive as well as negative by different participants

• One participant found the presentation to be cluttered • One participant found icons in the UI to be unnecessary Results of the extra statements (see Table 6) show a high score (4,14) with a low deviation (0,64) for the presentation of the app which suggests participants find the presentation in the app useful for preparing a route. The other two evaluated statements show a more mixed picture which suggests participants disagree on the usefulness of the information and the perceived effect on walking a route. Lastly it was observed during the tests of all participants that the step-by-step route instructions were scanned superficially and not studied in detail.

DISCUSSION

In order to answer the research question multiple methods of data gathering were used. Both the observation and focus groups revealed types of information VIPs use to help them walking a route. The scenario helped triangulate some of the findings from the observation and focus groups and helped gauge reactions to help designing the prototype. The application of these findings in the prototypes and their evaluation allowed for more triangulation in a setting closer to a hypothetical reality. The prototype evaluations also allowed data gathering on usability and accessibility useful for further development in the EWPS project.

The types of information found during the observation and focus groups show overlap with types of information found in earlier studies. The biggest difference was that participants in the focus groups seemed to put a greater emphasis on obstacles. In this study, however, supporting evidence was found that the contents of these types of information might differ based on visual capabilities. For instance, blind participants prefer different landmarks than low vision participants. The scenario helped to verify information in the filtering section and gave a better understanding how a system might function for VIPs. The prototypes revealed to us that it is possible for low vision VIPs to use the prototype based on vision. Only 3 participants used VoiceOver functionality, only one used it for the complete test. This seems to confirm our assumption based on literature that low vision VIPs prefer to use visually based information when possible. The pilot tests revealed that, despite following guidelines and recommendations, accessibility of an app targeted at VIPs needs to be tested. The pilot tests pointed out several accessibility concerns which prevented evaluating the information in the prototype. The second prototype proved to be improved with regards to accessibility, although not

perfect. One issue regarded wording on buttons in a voice over situation. Other issues included hampered interaction when turning on or off OS specific accessibility features. With regards to information needs, some interesting results were found. The filter options chosen revealed the relative importance of traffic lights with audio signals. Participants preferred to walk routes which includes them as much as possible. While intersections and crossings were considered by participants to be unavoidable, other filter options showed no clear preference by all participants. From this we can assume they are based on personal preference. Another interesting observation was that the WHO categorization of the visual impairment and field of view of participants seemed to be unrelated to performance on the test and perceived usability. Reasons for this could be that the ability to see a smartphone screen is more dependent on specific nature of the conditions of a person.

CONCLUSION AND FUTURE WORK

In the process of researching information needs for low-vision VIPs when preparing for travel using an app, several observations were made. Evidence suggests there might be a relation between visual acuity and the contents of information types found during the focus groups. The stated information needs seem to depend on the way a person navigates using currently available means such as canes, guide dogs, and whatever vision that is left.

The prototype tests showed that the majority of participants were able to perform the test based on a visual, screen based representation of the information. The limited data, however, also suggested that WHO based categorization of participants was not predictive for performance on the test. This suggests that individual conditions and preferences of participants have a larger influence than the diagnosed visual acuity.

Results did suggest a positive effect on the participants’ perceived confidence after preparation using the prototype. However, observation showed that participants generally spent little effort studying the route instructions. In conclusion, it can be said that a route preparation walkthrough should focus more on summarizing orientation details than on step-by-step instructions.

The research presented in this paper provides several potential starting points for future research. One area of interest would be to study the individual preferences of VIPs with different visual acuity in more detail. Another opportunity would be to test the effect of a preparation app in an experimental setup to actually measure the effect of preparation.

REFERENCES

1. Dragan Ahmetovic, Cole Gleason, Kris M Kitani, Hironobu Takagi, and Chieko Asakawa. 2016. NavCog: turn-by-turn smartphone navigation assistant for people with visual impairments or blindness. 13th Web for All Conference, W4A 2016:

4–5. https://doi.org/10.1145/2899475.2899509 2. Aaron Bangor, Philip T Kortum, and James T

Miller. 2008. An Empirical Evaluation of the System Usability Scale. Intl. journal of Human– Computer Interaction 24, 6: 574–594. https://doi.org/10.1080/10447310802205776 3. Eliot Bentley. oTranscribe. Retrieved June 1, 2017

from http://otranscribe.com

4. Joey van der Bie, Britte Visser, Jordy Matsari, Mijnisha Singh, Timon van Hasselt, Jan Koopman, and Ben Kröse. 2016. Guiding the visually impaired through the environment with beacons. Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing Adjunct -

UbiComp ’16: 385–388.

https://doi.org/10.1145/2968219.2971387

5. Melis-dankers BJM, Else M Havik, Frank J J M Steyvers, Helen Petrie, and Aart C Kooijman. 2015. Accessibility of Shared Space by Visually Challenged People. Proceedings of ICEAPVI, 12-14 February 2015., February: 120–126.

6. Susanne Bodker. 2000. Scenario in user-centred design-setting the stage for reflection and action. Interacting with computers 13, 1: 61–75. https://doi.org/10.1016/S0953-5438(00)00024-2 7. Anke Brock, Emeline Brulé, Bernard Oriola,

Philippe Truillet, Annie Gentes, and Christophe Jouffrais. 2016. A Method Story about Brainstorming with Visually Impaired People for Designing an Accessible Route Calculation System. ACM CHI 2016 - chi4good, May.

8. Jacqueline Broerse, Dirk Essink, and Carina Pittens. 2015. Zicht op Onderzoek - Een onderzoeksagenda vanuit cliëntenperspectief. Retrieved February 20,

2017 from

http://www.oogonderzoek.net/rapportzichtoponderz oek.pdf

9. John Brooke. 1996. SUS - A quick and dirty usability scale. Usability evaluation in industry 189, 194: 4–7. https://doi.org/10.1002/hbm.20701 10. Hsuan-Eng Chen, Yi-Ying Lin, Chien-Hsing Chen,

and I-Fang Wang. 2015. BlindNavi: A Navigation App for the Visually Impaired Smartphone User. Extended Abstracts of the ACM CHI’15 Conference on Human Factors in Computing Systems 2, Figure 1: 19–24. https://doi.org/10.1145/2702613.2726953 11. Florence Gaunet and Xavier Briffault. 2005.

Exploring the Functional Specifications of a Localized Wayfinding Verbal Aid for Blind Pedestrians: Simple and Structured Urban Areas. Human–Computer Interaction 20: 267–314. https://doi.org/10.1207/s15327051hci2003_2

12. Reginald G Golledge, James R Marston, Jack M Loomis, and Roberta L Klatzky. 2004. Stated preferences for components of a personal guidance system for nonvisual navigation. Journal of Visual Impairment & Blindness 98, 3: 135–147.

13. John D Gould and Clayton Lewis. 1983. Designing for usability---key principles and what designers think. CHI 83 Proceedings of the SIGCHI conference on Human Factors in Computing

Systems 28, 3: 50–53.

https://doi.org/10.1145/800045.801579

14. Jan E E Keunen, C Anton Verezen, Saskia M Imhof, Ger H M B van Rens, Marc B Asselbergs, and J J Hans Limburg. 2011. Increase in the demand for eye-care services in the Netherlands 2010-2020. Nederlands tijdschrift voor geneeskunde 155: A3461.

15. Mirjam de Klerk, Henk Fernee, Isolde Woittiez, and Michiel Ras. 2012. Factsheet: Mensen met lichamelijke of verstandelijke beperkingen. 0, 8. Retrieved February 20, 2017 from http://www.scp.nl/Publicaties/Alle_publicaties/Publ icaties_2012/Factsheet_Mensen_met_lichamelijke_ of_verstandelijke_beperkingen

16. Hui Liu, Houshang Darabi, Pat Banerjee, and Jing Liu. 2007. Survey of wireless indoor positioning techniques and systems. IEEE Transactions on Systems, Man and Cybernetics Part C: Applications and Reviews 37, 6: 1067–1080. https://doi.org/10.1109/TSMCC.2007.905750 17. Jakob Nielsen. 1994. Estimating the number of

subjects needed for a thinking aloud test. International Journal of Human-Computer Studies

41, 385–397.

https://doi.org/10.1006/ijhc.1994.1065

18. Solveig Osborg Ose. 2016. Using Excel and Word to Structure Qualitative Data. Journal of Applied

Social Science, August.

https://doi.org/10.1177/1936724416664948

19. Uta R Roentgen, Gert Jan Gelderblom, Mathijs Soede, and Luc P De Witte. 2008. Inventory of Electronic Mobility Aids for Persons with Visual Impairments : A Literature Review. Journal of Visual Impairment & Blindness, November: 702– 724.

20. Helen Sharp, Yvonne Rogers, and Jenny Preece. 2007. Interaction design: beyond human-computer interaction. Book 11: 773. https://doi.org/10.1162/leon.2005.38.5.401

21. Sarit Szpiro, Yuhang Zhao, and Shiri Azenkot. 2016. Finding a store, searching for a product: a study of daily challenges of low vision people. In Proceedings of the 2016 ACM International Joint

Conference on Pervasive and Ubiquitous Computing, 61–72.

22. BlindSquare. Retrieved April 20, 2017 from http://www.blindsquare.com/

23. Ratchet. Retrieved June 1, 2017 from http://goratchet.com/

24. Using ARIA - Accessibility | MDN. Retrieved June

10, 2017 from https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniqu es

25. 2016. WHO | Visual impairment and blindness. WHO. Retrieved July 4, 2017 from http://www.who.int/mediacentre/factsheets/fs282/e n/

APPENDIX 1. SCENARIO

Scenario ter illustratie van Topic 4: voorbereiding van de reis

Luuk gaat zaterdag 3 juni op verjaardagbezoek bij zijn vriend, Bart. Hij is hier nog niet eerder geweest, aangezien Bart recent verhuisd is. Op weg naar Bart wil Luuk zijn cadeau besteld bij bol.com afhalen bij de Albert Heijn To Go op het Amstel Station. Luuk moet om 14.00 uur op bij Bar Joost in Amsterdam Oost zijn.

Ter voorbereiding van zijn reis opent Luuk de EyeBeacon omgeving. Met behulp van EyeBeacon neemt Luuk de volgende stappen:

• EyeBeacon begint met de mogelijkheid voor het instellen van een startlocatie. Hierbij is het mogelijk om gebruik te maken van de huidige locatie, een opgeslagen locatie of een nieuwe locatie. Luuk kiest hierbij voor de bestaande locatie “thuis”.

• Daarna vraagt EyeBeacon om een eindbestemming. Hier kan Luuk kiezen uit een nieuwe locatie of een opgeslagen locatie. Luuk kiest voor het invoeren van een nieuwe locatie en voert het adres van het café in. “Molukkenstraat 33 Amsterdam”

• EyeBeacon biedt de mogelijkheid voor het toevoegen van een tussenstop. Luuk maakt gebruik van deze optie om de AH To Go op het Amstelstation toe te voegen. Hij komt hier vaker dus hij staat tussen de opgeslagen locaties. • Vervolgens biedt Eyebeacon de mogelijkheid om een route te kiezen uit verschillende opties zoals:

o Kortste route

o Dichtstbijzijnde ov-halte o Minste oversteken (complexiteit) o Geen stoplichten

o Geen pleinen o Gescheiden voetpad o Geen park

o Geen trappen

Luuk kiest voor de route met de minste oversteekpunten.

De app informeerd hem dat deze route een duur heeft van 40 minuten en 10 minuten langzamer is dan de kortste route. • Ter voorbereiding van zijn reist maakt Luuk gebruik van de functie van EyeBeacon om de route te doorlopen. Deze

optie beschrijft de verschillende stappen, zoals verandering van richting, oversteekpunten, stoplichten en aandachtsgebieden zoals obstakels.

• Een van de stappen die genoemd wordt is de oversteek van een druk plein met veel verkeer. Luuk vindt dit geen goed idee en besluit het doorlopen van de route te stoppen en een alternatief te kiezen.

Luuk maakt opnieuw gebruik van de doorloop-functie en besluit na afloop om deze route te kiezen. Dit bevestigt hij door de route op te slaan als “Verjaardag Bart op 3 juni”.

APPENDIX 3. INFORMATION CATEGORIES FROM LITERATURE

Types of Information Needed (Golledge et al.) Guidance functions (Gaunet et al.) Type of information (Brock et al.)

Landmarks Location of pedestrian distances Street information Instruction about orientating towards directions Route information Instruction about crossing a street complexity Destination Information Progression street names

Building information Intersection public transport stops

Transit information Goal location traffic lights (w / wo audio signal) Route ending roadworks

orientation points crossing / roundabouts bridges

bicycle lanes position tov pedestrian path parks parkings stairs public buildings noises information points direction of traffic stores obstacles sidewalks

details regarding traffic quiet areas

outdoor seating areas in cafes shadows

smell

urban equipment

inclination of street/pavement rivers and water in general width of the street and sidewalk

APPENDIX 4. SUS SCORES

Participant Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 SUS Added SUS Final Q11 Q12 Q13

A 4 3 3 4 2 4 5 4 4 5 18 45 3 4 4 B 3 2 3 4 3 1 5 1 1 4 23 57,5 3 4 5 C 3 3 5 2 2 1 5 3 3 3 26 65 4 4 1 D 5 1 5 1 4 2 4 3 5 4 32 80 4 4 5 E 5 1 5 1 4 2 3 1 4 2 34 85 4 5 5 F 5 1 3 1 3 1 5 1 4 1 35 87,5 5 5 5 G 4 1 4 1 5 1 5 1 5 1 38 95 1 3 3 H 5 1 5 2 5 1 5 1 4 1 38 95 5 4 5 I 5 1 5 1 5 1 5 1 5 1 40 100 5 5 5 J 5 1 5 1 5 1 5 1 5 1 40 100 5 5 5

APPENDIX 5. USABILITY TEST FORM

Instructies en observatieformulier prototypetest voorbereidingsapp

Instructie

Met behulp van de prototype app gaat u straks een route voorbereiden. Deze route is onbekend voor u. Om de route voor te bereiden krijgt u een aantal opdrachten om uit te voeren met behulp van de app.

Tijdens de test wordt u door mij geobserveerd. De test gaat niet over u, u kunt het niet fout doen! Het doel van de test is om het prototype te evalueren. Daarom wil ik u vragen om zoveel mogelijk hardop uit te spreken wat u denkt en ervaart tijdens het uitvoeren van de opdrachten. Ik wil u graag 1 opdracht uit het dagelijks leven geven om even te oefenen:

Zet thuis een kop koffie!

Datum: Tijd:

Opdrachten

U gaat een nieuwe reis plannen van de opgeslagen locatie “Thuis” naar het adres “Molukkenstraat 33, Amsterdam”

a. Start met het plannen van een nieuwe reis. Scherm route plannen wordt herkend

b. Kies het startpunt van de reis, de opgeslagen locatie “thuis”.

Knop startpunt is herkenbaar? De lijst met opgeslagen locaties is

c. Voor als eindpunt het adres “Molukkenstraat 33, Amsterdam” in.

Knop eindpunt is herkenbaar? Invoerveld(en) adres herkenbaar? Knop adres zoeken herkenbaar? Knop Naar route is herkenbaar?

U gaat een aangepaste route kiezen op basis van uw persoonlijke voorkeur

a Kies voor het maken van een aangepaste route en zet de mogelijkheden van uw voorkeur op “aan” en plan de route.

Knop aangepaste route is herkenbaar? De aan-uit switches zijn herkenbaar? De knop route plannen is herkenbaar?

Overwegingen bij opties - Kruisingen vermijden - Stoplichten aanwezig - Rateltikkers aanwezig - Vermijd pleinen - Gescheiden voetpad - Dichtstbijzijnde Ov-halte

Ga naar route plannen en beschrijf

a. Bestudeer de route

b. Bekijk de detailinformatie van een stap uit de route in detail

c. Zoek de instructie over een “plein”, bestudeer deze in detail, vervang deze stap uit de route.

Scrollen Klikken op stap Reactie op afbeelding Reactie op beschrijving Kiest de juiste knop

Het opslaan van de route

a. Sla de route op en geef deze de naam “Verjaardag Bart”

Knop vindbaar (scroll) Invoerveld vindbaar Opslaan knop vindbaar Bevestiging duidelijk

b. Bekijk de opgeslagen routes en selecteer “Verjaardag Bart”