FinalPrototype-Group:Team Awesome

From Cs160-sp08

Jump to: navigation, search

Contents

Presentation

Final Presentation

Final Report

Team members and roles

  • Robert Glickman : Add/edit and interviewing, design evolution
  • Raymond Planthold : Location, home, prototyping, tasks, problem & solution overview, intro, unimplemented parts
  • Adam Singer : Database, browse, browse picture, presentation
  • Andrew Wan : Map view, presentation, UI design

Problem and Solution Overview

Given the ubiquity of cellular phones with geolocation capabilities, remarkably few applications have made use of the available information. Predictably, simple location tools like maps have become increasingly popular. While these applications fill an obvious role, they lack many extra features. Now, with the coming of more standardized mobile platform like Android, more interesting software can be developed to take advantage of available geolocation features.

Trippen is a trip journaling application that records and organizes location waypoints. Individual points can be saved manually, or at some regular interval (as part of a trip), and tagged with various metadata later. Users will be able to easily journal trips and organize related photos and comments. More generally, the application allows people to "bookmark" real-world locations with their phones, an ability which may prove to be extremely useful.

Target user group

Our target user group is people who like to travel, and like to share their travels with others. Our specific group of travelers skews more towards outdoor types than globetrotter types, though the latter should find use in our application as well. Our users are not inclined to monitor their phones closely while on a trip; they would prefer a "set it and forget it" approach. However, in certain cases, such as taking down specific information about a place or taking a photo, they do engage in "active" recording. They want a system that they can leave alone (and that leaves them alone) when they are otherwise occupied, but that will seamlessly integrate manual input of data when desired.

Tasks

  • Task 1 – Easy – Start (and end) trip recording
    • This will start the location service recording points at a predetermined frequency. A new trip will be added to the database, and recorded points will be added to the current trip.
    • This task will make use of the following components: Home Activity, Location Service, Database Adapter
  • Task 2 – Medium – Mark current location and add a title and comment to it
    • Whether or not you are on a trip, you may mark the current location manually. This functionality is important if a user wishes to mark an exact location of a particular event or photograph. Marking the current location will create a new point in the database and launch the Add/Edit Point Activity. From this activity, a user can add content (such as a comment or a photo) to their new point. Any changes made in this Activity will be saved automatically when the Activity
    • This task will make use of the following components: Home Activity, Location Service, Database Adapter, Add/Edit Point Activity
  • Task 3 – Hard – Review the current trip and add a photo to a point along the trip
    • While a trip is in progress, a user can review all points plotted so far. Once a point is selected, the Add/Edit Point Activity will be launched and the user may associate content with their point. From this Activity, the user may add a photo. The Review → Edit path will be the most common path of action in our application
    • This task will make use of the following components: Home Activity, Location Service, Database Adapter, Map/List Activity, Add/Edit Point Activity, Photo Browsing Activity

Design Evolution

     Throughout the course of this project, our interface design has changed greatly from the sketches of Contextual Inquiry to the Lo-Fi Prototype to the Interactive Prototype until the present, final design. However, the structure of the interface, in that we would include 5 basic activities – Home Activity, List/Map Activity, Trip Browsing Activity, Add/Edit Waypoint Activity, and Photo Browsing Activity – primarily remained the same. Our design would evolve with the considerations of user feedback, common sense, and feasibility of implementation. Each phase would become extremely important to the final interface.

  • Home Activity

     This activity was designed to be the initial screen when the application started up. This activity would present to the user the current state of the application and would serve to facilitate navigation to perform desired tasks. When we first conceived this page during the contextual inquiry phase, this is how it looked:

Image:fig1.jpg

     It displayed the current location in text and mini-map forms at the top of the page, and there were buttons for marking the current location, leaving a public comment at the current location, stopping (and starting) the trip, editing application settings, and going to Android’s camera application. This interface was refined before the Lo-Fi Prototype stage to look like the following:

