This MediaWiki 1.13.5 installation needs to be upgraded. Contact help@csail to schedule.

Projects/Trip Planner

From 6.831Wiki

Jump to: navigation, search

Contents

Group Members

  • Zahir Dossa
  • Akash Shah
  • Amy Wooten

The Idea

Problem Statement

Currently, to plan a road trip, one needs to map directions from one point to another while also trying to find points of interest along the way. Furthermore, there is no easy way to integrate points of interest into a trip and get driving directions along the way. For example, if someone wants to drive from Los Angeles, CA to Boston, MA, it would be nice to see pictures of places to see along the way with driving directions that automatically include the places that person would like to see.

Solution

We plan to use the Google Maps API to allow a user to get directions for their trip while incorporating points of interest along the way. Moreover, when the user sets a starting point and destination, the program will show images of key points of interest along the way. The user can then select what points of interest they would like to visit and the driving directions will be updated to have stops at these places along the way. Points of interest will be ranked based on number of pictures available. They will be shown based on their rank and proximity. The user will be able to view more points of interest (those of lower rank) upon request. The program will also serve as a map-based photo album where users will be able to load pictures from their trips and point to the location where each picture was taken. We will use the tags on these pictures to determine points of interest!

Task Analysis

Users

This program is for anyone trying to plan a trip from point A to point B, whether it is a long road trip, or a simple walking tour.

Parents and Families

  • Age: 25-70
  • Male and Female Users
  • US, English speaking individuals
  • Literate and Educated
  • Not necessarily computer experts, but comfortable with using computers
  • Want the most memorable family experience
  • Generally using the application from home in their spare time
  • Do not need to be familiar with the application
  • One or more users using the application together

Students and Young Adults

  • Age: 16-30
  • Male and Female Users
  • US, English speaking individuals
  • Literate
  • Generally have computer experience from school work
  • Familiarity with computers
  • Concerned with flexibility
  • Want to explore as much as possible
  • Do not need to be familiar with the application

Tasks

Loading Pictures

Goal:

  • To load pictures from a camera or computer folder onto website

Preconditions:

  • Internet access (this is a precondition for all tasks and therefore will not be repeated)
  • Mouse and keyboard input (this is a precondition for all tasks and therefore will not be repeated)
  • Account user name and password
  • Pictures must be stored/accessible from a computer folder
  • Ability to navigate to find picture/folder location

Subtasks:

  • Log in
  • Go to "load pictures" area on website
  • Locate picture or album location
  • Select picture or album to upload

Tagging Pictures

Goal:

  • To tag the subject and location of pictures

Preconditions:

  • Account user name and password
  • Be able to find picture to tag
  • Knowledge of subject and location of picture
  • Be able to point to a location on a map of where picture was taken

Subtasks:

  • Log in
  • Locate album
  • Find pictures to tag
  • Enter subject for picture
  • Find map location of where picture was taken

Getting Directions

Goal:

  • Finding driving directions from a starting location to a destination.

Preconditions:

  • The address of the starting location.
  • The address of the destination location.
  • Understanding driving directions.

Subtasks:

  • Enter starting address
  • Enter destination address
  • Submit query

Finding Points of Interest

Goal:

  • Being able to search for a point of interest to locate it on a map

Preconditions:

  • Name or subject of the point of interest

Subtasks:

  • Access search portion of the website (no log-in required)
  • Enter a subject to search for
  • View thumbnail pictures of point of interest
  • View location(s) of point of interest

Finding Things to See and Do

Goal:

  • Find interesting things to do in a certain area

Preconditions:

  • Location
  • Types of things you want to see
  • How far you want to travel
  • Time you have

Subtasks:

  • What is the representation of location (how can I search for them)
    • GPS coordinates
    • City names
  • Storing things to see
  • Searching for things to see
  • Displaying relevant pics/location on map
  • Calculating how far you have to travel/how much time it is going to take

Including Points of Interest to See in Directions

Goal:

  • Given a different options of things to see/do, include them as part of the trip

Preconditions:

  • Must already have a trip planned
  • Must already have atleast one destination to add

Subtasks:

  • Storing which new points to add
  • Calculate new driving directions based on new entries
  • Choosing where to stop at what point
  • Displaying new map + printed directions

Viewing Pictures

Goal:

  • Search and viewing of photos

Preconditions:

  • Need either a location or subject to search for

Subtasks:

  • Searching
    • entering search terms in a text field
    • browsing by category
    • clicking on an area on the map
  • Choosing which picture/pictures to display
    • Shown 10-20 pictures at once
    • Chosen by relevance and popularity
  • Way to display the results
    • Thumbnails displayed in a scrollable pane on the page
    • Results viewed as anchors/markers on the map

Domain

Domain diagram for Trip Planner:

Trip Planner domain diagram.
Trip Planner domain diagram.

Design Sketches

Scenarios

Lil' Stevie

Little Stevie is a college student who would like to plan a road trip. Stevie currently goes to school in Los Angeles and is planning to take a spring break trip with some of his college buddies. The group is planning on traveling from Los Angeles to Boston over the course of one week. Stevie wants to use the trip planner to find directions to drive to Boston as well as figure out what points of interest him and his friends should stop by along the way.

Little Stevie has the address of his apartment as well as the address of his friend's apartment in Boston. Stevie goes to the the trip planner application and chooses the directions option. Stevie enters both addresses and sees the results on the map. Stevie likes the results since he has heard good things about the popular places that have been suggested to him, national landmarks and very popular attractions along the way. However, Stevie feels that his group of friends will have ample time to cover these sights and more, so he tries to get more results, hoping the group can visit something a little more out of the ordinary, perhaps hoping to have an intriguing story to tell some of his friends in Boston when the trip is complete. Stevie also has a general idea of what he'll be seeing because of the user-contributed photos he can see on the website. Stevie gets the results and is satisfied, and the group goes on their trip.

