Contextual Inquiry-Group:Anbaric sheep

From Cs160-sp08

Revision as of 09:37, 11 March 2008 by Pavel Borokhov (Talk | contribs)

(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)

Scott Crawford completed the Task Analysis section, and conducted an interview.
Paul Mans conducted an interview, completed the Task Overview and Analysis of Approach, and helped assemble and print the final product.
Paul Borokhov was charged with the Interface Design.
Jeff Bowman conducted an interview, completed the Target Users, Interviews, and Analysis of Tasks, and helped assemble the final project.

Target Users

One interview was held with "Kristen", a student attending community college in Santa Rosa. Kristen takes four round-trip bus trips per week, between her house and the school; she also takes additional weekend trips from Santa Rosa to Berkeley via San Francisco, and much longer trips to the South Bay once or twice a year. She has been travelling an increasing amount on mass transit over the past four years.

Another interviewee, "Herbert", is a UC Berkeley student who has become reasonably well versed with the various Bay Area public transit options after moving here four years ago from Southern California. He described his public transit use as frequent around Berkeley (the AC Transit buses), but around monthly for getting on any of the transit lines that lead out of Berkeley. In town, probably four times a week, Herbert takes one of the AC lines that stops near Soda on Euclid to get to his apartment over Southside. Every three or four weeks or so Herbert takes Bart to visit friends in San Francisco or he rides Bart then Caltrain to go visit friends at Stanford. Herbert also occasionally uses Bart to go to baseball games in both Oakland and San Francisco in the summer. Additionally, earlier this year, Herbert took the Amtrak train from Emeryville to Truckee to go skiing.

Our final interviewee, "Richard", has spent nearly the last 40 years varying between public transportation and driving to get to work every day. As a computer software engineer, he has constant desktop access to the internet, but frequently walks or bikes away from a dedicated internet connection. He also plans the occasional trip from the East Bay to sports games and airports, but predominantly uses mass transit to get to and from work.

Problem and Solution Overview

Our group recognized through our own experiences that there is a need for a mobile application to aid user's in keeping track of public transit schedules and performing useful operations such as reminding them as their scheduled time of departure approaches. Interviews with users of various Bay Area public transit vehicles confirmed that we were not alone in desiring such an application. Our efforts in the conceptual design of this application have yielded the description of a mobile app that will provide users with three helpful features. First, our application will provide an interface that makes easy the entering of trip length transit schedules into a Android powered mobile phone. Secondly, these "trips" will be saved for the user to call up on later dates because we have determined that our users often experience recurrent transit patterns. Thirdly, our application will provide the ability for the user to easily set various alerts corresponding to times on their travel itineraries.

Contextual Inquiry - Interview Descriptions

When asked his process in planning his trips on public transit, Herbert replied that it depends on what kind of transit he is taking. For the AC bus lines he only boards the bus if he happens to see it approaching when he is starting to walk home. Otherwise, if he doesn't see a bus, he will cut through campus and walk the entire way. Kristen and Richard, however, have a set routine which they have memorized and written down; their commute is more regular, so their transit options are much easier to predict.

As part of the interview, Kristen recreated a page she carries around with her during her normal commute:

M-W
 MV  term  14  SRJC
9:28-9:40-9:45-9:50
8:58-9:10-9:15-9:20

She noted that the real page has three such trips, and an additional three trips on the way home. Upon asking how long it took to make the page, she said "5 minutes". In creating the schedule, she pulled up Google to find the transit provider's schedules in PDF format, and also used her bookmarks to find BART's trip planner. When asked about 511's Transit Planner, she called it a "pain in the ass", and noted that for longer trips or trips where the schedule was unknown, she would print out entire pages of schedules "like [she] used to do".

In addition, after doing spontaneous commute research during the interview, Kristen produced a Post-It note recreated here. "The first is the trip on BART", she explained, "and the next is the trip on Golden Gate Transit." When asked why she only put a single trip, she responded that she was pretty sure she could make it, and that she had left herself enough room between trips.

 1:47 - 2:10
 2:20 - 3:56

Kristen noted that she usually looks at the clock before a pending transit trip, and occasionally sets an alarm: She lamented that her cell phone had a finite number of alarms, and that she would definitely set an alarm if it were easier to do. She said that this was more important with the longer trips, which may have an hour between buses for certain trips.