Image:figure1.jpg

     In this next phase, we decided to rename and move the buttons to make their actions clear, and to add buttons which were needed and to remove buttons which were unnecessary. Start/Stop was renamed to Start New Trip/End Current Trip, View Map was added to view the current location in the full map activity, Review was added to allow for the reviewing of past trips, and Mark Waypoint was changed to Mark Current Location for clarity. In addition, the Settings and camera buttons were found to be unnecessary, and thus were removed. After the Lo-Fi Prototype’s user testing, some additional refinements were made for the Interactive Prototype:

Image:Trippen1.jpg Image:Trippen3.jpg

     User testing from the Lo-Fi stage made it clear that the wording for some of the buttons was ambiguous, so these were changed (View Map to View Current Trip and Review to Review Past Trips). Also, the current location text and mini-map were removed due to issues with feasibility of implementation. Finally, our final design refined this activity even further:

Image:Picture_1.png Image:Picture_2.png

     Now, the interface was changed to incorporate all buttons without the need for scrolling. Also, icons were added for better aesthetics and usability. The Trippen (“T”) icon is added to the tray whenever the trip is recording.

  • List/Map Activity

     This activity is used to navigate through the points of a trip (past or present) and to view the current location. This interface evolved very little over the course of the semester, other than the addition of the list view and other small changes. The contextual inquiry sketch:

Image:fig2.jpg

     We chose, at first to have the point navigation be using the d-pad on this map view, with add comment and add photo selected by selecting a point. The Lo-Fi version only had one small change:

Image:Figure4.jpg Image:Figure3.jpg

     Now, since the Add Comment/Add photo are merged into one, there was no need for the distinction when selecting a point. Also, the point list activity was added. The interactive prototype added the list overlay:

Image:Trippen4.jpg

     The separate point list was replayed by a list overlay. This list overlay allowed the user to navigate points logically by time. Navigating spatially as was done previously before the list overlay proved to be confusing and ambiguous. Point-specific information was also added to this version of the activity. Finally, in the current version one more change was made:

Image:Picture3.png

     The list overlay was changed to be a little bit wider and to have time and date information by default instead of “Untitled Point.”

  • Trip Browsing Activity

     This is another activity which has not changed much in its essence. It started as a list with date ranges, description, and path outline, as shown below:

Image:Fig6.jpg

     The path outline was eliminated in the Lo-Fi Prototype because it was unnecessary and not feasible:

Image:Figure2.jpg

     In the Interactive Prototype, date ranges were eliminated and number of points and trip number (in chronological order) were added. There was also the functionality to rename and delete trips through the menu:

Image:Trippen6.jpg Image:Trippen7.jpg

     Finally, the current version allows for the separate viewing of trips and points. Also, trips can now be sorted by ID, name, or number of points in ascending or descending order through the menu:

Image:Picture6.png Image:Picture7.png

  • Add/Edit Waypoint

     Add/Edit Waypoint was one activity which consistently cropped up with usability issues in the user testing. It started out as encompassing two separate activities:

Image:Fig3.jpg Image:Fig5.jpg

     The Contextual Inquiry version had separate screens for tagging locations with photos and with comments. Initially, photo tagging was going to be an extension of Android’s camera application. One would take a picture and then could choose to tag the current location with this picture. In a separate activity lay the commenting capabilities. This screen had the current location, a comment box, and buttons for saving, cancelling, and clearing the comment box. The Lo-Fi prototype offered something closer to the final design:

Image:Figure6.jpg

     This version had photo tagging, commenting, and renaming capabilities all in one screen. All buttons, except for Save, were eliminated to reduce clutter. There was also a button which could be used to view a map of the given location. The Interactive Prototype essentially implemented this Lo-Fi Prototype with a couple small changes:

Image:Trippen2.jpg

     The comment and renaming boxes remained the same, while a camera icon (not shown) replaced the generic picture for photo tagging when no photo was yet associated with the point. Also, the save button was removed because of feedback from Lo-Fi testing. The final stage made more small changes, per user requests:

Image:Picture4.png

     The Done and Cancel buttons were put back in to eliminate ambiguity. Also, the view map option was taken out, as it was determined that that had become obsolete.

  • Photo Browsing Activity

     The Photo Browsing was introduced the first time in the Lo-Fi stage. In Contextual Inquiry, photo tagging was attached to Android’s camera (see drawing above in Add/Edit Waypoint section). Here is the first drawing in the Lo-Fi Prototype:

Image:Figure5.jpg

     This list-based view of the photo browser was improved using a Gallery in the Interactive Prototype and final design (no changes between the last two stages):

Image:Trippen5.jpg Image:Picture5.png

  • Miscellaneous changes
    • Toast notifications were introduced when starting/stopping trip recording and saving a point to make the user more aware of the consequences of his/her actions:

Image:Picture8.png

    • A tray icon was added to indicate when trip recording is running (The “T”).

     Through each phase of user testing there was a lot to learn and much to revise. The Contextual Inquiry provided some reflection on the initially planned interface and led to some revisions. Then, the Lo-Fi user testing revealed many usability issues within the planned interface before that interface was built. Once there was a Hi-fidelity Prototype built, there were very few major changes to the interface and its structure. Most of the ensuing changes, while still very important, were superficial or add-ons to the existing interface. Therefore, the most useful phase of this project, in terms of making changes to the interface was the Lo-Fi Prototype.

Final Interface

Final UI Design

Functionality

Trippen is designed around two basic types of usage: recording and tagging. The application provides a simple interface for saving physical locations, either automatically or manually. These points are organized into trips and points, which can then be edited and viewed at any time.

Specific tasks:

  • Begin/end trip (automatic) recording: Toggles automatic location recording, which runs in the background. The application has a simple distance check to avoid redundant points.
  • Save the current location: Saves the current location as part of the current trip, or on its own (if not currently on a trip)
  • Review a trip or point on a map: Collections of points can be viewed on a map, which has an overlay list for navigation and location details.
  • Tag individual points with name, text comment, picture: Locations are customizable, and can be renamed or commented upon. Points can also be associated with a picture from the phone's memory.
  • Browse trips/points in a list: Simple list for browsing trips and points. Rename, delete, and sort options can be found through the menu button.
User Interface Design

The application UI is divided into 5 basic activity screens, which generally serve one major function. I will describe each of these here.

Home: The home activity serves as Trippen's default screen, and contains the widest variety of options. Initially, three buttons allow a user to either start trip recording, review past trips, or mark the current location. Upon the start of a trip, the middle button splits, adding the ability to view the current trip. While it provides control over some of the most important features, the home activity is designed to be simple and low maintenance. Given our target consumers, this may be the only screen users interact with until after a trip is done (more user-testing would be helpful in checking this).

The default home view, with recording off.
The default home view, with recording off.
Now recording.
Now recording.


Browse: The browser provides a listing of trips or points, which can be tabbed between. Selection of a trip or point takes the user to the appropriate map or point, respectively. Further functionality is accessible through the menu button. Trips can be deleted or renamed, and users can sort by column, hopefully making for easier browsing.

The browser has been updated, and can view points.
The browser has been updated, and can view points.
Sorting options.
Sorting options.


Map: The map activity provides a visual display of trip locations, which are plotted on the map with a navigation list. Button presses up/down move through points in the list, and the map is re-centered to the next location. Selection of a point takes the user to the add/edit point activity. Additional point information (latitude, longitude, etc.) is provided in a status bar across the bottom of the map.

The map view now provides thumbnails when a picture is available.
The map view now provides thumbnails when a picture is available.

Add/Edit Point: This activity provides two text areas for renaming/commenting on the selected point. A button with camera icon (or thumbnail preview) takes the user to a browser where they can associate the point with an image. A done and cancel button provide a clear way of saving or discarding changes. Clicking the back button takes the user back to the calling activity, but saves any changes to the page.

The add/edit view has a thumbnail, and two buttons for done/cancel.
The add/edit view has a thumbnail, and two buttons for done/cancel.

