Easy Rider Navigation System: In the Pursuit of Riding

Transcription

1 1

2 Project Description The Easy Rider Navigation System is a navigational aid to a bicycle rider while touring. Before a ride our users, the members of the Southern Bicycle League, will predefine the route using the mapping system (component) of the system, and then download updated map, route and point of interest information to the mobile device. During the ride, Easy Rider will actively inform the rider where to turn, where to stop, and if he/she has strayed from the route. The system will contain detailed mapping and location information, and will help the rider find food and water, and other necessary resources. It will also provide the rider s current position, and if lost, help the rider navigate back to the route. The rider can change the route dynamically to suit his/her needs, and can even view a (simple) map to aid in orientation. Information is presented to the rider using a visual display system integrated into his/her glasses, and appears at the top margin of the rider s field of vision. The rider interacts with the system through buttons that are attached to the handlebars of the bike. 2

3 Requirements Summary Functional Requirements Easy Rider Navigation System: In the Pursuit of Riding Follow the route: Inform the rider when and where to turn, and when a planned stop is near. Locate points of interest: Provide a search capability so the rider can locate necessary resources such as food, water, a bike shop, medical aid, and campgrounds. Change/create a route: Allow user to dynamically change the current route, or to create a new route. Record route: Record the route the rider is riding, storing waypoints, distances, and times. Provide present location: Provide the rider with his/her present location, as well as the distance to waypoints and/or to stops along the route. Download /upload routes: Connect with mapping system to 1) download current maps, 2) download preplanned routes 3) upload recorded routes Work in limited capability mode: Even if the route tracking capability is down, the system should still provide basic map and route information, at least as much as the original map and cue sheet provided. Non-Functional Requirements Provide consistent response: the rider needs to have confidence in the device, and know what to expect regarding response times. Adjust to ambient conditions: Automatically adjust to light and/or noise conditions. Sturdy: the device will need to withstand vibration and some shocks Lightweight: should not add significantly to the weight being carried on the bicycle. Mobile: this is a given, the question is where to mount the device Easy to setup: the device on its own should require minimum setup, and once a route is downloaded, should allow route tracking with no further setup. There is another component, the mapping system that will also require setting up and connection to the Internet. Easy to use: the critical function of route tracking should require little or no training. Additional functions, such as route modification, may require additional training. Maximize recoverability: even if the user commits an error, the device should always allow the rider to return to route tracking, and load the original route Waterproof, rustproof: the device will be used outside, and needs to be able to withstand the elements 3

4 Design Summary Easy Rider Navigation System: In the Pursuit of Riding Functional Components The Easy Rider Navigation System is composed of the following functional pieces: Input Device 1 Ride Computer Processing Unit Display System Display Processor Input Device 2 GPS Display Screen Easy Rider is composed of the following overall components: Input controls - 8-position button, 4-position button Ride computer processing unit and tracking system Display system processor and screen Input comes from a 4-position button and an 8-position button. Each incorporates a battery and a wireless transmission system to communicate with the ride computer. Straps allow either one to be attached to the handlebars where user prefers. The 8-position button controls panning when viewing the map, while the 4-position button controls zooming. The 4-position button is also used to navigate the menu system, and to respond to system queries. The ride computer handles all the processing and tracking for the system. It is mounted on the bicycle, and incorporates the GPS sub-system and a rechargeable battery. It uses a wireless connection to communicate with the display system and with each of the controls. The ride computer is connected to the mapping system for downloading of maps and predefined routes. The display system is composed of a display processor and a display screen. The display processor is attached to the rear of the helmet, and includes a rechargeable battery. It accepts display information from the ride computer via a wireless connection, converts it in real time, and outputs it to the display screen via wire. The display screen is composed of digital and optical elements that are mounted on the rider s glasses. The rider can adjust the contrast, brightness and focal length. Please see below (While riding) and also the section describing Prototype 3: Visual Experience for more information. Other accessories include a pc cable and software, an a/c adapter for the ride computer, and a battery charger for the display and computer batteries. 4

5 Please see the section describing Prototype 1: Physical Prototype for more information regarding the physical characteristics of the system. The system displays information by overlaying it on the rider s view of the real world. It is presented to the rider at a fixed location in the rider s field of vision. Non-map information is displayed in the upper edge, while map information is displayed on the upper right side, away from the center of the road. The system affords interaction by presenting a series of menus in the display, and getting input from the buttons. Through menu interaction the rider can get location and distance information, as well as make limited route changes. Please see below (Interacting with the system) for more information. So, what is a route? Throughout this document we will be using the terms route, waypoint, stop, and point of interest. Here is a brief explanation. Each route has a name, and is composed of: A starting waypoint Waypoints along the route Stops along the route An ending waypoint Each waypoint represents a physical location. These are stored in a specific order, and serve to define the path to be followed. The stops represent a point of interest (food, store, and medical help) along the path. The combination of waypoints and stops constitute a route. An optional route is the same as a predefined route, except it must start and end on points of a predefined route. For example, when riders go on a group tour, the map he/she gets usually includes a 20 mile, 40 mile and 60 mile version of the route. This way, when the rider is approaching the beginning of an optional route, the system can offer this option to the rider. Before a ride There is some preparation required before a ride. Most of the preparation will occur on the nonmobile aspect, the mapping system defined in part 2. First and foremost, the user should charge the batteries for the ride computer and the display system. The battery charger supplied by the system can charge multiple batteries at a time, and additional batteries are recommended. Before going on a ride, the user should first download current information from the Internet in preparation for creating or modifying the routes for the ride. The data the user should download includes: A current map of the area The point of interest database 5

6 The user can also search the web to find routes that other riders have created and uploaded to a variety of cycling web sites. Any route that is downloaded will be checked against the updated map and point of interest database to verify its accuracy. The mapping system will graphically display the route (on a map) and provide a list of waypoints, stops, and distances. The mapping system also has its own database of routes that the user has accumulated, either through previous downloads, created by the user, or downloaded from the ride computer after a ride. The user can use an existing route, modify an existing route, or create a new one. When creating a new route, or modifying and existing one, the user will: Select a starting point Select an ending point Select places to stop Select waypoints on the route The user can ask the system to fill in the waypoints that he/she does not specify. The system will calculate the shortest path between each of the defined waypoints, and add the result to the route. When the routes for this ride are ready, the user will connect the ride computer to the a/c adapter and to the mapping system, and download the following data from the mapping system to the ride computer: The current map of the area The point of interest database The predefined routes When a ride first starts, the rider will select the route to follow. Please see Interacting with the system below. The selected route becomes the current route. It is important to note that the predefined routes are never altered. Any actions taken by the rider that affect a route will result in changing only the current route, or, more often, generating a new route that the rider can then select. While riding The GPS tracking sub-system knows where the rider is, and the direction he/she is traveling. By using the rider s location, direction, the map stored in memory, and the current route, the system determines and preemptively informs the rider: which direction to take when starting out where the rider should turn to stay on the route where the predefined stops are whether the rider is following the path defined by the route when the rider is approaching the beginning of an optional route The user has the option to put the system in quiet mode. The system continues operating, but will not display any information until the rider touches a control. 6

