The Application:

Active: Hiking Safely is an application for mapping and sharing information about trails. Users can plan a route, get directions, see their current location, post reviews of trails and report issues. During the first phase of the project, we identified the problem and our core users based on survey feedback. From this information we are trying to create a design that is both aesthetically appealing and easy to use whether they are at home planning for their hike ahead of time or already outdoors.

The Design Alternatives:

When brainstorming these designs, we first looked at existing mapping applications. Most were for driving or purposes other than hiking, but it was still helpful to see how they were laid out and which features made for easy navigation. Using components from these existing systems along with ideas of our own, we came up with three design alternatives. Our application will not be the only mapping application that users will have used, so tying our designs to something familiar is a useful technique to allow users to more quickly become familiar with the usage and functionality of the application. While it may seem like a lack of creativity to have a feature that closely resembles an existing popular mapping solution, keeping some similarities was an intentional design choice.

Option 1

The map is always displayed on the screen when it can be. Menu hidden so that not getting in way of map.

With this design, the users will always see the map and their current location as needed so that they do not lose track of what they were doing or where they were going. This is especially helpful for users who want to reference back to the map as needed. A shortcoming of this design is that the buttons to report a hazard, search, etc, are small to prevent the map from getting covered, so users would have a hard time seeing changes on the screen.

Option 2

The map is only displayed when necessary. It is not partially shown when the menu is open, when searching for trails, or some of the other functions.

With this design, buttons, options and results are easier to see because they can be bigger than in Options 1 and 2. This is especially helpful for older users. A shortcoming of this design is that the application is primarily for mapping, and some functions could be made easier if the map was in view.

In the main page of the app, which does show the map, the menu bar appears to the left of the screen. In design 1, it is not as clear how to navigate the app. However, the downside of the placement of the menu bar is that right handed users will have a more difficult time accessing the menu if they are just using one hand. Also, depending on how they are holding the device, it may not be natural for the user to select items at the top of the screen. We chose a color scheme that would be easy on the eyes even if the users are outside and the sun is directly on the screen.

Option 3

A mix of the first two. The goal of this design was to take the best ideas from the other two design. The map is usually at least halfway on the screen, but some parts of the interface can become fullscreen when their functionality does not require the visibility of the map or the amount of information displayed in that submenu is large enough. There is a menu bar shown at the bottom of the screen in the map view. The menu bar was chosen to be at the bottom because of the reachability provided by this region for most mobile phone users. The zoom buttons are also near the bottom on the right to be easily reachable by the thumb. When search bars are added, such as when finding directions on a trail, the bars appear at the bottom of the screen. Visual-only components, such as instructions and the map view are often present in the top area of the screen, since the top area of the screen is actually more easily visible because of the reduced occlusion from the hands.

For small sub-menus such as the track-recording interface shown, only a portion of the screen is covered, so that the user does not have to switch contexts to perform the simple action. For more detailed actions, the interface switches entirely to the sub-menu, such as in the selection of the type of report the user wants to create. This type of selection does not require the use of the map and has enough density of information to make it worth a context switch.

Bright colors are used for action buttons, such as the “Go” button when searching for directions in order to catch the eye of the user more easily.

Appendix:

Option 1 Report a Hazard Option 1 Record a Track Option 1 Additional Functions

Option 2 Main Screen Option 2 Record a Route Option 2 Rate a Trail

Option 2 Search Results Option 3 Main Screen Option 3 Record a Route

Option 3 Navigation Option 3 Change Map View