...
(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.
...