Photo Browse: The photo browser is a simple tool for selecting a photo to associate with a given point. Movement left/right switches the current image selection, and a selection associates "this" picture with the point. Users can cancel by using the back button.

The photo browser remains fairly simple.
The photo browser remains fairly simple.
Implementation & Difficulties

Overall: In general, implementation went well, with no major roadblocks. The most difficult part of the project may have been learning the Android API, and dealing with its inconsistencies and beta nature. Fortunately, most features in our specifications were doable without too much invention or painful workarounds. The database and location interaction were done early, leaving us considerable time to work on the UI.

Home: The home activity provides a menu to control basic journaling features, and access to related review activities. The layout changes to reflect available usage options, and has been refined from a simple linear layout to a more complicated mix of linear and absolute layouts that prevent any vertical scrolling. A tray icon was added through the notification manager to indicate the recording state (on/off).

Browse: The browser is a simple list activity which pulls general trip and point information from the database. Simple menu options and sort/rename dialogs were added as other screen became more polished. The list itself is updated whenever manually edited or reloaded, though there is no handler for SQL content changes (here, or anywhere).

Map: The map activity provides a set of overlays on top of the default map. On creation, the activity collects information about all relevant points, calculates a reasonable zoom level, and adds three overlays to the map. The first draws and numbers all points in the viewable area. The second draws a list of the points, sorted chronologically. As users move up and down with the directional pad, they move up and down the list, which re-centers the map on the correct point. Finally, a third overlay provides information about a point's name, timestamp, coordinates, and a thumbnail of its associated image, if one exists. Some effort was put into reworking this screen to use more general Android components, but the overhaul seemed to offer little benefit for a lot of work. That said, progress in this activity was slowed somewhat by usability requirements, and a lack of experience with the Android SDK.

Add/Edit: This activity initializes with a point, extracts the relevant information from the database, and populates its two text areas (and image button) appropriately. As a convention, any calling activities provided a simple Toast notification whenever add/edit closed, to inform the user of any changes. More notifications provide feedback about changes to the picture. Finally, the back button and the on-screen "done" button have the same functionality, in keeping with early testing complaints, and later concerns of ambiguity.

Photo Browser: The photo browser was adapted from the Flickr project earlier in the semester, and provides a simple gallery and view of all pictures in "data/misc/images" on the phone. Selection of a picture (directional pad center) associates it with a point (from the add/edit view - the only way to this screen).

In addition to the five activity screens, Trippen relies on a few utility classes.

Database: A single wrapper class provides an interface between SQLite database and the application, and contains all table declarations and access methods. These include helpers to retrieve individual trips and points, all trips and points, and various update functions. In the most recent iteration of the application, points are automatically named according to their timestamp.

Location: Another class receives and records geolocation information from the provided Android location manager. While initially we assumed this would have to be written as its own service, the manager includes a "requestUpdate" method that can report a location at a set interval (as its own service). The trip data receiver automatically inserts these points into the database whenever they are sent.

What was left unimplemented

What was left out and why
Device Features with Significant UI

