FinalPrototype-Group:Anbaric Sheep

From Cs160-sp08

Jump to: navigation, search



If you can read this thumbnail, you don't need glasses.  Otherwise, click here to download the PDF.
If you can read this thumbnail, you don't need glasses. Otherwise, click here to download the PDF.

The Dream Team (or, group members)

  • Scott Crawford prepared part of the writeup
  • Pavel Borokhov worked on completing implementation of the trip creation (text entry) and route generation tasks, along with the data model, and prepared part of the writeup
  • Paul Mans worked on completing implementation of the trip creation (map mode) and map manipulation tasks, worked on the presentation, and prepared part of the writeup
  • Jeff Bowman prepared part of the writeup and presentation

What's at Stake (or, problem and solution overview)

Our group recognized through our own experiences that there is a need for a mobile application to aid users in keeping track of public transit schedules and performing useful operations such as providing relevant reminders for trips that they undertake. Interviews with users of various Bay Area public transit vehicles confirmed that we were not alone in desiring such an application. Our solution is a mobile app that will provide users with three helpful features. First, our application will provide an interface that makes it easy to plan a trip using built-in schedule data using both text and map input. Secondly, these trips can be saved for the user to call up at a later time and be able to set alarms. Finally, our application will provide the ability for the user to easily set various alarms corresponding to times and locations of their saved trips.

The Guinea Pigs (or, target users)

Our primary user group will be users of mass transit systems who take public transit with at least a moderate frequency, including but not limited to college students and commuting professionals. The accessibility and prominence of mass transit in the San Francisco Bay Area makes it an ideal test environment; however, the system is not specific to the area and as such can support all users within reach of mass transit systems. The backend data structures allow for the addition of other agencies seamlessly but no interface is provided for this capability at this time.

Finally, the system is designed to encourage infrequent mass-transit users to use the system more frequently, or try it for the first time. Many new users might be unfamiliar with all of the different transit agencies that are at their disposal to arrive at their destination. The system would enable them to find an efficient route quickly, and not be lost or stranded if something goes wrong and they miss a connection. Thus, the system will simultaneously cater to new as well as seasoned users of mass transit systems; the interface is designed in such a way as to allow the maximum amount of flexibility while at the same time not getting in the way of more experienced users.

What's Going On (or, tasks)

  • Easy: create a new trip: The user can create a new trip using schedule data that is already present in the program. They have the option of choosing their endpoints either via text input or map input. After being presented with a list of results which fit their desired endpoints and times, they can browse this list, save a trip for later perusal, set alarms for it, and view it on the map.
  • Medium: view and edit schedule data: The user can access a particular agency, route, and schedule data and insert new data across stops (horizontally) and across runs (vertically). This task is very simple at first glance; however, this task will be the basis for all user-entered data, so providing fast, intuitive input is crucial to the use of our application.
  • Hard: set a trip-contextual alarm: For each trip, there is a list of alarms associated with it and set to go off either at an appropriate time or place. This list is accessible whenever a particular trip is well-defined in the trip creation task (in which case creating a new alarm ties it to the selected trip) and from the main screen (in which case all alarms are shown). In the list, new alarms can be created and old ones edited. There are three types of alarms: general (which just has a time), transfer (which has a time tied to a transfer along the trip route), and proximity (which has a distance tied to a location along the route). Finally, all alarms have a choice of notification methods, which can be (1) the phone ringer or the phone ringer followed by (2) a textual pop up of the trip or (3) a map view of the trip.

These tasks were chosen because they are the most common tasks undertaken by the target users in solving the stated problem. Therefore, designing a good interface to help users solve the problem will result in a good experience and significant time savings for the user.

DEvo (or, design evolution)

UI Metamorphosis

Trip creation

The text-based alarm creation interface experienced very minor changes, most likely because it was very simple and straightforward. As described below, the major change was the elimination of two separate pathways for trip creation, which simplified the entire trip-creation process even further. In addition, some minor changes were made to the interface in the transition from paper to device due to device limitations widget size constraints. Just prior to the pilot usability study, I also modified the up/down/left/right field orders so that they would be more intuitive.

A number of features were also dropped from lo-fi to hi-fi due to the difficulty of implementing them. For example, we had initially planned for the from and to fields to be free-form address fields (as well as autofills) that would find the nearest stations to the entered address (if the text entered did not match any station names), but this was never actually implemented. Trip planning involving transfers also never happened, so the "trip details" screen was never really implemented as it would offer no additional functionality beyond the trip results summary screen.