For BART trips to San Francisco, Herbert said that he usually just goes to the station and catches the first available train going his direction. However, recently he has been using the online schedules more often because he found that they are actually pretty accurate of the timing of the trains. For his trips to Palo Alto Herbert said that he almost always checks both the schedules of Bart and Caltrain online from their respective sites before leaving. He said that once he had to wait almost an hour for the Caltrain because he picked a poor Bart connection, and that this experience was something he wanted to avoid thereafter. When Herbert took the Amtrak to Tahoe he purchased his ticket ahead of time online and used Amtrak's student rewards club.

When I asked Herbert whether he could imagine himself using an application on his cell phone to aid in recording schedule info on public transit trips he said maybe. Herbert's exact response was "only if it was super quick and easy to use". I then asked Herbert whether he would use such an app if it was as easy to use as writing the info down on paper but of course had the benefits of digital data (like saving, emailing and actions upon that data like alarms etc.). Herbert liked the idea of setting alarms but said that he really wouldn't have much use for pulling up former trips that he had saved because he never leaves at a consistent time in the day and he was worried the schedules might have changed in the meantime. I then asked Herbert whether he would use the product if it was slightly harder to use then writing the data down on paper. Herbert responded by saying that he probably would not use the program if it took more time to input data then it takes for him to write it down--however if the additional features like alarms and stuff were really good then he might even so.

Partway through the interview Herbert got a very excited look and exclaimed "Wait, is this going to have the schedules from Bart and Caltrain"? I asked him if this was important to him. "Hell yes," he said. "I would love to figure out what time the next Caltrain is leaving while I'm roving the city". I asked Herbert what other things would make planning his transit easier. He said that when he plans his trips online he hates wading through the long list of Bart stations that are in a drop down menu. He said it would be really cool if only the closest Bart stations were shown. He also wished that he could pick stations on a map instead of in a list.

These were some of the most salient points gleaned from the interview:

Herbert started using the online BART schedule more often when he found out that the trains are pretty reliable in terms of time
Herbert said that he would use the app as it was described to him but only if it was as easy to use as paper
Herbert wanted to be able to access schedule data on his phone
Herbert said that he would like to be able to plan his public transit through a map interface

Richard noted that he has a very set routine commuting to work: He rides his bike to the bus stop, assuming that the bus will arrive close to the published schedule (at 15 minute intervals), because he wants to sleep as long as possible. He said that he normally arrives less than 5 minutes ahead of his intended bus.

Richard's commute home is more erratic, he said, and that last minute work things may switch which bus he wants to catch. He rides back to the bus stop, averaging 6-8 minutes—a length he's established from experience. He mentioned the display attempting to estimate when the next bus will arrive, and that it is usually wrong (but sometimes correct or close). He said that if the information were more accurate, or available before leaving the office, it would make the commute ride more efficient and less stressful. Regarding the trip planning, he said "you're there and you have to wait anyways"; meaning that he wasn't concerned with planning his trip.

Task Analysis Questions

Who is going to use the system?
The system is designed for users of mass transit who plan their trips. Not all users make such preparation: Herbert, for instance, noted that many of his trips were spontaneous and that he just took whichever bus came first.
What tasks do they now perform?
The major task performed is to plan, store, and recall a plan for using mass transit to take a trip of some kind. In addition, as all three interviewees mentioned, setting an alarm or alert would also benefit.
What tasks are desired?
Herbert mentioned that he would like to fill in his destinations based on current location, and/or select them on a map. Kristen mentioned that she would like to see easier trip selection, and see times side-by-side in a trip with multiple "legs" (defined below). Richard mentioned that his commute changes based on how the weather will be, so it would be nice to integrate a weather report into the trip planning, or make it easily accessible; he also noted a need for some kind of alarm system that integrates real arrival time data instead of published times.
How are the tasks learned?
All three interviewers seemed to have learned by reading the transit providers' websites and taking mass transit; there do not seem to be any explicit educating entities.
Where are the tasks performed?
Currently, the tasks are usually performed at home or work, in conjunction with the internet and several mass transit websites. [The need to switch between different websites during a trip plan is clear; during the interview, Kristen explicitly created new tabs in her web browser to accommodate the different transit schedules.]
What is the relationship between the user and the data?
The user is very much a consumer of transit data, provided by the transit providers. There is currently no system for aggregating user-submitted transit data and plans, though that is a possibility in the context of the proposed application.
What other tools does the user have?
All three interviewees mentioned published schedules online; Kristen also mentioned published schedules near bus stops. Richard mentioned NextBus bus schedules available at his bus stop.
How do users communicate with each other?
Users do not communicate with one another in our current and proposed tasks.
How often are the tasks performed?
Each of our interviewees was a frequent user of mass transit; however, the planning component took place at a variety of different times. Kristen's courses change every semester, so she plans once a semester and sporadically for "new trips". Richard plans only when bus schedules change. Herbert plans only for long trips, and during the week uses mass transit without making explicit plans beforehand.
What are the time constraints on the tasks?
None of our interviewees mentioned any specific time constraints in connection with their tasks.
What happens when things go wrong?
Kristen categorized her trips into three categories: "buttf^@% early", "early", and "oh s#!+ i need to run" trips. She noted that the trips home were less stressful, because the buses were frequent and there was not usually any time constraint on her arrival home. Richard noted that his trips home also had frequent buses, so it isn't terribly inconvenient just to show up and "wait for the next one"; he also noted that he drives to work under extenuating circumstances (such as bad weather).