Once in Boston, Stevie realizes that he has amassed a collection of incredible photos of his journey. He goes back to the web to see if he can help contribute images. However, he quickly realizes that he must create an account in order to contribute photos to the application, so he clicks on the 'Create Account' link on the webpage. He enters in his information and is able to log in to the service once he is returned to the main page. Stevie quickly finds the 'Contribute' button which takes him to an interface which will allow him to upload his photographs. Once he finds his photos located on his computer, he clicks the upload button which transmits the data to the service, seeing a bar which indicates progress in the meantime. Once this is complete, he is redirected to a interface which allows him to tag the photographs. Once Stevie tags the location of a photo, he is asked for a subject of the photo. Once this is complete, the image is stored on the webpage and the image has been contributed.

After Little Stevie has uploaded and tagged all of his photos, he then logs out of the webpage.

Paul

Paul is a 42 year old small business owner in Boston, Ma. This summer, he wants to take his wife Carol (38), and his three children Megan (14), Lilly (8), and "Lil' Stevie" (4) on a road trip down to Disneyland. While searching on google for a trip planning tool, he stumbles upon Trip Planner, and decides to use it.


When Paul gets on the website, he searches for Boston. Finding it, he realizes he doesn't exactly know where in California he's headed, so he does a second search for Disneyland. Adding it to his trip, he remembers that he and his wife had some kind of anniversary coming up that summer, and wonders where he can take her to celebrate. A quick search for local attractions reveals pics of a cozy little restaurant a few blocks away, a local favorite.. . . Bingo! Just as he finishes adding it to his trip, his wife reminds him about his uncle Steve in New Mexico who they haven't seen in ages. Searching for his address, he adds him to his list of destination on the way home, then sends the trip to himself and his wife.

Despina

Scenario Despina, 60 is almost out. Twenty four years of working nightshift as a nurse in a local hospital and she is more than ready for retirement. To celebrate, she and husband Marlboro (64) decide to take a “Toure d’US” (a rather thinly disguised excuse to visit all their kids and grandkids, of course). Not really sure where to start, Despina remembers her good friend Susie tried this new website called "Trip Planner" when she took a trip to Florida last year. Despina decides to give it a try.

Despina begins by finding directions to her youngest daughter, Carol, who lives in Boston. While trying to remember the name of the city in Maryland where her middle child, John, lives, Carol remembers that Maryland is kind of close to DC, and that Carol still hasn't taken her kids to see the Capital yet. After doing some quick searches ("Lincoln Memorial", "Washington monument", "museums"), Despina decides to all them all to her trip. Calling Marlboro into the room to help her remember John's address, Marlboro is dismayed to find she's stayed true to her habit of finding ridiculously boring activities to do, and wonders why he left her in charge of planning the trip. After telling her that dinner is burning (cough, cough), he quickly takes her seat at the computer and looks what else might be more interesting in the area. . . A quick search reveals a sweet looking car museum in the area, and with pictures of classic cars fresh in his mind, he adds it to the list, hoping she won't notice. He continues browsing car pics, until Despina calls him from the kitchen that dinner is ready. Knowing that he can't possibly finish in the next few minutes, he signs up for an account and saves the trip. He and Despina will have to come back to it later.

Sketches

Design 1

First design set:

Design 2

Second design set:

Storyboards

Storyboard 1

Storyboard 2

Paul arrives at homepage. He enters "Boston, MA" and Disneyland in the "Plan a trip" section, then clicks "Find Route"

Paul can view his trip, with starting point Boston, and ending point Disneyland. He wants to add another stop in to take his wife out for their anniversary, so he clicks "Add destination".

A small panel slides out, and Paul can either enter where he would like to go, or browse on the map. Since he isn't really sure what he wants to do, he decides to browse.

Paul is given a map of the US, and he zooms into California until he can see the neighboorhood he will be in. Little red balloons indicate there are points of interest in the area. Paul clicks on one, and sees a little photo tagged "The Slanted Door".

Paul likes what he sees. He clicks "Add", which takes him to a new page. After reviewing the street address and giving the location the name "Slanted Door", he clicks "I'm finished."

Paul is taken back to his trip. The map now has three locations on it, and the "Trip Summary" and "Directions" sections are also updated to include the information about the new stop. Sometime around now, Paul's wife suggests they go see his uncle Steve in New Mexico. Paul decides to add another destination, and clicks "Add destination" again.

This time, since Paul knows exactly where he is going, he enters Steve's address in the text field and presses "Search"

Paul is taken to a map of New Mexico, with a red balloon where Steve's hhouse is. Paul clicks "Add" again.