One major change we made to the map interface between our low-fi testing and interactive prototype was a shift in the way users interact with overlays on the map. Formerly, the directional DPAD was used to move around and then the user would click upon a station marker to show an info-window containing station information. We decided that it made much more sense to follow the convention established in Android's default map application -- now infowindows (figure 1) pop up when the cursor hovers in their vicinity and in this "engaged" state a user can click the center button to interact with the object represented by the overlay in a noun-verb manner. (Figure 4) shows what happens when a user clicks the center button while engaged with a station overlay. In the end, this change wasn't too much harder to code and it freed the center button from only being functional when the cursor is over top of an overlay. Now, although we have not yet implemented this, we can register center clicks anywhere on the map and if the point does not correspond to one of our stations we have the option of perhaps showing the user the transit stations in his or her immediate vicinity.

Alarm creation

The alarm-based interface experienced several changes through the design process, but they were primarily minor changes that tended to thrash, in some sense, slightly in response to testing data. Initially, the 'saving' regime for alarms was to distinguish between saving an alarm being edited and being done editing the alarm. This distinction persisted until after the pilot usability test, during which testers consistently tried pressing 'save' first and were mystified that this didn't take them back to the list of alarms. The 'saving regime' was hence reduced to a single option ("save" == "save and done" from before) instead of three options ("save", "save and done", and "done"). A feature to have a global list of all alarms available from the homescreen, as opposed to just lists of alarms for each trip, was ideated after lo-fi testing (and was ultimately implemented after the first presentation). Generally speaking, on screen buttons were removed as time went on. The button on the alarm list screen to add a new alarm was removed after lo-fi testing because it just didn't seem to be worth the screen space, and having this functionality in the menu didn't seem to be a problem (this was backed up in later testing).

The one somewhat major area of alarm creation interface change was the evolution of the alarm type modality. In lo-fi testing, the plan was to make the screen display change depending on the selection of the alarm type in a spinner. However, the task of implementing this in android proved to be quite arduous, so the alarm type selection was shifted from a spinner to a pre-alarm-edit dialog (figure 7), required to get to the rest of the alarm definition options, and fixed thereafter. In pilot testing, this did not cause serious problems, as logically the user probably has an idea of what kind of alarm they are interested in before setting it (once they understand what their options are). There was an incident where the user had to restart the editing process, but it did not slow the process down significantly, and with an 'expert' user would cause errors infrequently, with the benefit of not having to dynamically shift the display, which on top of being difficult to code would potentially cause problems of it's own in terms of disorienting the user.

Schedule editing

The schedule editor interface experienced drastic simplification across our design process. In the beginning, much of the functionality was accessible through the pop-up menus, including a "special case" for multiple schedules within a route. As the design evolved, it became clear that standardizing that interface would improve both implementation time and interface discoverability. Furthermore, the need to enable "scrolling" throughout the schedule editor left the additional controls unusable in reasonably-sized schedules, in addition to taking up valuable screen real estate; as such, those controls disappeared from the page after testing. In addition, the original design called for only the center column to be the active "selection" at any given time; however, used to Excel and other spreadsheet-style editors, our design quickly reverted to the conventional table method rather quickly.

One of the major usability aspects we had conceived from the beginning was how to enter data in an intuitive way. As it turned out, this was not as big of a deal as we had anticipated; most users intuited a minimal way to enter data, and that was sufficient enough--the time-saving extra features remained unused. One of the more frustrating things about this section of the interfaces is that we encountered two types of users--those who understood it and used it as it was, and those who questioned who would need it or use it--making it difficult to receive feedback effectively. While earlier testing acknowledged its usefulness, it seemed that nobody cared much how to optimize the task.

Major Interface Changes

The biggest application-wide interface change we made was the elimination of two pathways for trip creation. In the lofi prototype, a trip could be created entirely using map mode or text mode, and there was the possibility of switching between the two modes at any time in the process (albeit in only one direction). This turned out to be extremely confusing for users, in part because the map interface did not have a complete replicate of the text input functionality, such as the lack of a date selector for the trip. This resulted in us keeping the text entry mode as the main trip creation mode, and simply allowing the map to be used for the individual selection of the starting and destination locations.

In the Alarms interface, since it was hard to implement views that change on-the-fly as a spinner selection changes, we implemented a pop-up dialog (figure 7) instead when creating a new alarm to prompt the user the alarm type that they wished to create. This could actually have negative side-effects on usability, as the user needs to now back out and restart the alarm creation process if they accidentally select the wrong alarm type.