Analysis of Tasks

The tasks that our project intend to provide functionality for can be summarized as a subset of ways to interact (usefully and meaningfully) with data about routes (involving at least some public transit component). I will refer to these routes as 'trips' and any distinct component of a trip as a 'leg'.

Easy Tasks

Create and set an alarm for a new, non-recurring trip. This is a ‘reminder’ task for users and can pertain to the whole trip or to individual legs of the trip. A trip is non-recurring when you only intend to take it once; more concretely, you only intend to take the trip with this trip’s sequence of legs once. An example of a non-recurring trip would be a non-frequent flyer taking a trip via plane somewhere (the destination can be variably defined – perhaps they are only worried about getting to the airport, or perhaps the real destination of concern is their hotel in the new city – and example legs of the trip would be the BART ride to the airport, the flight, and the taxi to their hotel). In practice, people may devise any number of ways to remind themselves about when they need to switch trip legs, or begin a trip in order to get where they are going on time (ex/ a standard cell-phone or wrist-watch alarm, writing times on their hand, asking people to remind them, post-it notes etc.). We want to address this user task in our project because we feel that a user might create a more effective alarm by correlating data about their intended trip with. This would entail things like notification and countdown timers about when to begin the trip (ex/ “Leave within 10 minutes so that – if all goes according to plan – you arrive at your destination at or before your desired ETA.”) or transitions between legs (ex/ “Get from the BART station to your plane terminal within 30 minutes so that you won’t miss your flight.”).
Set an alarm for a recurring trip. This is a ‘reminder’ task for users, intimately similar to the previous task, but with the nuance of the alarm being associated with a trip that is being repeated. Commonly, this will refer to commutes – trips performed on a nearly daily basis – but this task generally applies to any trips that the user frequents.

Moderate Tasks

View a pre-defined trip. This refers to wanting to be able to visualize where you are going (ex/ referring to the map of the BART system posted on the interior of a train while in transit). Being able to see the ‘plan’ for a trip may be important for a number of reasons. You may need to relay the information about how you intend to complete a trip to someone else who wants to possibly perform your trip for themselves or maybe so that someone else will know what sequence of places you’re going to be at (in case they want to meet with you somewhere, or are concerned about your safety/progress). You might also want to see the plan in order to consider how to alter the plan for some other purpose (ex/ how to pick up a pizza for the family on your way home from work).
Edit a pre-defined trip. As implied by the previous task, users will not only want to abstractly consider alternate or additional legs for a trip, they will also want to actually implement those legs. This requires you to alter your trip plan and will completely reformulate things like when you expect to arrive. This operation isn’t actually that difficult in practice because though the whole trip may be complex, the ‘detour’ – or, the addition/substitution of new legs – is a ‘minor’ change to the trip as whole in comparison to planning the whole trip from scratch (note: trip modification can either be an insertion process that preserves the previous source and destination, or an extension process that defines a new source and/or destination). Also of note, as far as our end product is concerned, creating a ‘duplicate’ trip for the purpose of editing (and preserving the original trip) would fall into this task category.

Hard Tasks