These features would have been the most important to have in our user tests, and were the most likely to be left out becuase of technical infeasibility.

  • We currently only support using existing photos on the phone.
    • We would like to be able to "intercept" photos the user takes with the phone's camera and automatically add their location information, subject to user preferences.
      • There currently is no camera interface to speak of in Android. Since taking pictures is not part of our application's primary purpose, it was not worthwhile to mock up our own interface for this.
      • Hopefully when there is a camera interface, it will be possible for a standard Intent to be broadcast when a photo is taken. Otherwise, we would have to re-implement the camera UI anyway.
    • It would also be nice to have a shortcut to "Take New Photo" or something along those lines in the photo browser.
  • We lack complete support for Android's menu system. In our hi-fi tests, users still preferred not to use the menu button, so we still have no idea if they'd ignore it on a physical phone as well.
  • We still make no distinction between points automatically recorded along a trip, and points manually recorded on or off a trip.
    • This is undoubtedly our biggest missing feature, and the one whose absence has the most to do with missing Android functionality rather than relative importance.
    • The biggest hurdle in making this change would be to enable path-drawing on the map. The Google Maps API for Android does not appear to support this at the moment, even though the full-fledged non-Android API does. Writing our own support for path-drawing would be far beyond the scope of this project.
  • We were unable to complete our originally-envisioned "rich list" UI.
    • This was intended for use in both the trip/point list, and the photo/media picker.
    • It would probably be possible to do this with the current Android API, but it proved too difficult in the time available.
  • We want to have a little thumbnail map for each (manually recorded) point.
    • If a point has no photo associated with it, the map thumbnail could be shown in its place in the rich listing described above.
    • Clearly, this thumbnail should be generated once and saved as an image. (There could possibly be some "smart" strategy for updating the thumbnail in case of map changes, but that would not be a frequent occurence.) We have no idea how to do this properly with the Google Maps interface.
  • The Home screen was supposed to have a live preview of the current location, including a mini-map. However, the standalone map interface proved to be difficult enough under the Android API, so we scrapped that for now.
Device Features with Minimal UI

These features are needed to make our application "complete," but require very little in the way of user interaction on the Android device.

  • We did not add support for associating arbitrary media with locations. Some examples of such media we might want to enable use of in the future include sound recordings and blog or Twitter entries.
    • At the moment, Android has no concept of a "user data" folder. This is frequently seen on other phone interfaces under names like "My Media" or "My Stuff." Neither does it have much in the way of ContentProviders, which are the proper interface to access data managed primarily by another
    • Any solution we could have implemented would be little more than a mockup, which would bear no resemblance to what we would want to do once Android does have the media support we need.
    • Pictures are the most obvious type of external data to associate with a location. If we did not support pictures, nearly everyone would consider them missing, whereas other forms of media fall mainly into the category of "nice to have." Therefore, it was useful to have a rudimentary UI to demonstrate this capability.
    • The interface for associating sounds, etc. would not be significantly different than the file listing we imagine for a later version of our photo browser (see above).
  • We do not make use of the ability to store location information in a photo's EXIF data.
    • Eventually, we would want to use the native metadata format for any supported media to store GPS coordinates when applicable, in addition to our own database.
    • Another thing we could do with EXIF (and other metadata) is scan the existing media on the phone, and if it has a location tag, create a point in our database to associate it with.
    • This feature (both reading and writing metadata) becomes far more useful when sharing comes into play. For example, if a friend sends you a photo with a GPS tag, it automatically shows up on your map.
    • As this would have very little impact on the interface in the single-user case, it was not a priority.
External Features

These features are designed for interaction with another Android phone or with the Internet, so they were the lowest priority.

  • We do not share information with other Android users.
    • Though sending and receiving photos and other media is arguably some other application's responsibility, having such a capability would still enhance our own application.
    • We also wanted to implement a kind of location "ping" as a simplified way of requesting a friend's current location.
      • The focus of our application has shifted significantly from our original concept, so this would be somewhat out of place in the context of trip-taking.
      • A better place for this feature might be an instant messaging application.
  • We don't have any way to submit user data to photo sharing or blogging sites.
    • This is best left to a dedicated application, though we could put shortcuts in our application.
    • A possible extension of this idea is to be able to browse Flickr images (for example) that are tagged with a nearby location.
  • There was a lot of interest in the possibility of establishing a web site where entire trips could be submitted and shared.
    • We never had any delusions that this could be accomplished in the available time, but it would be a nice thing for the future.
  • We also had the idea of leaving public comments on locations for people to "find" when they are nearby.
    • This would require a less extensive web framework, but it would still require too much for this project.
Wizard of Oz techniques

The only feature that could be considered "Wizard of Oz" is our use of a mock GPS data provider. Obviously, we could not do anything with real GPS data. However, aside from the fake source of the data, everything we do with it after that is done on-the-fly.



[add comment]
Personal tools