Since our group presented our interactive prototype the map interface has undergone some key changes. As described in the Pilot Usability Study write-up, our application now provides the user the option to view a visual display of their trip route after they have created it. Shown in figure 12, this feature allows users to become more aware of the distance they will be traveling on their trip and it allows the preview of the stations they will be passing in route. Coupled with the current-position indicator (the red marker shown in figure 2), provided gps access is available users will be able to preview their progress in route as well.

Another addition to the map interface is the ability to navigate with the directional keypad in a "snap-to-station" manner. This is a feature we long debated adding because we didn't want to force our users to use a navigational mode on the map that was different then what they get with the standard Android map application. Additionally, we were very worried about constraining our users from only allowing the map to be centered at public transit stations because that would render other values of the map useless (e.g. users would not be able to move their map to decide on their pedestrian route after concluding their trip on public transport). The solution we came up with was to offer the functionality, but in a quasi-mode so that users wouldn't get trapped. Unfortunately, with a single mouse to use on the emulator offering a quasi-mode is impossible so for this stage in proto-typing the alt key switches between normal navigation and "snap-to" navigation in the map interface.

Another feature added to the map interface is the ability to jump to one of the nearest stations when the user clicks anywhere on the map that does not correspond to a station marker. The screenshot of this in action can be seen in figure 5. This is a bit of a placeholder for the reverse-geocoding functionality that we had planned but google has not yet released.

Another feature added to the map interface is a help screen. This can be accessed through the Android menu and we felt that it was necessary to add it because of the large number of control options available in the map interface. This can be seen in figure 6.

Evaluation Valuation

Although our interface design benefited from each design cycle iteration, the majority of changes came about as a result of our low-fidelity prototyping efforts, making that the most valuable stage in our project evolution. During our low-fi stage we benefited from self-evaluation during the actual construction of the 'cardboard computer' as well as from our first official testers.

Constructing our cardboard mobile mock-up forced us to consider many design decisions at a much finer level than we had up until that date. Specifically with regard to the map interface, the act of actually mapping button presses to navigation around the various input fields and moving the map itself suddenly made obvious that we had many too many modes present on the same screen for the experience to be 'user intuitive'. In figure 10 you can see a drawing of the map interface prior to constructing the low-fi prototype. Including navigation of the map, this figure displays 4 modes of interaction with the interface that the user would have to switch between (map navigation, zoom, destination/ vehicle type and selected station popup). Mapping this screen to the mobile phone's input made the reality apparent that without extensive instructions our users would be hopelessly confused. Figure 8 shows the resulting low-fi prototype map interface which was greatly simplified with much of the previous functionality moved to different screens.

After experiencing a 'mini-iteration' just during the construction of our low-fi prototype, the input we received from our tests with users led to at least twice as many changes. Among other things we discovered that we were asking our users to navigate through too many needless screens upon startup, we needed be more consistent by using either our on-screen menus or the Android Menu, there were major scrolling problems with the edit-schedule interface (figure 13). Also, the users were pretty much oblivious of the connections that allowed passage between the new-trip map and new-trip text modes, and flashing a two-second message of instructions at the start of certain activities just annoyed our users.

It is also worth noting that the hi-fi prototypes used in the later testing stages partially suffered from the level of implementation required. While the lo-fi prototype was "slow" in its actions due to the necessity of a manual human interaction and on-the-fly widget generation, the general construction of the interface and inner workings of the program were quite simple since the widgets could just be drawn and the logic used was minimal and didn't require any "real" data (while also allowing us to use internal intuitions). The hifi prototypes more or less required all of this to be codified, which was a significant undertaking and required the elimination of some features. As a result, the lo-fi prototype resulted in the most feedback not only because it was the least-refined interface but also because it presented with testers with a wider feature set that was not as regimented (i.e. in the lofi prototype the question "what does this do" would often have the answer "we haven't thought about that, oops", while in the hifi prototypes the more frequent answer would be "we have thought about it, but haven't had time to actually code the functionality).

Final Interface


The most prominent piece of underlying functionality, bar none, is the ability to access schedule data everywhere. Based on the fact that solid-state flash memory is more prominent and inexpensive than ever, and that transit systems are not necessarily in range of the internet (particularly underground trains), the system is able to load and store transit data in its database. The object-oriented, client-side parsing interface allows the tables of data to provide the framework for real-time alarms and parsing, in a form that is not tied to any particular transit provider.

Access to this information is available through a search function we implemented, which takes the constraints of the trip desired and looks for appropriate buses and trains (etc) based on the locations involved. We have provided both a streamlined text interface (with autocomplete search), and a map interface; furthermore, we implemented a map-based visualization of the route involved.