Create a new trip manually. This refers to the arduous process of planning a trip. You have to obtain schedules for each leg and synthesize leg transitions. In other words, you need to know things like the schedule and routes of BART trains, where to make transfers, and how long those transfers are likely to take (ex/ BART trip from school – Berkeley – to home – Pleasanton). Often times in planning a trip, certain details may be replaced by more general information (ex/ instead of knowing the exact times at which BART trains are supposed to arrive at/depart from a station, you may simply be interested in the frequency with which they arrive/depart). This will make your plan less functional, but easier to create. Sacrifices along these lines are made consistently in current real-world situations, so whatever interface we design should allow for users to make similar sacrifices in trip/leg data granularity both in order to mimic their previous habits and to make the process of creating a trip – an inherently difficult task – as simple as possible (since the creation of trips is, in essence the core task). A possible avenue for exploration in the project is perhaps making the system robust enough to fill in some of the gaps that trip/leg ambiguities creates.
Set a recurring alarm (requires the trip/leg data to have finer granularity). This is a more complicated version of the two alarm-type tasks that are described as easy tasks. In essence, having an alarm go off once to alert you about something that happens once is easy, but having a system that reminds you every time a ‘general’ event happens is trickier. This is a hard task for a current real-world user, but would actually be reasonably simple to code. The important thing is that it requires information about the event-for-which-you-are-being-notified’s recurrence. In this way, the task will remain difficult for the user, because in order to get, for example, a 10-minute warning about the next bus that’s coming, the system needs to know the entire bus schedule (not just one particular bus).

Interface Design

Main contributor: Paul B.

The overall design of the program will be trip-oriented. As described earlier, the goal of the application is to allow users to effectively create custom schedules for trip(s) that they want to take in the future. Therefore, it makes sense that the interface be trip-oriented instead of action oriented.

Throughout this description, we will use an example trip to illustrate the functionality of the application. This sample trip is given by

 Berkeley    Coliseum    OAK
3.15->3.30  3.40->3.50  4.30

In this trip, the user takes some vehicle from Berkeley at 3.15 and arrives at Coliseum at 3.30. Then, the user takes a different vehicle at 3.40 from Coliseum and arrives at OAK at 3.50. Lastly, the user takes some other vehicle from OAK at 4.30 (no destination or arrival time are given). Note that "vehicle" can be any transportation mode, including bus, train, subway, bike, walking, etc.

The basic startup screen will depend on whether a trip is currently "in progress". A trip is defined as "in progress" if you have previously opened the program and "started" the trip in question. Consequently,

Figure 1. Trip status view

If a trip is in progress, the startup screen will show you a summary of the remainder of your trip, as determined by the device's clock. In our example trip, if the user opened the application at 3.25, the rest of the trip (Coliseum 3.40-3.50, OAK 4.30) would appear on the screen. An options menu would also be available to change the currently-set alarms for the trip, stop the trip, and view the list of other trips. (Fig. 1)

Figure 2. Trips list view

If a trip is not in progress, the startup screen will show you the list of trips. These are trips that you have previously defined and saved. In addition, a "dummy" trip would consist of a menu item to create a new trip and be located at the top of the list. (Fig. 2)

Upon selecting a trip from the trip list, you can do a number of things with it. Namely,

You can "Start" the trip. This will allow you to set an alarm for each leg of the trip which will go off a specified amount of time before each leg begins. For example, in the previously-defined trip, you could set an alarm to alert you of the coming departures 10 minutes before each departure is scheduled. In that case, alarms would go off at 3.05, 3.30, and 4.20. The user would have both the ability to set the same alarm for all legs, or different alarms for each leg. With our sample trip, if the last leg is an airplane flight, it would make sense for the last alarm to take place 20 minutes before the take-off time as a reminder that if you have not begun going through security by that time, you need to cut to the beginning of the line so that you do not miss your flight. If the selected trip is already in progress, there will be a "Stop" option in place of "Start", which will end the trip immediately, canceling all previously-scheduled alerts and removing the trip's progress from the startup screen.
You can view a trip. This allows the user to peruse the trip before it is actually started and potentially correct errors or simply verify that the information is correct and think about how their trip will go. For example, if we created the previous trip on a Wednesday but won't actually be taking it until Sunday afternoon, we might want to look over the trip again during breakfast on Sunday morning. While viewing a trip, we can immediately edit it, use it as a template for a new trip, or start it.
Lastly, you can directly edit the trip without needing to view it first. This allows the user to either modify the selected trip and save it, or to make changes to the trip and save it as a new trip.

