GR2 - Designs

Scenario

Victor is currently an undergraduate at MIT in Cambridge, Massachusetts. His spring break will start in one week, on March 14th. He really wants to get away and travel to New Orleans, Louisiana to see an old high school friend - Mark - at Tulane University but wants to stop during the trip to see other friends and cities. He currently has a car and some money but cannot afford to stay in hotels along the way. He already knows he will be staying with his friend in New Orleans but doesn't currently have any planned accommodations along the way or along the way back. He wants to go but because of the school work he has, he really doesn't have time to spend hours planning a trip. He is planning on leaving Friday, March 11th and wants to be back in Cambridge on Tuesday March 22nd. He hears about the Facebook Application called Road Trippit and decides to plan the trip with this traveling tool. He does already have a Facebook Account.

    Victor logs into Facebook and searches for the Road Trippit application. Upon finding it, he signs-up for the application. He is brought to the "First Time User Page" which contains a little blurb about the application and link to "Create a Trip." He clicks on the link and is brought to the "Create Trip" page. Victor inputs his starting and ending location and the dates of travel. Now Victor is able to finalize the trip and take the next step of requesting hosts, etc. but he doesn't just want to travel from Cambridge to New Orleans - he wants to see some friends and places along the way.

    Victor wants to add locations to stop at along the way. Victor really wants to visit Washington D.C. to see his friend Maggie at Georgetown University; Nashville, Tennessee to his friend Stan at Belmont University; and really wants to see the city of Atlanta, Georgia but doesn't think he knows anyone in that there. Victor adds these locations to the interface and picks the dates:

March 11th : Cambridge, MA
March 11th - March 14th : Washington D.C. -> Maggie
March 14th - March 17th : Nashville, TN -> Stan
March 17th - March 20th : New Orleans, LA -> Tourism
March 20th - March 22nd : Atlanta, GA -> Mark
March 22nd : Cambridge, MA

    Victor likes the trip so he will plot the trip. He is starting from Cambridge, stopping in Washington D.C., Nashville, New Orleans, Atlanta, and returning back to Cambridge. There are "views" that contain the directions from each point to the next point including the dates and duration of the trip.

    Victor is almost all set to go but he needs to contact Maggie and Stan and see if he can stay with them. For each location there is an interface specific list of Facebook friends that are currently in that location. He selects Maggie for Washington D.C., Stan for Nashville, TN, and Mark for New Orleans, LA. However, he still needs a place to stay in Atlanta. As it turns out, he has some friends from high school going to school in Atlanta. He selects a few of them in order to see if he can stay with them; they are John, Jack, and Alexa.

    Now that Victor has selected his trip locations, dates, and people h wants to stay with (or request to stay with) he is ready to message those people about hosting him on his trip. He has the option to write a generic message to all of them with the dates he'll be there or "person-specific" messages. He opts for the generic messages for his friends Mark, Stan, and Maggie but decides to send a personal message to each of John, Jack, and Alexa. These personal messages outline how he'll be going on a road trip and really wants to see Atlanta and reconnect with old friends.After writing the messages, he sends them out and waits for replies. His trip is designed and dates are picked and most places are already "okayed" to stay at. He is waiting to hear back from Maggie, Stan, John, Jack, and Alexa.

    The next day, Maggie opens up Facebook and sees she has a message in her inbox from Victor. It describes the trip is going on and how'd he like to be able to stay with her in D.C. and wants to see if it would be okay. Maggie misses Victor and replies with a "yes." Stan does the same. Now, John sees the message but doesn't really remember Victor. He just thinks it's a "junk" message and deletes it without responding. Jack, on the other hand remembers Victor but won't be in Atlanta during those dates.  He replies back saying "no." Alexa sees Victor's message and would love to reconnect and will be in Atlanta. She responds with a "yes."

    Victor goes back to Facebook and sees these messages in his inbox and is relieved that he has a place to stay in Atlanta. He responds back thanking everyone and opens up Road Trippit. He then finalizes the trip by solidifying the people he is staying with: Maggie in D.C., Stan in Nashville, Mark in New Orleans, and Alexa in Atlanta. He is all set to go!
The day before his trip, Victor downloads and prints off the directions from Road Trippit as well as exporting them to his GPS on his smartphone. He hops in the car and heads to D.C. for his trip.

Designs

Design 1:



 

1)  Home page. Victor logins with his facebook account.

2)  Welcome page for first time users. Suggests how to get started and has a preloaded example of how to plan a trip.

3) List of trips that the user is planning. The user creates a new trip by entering the name and pressing the ‘create new’ button. Victor creates a ‘Spring Break 2011’ trip.

4)  Victor’s new trip is added to his list of trips.