Our functionality also included the ability to set alarms of three distinct types: time-and-data-based Generic alarms, time-and-data-based Transfer alarms, and location-and-data-based Proximity alarms. Both generic alarms and transfer alarms use the time information involved with a trip to streamline the creation of transit-based alarms, and the system uses location data based on stops to produce the Proximity alarms.

Finally, we include the capability to view and edit existing transit times, and add new runs to existing transit routes, with hooks in place in the final interface to add full Create/Read/Update/Delete options to all data objects.

UI Design

The interface as we have designed it will provide the user with many useful features for a mass transit trip, in a self-contained package.

For instance, a user who needs to travel from one place to another will create a "trip", input his/her ideal time and location information, and select a matching trip (including transfer information) from a list. That trip can then be saved for easy access through the "Saved Trips" feature. This feature remains useful even if the user does not know where a transit stop is in relation to his or her current location (via the map), and also if the user wants to know the approximate route the trip will take.

The set of alarms takes particular advantage of the mobile device, as it enables the user to interact with this data at any time. Users mindful of catching a particular bus or train (et al) can set alarms based on the actual trip data, enabling alarms to provide information about their cause (i.e. which train is coming and when) and other appropriate metadata (e.g. when does the next train come). The use of Android in creating this information even allows alarm components to become interchangeable, if another developer produces a similar Activity with our API. Likewise, the ability to set both time and GPS designations for the trip's "arrival" allows the user to sleep or relax during the trip, which seemed consistent with our research and interviews, with the ability to wake up at the most appropriate time. Finally, the use of the underlying data to create transfer alarms enables the user to know precisely when and where transfers need to happen, allowing the application to keep and use the data and relay it to the user at the most appropriate time.

For users who do not need to create and save a trip, schedule information is easily accessible to be read in large quantities, allowing easy answers to questions such as "how often does this route run on Sunday" or "how long does it take to get to these intermediate stations". Furthermore, schedule editing on-device is an immediately easy solution for three major cases, most notably the third:

  1. Fixing incorrect or changed data on demand, which may not be edited in the central repository
  2. Adding data for public transportation that is not yet available, or has not been downloaded
  3. Inputting private transportation with unpublished schedules, such as vanpools, carpools, and shuttles

While schedule editing will not be a particularly frequent occurrence, the optimizations in our interface reduce the time necessary to make broad changes to existing data and input a large quantity of data quickly. For instance, while editing a field saying "8:42p", the user is able to change the time to "8:12p" by pressing only "1" and "2". The editor is also mindful of what constitutes a logical time and what doesn't; the editor is capable of discerning that "34" is a proper minute input, "342" is a full time (with no other possible characters), and "3421" cannot exist, while "1234" can. The research that we conducted opens the door for further optimizations, such as the possibility of AutoComplete for regular schedule intervals and automatic field advancing when the entered field is "finished", if and when the scope of this project is appropriately extended.

Implementation Described

  • The data-model (figure 11) that backs our system constituted a significant part of the actual implementation, though it is not explicitly reflected anywhere in the interface. This model is reflected as an SQLite database which we, unavoidably, had to write from the ground up. The database serves as a central accessor for both schedule data and trip data, broken into two separate tables (schedule data being 'global' - something that though editable by the user, comes 'pre-packaged' with, as of the current implementation level, BART data; and, trip data being 'local' - completely user-specific; encompassing both all trips and all alarms defined by the user).
  • We had to write a data-parser for the BART schedule data our system currently uses from scratch. This 'fills' (not completely as far as a real product would be concerned, but sufficiently as a proof of concept) the schedule data database table from above. In an ideal world, we would have to have done little or no parsing of our own, given access to something like the google transit API. Unfortunately, that was not available to us, so we had to treat BART as a special case in order to fill the system with transit data. We toyed with the idea of having the user input all the necessary transit data, but quickly discarded it as being FAR too cumbersome for realistic use (too much user overhead), though included editing schedule data as a feature.
  • In order to make the database work on the emulator, we had to consistently 'push' data to the emulator - part in the command line and part in code. The command line part only happens once per machine (ostensibly), but the code part has to happen once for every emulator life cycle. Essentially, we have to create the database on the emulator on the first run, kill the run, comment out the database creation section, and restart the program (in the same emulator).
  • The map-based selection was a particularly difficult part. While we definitely enjoyed working with Android because it is a very well designed platform, in certain areas the documentation is still quite lacking. Thus many hours were spent reading 3rd party tutorials that often were written for earlier releases of Android and included no longer functioning syntax. Some of the particularly challenging parts of our map implementation were the algorithms to determine when a user's cursor was hovering over a station marker thus requiring a UI event to be dispatched. This algorithm had to provide a reasonable margin of error so that the user's cursor need not be precisely on top of the coordinates of the marker and it also had to react gracefully in the context of varying degrees of zoom. Writing the code to display the route of a user's selected trip was similarly challenging as was the design of a mode of jumping between stations which acted in the manner the user would expect.
  • The alarm creation section was mostly straight forward to implement, however, as mentioned previously, implementation complications prevented the editing view to be modal based on the alarm type selection so the alarm type selection had to be implemented as a dialog (figure 7).
  • The main screen for schedule editing is implemented low-level using intercepted keyboard input and labels, rather than 'standard' android widgets. This was done because there wasn't a very flexible or useful set of controls within any of the widgets for implementing the complex (complex from a code perspective, but very streamlined from a UI perspective - feature invisibility aside) time input logic. Consequently, the input method for this activity had to be built from the ground up to implement the interface as envisioned.