Each of these is described in further detail below.

Starting a trip

Figure 3. Starting a trip and setting an alarm for all legs

Figure 4. Starting a trip and setting an alarm for only the first leg

You start a trip by opening the trip list, highlighting the desired trip, and then pressing the selection button. Upon doing this, you will be prompted with a dialog in which you can choose the alarm interval for the alerts which will pop up prior to each leg's departure (Fig. 3). In addition, you will have the choice of setting no alarm at all or setting separate alarms for each leg (Fig. 4). In the former case, the result of starting the trip will simply be that the next time you open the application, you will be presented with the remaining portions of your trip instead of the list of trips. In the latter case, the alert you enter into the current dialog will only apply to the first leg of the trip and additional dialogs will pop up for each additional leg of the trip. These will be clearly reflected to the user so that they know the effect of their choices. In addition, at any point you can back up to the previous step, whatever that step might be (setting the alarm for the previous leg, going back to the trip list, etc).

Stopping a trip from the trip list

While a somewhat corner case, since trips can be stopped directly from the trip status view, a trip that is currently in progress can be stopped from the trip list as well. To do this, one would highlight a trip from the list as usual and press the menu, choosing the "Stop" item in the popup menu that appears (the effects of stopping a trip were described earlier, as well as below).

Viewing a trip

Figure 5. Choosing to view a trip

Figure 6. Viewing trip legs

Figure 7. Popup menu

To view a trip, you highlight it in the trip list, press the menu button, and choose "View" from the popup menu (Fig. 5). This takes you a new screen on which the entire trip is displayed. The legs are displayed in a list, with the starting and ending points for each leg, as well as some additional information the user might have added. Depending on the amount of screen space available, only crucial information (leg endpoints) is shown, and additional info is shown only when a leg is highlighted (Fig. 6). A leg is highlighted by using the 4-way navigational buttons to move down or up the leg list. Whenever a leg is highlighted, it can be directly edited if the user so chooses by pressing on the menu key and choosing "Edit leg" from the popup menu. Pressing the selection key shows complete details for the leg, including any notes the user has added. In addition, regardless of the selection, the trip can be started immediately when it is being viewed by pressing the menu key and choosing "Start trip" from the popup menu. Lastly, the entire trip can be edited (instead of just a single leg) by choosing "Edit trip", and it can be duplicated to create a new trip which can then be modified with the original trip remaining unchanged (also choosing "Edit trip" but then saving the changes differently) (Fig. 7).

Creating a trip

To create a trip, highlight the "New trip" dummy "trip" in the trip list and press the selection key. The user is then prompted for a name for the trip, prefilled to a generic name such as "Trip 1". In addition, the user can set the default alert for the entire trip if they want to. This will be used to prefill the alert settings when the trip is started. After this, the user is shown the leg list, in which the only "leg" shown is the "New leg" menu item. They can then create legs as described below.

Editing a trip

To edit a trip, you highlight it in the trip list, press the menu button, and then choose "Edit" from the popup menu. Alternatively, you may first view the trip and then choose to edit it from there as described previously. When entering the edit trip mode, you are shown a list very similar to the one displayed while viewing a trip, with the trip's legs listed and the most important information shown regardless of selection, and more information shown when the leg is highlighted. However, unlike the view trip mode, the edit trip mode allows you to delete, edit, and add legs and modify trip properties. As a result, the first "leg" shown in the list is actually a menu item which allows you to add a new leg. Consequently, the "legs" shown for the example trip would be "New leg", "Berkeley-Coliseum", "Colisuem-OAK", and "OAK". To edit the trip name and default alerts for the trip, press the menu key and choose "Edit trip properties" from the menu.

Creating a new leg

To create a leg, simply press the selection key with the "New leg" highlighted. This will present a new screen with a number of fields to define the leg. Some fields will be pre-filled to speed up entry, while others will be optional and can be put in by the user if they want to be thorough or are not in a hurry. In addition, the editing form will be broken up into tabs to make sure that not too much information is presented on the screen at a given time.

The first tab will contain fields for the names of the starting point and ending point and starting and ending times. The name of the starting point, if this is the first leg, will simply be a generic name like "Point 1" ; this allows someone in a hurry to quickly enter the times for the leg without having to bother with destination names. If this is an additional leg, then the starting point will automatically be prefilled from the ending point of the previous leg. The ending point can be left blank, as was the case with the last leg of the example trip. Then, under starting point, the departure time can be set with a standard time picker control, and an arrival time can be set for the destination, if one exists. Both of these are prefilled with the current time for convenience.