Once again, Paul reviews the information, and gives the location a title: "Steves". In addition, he selects "Steves" in the list of locations, and uses the "Move up" button to the side of the list to push "Steves" up by "Boston" (Since he and his wife would like to visit Steves on their way to California"). He clicks "I'm finished"

Paul is taken back to his trip. The map now has four locations on it, and the trip infomation has been updated again as well. Paul is satisfied with his trip, and decides to email it to himself and his wife. He clicks the "Email Trip" button.

A panel slides out, and Paul enters both he and Carol's email addresses, types a brief description of the trip in the box, then clicks send. Paul will recieve an email with a map/description of his trip shortly.

Paper Prototyping

Risk Assessment

Homepage

  • Should be mostly straightforward
    • Not much here to get lost on
  • Only potential trouble spot could be the tabs
    • Tabs should be distinctive enough for the users to deduce that multiple options are available.
    • Descriptions on the tabs are also a potential problem. Users need to be able to quickly and easily distinguish one type of search from another.
    • Should be tested with paper prototype in all scenarios

Trip Planning View

  • Again potential difficulty in noticing tabs for stops and directions
    • Stops tab intended to show a picture of each stop on the trip
    • Directions tab intended to show turn-by-turn directions
    • Should be tested with paper prototype in trip planning scenario
  • Also potential difficulty with interface/process to add stops to the trip
    • Drag-n-drop would be ideal, but this functionality is hard to indicate to the user that it is available. An 'Add' button might work well.
    • Can the user only add suggested stops or can the user add custom points of interest (i.e. Grandma's house) as well.
    • Button functionality tested with paper prototype in trip planning scenario. Tested again in paper prototype. Drag-n-drop if feasible and works well possibly tested with computer prototype.
  • How to show which points are selected
    • Try to show in 'Stops' tab as well as by markers on the map
    • Tested with paper prototype in trip planning scenario
  • Layout/Positioning of suggested stops
    • Side or bottom? Next to the currently-selected stops?
    • Tested with paper prototype in trip planning scenario

Things to See & Do/Points of Interest

  • Main risk here is users not being able to tell the difference between the two functions.
    • Largely because of the names. Therefore, we need a better naming scheme.
    • Tested in paper prototype with things to see & do scenario.
  • Aside from that, there's not much functionality that's unique to this section.

Accounts Page

  • Timeline view is a novel idea
    • Albums are shown in the timeline. When a user clicks on the album within the timeline, the photos from that album show up in the photo pane and the tagged locations for those photos show up on the map.
    • Should be tested with the computer prototype in the uploading/tagging scenario
  • User also needs to be able to see the connection between the photos and markers placed on the map
    • Tested with the paper prototype in the uploading/tagging scenario

Uploading

  • Should be a standard interface to upload photos. Nothing too complicated or novel here
    • Tested in uploading/tagging scenario

Tagging

  • Tagging system
    • Once again Drag-n-Drop would be nice, but difficult to test with paper prototype and difficult to inform the user that it is available.
    • Risky because it seems there are many ways to go about tagging a location (subject is more straightforward).
    • What does the user need to do to assign a location to a photograph?
      • One suggestion: User clicks on photo, clicks on map to add a marker, clicks a button that says 'Tag Location'
    • Tested in paper prototype with uploading/tagging scenario as well as in the computer prototype.

Prototype Photos

User Briefing

We are designing a web page to allow you to easily create road trips, although it does have other functionality. Using a map interface as the bassis, we have 3 main ways of using this map functionality:

  • Plan a Trip
    • This is where you plan a trip going from Point A to Point B and choose stops along the way.
    • The directions will automatically update as you add stops.
  • Things to See or Do
    • This is where you can enter a location and find the things to see or do in the area
  • Find point of interest
    • The user can enter in a point of interest/attraction (like the Eiffel Tower)

Beyond this, there are 2 modes the user can work in:

  • Maps: This is where you can perform any of the above 3 options
  • My Profile: This is where you can create albums, tag your albums, and view your albums organized by map location and time


Keep in mind that we’re testing the computer system. We’re not testing you, and any problems you may encounter are not your fault but ours. The system probably has problems that make it difficult for people to use. We would like your help today to find those problems.

We will be taking notes about how well the system performs and on your interactions with parts of the system. Your test results will be completely confidential, and you are free to stop the test and leave at any time if you feel uncomfortable.

Feel free to ask us any questions during the test. Finally, do you have any questions before we begin?

Scenario Tasks

Task 1: Trip Planning Scenario:

  • Plan a trip from Disneyland to Boston
    • Add a couple stops of your choice to your road trip so you can see some interesting stuff along the way.
    • Review the map of the trip and print out the directions

Task 2: Uploading/Tagging Scenario:

  • Create an account
  • Log In with your new account information
  • Upload photos from your latest road trip from Disneyland to Boston
  • Tag the photos you have uploaded

Task 3: Sightseeing Scenario:

  • You're now in Boston after your road trip.
  • Find some interesting things to do around Boston.

Observations

Our users included three members of 6.831 during prototype testing day, as well as three random students from Baker who tested the new version of the prototype.


Task 1: Create a road trip from Disneyland to Boston, add another destination to the road trip, and view directions

In class: After entering the two destinations in the correct boxes, all the users were stuck on what to do next. This was due to: 1) our forgetting to add a “Go” or “Get directions” button to our main page, 2) the paper model not having the affordance of a normal textbox (you aren’t able to hit “enter” after writing on our fake text boxes like you can with GoogleMaps)

Once they entered the locations, a new screen was displayed with “Stops on trip”, and “Places to add”, as well as a map. While we meant for users to drag any one of the “places to add” icons into the “Stops on trip” area, none of the users picked up on this. All three expressed confusion at this point. They didn’t seem to correlate the list of places on your trip and the list of places you could go to as being in any way connected (Later one user suggested moving the list of places to add closer to the list of destinations, so they wouldn’t be so removed from each other).

In addition, all of the users questioned what the “places to add” were pictures off—since the pictures had no text indicating where the pictures were taken or what they were pictures of. The facilitator had to indicate that they were locations along the trip that you could add to the trip, and had to prompt the users on how to add them to the trip (“What do you feel you should do to add these places to your trip”). Some of the users still didn’t get it, and needed to be told explicitly to drag and drop the photos.

After getting all the stops on the trip, the users were then supposed to find the directions for the entire trip. Most were confused on how to do this, and began searching the page for clues; one user thought he was done at this point, and needed to be reminded he didn’t actually have directions yet. Most of the users had to be prompted on where the “directions” tab was, although one did find it himself. This concluded task one.

At Baker: All users entered the two locations in the correct boxes. (although one user wondered if it was okay to put something as unspecific as “Disneyland” into the location box, and another voiced anxiety that she didn’t know the address of Disneyland). In addition, one user thought she had to/tried to make an account before making the trip. Most of the users hit “go”, but one tried to hit “Maps” after entering the two locations.

Once the screen changed, most of the users still had questions regarding the “places to add”. Two still didn’t make the connection between adding something from the “Places to add” column into the “stops on trip” column. All, when they understood this, were able to easily add stops. One user wondered if you could still have the trip without having to add extra stops.