5)    Here, Victor enters the starting and ending locations of his trip along with their dates.

6)  Victor now adds intermediate stops that he wants to be sure to stop at or at least close to on his trip. He enters the location along with the desired dates and desired hosts. Victor can get a list of suggested hosts if he wants to by clicking on the ‘suggested hosts’ button. Victor adds a new stop by clicking the ‘add’ button.

7)   Victor views his road trip so far on the map. Victor can click on a location and see the dates and host he has planned for that location (or a message saying that he has not confirmed a host for that location). Victor can click on the ‘View All Friends’ button to see a plot of all of his Facebook friends’ locations to give him a better sense for the best travel route.

8)  Victor navigates to the messaging tab. Based on the desired locations specified, Victor is presented with a list of possible hosts for the various locations pulled out of his Facebook friends. Victor can click on a possible host and start a message thread with that person via Facebook. Based on the conversation, Victor can confirm a host for a location or remove the person as a possible host.

9) When Victor is ready to be on his way, he navigates to the directions page which shows him step by step directions for his entire trip. He can click the ‘print’ button to print the directions or click the ‘export button’ to export the directions to another device.

Design 1 Analysis:

This design lets the user think of the trip creation as a step by step process. The tabbed interface allows each step in the process to be a distinct page which takes the user from beginning to end one step at a time.   

Learnability:

Learnability is probably the main advantage of this design. The tabs on the left side of the page suggest a clear progression of how to create a trip from start to finish. The interface is broken up into small manageable tasks on separate pages so that the user is not overwhelmed and can focus easily on one task at a time. The one downside is that this layout might not make it clear to the user that they can modify any step at any point in the process.

Visibility:

This design has good visibility in the sense that each task is on a separate page which allows the page to be simple and easy to manipulate. The design makes sure that clutter does not become a visibility issue. This design has bad visibility with regard to the fact that the whole state of your trip is not visible at any one time. In order to view the different aspects of the road trip, the user has to change tabs which limits what can be seen at one time.

Efficiency:

The design seems to be fairly efficient. The design does however gives up some efficiency in order to gain better learnability and visibility by using the tabbed interface. It might be somewhat inefficient for the user to have to change between views when trying to modify different aspects of the trip. The user may be viewing the trip map and want to change an intermediate location and might not want to have to change views in order to do that. However efficiency in this regard is sacrificed in order to provide a structured and distinct set of tasks for the user to easily complete.

Error Prevention:

This design has good error prevention. Each field that the user fills in (locations, hosts, dates, etc.) will give suggested completions. Fields will be checked and only accepted if they make sense (real locations, hosts and a timeline that makes sense). Also, every action that user makes can be undone, whether that includes changing locations, changing hosts, or changing dates. The user will be alerted if the change is inconsistent with the rest of the trip that is planned.

Design 2:



 
(1) This design starts with a login. Victor would login by pressing the "Login with Facebook" button. This page doesn't have much except a login button which is very simple and learnable. Not much about efficiency or error prevention.

(2) Welcome page (for a first time user - Victor). It talks about the application, what it does, etc. After reading, Victor will click on the "Design a Trip" button to begin planning a trip. This page, like (1) is very simple and learnable with little about efficiency or error prevention.

(3) Plan trip page. Here, Victor inputs his trip name, starting and ending location and the dates he wants to leave and return. The "Roundtrip" checkbox is preselect. Under the preliminary information of Start/End and Dates, is the "Add a Destination" option which, when clicked, allows Victor to add a destination. He clicked it 3 times, inputting Washington D.C., Nashville, and Atlanta as new cities. Each "Added Destination" will also all input for arrival and departure from these intermediate destinations. All "Date" input boxes will have a mini calendar which will allow a user (Victor) to select a date. There is a "Plot Trip" button which will bring the user (Victor) to a page with all of the information including itinerary, hosts, map, directions (see (4)). This page is simple and visible. The user can see all of the information that he inputs and and dates that are chosen. He is quickly able to add new destinations by clicking the "Add Destinations" button which doesn't change the page so everything stays visible. This makes it very learnable as well because this follows the traditional "Travel" site model such as Kayak.com. In terms of error prevention, this page doesn't have much room for actually having errors. Where errors could occur are in the "date selection" boxes and the "roundtrip" checkbox. We prevent errors in the "date" selection by having a mini-calendar which will enforce dates in the right format. These mini-calendars can potentially cover other fields and make them less visible but because we feel that's okay because it forces dates in the right format and prevents errors and when Victor would click out of the calendar or the "x", the calendar would disappear, returning back to full visibility. In terms of the other error of the "preselected roundtrip checkbox," more users planning a trip would most likely want a roundtrip and forget to press it then not wanting a roundtrip and remembering to uncheck it. We think it prevents more errors then it causes.