The second tab will include additional information about the leg. The user will have the ability to specify a mode type, which is free-form and can be something like "bus", "AC Transit", etc. In addition, the user can add a more generic "note" which can have any additional information and will only be displayed when the leg is fully viewed from the trip. Lastly, the user can set a custom default alert for the leg if they would like to. This implies that each leg in the trip will have a different alert.

Once the user has entered information to their satisfaction, they press the menu key and choose "Save" from the popup menu and are returned to the list of legs, which now has the newly-entered leg. To add additional legs, the user highlights the "New leg" and selects it; a popup menu prompts where to insert the leg (end of trip, beginning of trip, after X leg); the user then chooses the appropriate insertion location, and they are presented with the fields described above for entering data about the leg. Obviously, the popup menu will be smart enough that when there's only one leg, the "after X leg" item would not be visible, and no menu would be presented when there are no legs in the trip at all.

Editing a leg

Upon highlighting a leg, pressing the selection key will allow you to edit the leg. Then, the same fields as described above in leg creation, will be shown to the user with the leg's information filled into them. Changing the starting time for the leg will timeshift the arrival time by the same amount of time, so if the starting time is changed to be 30 minutes after the previous time, the arrival time would change by 30 minutes as well (of course, if this is not correct, the user can change the arrival time after this). Saving the information will return the user to the trip that the leg is part of. In addition, pressing the menu key after highlighting a leg will popup a menu from which the user can select "Delete leg" to delete the currently-highlighted leg.

After the user has edited the legs to her satisfaction, she then presses the menu key while in the leg list view and chooses "Save trip" if she wants to save the modifications to the existing trip under the same name or "Save as new" if she wants to create a new trip with the legs as she defined them. She can also choose to cancel all of the edits by choosing "Discard changes" from the popup menu. Attempts to exit the application or return to the trips view from an edited but unsaved trip would result in a popup dialog which would prompt the user as to what she wants to do with regards to the changes.

Trip status view

The trip status view is displayed when the application starts up and a trip is in progress, as described earlier in the overview. The trip status view shows the legs which are remaining in your trip (as determined by the departure times you have put in and the time provided by the mobile device). The first upcoming leg, which is also highlighted, shows the starting and ending points, the departure and arrival times, and the alert time, if one is set. Pressing the selection key allows the user to view full details about the leg and modify the alert that is currently set for it. If there are more legs remaining, they are shown in summarized form, displaying only the starting and ending points and the departure time in a smaller font. The user may then highlight them using up/down arrows to view more details about them. Pressing the menu key in this screen presents a popup menu with options to "Stop" the trip, which will remove the trip status view from the screen and cancel all pending alerts, and view the list of all other saved trips ("View trips list").

3 sample scenarios

User wants to view a trip

Storyboard for the view trip scenario

The user tells his friend that he is planning on going into the city tomorrow and the friend is interested in when the user will be going there and some details about the trip. The user opens the application and is presented with the list view (if the user is currently in the process of taking a trip, he will open the application, press the menu key, and choose "View trips" from the popup menu that appears). He then highlights the trip that he is looking for and presses the menu key, then selects the "View" menu item from the popup menu that appears. He can then scroll through the list of legs of the trip to get detailed information about each leg, and if he wants to, view complete details about each leg by pressing the selection key.

User wants to edit a trip

Storyboard of user editing a trip

The user has realized that she needs to make her trip an hour later than previously thought. To edit her trip, she arrives at the trip list view (as described in the previous scenario), highlights the trip of interest, presses the menu key and then chooses the "Edit" menu item. Let's say that the trip she wants to edit is the example trip displayed in the beginning. She highlights the first leg, Berkeley-Coliseum, and presses the selection key. She then changes the starting time to be one hour later, 4.15. She then verifies that the arrival time for the leg is correct, since the program would automatically change it to 4.30. She then presses the menu key and chooses "Save" from the popup menu, which returns her to the leg list. She then chooses the next leg and edits it in a similar manner. Once she is done editing legs, she presses the menu key and chooses the "Save" or "Save as new" option depending on her preference to save the changes. This returns her to the trip list view, from which she can then start the trip if no other trip is currently in progress.