Two users also still had questions about where the photos in the “places to add” column were taken from/what they were, since the photos didn’t have any description.

After this, the users were supposed to find directions. Two of the three users had difficulty locating the tab, and had to be prompted. The third found it immediately (One user later suggested we put a “Get directions” button at the bottom of the list of destinations.) This concluded task one.

Task 2: Create an account and upload photos

In class:

All users knew to go to the “New User” box to set up an account. Once they were in their own account view, all the users were confused on what to do next. With time, some found the “add photos” tab, but one needed to be prompted to find it.

All users were able to select photos for tagging, although some questioned if there was a way to select multiple photos from the J-Filechooser-type selection box we gave them.

Once they were given the photos, all the users were confused on how to tag them (at this point, there was no window that popped up and prompted for subject/location of the photo). None of them made the connection that they could drag the photos onto the map to tag it’s location. After much prompting, the users were able to tag the location.

None of the users had difficulty with naming their album. This concluded task 2 At baker: All users knew to go to the “New Users” box to set up an account. Once the view changed to show them their profile, most of the users knew to go to “add photos”. One tried instead to click on “my photos”. When she got a blank list of photos and empty timeline, she got rather confused/upset and tried clicking on random places on the screen. With some prompting, she was able to find the “add photos tab”.

Once they found the add photos tag, all users knew had to select at least a single photo to add, although some expressed questions on how to select multiple photos, and if you could add an entire folder, and whether you could exclude a single photo from an entire folder.

After viewing uploaded photos, the users were supposed to tag them. All users understood how to tag photos, but some questioned how specific the location had to be—could you put both “Disneyland” for subject and location? What if you didn’t know the exact location of Disneyland? One also questioned who would be allowed to see the photos.

None of the users had difficulty naming their album. This concluded task 2.

Task 3: Find something to do around Boston

In class: All of the users were confused about how to go about this. They couldn’t tell the difference between the two tabs “things to see and do”, and “find a point of interest”. Two users tried to enter “Boston” into “find a point of interest.” With prompting, they eventually used the right tab.

Once they were presented with different places to stop, most were confused on whether or not the task was done. This was due to our ill-defined task (we didn’t say whether or not they had to find directions). This concluded task three.


In Baker: All users knew to click on “Search by location” (our new tab) and enter Boston.

Once they were presented with different places to stop, all made the connection they had to select the photos of the places they needed to go. Two selected the boxes by the photos and pressed add (like we intended), while one clicked on the photos themselves.

Two of the users found directions after selecting stops. One thought she was done. This concluded task three.

Prototype Iteration

Risk Resolution

Homepage

  • Only potential trouble spot could be the tabs

As expected, the tabs and particularly the descriptions were very confusing for the user. None of the users we tested on knew the difference between or the purpose of the "Find things to See or Do" and "Find Point of Interest" tabs. We clarified this by changing the descriptions to "Search by Location" and "Search by Subject", which were far more intuitive.

Trip Planning View

  • Again potential difficulty in noticing tabs for stops and directions

The Users had a difficulty noticing the 2 options but remarked that if we were to clearly make them tabs, then it would be easy to understand

  • Also potential difficulty with interface/process to add stops to the trip

We revamped this portion to have the Adding Stops to Trip portion only available when viewing the current stops on trip so that users could only add more stops in this mode (not the Directions tab). We then incorporated a "checkbox" system to allow users to select what stops to add to the trip to make it easier to understand.

  • How to show which points are selected

We solved this issue with the above solution.

  • Layout/Positioning of suggested stops

Users complained that they had no idea how to use the Suggested Stops locations. We therefore re-positioned it to the far right of the screen and added a big arrow between it and the "Stops on Trip" section so that it was very clear that these were stops that the user could add to the trip. The checkboxes also helped in this regard.

Things to See & Do/Points of Interest

  • Main risk here is users not being able to tell the difference between the two functions.

As described in the Homepage section, the users were clearly confused with this function and how it differed from the "Find Points of Interest" function. We therefore revamped both of these two tabs as described above to "Search by Subject" and "Search by Location". Therefore, you would search for Eiffel Tower in "Search by Subject" or Paris, France in "Search by Location".

Accounts Page

  • Timeline view is a novel idea

The users we tested on actually understood the timeline very easily and really liked it so we kept it as is. However, we are not making the timeline visible in the Tagging mode since it will only add to confusion and unnecessary complexity.

  • User also needs to be able to see the connection between the photos and markers placed on the map

The users did have a bit of confusion when linking the list of albums in the timeline view to the photos in selected album section to the markers on the map. While this will be made more clear in the computer prototype we have decided to only show the markers for all the photos in the selected album as opposed to a marker for each album.

Uploading

  • Should be a standard interface to upload photos. Nothing too complicated or novel here

Users agreed that this was an easy mode but reminded us of simple buttons like "Upload Now" that we forgot to add.

Tagging

  • Tagging system

The users were not very sure of how to tag photos, especially because there weren't many, or any, directions on what to do to tag a photo. As we had predicted, the Drag and Drop functionality was not clear. To address this risk, we have decided to simply make it clear that you can click any photo to tag it. Once the user clicks a photo, a sliding window appears and the user enters in a Subject tag and the Location tag. We determined it would be much easier and quicker for the user to type in a location than find it on the map. If time permits, we will incorporate this with Google Maps Search on the location so that the user can confirm the exact pinpoint location from the list of suggested locations that Google Maps returns.


Computer Prototyping

Platform

The website should be viewed with the Firefox web browser.

Startup

  • The webpage is located at:

http://web.mit.edu/akashs/Public/6831/homepage.html

Implementation

  • Unfinished
    • User accounts/Login - Assumed to be logged in under a Guest account
    • Complete backend for photos not finished
    • Ranking/Clustering/Traveling Salesman algorithms
    • Search by Subject
  • Deeply Implemented
    • Maps functionality
    • Directions/Location searching
    • Album Viewing
    • Photo Viewing


