...
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
...
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.
...
This interface is panel/frame based. Victor would be able to visualize all information in different frames within the page.
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.
...