(4) This is the information page - the bread and butter so to speak. Visibility is number one here and all the information is visible to Victor (the user). He can see his trip itinerary which includes his destinations and dates of travel. He even has the ability to add a location or edit the information. He has a map that plots all of the destinations in the order of dates. Under the map there are directions from each point along the trip to the next point which are able to be printed, emailed, or exported to a smartphone gps interface (google maps, etc.). Victor (the user) also has a panel for hosts. Here He can see all the hosts he has selected for each location. Initially, this panel will list just the locations and no hosts (because no hosts were selected). As Victor (the user) selects hosts for each location, they will be added. He selects hosts by either clicking on the point in the map which will load a bubble of all his friends in that location and he search for a specific friend or pick anyone in that location. He can also select hosts by pressing on the location in the host box which will open the bubble in the map. From this "Hosts" panel, Victor (the user) will be able to send messages to his hosts asking to stay with them. This design of the page presents complete information of the trip (visibility) while still trying to stay simple (nicely organized, etc.). Learnability is relatively good here except the "host selection" may not be so obvious (there is no doubt room to improve here). By clicking the point on the map, one is able to select possible hosts but that might not be so obvious. Hence, by allowing the user to select the city in the "Hosts" panel, he will be able to add hosts because the bubble with friends will pop up on the map as if the user had clicked on the point. We hope that this "linkage" will make the interface more learnable for the user in future trip planning. Some of the errors that could occur here could be that the user (Victor) would print/export the trip without selecting hosts or sending them messages and assuming that messages were sent and confirmed. Perhaps this could be solved by adding a "Message Sent" icon next to each possible host to indicate that a message was sent. We could additionally add a checkmark icon or an "x" icon to indicate that host has accepted or declined to host as well. This would make the interface a lot more visible.

(5) This is the messaging page. By clicking on the "Send Messages" option in (4) in the "Hosts" panel or by clicking on the actual friend option in (4) in the "Hosts" panel, Victor (the user) would be brought to this messaging page. Here, the user can generate messages to send to each possible host. There would be a panel with all hosts and by clicking on one of them, the user (Victor) would be able to see the entire messaging thread. Next to each name in the "Hosts" panel, the user can select "yes" or "no" to show whether a host is confirmed or not. There is also an option to "Return to Trip" so the user can get back. This page is very visible. It shows the entire thread of messaging with each friend. The user can navigate to each message by simply clicking on their name. Further, the user can input whether the host is confirmed or not. Having these options and by keeping the messaging thread similar to the Facebook messaging system, the interface is very learnable. We could improve efficiency by not having to have the user select whether a host is confirmed or not. A possibly better method would be to have, in the message sent to the possible host, a "yes" or "no" button which the recipient of the message would select and it would automatically update the user's (Victor's) road trip information. This is a lot more efficient and prevents the error of the user not updating that information. The con of this is that this page is separate from the main dashboard of the trip; (4). Separating this from (4) allows for simplicity, both in (4) and (5) but it does reduce the visibility of the information for the user (Victor) in terms of the trip information. But having this in the (4) could really clutter that page and make it less efficient, simple, usable. This is the reason we ultimately opted for this separate messaging page with the "link" to get back to the trip dashboard.

Not shown in this scenario is the "My Trips" dashboard which will the user, upon logging in, to see all past, present, and future trips. He will be able to share them, edit them, etc. Hence, each trip, where ever left-off at, will be saved and able to be accessed later. Each trip will be identified by name.

This interface is panel/frame based. Victor would be able to visualize all information in different frames within the page.

Overall Design 2 Analysis:

Learnability:

The learnability of this design is good because it is consistent with what the user is familiar with when it comes to travel sites. The only downside to learnability is that the main information page (diagram 4) has many tasks that can be executed from the same page. The user will need to learn how to use all the features on this page without too much guidance from the interface. The trade off in this regard is made for better visibility. 

Visibility:

The main advantage of this design is the visibility. As the user updates and changes the trip, the user will always be able to view the state of the trip (locations, dates, hosts, maps, etc) in one page. The interface is however broken up into three different pages for three different tasks so that no one page becomes too cluttered. 

Efficiency:

Efficiency is good for a couple of reasons. First, the interface is consistent with what users are used to from most travel sites. So the user will be comfortable using the site. Second, the main information page makes it easy to switch between the various tasks of planning a trip without having to switch views. The user does have to switch pages to see messages but this comes with better visibility. Also, we feel that messaging isn't something that needs to be executed quickly and doesn't need to be in the main information page.

Error Prevention:

Errors will be prevented by helping the user complete the required information (by prompting and suggesting) and also do checks on every user action to make sure that the user is building the trip consistently and alert the user when they do something that is clearly wrong. Also, each user action can be undone so that user errors that cannot be automatically detected can easily be corrected by the user.

Design 3:

(1) This design starts with a login page where Victor will click on the button and login with facebook. Very simple and learnable. Not much with errors or efficiency.

(2) This page is the "Trips Dashboard" where all trips can be viewed. Because Victor doesn't have any previous trips, he will press the "Design New Trip" button which will allow him to create a new trip. This is a very simple and learnable interface, keeping consistant with many "travel dashboards" like those of Kayak, Orbitz, and Travelocity.

(3) & (4) This the map interface where all work is accomplished. Victor is present with a blank map where he can zoom in, zoom out, etc. Victor is able to select a point on the map and is presented a information bubble which consists of tabs of "Dates", "Friends", "Hosts", and "Directions." In each location, he would input the dates of arrival and departure and whether each location was a starting location or ending location. For example, after selecting Cambridge, MA as the starting location and inputting the dates, Victor would now select a new location and go through the same process. After select all locations, Victor would then search for possible hosts by selecting the "Friends" tab in each bubble and search through all his friends in that location, selecting them. He can them see this possible hosts by selecting the "Hosts" tab which will show whether each host is confirmed, pending, or no message sent. Here Victor will be able to send messages to his possible hosts by clicking on their name. and writing the message to them in the bubble. Once all hosts are confirmed, Victor can than view directions by clicking the "directions tab" and it will show directions for each point from the previous point and directions to the next point. There is an option on the top of the map to export directions to print, email, or gps. This interface is learnable but not very efficient or visible. All the information is hidden until the user (Victor) clicks on a location. Further, everything is tabbed so when writing a message to possible hosts, Victor would have to go back to the "dates" section and then go back to the message to write it in. This not efficient. Another con to this interface is that a user must click exactly on a location to select it. If Victor didn't press the exact location for "Cambridge, MA" he could have gotten the location of "Waltham, MA" or "Woburn, MA" which would have been wrong. Further, Victor may not have know that he had a wrong location and gotten directions that were wrong. This would have been a huge error. However, we try to prevent this error by showing, at the top of each bubble, the name of the location. This interface's pro is that it is all self-contained. Everything is there in one place and accessible. This is a traveling application so keeping everything in a map is the metaphor but perhaps this isn't the best interface or metaphor to keep with.

Design 3 Analysis:

This idea of this idea is to make the trip planner one page that is just a map of the user’s trip. Every task that the user needs to do in order to plan the trip can be done directly on the map. The design is location-centered meaning that instead of picking a task to do which has different locations within it, the design makes the user click on a location which presents all the tasks the user can do for that location (using pop up bubbles).

Learnability:

The design is learnable in the sense that it is very intuitive for a user to manipulate a trip solely by clicking around on a map. The user thinks of a trip in terms of geography so it makes sense that the user should be able to complete tasks by clicking on locations and modifying the parameters of that location. However there might be problems if the user doesn’t realize what can be accomplished by clicking where. There will be help messages displayed to first time users that tell them for example that they can click anywhere on the map to create a new stop in their trip and that they can click on any stop to modify the details of that location.

Visibility:

The upside to the visibility of this design is that the route of the trip is always visible because that map is always displayed no matter what task the user is working on. For example, if a user adds a location to the trip that change is immediately visible to the user. However there are some drawbacks to this approach. First, most of the state of the trip is not visible to the user unless the user clicks on a location. Second, once the user clicks on a location, that information is displayed in a pop-up bubble which has limitations on its size which limits visibility. The bubbles will be tabbed in order to fit the information comfortably in the bubble. Also, if the user has many bubbles open at a time, the interface may start to feel cluttered.

Efficiency:

Some aspects of the design are efficient. As mentioned earlier, from start to finish the user never has to navigate to different pages. Everything task the user might wish to perform can be done on the map from choosing locations to messaging possible hosts. However, the design lacks efficiency due to somewhat poor visibility. Another aspect that may be inefficient is the way that directions are displayed. Due to the design goals of this interface, the directions are viewed one leg at a time. That is, the user views directions from point X to point Y from within that location's bubble. It might be more efficient to display all the directions for the entire trip to the user but would require a modification to design that would sacrifice the learnability/visibility that is intended for this design.

Error Prevention:

Like the other designs, error prevention is dealt with by having suggestions for completing user defined fields and will check that what is input by the user makes sense. The user will be stopped from adding locations and a timeline that are inconsistent. Every action that user can make on the interface will have the option of being undone (except for the sending of messages).