GR6 User Testing

Design

Overview

Our main interface design stems from our paper prototype. This prototype represented an integration of the best design aspects from our paper sketches. The general layout and overall design theme remain consistent from this paper prototype. We decided to keep these elements because users generally did not have issues with visibility during the paper prototype testing sessions.

The design of the site on the whole strives for minimalism and simplicity. For instance, the map which is central to the website is presented as a large canvas in the middle of the display. Additional controls and information are hidden from view with tabs. Helpful tool tips for certain tasks are consistently provided at the center of the user's focus during these tasks. The colors in our limited color template were chosen in such a manner that avoids saturating receptors and avoids potential accessibility problems for either color-blind users or older users. All text entry fields are tagged with a label to help with accessibility as well. Every page resizes well to accommodate users with differing screen sizes and differing font sizes. The Arial, Sans-Serif font was chosen to provide the best readability to the users, and a consistent style sheet was used across pages to maintain consistency with sizing as well as coloring. Additionally, both the Maps and My Albums sections of the website keep a similar layout to provide consistency to users.

In general, we tried to follow Nielsen's usability heuristics when designing the website, and we revisited these heuristics when finalizing the implementation to ensure that we had followed these heuristics as best as we could. Therefore, while many of the design decisions made and much of the work put in may not be readily apparent to most users, we tried to pay attention to small details and we feel it is actually a good thing if these decisions and tweaks go unnoticed because it means our interface does what it should without being excessive or complex.

Homepage

Homepage Design
Homepage
Tripr Homepage
Tripr Homepage
The homepage serves as an effective welcome to the website. The Tripr logo not only tells the user where they are and informs the user about the website, but it effectively communicates the principles behind the rest of the website (simplicity, minimalism, etc.) to the user without drawing attention away from the tasks that concern the user. Additionally, the 'About Tripr' link provides information to the user about the purpose of the website.
Navigation Links
Navigation Links
Navigation Links
For instance, the navigation bar is located at the top left corner of the page, keeping it consistent with other websites as well as keeping consistent with the other pages on the rest of the Tripr site. This design was chosen based on feedback during heuristic evaluations that the original icons were large, garish, and did not convey affordances well.
User Info
User Information Section
User Information Section
The information at the top right of the page tells the user about account status. It tells the user whether they are signed in or not, and gives information about the state the system is in by displaying the user's account name in this area as well. Furthermore, and actions related to the account itself, such as logging out or retrieving a lost password, are conveniently located in this area as well. Although this location and general idea remained from the original paper prototype, we finalized this simpler interface after reducing what we had planned to the basics.
Search Tabs
Tabbed Search Interface
Tabbed Search Interface
The search boxes are at the center of the user's focus for this page, hence they are conveniently centered, and are located towards the center of most user displays. This placement allows the user to quickly locate the controls to be used for the tasks without much need to visually scan the page. Additionally, the tabs separate the different types of searches available to the user, showing only one at a time to avoid crowding the screen. The subtle outline on the tab interface gives the affordance for clicking while the missing bottom border indicates to the user which tab the current controls are associated with. The subtle blue color to distinguish inactive tabs was chosen to provide visual distinction without drawing too much attention and was finalized by asking several potential users to distinguish which tabs were active and which were not. Since the affordance for clicking a tab was not very apparent during our paper prototyping sessions, we made sure to pay close attention to the choices we made here. Fortunately, the design decisions for this aspect worked out well and there were only positive comments about the tabbed interface during the peer heuristic evaluation. Additionally, based on the user testing and heuristic evaluations, 'Search by Location' and 'Search by Subject' tabs were consolidated into one because the tasks were very similar and the distinction was causing confusion.

My Albums

My Albums Design
My Albums
The 'My Albums' Page
The 'My Albums' Page
The My Albums portion of the Tripr website provides the functionality for the website that is essential to growth of the website. Here, users can view and create albums as well as add and tag photos for these albums. These photographs are then used to populate the attractions in the 'Maps' portion of the website. To remain consistent with the homepage, the set of navigation buttons appears at the top as well as the user information area and a logo at the center of the page.
Previous Iterations
Previous Iteration of the 'My Albums' Page
Previous Iteration of the 'My Albums' Page
This page was changed significantly in layout from the original paper prototypes. Originally, the design called for a set of pages, one page to view album information, one page to be able to upload photos, one page to tag photos, and also a page to view user information. For the computer prototype, these functions were consolidated into a single page to help error prevention and efficiency, all while creating a more simplistic and minimalist design.

The next iteration for the computer prototype was an improvement, but was very difficult for users to use as we had difficulty integrating these pieces. For instance, visibility of modes was a problem as users had trouble determining which album was selected. Resizing was also an issue as the spinner would move on top of the map canvas for smaller screen sizes. Error handling, speaking the user's language, consistency, help and documentation, and efficiency were also issues in addition to this and other visibility problems. Moreover, the page contained several bugs in the script that led to usability problems.