Unimplemented/WoZ (Wizard of Ozzing)

  • Functioning Alarms - these were left unimplemented because testing/demoing proximity alarms would have been difficult seeings as the emulator doesn't have a live GPS feed. Furthermore, the scope of the class was to design a UI, and actually having alarms go off is a trivial UI (nothing novel happens when the alarm goes off, it's defining when the alarm should go off that is novel).
  • Trips that involve transfers can't actually be created. Though this seems like a large gap in the interface, the logic that would have been required to figure out transfer possibilities was far beyond the scope of designing the interface and was not realistically implementable. In an ideal world, none of the actual route-finding would have to be implemented by us, and we could simply have access to a system like google transit which could do the planning remotely for the phone.
  • On the map, though searching for stations is possible, searching for arbitrary locations (geocoding) on the map is not implemented (in other words, searching for a street, city, etc. to find stations in that vicinity would be useful in an ideal solution, but isn't supported). Similarly, reverse-geocoding - getting an address from a map location - is also a reasonable, but unimplemented feature. The primary reason for geocoding and reverse-geocoding remaining unimplemented is that the logic is extremely complicated, and not something we could reasonably tackle. To have a chance at implementing this, we'd need to have access to an API of some kind that takes care of the logic (which we don't), and in that case the integration into the UI would become the primary concern (seeings as the 'menu' would start to get a bit cluttered). Note: as a compromise, the ability to get a list of the nearest 3 stations is a recent addition to the map interface.
  • Agencies other than BART - we only have BART schedule data currently in our system because there is not a well-documented API that has comprehensive public transit data, so the addition of each agency requires a parser specific to the format of that agency's published data.
  • The schedule data editing does not allow for the addition of new or editing/deletion of present agencies, routes, and stops. Also, though times of existing trains' stops can be edited, new trains can't be added nor existing ones deleted.


Figure 1

Figure 1.  An info window displaying stop name on "Cursor Over"
Figure 1. An info window displaying stop name on "Cursor Over"

Figure 2

Figure 2.  Menu as accessed from map.
Figure 2. Menu as accessed from map.

Figure 3

Figure 3.  "Go to Station" functionality allows quick traversal.
Figure 3. "Go to Station" functionality allows quick traversal.

Figure 4

Figure 4.  Select Station (returns to new trip text entry).
Figure 4. Select Station (returns to new trip text entry).

Figure 5

Figure 5.  Quick navigation to closest stations when center is clicked away from marker.
Figure 5. Quick navigation to closest stations when center is clicked away from marker.

Figure 6

Figure 6.  Help screen from the map view.
Figure 6. Help screen from the map view.

Figure 7

Figure 7.  The dialog that prompts for the alarm type prior to creating the new alarm.
Figure 7. The dialog that prompts for the alarm type prior to creating the new alarm.

Figure 8

Figure 8.  The phone prototypes and maps, as they would be used.
Figure 8. The phone prototypes and maps, as they would be used.

Figure 9

Figure 9. The summary results screen.
Figure 9. The summary results screen.

Figure 10

Figure 10. The summary results screen.
Figure 10. The summary results screen.

Figure 11

Figure 11. The data model.
Figure 11. The data model.

Figure 12

Figure 12.  A subset of a selected route is indicated by lines between stops.
Figure 12. A subset of a selected route is indicated by lines between stops.

Figure 13

Figure 13.  Viewing schedule data, with carets on the side
Figure 13. Viewing schedule data, with carets on the side

[add comment]
Personal tools