User wants to set alarms for a non-recurring trip

The user is getting ready to undertake the example trip described in the beginning and is getting his things together on the morning of the day on which the trip will be undertaken. He wants to set alarms for the legs of his trip so that he doesn't miss any of his connections. He opens the application and highlights the trip which he had previously created. He then presses the selection key to "Start" the trip immediately, upon which he is presented with a popup dialog for setting the alerts for the trip. Since the modes here are different, and the final leg is a flight for which he needs an early reminder, he will check the "Unique per leg" checkbox in the alert box and enter the number of minutes before the start of the first leg that he wants to be alerted at (say, 10 minutes). He then selects the "Continue" button to choose the alert for the next leg. In case his first segment is running late, he wants to be reminded when the second leg departs so that he can run to catch it if the time is close. Consequently, he sets an alarm of 5 minutes before departure and again selects the "Continue" button. Then, he sets the final alarm of the trip for the last leg, 25 minutes before departure, to make sure that he doesn't miss his flight. At any point in the process, he can also select the "Back" button to go back to the previous step.

After choosing the "Continue" button for the last time, the program presents the trip status view showing the upcoming legs of the trip, with the first leg shown in the biggest font and highlighted. The user can then exit the application; whenever they want to see the trip again, they can simply start the program again and the trip status view will be displayed.

Analysis of Approach

In design thus far, our application has a fairly specific scope that we believe will lend it strengths and weaknesses as well. By focusing on the specific problem of entering scheduling data into a mobile device our design team hopes to finely tune a single area of interface design as opposed to only satisfactorily accomplishing a great number. Furthermore, we plan to design our application in such a way that it is extensible for continued development after the duration of this course.

In more concrete terms, the tradeoffs that we plan to make due to focusing on a limited scope problem area have to do with the feature set of the application. In particular, the idea of integrating scheduling data from the various transit authorities around the Bay Area has been frequently debated in our group meetings. The obvious benefit of this would be a single source for the user to consult for both planning the times of their transit as well as creating a saved trip itinerary. The principle reason not to extend our application to a route scheduling solution as well as a transit itinerary helper comes simply from the magnitude of complexity that route planning and scheduling would add to our program. For starters, scheduling data from public transit authorities in the US has not yet been suitably standardized (although Google Transit is a major step in the right direction). Thus an application that provided scheduling functionality as well would be limited to using public transit authorities in the US that had compatible schedule data.

The obvious con to not having scheduling data integrated into our application is that users will need to consult public transport schedules online or in print so that they can enter their itinerary into our application. However once this step is completed, and it would only need to be completed once for recurrent trips, users will suddenly no longer be tied to a computer or post-its which are the temporary alternative to entering trip information in our application. This is in fact the principle quality of our application that will take advantage of the affordances of mobile devices. In comparison to post-its, the data storage capacity of mobile phones is bigger then most recycling centers. Entering trips in their phone will provide users with a digital record at their disposal until the time when user does in fact dispose of (erase) a trip record.

Another quality of mobile phones is the tendency of users to keep them on their person at all times. Since phones are small in form factor and most importantly enable communication, users tend to carry them around more consistently then TabletPCs, GPS units and even PDAs. While our program could indeed be ported to all of these other devices, mobile phones undeniably are the most exciting platform due to their average proximity to our users. Additionally, Android offers some qualities that make it more suitable for our application then some of the other "closed" platforms like Brew or Windows' Mobile Edition that are other platform choices for development. Provided that we do in fact develop a successful interface for entering trip information, we could source our interface for other companies to use for data entry in their own mobile apps. Developing on Android will make this much easier to do.

Despite the numerous positives we can point out about our application there are also some glaring cons that are apparent. I think we can all agree that an app that included scheduling data and route planning data could accomplish much of what we are trying to do and with added value as well. Despite the fact that there are no current such solutions that integrate the various public transit authorities, I believe it is only a short matter of time until such a solution does in fact exist. Both 511.org and Google Transit already offer point to point route planning services and it only makes sense that one of them will soon port these services to a mobile device.

Nevertheless we are confident that our team can make large strides in the design of a mobile phone interface that facilitates the entering of transit schedule data. We only look forward to exhibiting the results we arrive at.

[add comment]

Retrieved from "http://vis.berkeley.edu/courses/cs160-sp08/wiki/index.php/Contextual_Inquiry-Group:Anbaric_sheep"