Center Stage
Map at the Center Stage
Map at the Center Stage
Therefore, the 'My Albums' section was the most heavily reworked portion of the website since the paper prototype and since the computer prototype. Although, most of the changes are subtle details that may be easily overlooked by most users, these changes should be very apparent to anyone doing a heuristic evaluation. The page follows a center-stage design pattern, placing the map canvas at the center of the user's attention. To the left of the map is a scrollable container that displays a list of the user's albums. Below the map is a spinner control that allows the user to browse through the photos in the selected album. We stuck with this decision because users and evaluators liked having the map at the focus, given the intention of the Tripr site.
Map Canvas
Map Showing a Location Preview
Map Showing a Location Preview
The maps plays several roles in this section. The map serves to display locations where pictures were taken during a trip, but does so by placing the photographs from the album on the map. The currently selected photograph is blown up to indicate the current state and this photograph matches the photograph that is currently at the focus of the spinner. The photographs displayed on the map serve as buttons, and the user is able to click one of them to make it the current selection. While tagging, the maps also serves to indicate the current location of the photograph, it allows the user to preview a location that the user is about to tag, and also allows the user to drag a marker around the map to pinpoint the precise map location. This design mostly persisted from the paper prototype with small modifications because users found the markers on the map helpful. The only major difference is that we added some redundancy in favor of visibility and efficiency with images doubling as map markers.
Spinner
In Photo Edit Mode
In Photo Edit Mode
The spinner allows for a space-efficient way to allow users to scroll through photographs while providing better visibility compared to a scrollbox, which our original design called for. A large number of photographs are at least partially visible instead of a few being entirely visible as in a scrollbox. The spinner interface is linked to the map, blowing up an image at its location on the map when it is selected with the spinner. Selecting an image in the spinner brings up its description and clicking again brings up options to edit the tag information or to delete it. The location field that shows up when editing the information is linked to the map as the maps is updated when a user types a new location and the text field is updated when the user drags the marker to a new location. Overall, our interface allows the user several ways to scroll through images: using arrow keys, clicking on the spinner with the mouse, clicking on the map with the mouse, clicking or dragging the scrollbar on the spinner, or using the scroll wheel on a mouse. Not only does this allow for convenience and efficiency, it allows us to accommodate users with disabilities who may not be able to use one or more of these methods. The decision for this redundancy was made because of trouble users had during testing sessions, and as each user had a different idea of how to scroll through photographs or to tag a location, we tried to accommodate as many of those possibilities as we could.
Album List
Albums List
Albums List
The albums scrollpane is also integral to this portion of the website. The user is able to select an album to view or edit. Compared to the paper and computer prototypes, the panel provides much better visibility while achieving better simplicity and minimalism. While we originally intended to indicate the current selection with mostly text and an outline around the album photo, we opted for a subtle blue background to give feedback that is not only simpler, but conveys the selection better as this is consistent with the way selected images and folders are displayed in other applications such as operating systems. Therefore, not only does each image indicate the content of the album with an image preview and text description for visibility, the images also act as buttons allowing the user to select a different album or enter a state where the album information can be edited. These changes were made based on feedback from users and evaluators.
Other Decisions
Album Edit Mode
Album Edit Mode
Based on user-testing and heuristic evaluation feedback, we also took several steps to improve learnability and error prevention. For instance, the date entry field that appears when editing album information is not only self validating, checking for errors, but it accepts dates entered in a variety of formats (e.g. 5-5-08, 05/05/2008) and allows the user to use a calendar date picker to choose the date from a calendar. These decisions improve efficiency, error prevention, and learnability all at once. To also help error prevention, the user is asked to confirm deletion of a photograph or an album from the web page, and the user is able to cancel an editing operation for either an album or a photograph. The user is allowed to preview a location before submission to help prevent errors and is allowed to drag an drop the location marker around the map, providing better visibility, flexibility and efficiency. Finally, all default text that is provided in text boxes blows away to make the interface more efficient.

Maps

Maps Design
Maps Page
Maps Section
Maps Section
The 'Maps' section of the Tripr site provides the functionality that is central to the purpose of the website. The navigation bar at the top of the page remains consistent with the homepage, as does the user information section that sits opposite to the navigation links. Similarly, the search area is borrowed from the homepage as well, with the same layout and interface. A logo, although much smaller in this case, appears in a similar position to that on the homepage.

However, while the tabbed search interface remains the same as on the homepage, it's position has shifted to the top of the page. This decision was made to allow the focus of the page to be the maps and the stops on the trip which are more central to planning the trip. Therefore, the map canvas takes up a significant portion of the screen and the stops and directions are contained within a scrollable panel next to it. This center-stage approach allows the users to focus on pertinent information. This design decision remains the same from the paper prototype because of positive comments from users.