7 When starting out When the rider is first starting out, or after he/she has stopped for some time, the system helps the rider go in the right direction by displaying: what direction he/she should ride which road to take Once the system detects that the rider is going in the right direction, the message disappears. Approaching a turn As the rider approaches a turn on the route, the system displays: an arrow in the direction of the turn the distance to the turn the name of the street the rider will turn onto The distance counts down as the rider approaches the turn, and the message disappears once the turn has been taken. Approaching a stop As the rider approaches a predefined stop the system displays: the type of place defined the distance to point of interest the name of the point of interest The distance counts down as the rider approaches the stop, and the message disappears once the point of interest has been reached or passed. The rider is no longer on the route If the rider has strayed from the route, or is starting the ride at a location that is not on the route, the system informs him/her this condition exists and displays: the distance from the route the actual direction of travel the actual road the rider is on The system offers to lead the rider to the closest point of the route. If the rider accepts, the system reconfigures the current route, and includes the waypoints to reach the current route from the present location. If the rider does not accept the change, the system asks the rider whether to go into quiet mode. If the rider accepts, the system goes quiet until the rider re-activates interaction. Approaching an optional route When the rider is approaching the beginning of an optional route, the system displays: the name of the optional route 7

8 the length of the optional route the net distance added to the ride if the optional route is accepted The system gives the rider the option to accept the optional route. If the rider accepts, the system reconfigures the current route, and includes the waypoints to include the optional route. Warnings The system will display warning messages to the rider when one of the following conditions exists: Battery low GPS unreliable Interacting with the system At any time, the rider can use the system to: Locate key resources such as food or water View the map and pan and zoom Select a different route to ride View information about current location and distances Modify the current route The rider uses the 4-position switch to bring up the main menu. This, and subsequent submenus, are displayed in an upper corner of the display. The rider uses the buttons of the 4-position switch to: Scroll through menu options Select an option Cancel, and return to the previous menu The main menu has the following options: 1. Return to ride 2. Select a route 3. Find a place 4. Show the map 5. Show distances 6. Change the route 7. Options Return to ride When the user selects this option, the menu goes away and the system returns to following the route. Select a route The rider is presented with a list of the predefined routes, and can select from them. Once a selection is made, the system requests verification, and upon user confirmation the selected route 8

9 becomes the current route. The system then goes back to the main menu. When he/she tells the system to Return to ride, the system then detects if the rider is no longer on the current route, and it informs the rider and gives him/her the option to create a new path to get to the current route. Find a place (point of interest) The system asks the rider to choose the type of place, i.e. food, store, medical, bike shop, and campground). Once selected, the system displays a list of locations along with the distance from the rider s current location. The points of interest are in distance order, the closest first. If the rider selects a location, the system requests verification. If the rider accepts, then the system reconfigures the current route, and includes the waypoints to reach the selected point of interest, and then return to the current route. Show the map The system displays a simple map. The only information displayed is limited to streets, and the waypoints and stops on the current route. The initial view includes the rider s current location, and the next waypoint, as well as any stops. Using the 8-position button the rider can pan in any direction and can zoom in and out using the 4-position button. Show distances The system lists the type of information the rider can request, including: Current road and direction of travel Next waypoint: direction of turn, distance and street Next stop: type, side of road, distance and name Ending point: compass direction, distance and street Starting point: compass direction, distance and street Change the route The system provides the rider a limited ability to change the current route. The rider can ask the system to: Create the shortest route the system displays a list of the remaining waypoints and stops in the current route, and the rider selects the next waypoint or stop. The system then calculates the shortest path between the rider s current location and the selected waypoint or stop. Delete a waypoint the system will list the remaining waypoints and stops on the route, and the rider can select one of the waypoints and delete it. The system will then calculate the shortest path that includes all of the remaining waypoints. Reverse the current route the system will create a new route that will guide the rider back to the starting point along the path already taken. In each of the above cases, the system adds the resulting route to the list of routes, and the rider can then select the new route as the current route. 9

10 Options The settings the rider can change include: System pre-emptiveness Lead time to display system pre-emptive information Count-down increments for distances displayed Orientation of the map when shown Go into quiet mode Work in limited capability mode (GPS down or flaky) Although GPS is an excellent technology for determining a rider s location as well as the direction of travel, there are situations where it is not reliable. Our design has provisions for when the GPS system is not working, or is unreliable. If the system detects that GPS is not reliable, or the rider instructs the system, the system will work in limited tracking mode and assumes that the rider s current position is not available. The system still maintains the map, the routes, and the points of interest in memory. The system also provides distances from a fixed point of reference, such as the last waypoint. When following the route, the system will inform the rider what (not where) the next waypoint is, and which way to turn. Distances will be calculated based on the previous waypoint passed. Once the rider takes the turn, he/she will need to inform the system, and the system will provide information about the next waypoint. Even in limited capability mode, the system can list points of interest, displaying the distance from the last waypoint passed. The system can also display a map, oriented around the segment (waypoint to waypoint) that the rider is on. In any case, the rider can access the list of waypoints and stops on the route by using the menu system. In the background The system records the actual route the rider is riding. This information can be uploaded to the mapping system after the ride and can then be analyzed and/or converted into another predefined route. 10

11 Prototype 1: Physical Prototype Description The physical prototype should demonstrate the physical properties of all the subparts of our design. It s important to prototype these aspects of our design because several non-functional requirements should be satisfied. The user should get a good idea of how we tried to solve them. This prototype addresses the following requirements: Sturdiness: the device will need to withstand vibration and some shocks. Weight: it should not add significantly to the weight being carried on the bicycle. Weight plays an important role in the performance of a rider; all our users emphasized this aspect. They are only willing to use our design if the advantages overcome the inevitable increase in weight and additional discomfort. Size: the system should not interfere with the physical activities of cycling. Mobility: this is a given, the question is where to mount the device. It is also important that the device does not depend on a wired power source. Our design is based on battery power, and a battery life of at least 10 hours is necessary; a much longer life is desired. Resistance: the device has to be waterproof and rustproof because it will be used outside, and needs to be able to withstand the elements. To design this prototype we had to take into account several technological constraints. Thus, this prototype is based on what is realizable today with some assumptions about the technological development in the next five years. In Appendix A: The Technology, we describe the technology which forms the basis for some of our assumptions. The next illustration shows the schematic architecture of our design. Our prototype addresses the physical properties of each of these four sub-parts. Input Device 1 Ride Computer Processing Unit Display System Display Processor Input Device 2 GPS Display Screen In the following, the interesting physical properties of these sub-parts are described. These properties are directly influenced by our requirements; and the design is constrained by the technology that is described in Appendix A: The Technology. 11

