InteractivePrototype-Group:Beta Bears

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Contents

Member Roles

Sally Ahn: Coding for inbox/solutions and climbing log, data handling, project set-up and svn, screenshots and storyboard

Mikhail (Misha) Shashkov: Coding for log, Icon+some graphics, large portion of write-up.

Bobby Lee: Coding for the map, and the corresponding write up.

Bryan Trinh: Coding for the Splash view, Assist Climbing function, Drawing function, save Image function, editing write up

Problem And Solution Overview

Our application will help first-time and beginning rock climbers by helping them learn, log, and refine their skills by addressing the problem many beginners face while learning to climb the traditional way: reliance on the presence and guidance of more experienced climbers. The exchange of advice (or "beta," in rock climbing terminology) is an integral aspect of improving one's skills in this sport. It is such a key part of the learning process, that when such guidance becomes unavailable, climbers--especially beginners--will often not know how to proceed.

Our mission is to prevent such barriers by enabling climbers to give and receive beta quickly and easily, at anytime and anywhere, via the iPhone. Users will be able to capture their difficult problems with ease and share them with all climbers--whether they are at the gym or not--who may be able to provide some insight. Additional features include: a log for tracking progress, a map for locating other climbing sites, and a quick reference to climbing terminology. Thus, our application will be a package of useful tools that a novice climber can quickly access in the midst of a climbing endeavor.


The Interactive Prototype of our solution is available for review: File:IBeta.zip
NOTE: Be sure to read the following Read Me

Task Descriptions

For our interactive prototype we chose to implement the three main functionalities: climbing assistance, climbing log, and location finder. Not only are these believed to be the most used features (according to our interviews), but they will typically be used in tandem with each other. For example, after succeeding at a climb, the user may want to log it. And of course, beginners will typically use the location finder to get to and find the location in the first place. These three tasks are detailed below.

Assist My Climb (Hard)

Task Description:

The user would be at the location and failing to succeed at a climb. Using this functionality in our application, the user should be able to

take a picture of the trouble spot, annotate the holds(directional and non-directional), and submit it for review. Shortly afterwards, a reply will appear in the user's inbox which details, with pictures and text, how to approach the trouble spot.

Non-standard Interactions:

This is our main functionality and by far the most complex. Likewise, there is a non-standard interaction that must be learned by the user if they are to use our application successfully (luckily, they recieve instructions that walk them through step-by-step). The interaction of interest is the annotation of a climbing wall after the user had taken a picture of it using the camera. This involves denoting non-directional holds (simple tap) and directional holds (by sweeping, after tapping, towards the side of the hold that juts out.

Limitations From Mobile Device:

For this task, we are restricted by the camera which may or may not be of decent enough resolution to capture all the climbs the user may need help with. Likewise, the simulator does not allow for camera functionality, so we hard-coded an image that is used.

The orientation of the iphone was not yet implemented because this was hard to check on the simulator thus all associated instructions are removed for the time being.

My Climbing Log (Medium)

Task Description:

The user should be able to add to a persisting log any indoor or outdoor climb he completed. For indoor climbs, the user will just want to denote that they completed a certain difficulty and what style of wall it was (vertical, 45 degree, etc...); this simplicity is due to indoor climbs changing monthly. In addition, for outdoor climbs, the user will want denote what route was completed/attempted. All of this data should persist, and be visible in an aggregate form if the user desires to see an overview of their success.

Non-standard Interactions:

There are no non-standard interactions here; only table-view manipulation and various common forms of data entry.

Limitations From Mobile Device:

No issues due to the use of a mobile device arose.

Find Places To Climb (Easy)

Task Description:

The user should be able to locate indoor and outdoor climbs on a map and be able to deduce how to get there. Also, route information for each location should be available to help the user

know what difficulties are available (so that they don't waste time traveling somewhere that only has climbs that are too difficult.) This route information should also assist users in locating specific routes at the climbing site (such as denoting the beginner section on a map of the gym).

Non-standard Interactions:

None; navigation only requires manipulation of table-views, and the map functionality is the typical one used in most iPhone Apps (including default ones like "Maps"). so we expect the user knows how to use it.

Limitations From Lo-Fi and changes in Hi-Fi The main limitation from the lo-fi design was that the user didn't know whether cells in the table were expandable or not. We added a ">" on the right hand side of the cell to indicate that it was expandable.

Limitations From Mobile Device: This limitation is due to the discrepancy between iPod and iPhone: Ideally, we would want to use the user's location to generate the map (so that they can keep using the iPhone as a GPS as they get closer and closer to their desired location. However, we only have an iPod so we default to much larger map of Berkeley, focused at UC - Berkeley.

Revised Interface Design

Below we detail the changes made to the design, give images of unimplemented functionality and also provide some storyboards that detail how a typical user could use various functionalities of our task.

Changes Made

Seperated by functionality, changes are provided below. Also, we should note that we have removed a functionality that we previously intended to include in the final product. Specifically, the "Improve My Climb" feature, which provided work-outs to the user, has been removed. We made this decision for several reasons. First of all, a lot of the recommended work outs are fairly complicated and are outside the scope of our target user group of beginners. Second, we felt that this functionality did not fit in with the flow of use that we expect after performing our interviews. Moreover, after interviewing real climbers, we realized that communication among the climbers was an important resource for all climbers seeking improvement. Thus, we have shifted our application's focus on the to facilitate the exchange of advice among the climbers.

Climbing Advice Changes

Change 1: Changed navigation of assist my climb

Motivation and Change:

After the user testing we realized that we could stream line the retrieval of responses by making the inbox its own tab. This also presented an easier way for users to know when a response has been received. This navigational change created a hosts of different views in order to make the navigation more intuitive:

1. After a climbing image is marked up and shared, an alert appears to tell the user that solutions will be provided in the inbox.

2. Inbox button has been removed from the assist climb view.

3. Cancel button was replaced with camera button in order to be more clear.

Before and After : <links to images here >

Climbing Log Changes

Change 1: Added "add button to other screen"

Motivation and Change:

All three of our interviewees wanted to add a log entry on the detailed log screen (reference), but we had placed the "+" button one view up in the heirarchy.

This error could have arisen from the use of our lo-fi prototype. After careful review on the interview videos, the button had actually been slightly concealed

or became visible too late for the user to interact with it. To clarify, we slid paper views into a cardboard cutout of an iPod, and during this time the user is already

looking over the view and deciding how to interact with it; consequently, a button in the top right corner is last to show up.

In any case, to help users find this feature we added it to both screens and renamed the "+" to "Add".

Before and After: Before After

Location Finder Changes

Change 1: Show Route Locations

Motivation and Change:

All of our interviewees successfully clicked a location from the first screen, and then were dumbfounded as to what information they were supposed to be retrieving on the second screen, which seemed rather superfluous at the time. The existence of this screen, which perhaps was poorly exhibited due to the nature of the interviews, was to see what difficulties were available at a location and to not go there if there were not any routes of desirable difficulty. Regardless, we followed a recommendation by an interviewee and changed the image on this subview to be a map of the location and when a route is selected from the table view, that route is highlighted in the image.

Before and After:

Sketches of Unimplemented Portions

Terminology Search

Storyboards of tasks/screenshots

This is a video demo of our Prototype:

File:IBeta Demo.mov

Storyboard:

Scenario 1(Usage of Assist my climb and Inbox):

Bobby is a beginning rock climber in Berkeley. Today, he is going to Bridges, a nearby climbing gym.

Scenario 2(Usage of Map):
Scenario 3(Usage of Log):

Prototype Overview

This is the interactive Prototype:

File:IBeta.zip

This is the corresponding Read Me

Read Me

Overview

For the overview, we break it down modularly by functionality. For each functionality we provide a link to the images of our interactive prototype, so they can be quickly referenced. We also provide a link to a script that details, step-by-step, the intended interaction with the UI.

Splash Screen

Splash Screen Images

Script of Usage

When the user first launches the application he is presented with a splash screen. The splash screen is intended to provide an alternative method for navigating through the tabs that provides a brief explanation of each feature. From this view the user can reach any tab bar using the large buttons.

Assist View

Assist View Images

Script of Usage

The first tab contains the assist view. In this view the user is first alerted to take a picture of a climb that he needs help on. After an image is taken the user can mark up the image to indicate a sequence of difficult holds. The share button provides a way for the user to send this data to a website that other climbers can access to provide help in the form of responses.

Inbox View

Inbox View Images/ Video

Script of Usage

The second tab contains the inbox in which the user can retrieve responses from other climbers. Each assist message the user submits is presented in the table view cell and all corresponding data is presented in the cell. When the cell is clicked the user is presented with the response images.

Log View

Log View Images

Script of Usage

The Log view gives the user a way record problems that the user has successfully climbed. The user can add the following types of entries.

  • Outdoor Entry
    • Location of route
    • Name of the route
    • Difficulty of the route
    • Completed or not completed
  • Indoor Entry
    • Route Type
      • Example: Arete
      • Example: Vertical
    • Difficulty of the route
    • Completed or not completed

The entries have entry fields that match the context of the climb. The outdoor routes have associated names that do not change and more or less stay that for eternity. In contrast indoor climbs are always changing on a weekly basis thus it only makes sense to record the route type. The submitted route entry will be stored in a database and the first view will update its graphics and data accordingly.

Map View

Map View Images

Script of Usage

The map view is a GPS enabled climbing routes finder. On the first view the user is presented with a map with specific locations to climb in a table below. The locations can either be outdoor or indoor locations. When the markers are clicked a pop up display gives the user feedback on the name of the clicked location. When the detail view of the location is clicked, another table view pops up that contains a list of climbs in the area indexed by the associated climbing level.

Script of Usage

Splash View
  1. Opens up the application and is presented with a splash screen.
  2. Clicks on, Get Climbing Assistance and navigate to the first view.
Assist View
  1. The user is alerted that they are about to take a picture, and they press "Get Camera".
  2. They are then greeted with the camera API, which is faked due to the simulators inability to do it. The user presses the "camera" button on the bottom to "Take the picture".
  3. The user then sees the image they took and can either "Retake" or "Use" the image.
  4. Next, there is an alert-view that contains the instructions on how to annotate the image they just took.
  5. The image is then annotated using the various holds we have set up..
  6. When done, the user clicks "Share", to send their problem out to the experts for help.
Inbox View
  1. The user is greeted with a table view containing all of the current problems the have sent out, along with information on whether there are any replies.
  2. The user clicks on a message, if there are replies available.
  3. Then a list of solutions ("replies") is presented.
  4. After selecting one of these, whatever the expert submitted as a reply is presented to the user. For the sake of our demo, this is an animation that show how to make the transition in question.
Log View
  1. The user is greeted with a table view contains aggregate data for all their climbs. Each row is respective to each ranking, and show 2 bar charts which represent the amount of indoor and outdoor climbs (a legend is provided on the same screen) for that particular ranking.
  2. The user can press the "Add Entry" button if they wish to add a log entry.
  3. This pops up a dialog box that asks if they want to add an indoor or an outdoor climb. After selecting one of the two, the appropriate view comes up that asks the relevant information needed for the log.
  4. Currently this does not actually update the log, but we are close to perfecting CoreData and it will update shortly.
  5. Also, ideally the user will be able to click on the rankings in the first screen and see what climbs they have completed for a particular location. This is unimplemented as of yet, as it also depends on CoreData, but is not a crucial element so we focused on making sure other features worked first.
Map View
  1. The user is greeted with a local map of Berkeley that is annotated with pins on climbing locations.
  2. Clicking on these pins reveals the names of that location.
  3. These locations are also available in a table view below the map, which is clickable.
  4. Clicking on one of these locations provides an image of that location, and a map of the routes it contains (if such a map exists, which it does for Ironworks in our demo).
  5. In this second view, the user also has a table view containing these routes at the specified location, and clicking them updates the image to show the locations of the specified route.

What Was Left Unimplemented

Terminology Search is left unimplemented as it is not in any of the three tasks.

Application as a whole
Data Persistence

Currently the data models in the application are hard coded for features that do not need to pass between different views in the tabs. For the more essential information passing such as the loading of the image from the assist my climb view to the inbox view, the MainAppDelegate was used. We began implementing core data for our database of all persisted information needed for our application, but that feature is not yet functional.

Splash Screen
Button Animation

Currently the buttons on the navigation screen do not afford pushing. In the future the splash screen will have elements that look more like buttons and less like a flat graphic. It will also animate when it is touched down like other buttons.

Assist My Climb
Flick removal of hold markers functionality

The gesture removal of holds was not yet implemented so buttons that provide the same functionality were used instead.

Rotation of directional hold functionality

The rotation of the directional hold icon has not yet been implemented but has been explored. The only missing piece is a function that will rotationally transform a UIImage.

Camera functionality

The camera functionality is currently not supported. Code has been implemented for this using a UIImagePickerView, but it using this on the simulator made it difficult to show the functionality because the simulator does not have a camera.

Inbox
Responses to shared climbing images

Currently the inbox does not receive responses from a real user inputing data. Hardcoded responses are added instead to show the functionality. In the future responses will be created through an internet site and sent back to the user.

Support annotation

The inbox does not currently support annotations that the responder might have for the climber. This would be some sort of text input that gives more details that cannot be portrayed through the images.

Log
My Climbing Log components
Persisted data

Currently adding a new log does not update the first view as it should. There exist code for implementing this that uses core data, but it is not currently functional. Instead log items are hardcoded in.

Detail View

The detail views to inspect the climbs that have been completed or attempted is not yet implemented. Through our lofi prototyping we learned that users expected the add button to occur in this detail view, instead we placed the add button in its original location, the first view. The detail view is pictured on the figure to the right

Map
Routes are pre-input

Routes for now is input by the designer. But routes for indoors will be parsed from a website, where the coaches in the rock climbing gym can update.

Map Local Search

Now, the local search is input in the code. However, the real product will utilize another google API to do the local search.

Wizard of Oz

No aspect of our interactive prototype utilizes Wizard of Oz.

Documentation of code not written by team

The icons used for our tab bar are freeware available from www.glyphish.com

Presentation

File:Presentation.zip

Prototype Screenshots

Icon

Splash Screen

Assist my Climb Screenshots

Inbox Screenshots

Log Screenshots

Map Screenshots



[add comment]
Personal tools