Original Concept
Original Design Concept
Original Design Concept
The original concept of the maps page had a list of suggested stops that the user could then drag onto the map canvas to add them to the trip. This design decision led to problems during the paper prototype testing because users were not readily aware that they were allowed to drag and drop these images as it is very difficult to convey the affordance for drag-n-drop.
Final Design
Stops Added to Trip
Stops Added to Trip
However, the final implementation of the page has perhaps an even better solution as the images representing the suggested stops are placed on the map canvas itself. This is an improvement because it provides a lot of visual redundancy as the images not only give a picture to the user of what the place looks like, but the images are placed in the geographical location on the map, indicating their position. In addition, the images also play another role as a clickable button. These changes resulted by evaluating user feedback and the heuristic evaluations.
Location Preview
Location Preview
Location Preview
Clicking on the image gives a blown-up view of the attraction, allowing the user to see more detail. Under this blow-up is a button that allows the user to add the stop to the current trip. This feature needed to be added when the list of suggested stops was removed in favor of placing the images directly on the map.
Suggested Images
Additional Images and Loading Indicator
Additional Images and Loading Indicator
The images chosen to be displayed on the map are based on the bounds of the trip. The rationale behind this was that we wanted to avoid suggesting a stop that was far out of the way of the user's path. Initially, only a few stops are displayed, but upon zooming into an area of the map, the user is presented with additional suggestions, based on the scope of the search. Additionally, once a custom stop which is out of the way is added to the trip, the scope of the images displayed on the map changes due to a change in the bounds of the trip, so additional photographs, which were outside of the bounds of the original search, are also shown in this scenario. Additionally, based on feedback during heuristic evaluations, we added a spinning 'Loading' image to give the user feedback when waiting for the map to update.
Custom Stops
Custom Stops
Custom Stops
The user is able to add customized stops with the 'Add by Location' tab in the search interface. Using this feature allows the user to search for known places that may be out of the way of the current trip path. This feature was added based on formative evaluation during the paper prototype testing sessions where one user wanted to add 'Grandma's House' to the trip.
Stops on Trip
Stops on Trip
Stops on Trip
The sidebar area that contains the 'Stops on Trip' and 'Directions' tabs also contains a lot of useful information for the user. Originally, the 'Stops on Trip' tab was implemented as a SELECT element along a group of buttons which the user would use to reorder the stops along the way. Based on feedback from users and during heuristic evaluation this design was thrown out in favor of a design that automatically reorders the stops on the trip, improving efficiency and ease of use. This also allowed us to make the look and feel of the 'Stops on Trip' tab highly consistent with that of the 'Directions' tab. Therefore, the 'Stops on Trip' tab currently shows the order in which stops are on the trip, as well as their names. Moreover, the icons located next to the descriptions of these stops correspond to the placemarker icons on the map, giving the user a visual cue of where this stop is located on the map.
Directions
Directions
Directions
The 'Directions' tab uses the same icons and descriptions, but adds detailed turn-by-turn directions for the trip for the user to use when embarking on their journey. Additionally, the stops and directions tab maintain a consistent style, thereby indicating that the stops tab is essentially a summary of the details that are contained in the directions tab. The directions tab remains unchanged from the paper prototype.
Search By Location
Search By Location
Search By Location
Also contained in the 'Maps' portion of the website is the 'Search by Location' feature. This page has a similar layout to the 'Search by Directions' section, but omits the sidebar showing stops and directions and instead uses the extra space to display the map. Once again designed as a center-stage model, this section allows the user to search for attractions that are located near a specified location. It's functionality is similar to that of the 'Add by Location' tab in the 'Search by Directions' section, without the ability for a user to add the stop to a trip. Once again, this design and layout remains consistent with the rest of the website. The changes made to this section throughout the design process are parallel those changes made to the map canvas behavior from the directions view.

Implementation

Our project has two major sections: Map View and Album View, which we used HTML and JavaScript to code.

Map View:

The Map portion of our website uses the Google Maps API to draw a map, get directions, add anchor points, etc. We achieve this by sending requests to Google, who sends a response back that we use in order to update the Map. Our map has the functionality a user would expect to have on a map as we have borrowed the functionality from Google, which does an amazing job at this. The first major event is to send a request, asking for directions from a start point to a destination. In our example, we get directions from San Fransisco to Boston. We send this request to Google, which responds with directions that we post in the Directions tab of our Maps page while also drawing the route on the map. Due to the time delay, we have a loading symbol so that the user knows we are processing the request. As the route pops up however, we also populate the map with "Featured Stops". These stops are attractions that are within the bounding box of the route so that the user would not have to go too far out of the way to view them. More on the selection of featured stops will be discussed in the next paragraph. Regardless, the user can select a stop by clicking on it, which blows up an HTML-encoded window showing a blow-up of the picture. If the user adds a stop, we find the shortest path to add this stop. We can guarantee the shortest path for the first 8 stops a user adds but after this point, we have to use a greedy algorithm to make the heuristically best choice (which works in the vast majority of cases). This is due to a limitation on pinging Google with requests and time it takes to process them. Stops can also be removed with our route updating in a similar way. Lastly, there is a "Search by Location" option which we offer, where the user can type an address, which we query Google with. Using the response, we draw a marker at the exact location and adjust the zoom accordingly. Any nearby featured stops will also show. For example, if you type Washington DC, our maps will pinpoint the center of Washington and show all the landmarks around. However, only the White House is featured so as to not crowd the screen with points around the same location.

Linking Both Views:

While our desire was to only select the 10 most prominent stops on a path, we needed to communicate between our Maps mode and Album mode through a server-side database using PHP. We were unable to do this as we originally thought everythign was possible using XML files. However, it was not until closer to the end that we realized that Javascript is primarily client-side and what we needed was a server-side language. We still use XML and therefore cannot use the pictures a user loads as featured stops (each stop would also have a popularity rating so that the more users that post a particular attraction, the more heavily weighted the stop would be in showing up as a Featured Stop).

Album View:

In the Album view, the main purpose is for a user to visualize where his or her pictures were taken. We therefore also use a Google Map but simply ping the map for GPS locations and post markers there, where we have edited the markers to be thumbnail icons as we did in the Maps view. To offer the user another type of way of visualizing their pictures, we integrated the opensource code for ImageFlow 0.9 in order to give a very Mac OS feel to navigating through the pictures in an album. Because of our inability to update and save an XML file once the user updates their albums and pictures in it, we have just baked in different albums with pictures right now to demonstrate. The user is still able to have full functionality by adding an album, deleting an album, adding/removing/tagging pictures, etc. but is simply unable to come back and see these changes as we have not implemented the database to save them.

Evaluation

User selection:

Two of the testers were picked at random from the center. One was a male course six student, the other a female, course two. Both were licensed drivers (although neither had their car on campus).

The third user was a GRT from one of the dorms. He is married, a licensed driver, and has a car on campus.

Our users are fairly representative of our target population, which included two main groups: Young adults (16-30) and families. All were educated/literate, English speaking, and regular computer users. We noted that our users may have a slightly more technical background than the average user. However, we do not believe this greatly affected the results of our tests since our website does not require special technical knowledge above normal computer use/internet browsing.

The tests:

For the two student users, we selected a conference room on the fifth floor of the student center to do the testing. It was moderately quiet and offered a little privacy to reduce user anxiety. For the GRT, the test was performed in one of the lobby areas of the dorm.

All three users were briefed with a short, scripted description of the website (which included its overall purpose, as well as some of its features). The users were then handed three index cards (sequentially, as they finished each task) with the following tasks to complete:


Task 1:
Log in to account
Create a road trip from San Francisco, Ca to Boston, MA