12 Input Device 1 This is a button that has eight positions (clockwise from 12 o clock: forward, forward-right, right, backward-right, backward, backward-left, left, forward-left). This device can be attached to the handlebar (or another place where the rider likes it to have) with a Velcro fastener. There are rubber pads on the bottom side to prevent shifting. An important constraint is that it should be possible to operate it with cycling gloves; therefore the button must have quite a high resistance. The user has to be able to find it just by feeling for it without looking at the handlebar. Thus, the resistance needs to be high enough so that the button can be sensed through the gloves without firing a signal. And if the cyclist is riding on a bumpy road, the resistance of the buttons should prevent that the button is pressed because of bike vibrations that are transmitted through the rider s finger. It is also designed in a way that the user feels instant feedback when an output signal is fired. As soon as a certain pressure threshold is reached, the button suddenly releases the resistance; thus the rider senses a click through the gloves. Data is wirelessly transmitted to the processing unit; therefore we compared the size to wireless Bluetooth headsets that are used with mobile phones. Our input device can be built even smaller because less data (no voice data) is transmitted (we need less power) and because we don t have the constraint that it has to be attached to the ears. A small battery is integrated into the button. The button is attached directly to the ride computer when time comes to re-charge the battery. The size is 3cm x 3cm x 1.5cm plus the actual button in the middle. The weight should be less than 50g. 12

13 Input Device 2 This is a device that can generate four different output signals. It has two small long buttons; one of these buttons is on the left and the other is on the right. In the middle we have a bigger button, which can generate two output signals (you can press it down either on the front part or on the back part). The button is constructed in a way that allows the rider to feel for it without having to look at the handlebar. The thumb (or another finger) fits in between the two small buttons; the button in the middle has the affordance that a finger should be placed there (it has a concavity that matches the form of the finger). Similar to input device 1, the press resistance of the buttons is high enough in order to prevent that the buttons are pressed by accident. On a bike, the rider is normally exposed to high vibration and this should not cause an output signal. The user also gets instant feedback in form of a sensed click as soon as an output signal is generated. The rest of the button is very similar to input device 1. It uses Bluetooth to transmit signals wirelessly to the ride computer, and has a small battery integrated. When the battery needs recharging, the button is connected directly to the ride computer. It is also attached to the bicycle with a Velcro fastener and has rubber material on the bottom side. The size is 3.5cm x 2.5cm x 1.5cm plus the buttons on top of it; the weight is less than 50g. Position Tracker (GPS) The GPS chip and the antenna are in the same housing as the processing unit. It is wired to the CPU of the processing unit; it also shares the battery with the processing unit. The size and weight of the housing is described under Processing Unit. 13