Task 2:
Add two “Suggested Stops” to the trip
Add one custom stop to the trip
Remove one stop from the trip
View updated directions


Task 3:
Add a photo to an album
Tag a photo
Delete a photo from an album
Delete an album


When we were done, the user was asked about his/her general impression of the interface, as well as any comments they might have. The other two team members observed and took notes of the transaction.

Usability problems:

Clicked on the map when attempting to add a custom stop
Severity:
Minor
After reading the task cards, two users initially tried clicking the map to add a custom stop instead of using the “Search by Location” tab. However, after a few seconds, they found the tool tip which lead them to the appropriate place, without any prompting.
Possible Solution: Since google maps doesn’t yet allow for a stop simply by clicking on the map, our best approach might be to make the tool tip more prominent .


Took a while to figure out how to add a picture
Severity:
Minor
One of users didn’t make the connection that you had to edit an album in order to add pictures to it, and spent a few (< 30) seconds searching the page for a way to add photos before choosing to edit the album.
Possible Solution: The current tool tip for editing an album (which the user read a few times) reads “Click an album to view or edit its contents.” We could change the message to read “Click an album to view its contents, edit its information, or add a photo” to make it more explicit (although it would be wordier).


Excessive white space
Severity:
Cosmetic
As a general comment, one of the users thought the albums page had too much white space, and suggested putting borders to separate the different sections.
Possible Solution: This is actually a design choice we had made earlier. Using boxes would help group the different sections—however we think the interface looks cleaner and less crowded using white space to group elements by proximity.


Tried to click picture to remove stop
Severity:
Minor
After the test, one of the users commented that it would be nice to have another way to remove “Suggested Stops” from the trip, right next to the place you added them.
Possible Solution: We think our current method for removing stops is effective because all users knew how to remove them. We also like it because it is externally consistent with Google’s method of removing stops on a trip. However, it would be relatively easy to add a little redundancy and internal consistency by putting a little “Remove stop” button right next to the “Add stop” button in the window that pops up when you click a stop.


When you add a custom location, you need to add it after previewing it
Severity:
Minor
One of the uses didn’t realize that after you preview a custom location, you still need to add it to the trip.
Possible Solution: This could be easily fixed by changing the button name from “Add stop” to “Preview location”, implying that further action is needed to add the stop. Additionally, it would be very easy to add a tool tip right next to the preview button which says you need to click on the marker to add the stop (As a side note, the two other users got this point without help).

Conclusion:

User testing was much more successful and positive than the paper prototype testing. Most notable was the lack of confusion that the users sometimes experienced with the paper prototype. In addition, while there were a couple things that took users a few seconds to figure out (such as adding photos or a custom location), no one was ever stuck to a point where they couldn’t move on, which is a huge improvement. In fact, the users found most of the tasks very straight forward and needed very little prompting.

While not as informative as the paper prototype, this final round of user testing was still very useful and gave us ideas for some tweaks we can make. While time is obviously an issue, we will try to incorporate some of the feedback into our demo this Wednesday.


Notes taken during final evaluation:

final_notes

Reflection

Lessons Learned:

I think the biggest lesson we learned was setting realizable goals for ourselves. With a tremendous amount of time, we were able to complete the project from a UI point of view but were unable to implement the backend fully with a database to store user albums/pics in an affordable way while also using this pictures in the Maps View. We are continuing to work on this, but decided to prioritize the other parts of our project.

In addition, we realized just how helpful and necessary user testing is. There were several features that we were really excited about that we thought were 'obvious'-- but then user testing revealed that people didn't realize the features existed! Both rounds of user testing were very informative, and we incorporated many of the suggestions/things we learned into our final design. In all, we gained an appreciation for design as a continuous process that requires constant evaluation and change.

Risk Assesments:

Our risk assessments were critical as the project progressed. It allowed us to anticipate the flaws we would have and come up with bakc up plans. Below are how we responded to each of our risks:

Homepage- As predicted, our tabs were problematic and confusing. We therefore took the confusing tab out and were left with 2 tabs from 3.

Trip Planning View- We did our best to bring focus to the two tabs on the left (Stops and Directions), which we did very successfully judging from our users tests. Users noticed these tabs and understood them. As for adding stops, we realized early that Drag N' Drop would be difficult and therefore decided to do the second option by clicking the icon and having a button to add the stop, which users also accepted very well. Lastly, we ultimately did away with the list of featured stops and simply populated them on the map, addressing the risk of the user not being aware of them.

Things to See & Do/Points of Interest- As pointed out, it could be difficult for users to distinguish these. We therefore did away with it and simplified it.

Tagging- I think we found a good medium of how to tag the photos and connect a picture to the map.

Testing/Prototype Decisions:

The map view was the most complicated aspect of our design and we therefore rightfully chose it to be the part to be designed and tested first. As stated above however, because of how linked the two parts were, we were unable to move ahead on linking the two in time. Regardless, it was good that we first moved ahead with the map view but also had enough of the album view in order for users to give us constructive criticism on that as well.

Evaluating Criticism:

We took user and TA feedback very seriously. First we compiled a list of all the feedback we received, then reviewed each issue individually. For the comments that contradicted each other, we sat down and looked at the pros and cons of each decision before deciding what was the best option. In the cases where we were able to talk to the user, we explained our reasoning and saw if our design decisions were acceptable.

Final Thoughts:

Upon reflecting on the overall process, we think we did a very good job in our iterative design, prototype/user testing, etc. but the one thing we would have changed is outlining the parts of the backend that would need to be implemented and how long they would take, not just the front-end which is what we did. We attended to all our criticism and fixed all the issues people had with our website throughout the process. We all enjoyed the challenge this project gave us and the tremendous amount of UI and other programming experience we gained. In the end, we appreciated the focus on user design/testing and the iterative design process. Listening to the feedback, it looks like we successfully served the need we set out to in the beginning and developed the best UI for it.

Personal tools