14 Processing Unit Easy Rider Navigation System: In the Pursuit of Riding As mentioned above, the processing unit is in the same housing as the GPS chip; together they comprise the ride computer. So, the most important components the housing contains are the GPS-chip, the GPS-antenna, the CPU of the processing unit, external memory, the Bluetoothchip, the Bluetooth antenna and the battery. The housing has several external connectors: power connector to recharge the battery, data connector (e.g. USB) to upload maps, routes, points of interest etc. It also has two connectors for the two input devices; the input devices can be connected in order to recharge their batteries through the same wired power source. On the housing you can also see a button to turn it on/off. To have an idea of how to estimate the size and weight, we looked at existing commercial products ( A housing dimension of 10cm x 5cm x 1.7cm and a weight of less than 80g seem to be feasible. These existing devices all have a display, which we don t need; we therefore have a Bluetooth chip and more external connectors. If we combine this with our assumptions on the development of the technology in the next five years (better batteries, smaller storage, smaller CPUs etc), the housing can be even smaller if we had not the physical constraints of our external connectors. One charge of the battery is expected (in the future) to last as long as 150 hours. This unit will be attached to the bike s frame with two Velcro fasteners. To prevent shifting the contact surface is coated with rubber. The housing is water resistant and the external connectors can be closed with rubber plugs. 14

15 Display System Easy Rider Navigation System: In the Pursuit of Riding The display system consists of the display processor and the display screen. The display processor wirelessly receives data from the ride computer. The received data has to be transformed into a format that can be understood by the output screen (e.g. a VGA-signal). The technology of this device is based on the holographic display that is described in the Appendix A: The Technology. The visual output signal is generated in a small box that is attached on top of one lens of the glasses. This unit is connected with a small box (the display processor) that will be attached to the back of the helmet (with a Velcro pad). There are three small wheels on the glasses to adjust brightness, contrast and focal distance. This box integrates the battery, the receiver and the data transformer (CPU + graphic card). We decided to attach this unit there because the helmet better distributes the weight than the glasses can do. The wire (data + power) that connects this box with the display screen is lead through the straps of the glasses. Such a strap is normally used to hang the glasses around the neck when you don t want to have them on your nose. However, this strap is generally not connected to the helmet; therefore the rider has to plug the cable to the display processor when he/she wants to use the system. If the rider takes off the glasses (and the strap), it is automatically disconnected. To have an idea of the size of the display screen, we only have illustrations of the prototype. We think that this part is less than 30g and fits on top of the frame of the glasses. Because we don t know the exact power consumption of this output device, it is difficult to estimate the size of the display processor that is attached to the helmet. We looked at other head mounted displays and we think that the dimensions could be about 5cm x 3cm x 3cm and the weight is less than 70g. 15

16 Scenarios Easy Rider Navigation System: In the Pursuit of Riding Scenario 1: Setting up the system Lance is an enthusiastic bike rider and has just bought this new navigation system. Some of his friends have been using the system for a while and recommend it. He unpacks all the different devices and the manuals. He looks at the Quick-Start Guide. First, he attaches the buttons to the ride computer, and then connects the ride computer to the a/c adapter for charging. Then he connects the display processor to its a/c adapter for charging. At this point he starts wondering Boy, what have I gotten myself into? There sure seem to be a lot of pieces to this system! Lance spends the rest of the evening working on the mapping system part of the navigation system. Using the Quick-Start Guide, he installs the software on his pc, downloads a current map of the area and the point of interest database. He then works on setting up the route by following the instructions on the screen. He decides to define his house as the starting and ending points of the route. Once Lance is satisfied that he has created a nice easy route to test the system, he attaches the ride computer to the mapping system with the data cable provided and turns on the ride computer using the power button. The power led turns on. The mapping system detects the presence of the ride computer and runs a series of tests to verify proper operation. All is a-ok. Lance then tells the mapping system to download the route, the map, and the point of interest database to the ride computer. He leaves the ride computer and the display processor charging all night. The next day Lance gets up early, eager to try out his new navigation system. First he takes the ride computer and the buttons out to his bike. He attaches the ride computer securely to the frame with the Velcro straps supplied. Then he wonders about where the buttons go, and then remembers the Quick-Start Guide mentions that it s based on user preference. Lance attaches the buttons firmly with the straps provided. He tries to shift them about, but the rubber pads prevent any sliding. After a quick breakfast, and a kiss for his sleeping wife, Lance is ready to ride. He attaches the display processor to his helmet, puts the straps of the glasses over his head, and then plugs the strap s connector into the display processor. Again he thinks Boy, this is really a lot of connections and pieces. This better be worth it! He puts the glasses on, and sees nothing except his front lawn. After a second, he realizes he needs to turn on the ride computer, and he does so. Wow, this is neat. I can still see through the glasses, but I also see other stuff he tells himself as the system displays the startup message. Lance adjusts the contrast and brightness using the knobs on the glasses. He thought the glasses might feel uncomfortable, but they fit well, and the display screen does not obstruct his view of the road. The weight doesn t seem to bother him either. After initialization, the system displays the starting direction, North on Willow Road, which is the street that Lance lives on. Lance gets on his bike, and off he goes. The display turns off, and all he sees is the road. After a bit Lance starts wondering Is this thing still working? He looks down and notices the power led is lit on the ride computer. As he reaches up to fiddle with the 16

17 brightness, the system displays directions for the next turn. Whew, I forgot it only talks to me as a turn is coming up. Rationale We designed this prototype because we need to show how our system looks and feels. Performance is a very important aspect in sport. Additional weight and air resistance are limiting factors while cycling. So, size and weight are very important decision criteria for a rider and whether he/she wants to use such a device. This prototype is also important if we want to find out how it can be attached to the bike, the glasses and the helmet. There is also the fashion aspect that can play an important role, i.e. the better the device can be integrated in the bicycle, the less it disturbs the aesthetic sense of the rider. The input devices must not be too small because they are normally operated with cycling gloves. Finally, the devices must not interfere with the rider s normal movements or vision. Assessment The display is probably the most challenging aspect of our system. Some of the unknowns are: The actual weight and size Difference in weight on each side of the glasses Battery requirements How vibration will affect the display Will it work in bright light How will rain affect it Is it technologically feasible This prototype demonstrates the general size, weight and shape of each of the subparts. However, it is not complete: The charger is not shown and the two input devices cannot be connected to the ride computer (this would be necessary if you want to recharge the two input devices). The claimed resistance of the buttons is not modeled. The connectors of the processing unit cannot be closed to be water resistant. The wheels on the display screen for adjusting the brightness, contrast and focal distance are not shown. We also discussed this prototype with a potential user and got some positive and negative feedback: Positive Feedback The weight of the display system is ok; it didn t disturb him when he wore the glasses. We were told that the display screen that is attached to the glasses should be as thin as possible, so that it does not interfere with the helmet. The helmet is normally very close to the glasses. However, the helmet that was used to test it did not interfere with the display. 17

18 The connection between the display screen and the display processor at the helmet should not cause any problems. He had no objection that there was a small box at the helmet. Because he changes his helmet after around five years, it is not even necessary to be able to always detach this box. It would be easy to take the helmet with the display processor attached, and connect it to the charger. Negative Feedback The buttons are too big. He thinks that the buttons have to be more discrete because such big buttons are not aesthetic. The size of normal calculator buttons would be ok. He would like to have the display box, which is attached to helmet, a bit wider and thinner. He didn t like that there are so many different pieces. It is troublesome to recharge too many pieces. He would therefore not mind if the buttons are wired with the processing unit. We could perhaps use a similar system to the one that is used for bike computers. Only the cables and clip-on devices are fixed to the bike. The actual button could be attached to such a clip-on device. If the rider wants to use another bike, he/she only needs to have an additional clip-on device and the cables; but the same buttons could be used. The processing unit should have a different form. Because most parts of the frame are round, the processing unit should be made of flexible material or one side should better fit to the form of a round bar. One solution could be to fix a quick-release that allows easily attaching and detaching the processing unit. He also proposed to only have one input device. He wouldn t mind to have fewer buttons to control the same functionality. He had some ideas: our eight position button could have a middle button; it should be possible to press it down in the middle. He also proposed to use small wheels that could be turned and pressed down. All these buttons should be integrated in one input device. Fewer sub-devices are better! 18

19 Prototype 2: Interaction Description Easy Rider Navigation System: In the Pursuit of Riding This prototype demonstrates how the user can interact with the system while riding. It allows the user to bring up the menu and to complete tasks such as viewing a map, selecting a route, finding a point of interest, and other useful operations. Providing the rider with easy interaction is a critical part of the design. The more complicated and time consuming the interaction is, the more dangerous it is for the rider to use. The challenge is to provide a functional menu without distracting the user or drawing too much of their attention away from the road. With these goals in mind, we designed a menu which would: Be placed in the upper right corner of the riders vision Was easy to turn off and remove from the field of vision Only take 2-4 steps to accomplish any action Was easy to understand Used the buttons in an effective manner with straightforward mapping Interactive tasks The menu also has to provide the rider with the ability to carry out certain tasks. These tasks are: Return to the route o Allows the rider to exit from the menu Select a route o The user must select the route that will be followed. This route becomes the current route, the one that will be followed. Find a place o Riders can select from multiple categories and find what points of interest are in the vicinity and how far away they are. The predefined points of interest are programmed into the route before riding. Show the map o This displays a map of the area showing the area that includes the rider and the next waypoint. The rider can then pan and zoom on the map. Show Distances (cue sheet) o This displays the upcoming waypoints by distance, and is a metaphor for the popular cue sheet the some riders use. Change the Route o Allow the rider to make changes to the route, such as changing a waypoint or to go directly to a certain waypoint. Options o Provides the user with the option to change system settings 19

20 Menu structure The actual menu structure is as follows: 1. Return to the ride 2. Select a route 3. Find a place a. Store b. Restaurant c. Bike shop d. Police e. Hospital f. Scenic g. Campground h. Friend i. 4. Show the Map 5. Show Distances a. Current b. Next waypoint c. Next stop d. Ending point e. Starting point 6. Change Route a. Shortest route b. Review waypoints c. Reverse the route 7. Options a. System pre-emptiveness b. Lead time to display messages c. Count-down increments for distances d. Orientation of the map e. Go into quiet mode 20

21 How the prototype works Easy Rider Navigation System: In the Pursuit of Riding When the user activates the menu, it is displayed in the upper right side of the rider s field of vision. The first five options are shown, and an arrow at the bottom of the menu indicates that there are more options to select from. To the right side of the screen, a graphic depiction of the menu selection buttons is shown. These represent the buttons that are mounted on the bicycle to control menu scrolling and selection. For this prototype, the user clicks on the button on the screen, and the appropriate action is taken. The down and up arrows are used for scrolling on the menu. A white box around a menu option indicates that this is the currently selected option as shown below. The user can then click on OK to access that part of the menu, or cancel to exit the menu. 21

22 In this picture, the user has already clicked on OK to access Select a route. As you can see, the system displays the list of routes that the user can select from. If the user wants to select a route to ride, they click on OK the desired route selected (i.e. Stone Mountain). Once the user clicks on OK, they are asked to confirm the change. If the user selects Yes, the route is confirmed and it becomes the current route. The system then directs the user to this route. If the user doesn t want this route, they can click on Cancel, or they can scroll down to No and select ok. 22

23 In this picture, the user has selected Yes and they are taken back to the main menu. The menu for Find a place (point of interest) has some differences from selecting a route. When the user selects Find a place, the menu displays different categories for the user to select from. 23

24 The user then selects a category to show the places that are available. In this example, the user has selected Restaurant. The available places are displayed. The user can select one and the system displays information about the place. Note that the distance is highlighted to help the user find where the distance is located. Another important feature of the system is the map. With the map, the user also employs the other set of buttons. The panning button is used to move around the map. In the picture of the prototype below, the 8-directional button is shown with each arrow around the center representing a push of the button in that direction. Zooming is accomplished by using the up and down buttons of the other set of buttons. (Note that only one of the arrows is black, and the rest 24

25 of the arrows are grayed out. This is done because the prototype does not have the full functionality of panning, and can only pan in one or two directions.) Here is what the display looks like with the map and with the two sets of buttons represented. The user then can zoom in by clicking on the up arrow, or pan left by clicking on the arrow left of the lower button. Here is the result of clicking on the left button to pan the map. 25

26 The user can zoom in by clicking the up arrow, and the result is shown below. To exit the map, the rider clicks on Cancel or OK. Scenario Lance is a moderate rider and is looking forward to a day of riding. His friend Usps (that s really his name, it sounds like oops), ed Lance the route that he had ridden last week. Lance downloads the route, Blue Sky, into his Easy Rider. Lance gets to the start of the route, gets on the bike and puts on the Easy Rider glasses. He hits the OK button to bring up the menu, and then selects Select a route. From there Lance s stored routes are shown, and he selects Blue Sky. He then confirms his selection, and begins to head North on Spring Street, following the initial directions of the system. After riding for a few minutes, Lance is curious about how far the next waypoint is. He hits the OK button to bring up the menu. From there he selects Show distances and then selects Next waypoint. He reads the information and is now knows the distance to the next waypoint. Later on, Lance takes a look at the map by bringing up the menu and selecting Show a map. After looking at it for a few seconds, he thinks he knows where he is, and he remembers that he doesn t really like the upcoming hills. He then determines where on the map the hills are located, and figures out which waypoinst takes him there. Lance goes back to the main menu by selecting OK, and chooses the Change the route option. From here Lance selects the Delete waypoint option and then deletes the waypoints that go through the hills. The system calculates a new path, and stores it. Lance then selects the new route and avoids those tough hills. After riding about 10 miles in the direction of the new waypoint, Lance starts thinking I don t really like this route. There s a Super Wal-Mart over there, an airport, and that big office 26

27 building. He takes a look at the map again, and realizes that the hills aren t that bad and he d rather get back on the original route. So he thinks OK, I screwed up, now what can I do? One option he thinks of is to continue on the route that he entered. This will eventually bring him back to the route, but only after riding another 40 miles. He can backtrack until he gets back to the route he was on. However, he doesn t really want to ride where he s already been. After considering these two options, Lance remembers that the original route is still stored in the system. He then brings up the menu again, and chooses Select a route, and selects Blue Sky. The system tells him which direction to go in to get back to the closest point of the original route, which is only a couple of miles away. Rationale Interaction is a critical aspect of our system. This prototype was chosen to show how the rider would use the buttons and the menu to interact with the system. The prototype provides a somewhat accurate feel for how the rider would interact with the menu, given that we re unable to provide the actual visual device the rider would wear to provide the 3 dimensional environments. The menu structure and navigation accurately depict what the design intends to do. And while the buttons are not the actual buttons on the bike, the user was able to see the buttons and manipulate them with the mouse in a similar fashion as if they were pushing down on them. Of course, we cannot show the user what it feels like to interact with the system while riding. We realize that, without this ability, there is no way to know how the system works. Assessment We had our user interact with the prototype and we received these comments: When showing waypoints, have the distance displayed with the name, instead of having to select the name to find the distance Why do I need to confirm my route selection? I already know what I selected. I see the map. Now, where am I Maybe pushing left and right would navigate the menu instead of cancel and ok. Show distance should be called Cue Sheet Some other ideas our user came up with: When selecting the Find a place option, we don t need to show the categories. The numbers are not necessary in the menu. Use icons instead of names and categories for points of interest Show points of interest that are on and off the route, and let the rider know the difference Clicking on the point of interest should bring up the map showing the point of interest and the rider s location From our own assessment, we came up with these problems: In order to gather information such as point of interest, the rider has to spend too much time navigating the menu 27

28 The map is difficult to read and it takes time for the rider to locate themselves on the map Based on the feedback from the user and our own perspective, there are some issues that should be addressed with the menu. The map is too complicated for the user to read quickly and safely. In order to resolve this problem, we intend to highlight the rider s position and waypoints with the white color. In addition, the time taken to navigate the menu also could be cut down. A few things we can do to cut down the time is by adding the distance to the waypoint names when the user selects Show Distance, cutting out the categories after the user selects Find a place, and not asking for confirmation after the user selects a route. The numbers before each item should also be removed from the menu. The users also thought some parts of the map were very good. They liked how the selected menu item was highlighted and how the menu was rather small and did not take up to much space (with the exception of the map). Overall, the real test for the menu is when it is compared to a paper map. If it is easier to gather information from the menu than a paper map, then it is a success. If the paper map is as easy to use as the menu, then there is no point in using the Easy Rider system. 28

29 Prototype 3: The Visual Experience Description Our third prototype is intended to provide a feel for the experience that awaits them while riding with our system. It consists of a film of a ride, from the point of view of the rider (i.e. seeing out of his/her eyes) with system information superimposed. It attempts to demonstrate: How the information is displayed (color of display, opaque/translucent) What information is displayed (distance, points of interest) Where the information is displayed in the field of view (right/left, above/below) When the information is presented to the rider Each of the aspects is a big contributing factor in our prototype as each defines a part of the experience. The rider should feel at ease in adapting to the display, and at the same time be able to make optimum use of the information disseminated to them. Most importantly, our movie tries to give the viewer a notion of what the real world looks like with system information being displayed while riding and trying to look out for traffic and bumps in the road. Information should neither be obtrusive nor should it be overwhelming for the biker. It should be in the right doses, at the right moments during the ride, else it loses its impact. The biker should have a natural experience while riding, and the design should not take away from the ride. The information displayed by the system is divided into 4 categories: 1. Directions 2. Points of interest (POI) 3. Interactive menu 4. Interactive map The Visual Experience: The visual experience is the collective mix of the aforementioned design parameters and gives the biker a feel for device performance during the ride. The prototype shows off the visual interface, which guides the biker as well as allows for their interaction with the system. The Prototype consists essentially of a video of a biker taking a ride. During the ride, the display shows relevant information to the biker in the format described later. He/she sees the turn coming up along with distance to cover before the turn. The arrows provide good mental mapping to the biker in so far as to allow him to easily comprehend the direction of the turn. The distance before the turn helps the biker to judge and keep him on track by keeping such information in the back of his/her mind. 29

30 When a point of interest approaches, the prototype gives a notification similar to directions which inform the biker about the next approaching point of interest - the category it falls in, the name of the POI as well as the distance to it. The distraction level of the experience has been minimized by keeping the displayed information accessible yet out of the direct line of sight by placing it at the right hand top corner. When the biker notices a change in the display (which is out of focus though the change is discernable), he/she glances up to see the information displayed and makes a mental note of it. If the turn/point of interest is close, the information stays visible to allow for the biker to be reminded continuously. The distance counts down as the turn approaches. The biker can pull up menu using the buttons on the handle bar. The menu comes into view and gives the biker options. He can then interact the system, which makes the device both user as well as system pre-emptive. The visual experience is immersive to the same extent as taking out a physical map or less, hence the device will be as safe as riding with a physical map, if not safer, at worst. Display As a turn is approaching, the system displays information to the rider about the direction of the turn, the distance to the turn, and the street name. The rider can set the lead time to display the turn information. It is displayed continuously, with the distance varying, until the rider has completed the turn. When the rider is approaching a predefined stop, the system again displays information about to the rider: the type of resource and where it is relative to the road, the distance, and the name. 30

31 The system takes into account a variety of possibilities such as 2 waypoints coming within close vicinity of each other, as well as 2 points of interest. When there are two or more waypoints or points of interest that need to be displayed, the system displays the closest one and a small star is placed below the information, indicating that there is another one approaching. This keeps the biker alert and ready to tackle the turns one after the other. When the rider needs to interact with the system in order to get information or to make changes to the route, they activate the menu system. This is displayed in the upper right of the rider s field of view. 31

32 At the rider s request, the system displays a map. While looking at the map, the biker does not see other information, unless there is a turn coming up close by. In such a case, only a red arrow is shown to denote the turn. Zooming and panning are functions provided while displaying the map. The lead time to display turn and stop information is set by the rider. The rider can also choose to see distance in miles (1 mile, 0.5 miles, 0.2 miles) or in yards as the turn nears (300 yards, 150 yards, 25 yards). Scenario Lance has been having a hectic week. He decides he needs to get away for a while, maybe not out of the city, but out of the rut. He makes it a point to take a ride this weekend. He plans a route on his computer, and downloads it to the device. He gets out his gear, and puts on his glasses and his helmet. He s out riding, and sees a change in the display at the corner of the eye. The change isn t obtrusive. He looks up to see the status of the next turn, which is quite easily understood as the arrow is on the right of the display, and denotes a right turn. He glances at the name of the street in the display to ensure he makes the right turn, and the distance gives him an idea of the time lapse till the turn. The display appears at about 50 yards from the turn (and keeps counting down), since he has preset this distance. This allows him to always gauge and approximate the time till the next turn. 32

33 Lance sees the street coming up, and realizes the GPS system is not working at 100%, since the display still shows 25 yards to go, but the turn is much sooner. Fortunately, the system also provides the street name. He keeps on going. The ride is fun and he feels good while on it. It s a bit taxing but the gentle breeze keeps his spirit up. The system updates information based on his current position and informs him of a predefined store stop (point of interest) coming up. He makes a mental note about it and continues riding. Quick glances keep him updated about the estimated distance to store. He sees it, but decides not to stop. The information disappears and he puts his full attention back into the ride. Some time later he notices another turn coming up. As the turn gets closer, he notices that there is also a restaurant right after the turn. He keeps this in mind and makes the turn. The turn sign goes away and the distance till the restaurant keeps counting to nil. He passes without stopping, as the thrill of riding is what he really needs right now. After a while, Lance enters a deep valley with dense foliage. As he approaches the lowest parts of the valley, the system displays the message GPS down. The system then notifies Lance that the next turn is on Valley Way and is 4.6 miles from the last waypoint. The system asks Lance to confirm that he has reached the waypoint. Lance rides until he sees a sign for Valley Way, turns onto the road, and notifies the system. The system displays the next waypoint and the distance to the new waypoint, Peachtree Street. Lance rides for a few miles and approaches Peachtree Road. He turns right and notifies the system that he has reached this waypoint. The new waypoint is displayed, and Lance keeps riding. About a mile later, Lance runs into a dead end. How is that possible? Is my system wrong? Lance stops riding and brings up the map. The system shows him the area from Peachtree Street to the next waypoint. It shows that there are 7 miles between these two waypoints. But the road is not that long. Lance then zooms the map out, and takes a look at the last few waypoints. Upon closer inspection, Lance notices that Peachtree Street and Peachtree Road are two different paths. He then gets back on his bike and backtracks to Valley Way. From there, he turns right and heads down Valley Way until he reaches Peachtree Street. Now, he looks at the information and heads for the waypoint that is shown. After a few more turns, Lance leaves the valley and the GPS satellites are again visible. He then continues his route without any problems. Rationale This prototype was designed to give the bikers a feel for the visual interface, which would act as the link between the physical device/information and their cognitive drive. The need for this prototype was to show as well as assess how the biker perceives information regarding the ride. The prototype lets the biker immerse him/herself in the visual experience that allows him/her to get a feel for the interface. The color red and white were chosen as they are clearly visible, easy to overlay and combined they are readable in any background. 33

34 Assessment Easy Rider Navigation System: In the Pursuit of Riding Though the experience tries to get as real as possible, it cannot give a feel for the 3 dimensional aspect of the device. In the device, we allow for changing focal distance of the display, which allows for the biker to focus with less strain on his eyes. But this functionality cannot be incorporated into the prototype. Some comments that we received from the users: Can place the arrow lower on the display red box not necessary around arrows and points of interest progress bar easier to read along the edge of the vision than textual information textual information is harder to process arrow should change as the rider approaches the turn visually tactile hide/show display by hitting a button hitting any button brings up the show mode when in quiet mode show all information when calling show mode display rider s average speed cadence/how fast your feet move button to switch the colors due to brightness kill switch to end display From this excellent feedback, there are some changes that would improve the system. Probably the best idea is to remove as much text as possible and replace that information with graphical representation. Instead of having the distance to the next waypoint listed in a numerical form, we could have a status bar, or the arrow could vary based on the distance remaining. Another idea was a button to reverse the color of the display. This idea would allow for users to deal with different color backgrounds and levels of brightness. For example, if the current conditions make it difficult to read the color red, the user can hit the reverse color button, and all of the text will be white with red behind it. Another interesting point the rider mentioned is that hitting a single button would bring up the information for the next turn, distance traveled, and a few other bits of information. This is discussed more in the assessment of prototype 2. 34

35 Detailed Evaluation Plan Easy Rider Navigation System: In the Pursuit of Riding Please see our Final Summary section for an important discussion on significant changes to our usability criteria. These include safety (which we cannot evaluate at present), learnability and recoverability. One of the best ways to get feedback on our design is to talk to our users. A focal group should provide valuable information about user acceptance of our design, and whether it meets most of the functional and non-functional requirements. We also want our users to help us determine whether the interaction the system provides is straightforward and easy to use. In particular, we want to measure the learnability of our system. We feel a think-aloud would provide valuable insight from our domain experts. Finally, we plan to engage a group of HCI experts to help us evaluate whether our design meets both of our new criteria, learnability and recoverability. We feel that a heuristic evaluation would be appropriate for this. Evaluation A: Focal Group Our first method of evaluation will be a focal group (i.e. a group interview) composed of our users to measure the acceptance of how the system implements some of the functional and nonfunctional aspects of our design, including: Follow the route, locate points of interest, record route, provide present location, work in limited capability mode, download /upload routes Adjust to ambient conditions, sturdy, lightweight, mobile, waterproof, rustproof We intend to show them our three prototypes. In addition, we will describe and discuss in depth how our system works, and how it deals with technical aspects of navigation (routes and waypoints). The physical prototype will help us determine whether the form factor is acceptable to the riders. We will ask the users to comment on: Size and weight of the components The buttons and their arrangement and how they work The number of components that make up the system Where the components are attached to the bike Batteries, and the necessity to charge or change The requirement to remove components from the bike and reattach Through our visual prototype we want to get their feedback regarding the amount of information displayed, the way the information is displayed, and where the information is displayed. By explaining how the system works, and showing our domain experts the interactive prototype, we are looking for feedback relevant to the system s functionality, and its applicability to navigation while riding. 35

36 The users will be free to discuss any topic at any time. Some of the evaluators will focus on interacting with the users, while others will take notes of the session. Evaluation B: Think-aloud Using the think-aloud method of evaluation we intend to evaluate the learnability of our system. We will ask individual domain experts, our users, to use the interactive prototype to perform specific tasks that we will define. The only instruction they will be given is how to enter menu mode. While they attempt to perform the tasks, we will request that they think-aloud and explain the why s and wherefores of their actions, and their reaction to system responses. In this way we expect to evaluate the ease with which a first-time user interacts with the system, and the learning process they go through to accomplish each task. The interactive prototype will need to be further developed in order to simulate a more complete system. The rider will use a mouse instead of buttons on the bike, and the environment will not carry the distractions that riding a bike does. Evaluation C: Heuristic Evaluation We will use a heuristic evaluation performed by HCI experts using the interactive prototype to help us determine the recoverability of the system. We will ask them to base their evaluation on the following heuristics: Error recovery does the design allow the user to recover from a mistake, particularly if it results in modifying the current route? Error prevention does the rider know when an action may cause changes to the route, or to the interaction with the system? User control and freedom can the user easily navigate through the system, and comfortably move between following the route, interacting with the menus, and accessing the map, without getting stuck? 36

37 Final Summary Easy Rider Navigation System: In the Pursuit of Riding In this section we describe how we arrived at many of the aspects of the system, as well as modifications to our requirements specifications and our usability criteria. Modifications to our requirements specification At the end of Part 2: The Design, we indicated that, though our functional requirements did not change, we would need to compromise significantly in order to maintain a high degree of rider safety. In particular, the rider would need to stop in order to interact with the system In Part 3: System Prototype and Evaluation Plan, we looked carefully at our existing requirements, and we feel that they continue to be relevant and important. We looked closely at our designs and studied how to implement a system that will fulfill our requirements. The result is a design that we feel substantially implements all of our requirements, and strives to maintain rider safety. Additionally, we count on each rider s sense of self-preservation to decide what is possible while riding, and when to stop to interact. Modifications to our usability requirements What we were thinking of At of the end of Part 2: The Design, our important criteria was responsiveness, task migratability, and dialog initiative. Well, as our learned professor said, the devil is in the details. Well, she s right. Task migratability has to do with the ability to shift tasks between the user and the system, depending on available resources and user preference. Since GPS forms the basis for our tracking technology, and may be unavailable at times, we designed our system to work in limited capability mode. If we were actually building a functional prototype we could test this capability. As it is, we can describe how the system works in that mode and get user feedback. Dialog initiative is concerned with the pre-emptiveness of the system vs. the user. Although we feel that the system should pre-emptively inform the user when a turn or a stop is coming up, we have determined that the user should have the option to decide. So our design allows the user to put the system into quiet mode (completely user pre-emptive), and to change some settings related to system pre-emptiveness. So, as far as task migratability and dialog initiative, we have designed this usability into our system. Responsiveness is a bit more complicated. We absolutely feel that this is an important criteria, and if we could, we would test for it. In part 1 we mentioned running experiments to determine what level of responsiveness would be acceptable for the user by varying the response times of the system and asking users to rate performance. With empirical results in hand, we could then make sure that the system could provide adequate responsiveness. 37

38 What we think now Easy Rider Navigation System: In the Pursuit of Riding After working on the nitty-gritty of the design, we have focused our sights on a new set of evaluation criteria, based primarily from the user s point of view. At the top of our list is safety. Safety is directly related to the amount of distraction the rider is subjected to while using our system, and to how much of the rider s view is obstructed by the physical device. Some questions we would like to answer: Does the displayed info (signs, menus, maps) distract the rider? Does the displayed info block the rider s view? Can the rider interact while riding? Is the interaction distracting? Can the rider carry out complex tasks while riding? Does the physical device block the rider s view? What is acceptable? What is too dangerous? Second on our list of important usability criteria is recoverability. There are several aspects of our design that permit a user to make changes to the current route, and we want to make sure he/she can recover from these changes. And, since the system works in more than one mode (follow the route vs. interactive), we want to make sure a user can always find their way back to follow the route, and can maneuver through the menu system with little or no confusion. Finally, third on our list of usability criteria is learnability. The system requires practically no learning when using it to follow a predefined route, but this is only a fraction of the functionality offered by the system. And, since the user will be interacting with the system while riding a bicycle on roads and with traffic, we feel it is essential that basic interaction with the system be very easy to learn. This includes: Locating key resources such as food or water Viewing the map, panning and zooming Selecting a different route to ride Viewing information about current location and distances Very simple changes to the route Design and Implementation Process When we started part 3, on of the first things we did was take a closer look at each of our designs from part 2. We tried to determine which of the 3 designs would do the best job. Well, we weren t quite satisfied with any one of them, and here are some reasons: Maptacular o was not system pre-emptive enough o made the rider look down to get information o made the rider look down to interact Cycling Partner 38

39 o provided limited information density o interactivity provided was too basic Magic Glasses o provided limited information while riding o required the rider to stop in order to interact o required the rider to stop in order to get significant information Essence of our design As a result of extensive discussions within the group and also based on meetings with learned professors, we developed a list of essential design criteria. In a sense, we went back to the drawing board (actually, literally). While riding, our design must: permit the rider to look ahead at all times display only necessary information be primarily user pre-emptive, unless displaying time-critical information allow the user to adjust the pre-emptiveness of the system provide additional information to the rider at his/her request allow the rider to make changes to the route While riding, our design must not: block a significant part of the rider s view engage the rider in complex interactions connect the rider to the bicycle. And we must: KISS yup, Keep It Simple, Silly!!! In the sections that follow we detail the process that we went through to arrive at our final design, and how we decided on our prototypes. Controls This was relatively easy. We wanted to allow interaction with the system while riding, and we needed to give the rider a fair bit of control, and we got some excellent advice from a learned professor. So we went with buttons. What wasn t so easy was: Where do we put them How many What do they do How should we orient them While using the map we wanted to provide the ability to pan and to zoom without having to change modes. This would require on the order of 6 buttons, 4 for panning (north, south, east, west) and 2 for zooming (in, out). 39

40 When interacting with the menus, we determined we needed 4 buttons, 2 for scrolling (up, down), 1 for selecting, and 1 to cancel. We designed our prototype in this fashion. When we showed to our user, he had lots, and lots in input, all of it very good regarding: The size The position The number of buttons The feel of the buttons He even took us to a bike shop, and showed us examples of bike computers, and the kind of buttons they use. Augmented Reality When we started talking about how information would be displayed to the rider, we decided it should be presented visually, without requiring the rider to look down to see it. It sort of went downhill from there. We started a lively, multi-session discussion on the pros and cons of augmented reality. Here s how it went (kinda): We want to display information like road signs and bulletin boards and arrows on the road Yeah, but then you need lots of extra equipment and technology, battery, cameras, additional processing But what about the metaphor of road signs Maybe this is one example where the metaphor doesn t really work. Yeah, but then the design becomes boring! The real question is: Does it significantly add to the usefulness of the system? Augmented reality, i.e. synchronizing system output with the world, does not add a significant benefit. Besides, it s really hard, and adds too much complexity. So we decided, we won t use augmented reality. Registration We then discussed the need for registration, i.e. tracking head movements: If we re not lining up, why register Don t we want to show the map and menu when we look down? If the rider has to look down, then they are not looking forward So where do we show the map Well, show it in the field of vision Yeah, but won t that be dangerous? Less than having to look down! 40

41 So, we realized we had no need for registration. Easy way out? At this point we felt a bit like we were taking the easy way out, reducing aspects of our design in such dramatic ways. We had started with such grandiose plans for our Magic Glasses, and now we were talking about just a regular display. Well guess what: 1. Just cause it seems like a neat idea doesn t mean it s a good idea. 2. Fancy technology won t necessarily add to functionality, and could take away from it. 3. Sometimes you just have to get back to basics. 4. Our tough decisions weren t done The actual display So now we needed to figure out the basis of our display technology, so we could realistically estimate size, weight, and other parameters about our display system. Admittedly we got a bit stuck here. We did research on the web, spoke to more professors, saw examples of wearable displays, and, well, beat the topic to death. The professors we interviewed, who have expertise in the area of wearable visual displays, tried to dissuade us from using video, and instead recommended sound. As a result, we agonized whether to keep video: Too distracting Will cover the field of vision and be dangerous Too expensive Too many pieces Technology is not fully developed Wires/bandwidth problems Too many batteries Additional weight We decided to keep video for the simple reason that we wanted to permit the rider to look ahead at all times, and we felt that any other implementation would be more dangerous. Information and interaction Next on our list was to define the information that should be displayed, and how the user would interact with the system. At this point we needed to think long and hard about what a rider needs to see, how a rider thinks about maps and navigation. We also had to seriously consider rider safety, and make some tough decisions. Basically, we decided to do our best to design with rider safety in mind, to still provide the desired functionality, and to let the rider decide how far to take these concerns. In keeping with this decision, we designed the displays and interaction to be as simple as possible and to let the rider set system parameters such as pre-emptiveness and task migratability. 41

42 Deciding how our riders could interact with the system to get simple information was straightforward. We sketched out a menu system that the rider could navigate with little distraction. So, easy things are easy, such as locating a point of interest. We also decided we would display a map on request. The map should be very simple, with little to distract the rider, and will initially show him/her relative to the next waypoint. The rider could then pan and zoom to get the desired view. We do not intend this map to be a substitute for an actual map, just to provide spatial orientation relative to the route. When it came to more complex functions, like modifying the route, we had to carefully think through what a route is, how it is stored, and how it could be modified. We also had to consider issues related to error prevention and recovery, since modifying a route could lead to serious navigation problems. The Prototypes When we started discussing the prototypes, we first reviewed what were the critical aspects of our design that we wanted to show to our users. Our goal was not to show off how good our design is, but to get feedback from our users. So, we decided to show them the good, the bad, and the ugly of our design. Critical Aspects 1. How turn + stop info is displayed to the rider what user sees - where visually shown <Prototype 3> - what data is shown <Prototype 3> - when info is displayed how soon, how much time, repeatedly, flashing? <Prototype 3> 2. What/how can user interact with and control the system - Input - physical mechanism buttons,.etc. <Prototype 1> - What functions are available <Prototype 2> - Information and feedback given to user <Prototype 2> <Prototype 3> - Map + Menu info display <Prototype 2> <Prototype 3> 3. The physical characteristics of our design including weight, size, component breakdown <Prototype 1> A physical prototype was pretty obvious, we needed to convey the physical characteristics of the design. In particular, we wanted to evaluate whether the following would be issues: Weight Size Number of components Where the components go How the buttons work To show the interaction with the system we considered storyboards, displaying different screen shots and scenarios. We also considered simulating the interaction portion so we could better 42

43 evaluate the flow of menus and functions in the system. Finally, because of the basic nature of the system, the pc simulation won out. Ok, so, we had figured out how to show off the physical characteristics and the interaction, but how could we provide a hint of what a rider would see while riding. We considered taking photographs with a digital camera, and then superimposing our display information on top of it. But this would not show any concept of motion. So, finally, we came up with the idea of filming (while riding) and then mixing output from our system with full motion scenes. User Evaluation Once our prototypes were ready, we met with one of our users. This was one of the most productive sessions we have had so far with our users. It makes quite a difference when the user can touch and feel and see what the design might be like when done. Our user gave us a wealth of feedback about buttons, the information that will be displayed, and the interaction with the system. We also discussed the actual functioning of the system and how routes and points of interest are managed. His feedback is integrated in the assessment of each prototype. 43

44 Appendix A The Technology Our design integrates several key technologies: GPS GPS: it is used to track the user s position Display: the visual information should be directly displayed in the visual angle of the user. Data Network: there are several data channels (e.g. user-input processing unit, processing-unit display). These connections should be wireless. CPU: a processing unit generates output data based on several input channels (GPS, user input). Memory: maps, routes and additional information have to be stored and retrieved. Battery Power: the devices are mobile and are therefore dependent on mobile power sources. GPS (Global Positioning System) is used to track the position of our user. The chips that are produces nowadays are quite small. These chips are already integrated in a lot of mobile phones and are smaller than a postage-stamp. Such a chip only consumes some mw of power. Display The display should be integrated into the rider s glasses. It is necessary that the display does not obscure the view of the rider. We have identified two suitable display technologies. One technology (Virtual Retinal Display) directly projects the visual information on the retina. The other technology uses holographic optical elements (HOE) to create a virtual image that floats in front of the user. The Virtual Retinal Display directly paints the image on the retina of the user. This display could be integrated in the glasses of the user. An example of such a commercial augmented vision display is the Nomad-System of Microvision ( This system is able to display an SVGA-input signal in form of a monochrome red output signal. A small mirror (~1mm 2 ) reflects the laser light to the retina; this laser light is generated outside the visual angle of the user. The commercial system is a monocular (one-eye) monochrome (one-color) display. Microvision has already developed a full biocular system for full stereoscopic viewing of threedimensional full-color imagery. The following two pictures (from: show concepts that are (hopefully) going to be realized in the next years. 44

45 One problem of the current system is that there is only a narrow hole where the laser light can enter the eye. Thus, you can only see a virtual image if your eye is correctly aligned. This alignment could be a problem on a bike because of the vibration. It could also be problematic if you squint to one side. Another problem is that there is a small mirror in the view angle. The advantage is the very good resolution quality compared to other head-mounted displays. The second display was developed by Minolta ( As described, it uses holographic optical elements to create a virtual image that floats in front of the user and does not hinder the user s normal field of view. The weight of the prototype is virtually the same as that of standard eyeglasses. The visual signal is transmitted inside lenses of the glasses to a holographic optical element (also inside the lenses) that reflects the visual signal to the eye. The advantage of this display is its weight (only about 25g). The special lenses are also very thin (3.4mm) so that they could be easily integrated in the rider s sunglasses. 45