...

Figure 8. TravelGroups of people traveling near you during a similar date range. Deprecated.

2 Implementation

2.1 High Level Discussion

We decided to implement a web application based on using HTML, JavaScript, CSS, JQuery, with a PHP/MySQL backend and MySQL for storage.

2.1 High Level Discussion

2.2 Potential Problems

Several aspects of the interface design proved to be much more difficult than anticipated, and some of these struggles may have negatively affected the overall usability.

• Calendar: Our original intent was to use one single calendar for the sake of simplicity; however, this created the issue of determining whether a certain date was supposed to be the start date rather than the end date in addition to figuring out how to interpret a date change. As aforementioned, we settled on displaying two separate calendars rather than one – this resulted in greater ease of implementation but reduced simplicity. Additionally, we ran into some difficulties when highlighting/selecting the current date as the initial selection and this behavior could also cause problems for the user.
• Map: The map updates dynamically when the user selects either a start or end date in order to display the users traveling in the given date range; however, if the user has not entered a desired destination then all markers will disappear from the map, potentially causing confusion for the user.
• Graph: Like the map, the graph updates immediately when the user inputs a start and end date. However, the graph is only displayed when the user changes both the start and end date from its original (current date) selection. If the user is planning a one-day trip on the current date, he/she may not ever see the graph.
• Layout: We faced many difficulties when making design decisions regarding the layout of the application. On the home page, we decided to place the graph immediately below the input and map boxes; if the user is working on a relatively small screen, this requires him/her to scroll down in order to view the full graph. This could potentially cause decreased efficiency.

3 Evaluation

3.1 User Test Setup

Users were asked to sit down in front one of our laptops displaying our briefing page, located here. They were then told that they would be given three tasks and observed as they navigate through each of the three tasks. During each task, users were asked questions (included in 3.3 User Briefing and Tasks) to make sure that they were progressing through the tasks. If users became stuck, they were prompted. We made sure users knew that some of our data was dummy data. At the end, users were asked to say one thing they liked, and one thing they disliked or found confusing.

3.2 User Backgrounds

We found users by emailing out to our respective dorms. Those who responded participated in our user test. Because we did not get a response from an MIT faculty/staff member, we approached one in person and was able to elicit the person's participation. From our user tests, we identified three representative users:

1. An undergraduate student
2. A graduate student
3. An MIT staff member

Users were of the age range 18 to 50 and were of both genders. Our initial target population were students, faculty, and staff. In retrospect, anyone computer-literate can use TravelTech if he/she wants to plan a trip. We specifically identified students and faculty/staff because they would be traveling more often and be more likely to look for other people with similar travel plans.

3.3 User Briefing and Tasks

Users were briefed with a simple description of TravelTech's goals, located here. We felt that a demo was unnecessary because TravelTech is easily learnable and provides enough cues to the user. Then users were given the same tasks they received during paper prototyping. They were given the following tasks:

1. Input a trip and save it
2. View all trips and find a list of contacts
3. Edit then delete a trip

Task 1: Input and Save a Trip

A user was read the following in stages: "You are planning a trip to Newton, Massachusetts from May 17, 2012 to June 12, 2012. Please enter this information. How many people will be within 200 km of you during the date range you just specified? What are their names? How many people are within 360 kilometers? Who is/are the new person/people given this new specification? If you changed your trip's end date to June 13, 2012, how many more people will be near you? Change your trip's start date to July 13, 2012 and end date to August 11, 2012. How many people are within 360 km of you? Finally, change your location to Indianapolis, Indiana, but keep the dates July 13 and August 12. Who is the only person within 200 km of you? Add your new trip."

...

we use MIT's scripts server for hosting.  User authentication is implemented with MIT certificates, which are also utilized to pull user information (name and email address) from.  This may be confusing that users aren't required specifically to log in, but we expect that most users with certificates understand their purpose.  There are two sql tables: one for user information and one for all of the trips.  The site collects any information that the user is inputting and when the user does an action that requires table lookup/modification, the site passes the information via URL to the other page (home -> my_trips, my_trips -> home), which executes the relevant query.  The main usability problem with this implementation is that any action that requires a table lookup/modification requires a page reload, which as it stands resets any of the user's current partial input.  Most of our fields and buttons are controlled via javascript, and we utilize the Google Maps API for our maps.  We chose Google Maps for both its ease of use in implementation but also in hope that the users will be familiar with the interface and controls.

Our graph that shows nearby travelers on a day range greater than yours is only visible once the user has inputted a location and selected a start and end date.  While this was implemented this way because otherwise the information could be misleading, the fact that the graph is at times not showing and then being displayed may cause potential usability problems.  We also decided to implement the graph with dummy data to show off its functionality, as there would need to be a large amount of data entered into the system for the graph's output to be relevant.

2.2 Potential Problems

Several aspects of the interface design proved to be much more difficult than anticipated, and some of these struggles may have negatively affected the overall usability.

• Calendar: Our original intent was to use one single calendar for the sake of simplicity; however, this created the issue of determining whether a certain date was supposed to be the start date rather than the end date in addition to figuring out how to interpret a date change. As aforementioned, we settled on displaying two separate calendars rather than one – this resulted in greater ease of implementation but reduced simplicity. Additionally, we ran into some difficulties when highlighting/selecting the current date as the initial selection and this behavior could also cause problems for the user.
• Map: The map updates dynamically when the user selects either a start or end date in order to display the users traveling in the given date range; however, if the user has not entered a desired destination then all markers will disappear from the map, potentially causing confusion for the user.
• Graph: Like the map, the graph updates immediately when the user inputs a start and end date. However, the graph is only displayed when the user changes both the start and end date from its original (current date) selection. If the user is planning a one-day trip on the current date, he/she may not ever see the graph.
• Layout: We faced many difficulties when making design decisions regarding the layout of the application. On the home page, we decided to place the graph immediately below the input and map boxes; if the user is working on a relatively small screen, this requires him/her to scroll down in order to view the full graph. This could potentially cause decreased efficiency.

3 Evaluation

3.1 User Test Setup

Users were asked to sit down in front one of our laptops displaying our briefing page, located here. They were then told that they would be given three tasks and observed as they navigate through each of the three tasks. During each task, users were asked questions (included in 3.3 User Briefing and Tasks) to make sure that they were progressing through the tasks. If users became stuck, they were prompted. We made sure users knew that some of our data was dummy data. At the end, users were asked to say one thing they liked, and one thing they disliked or found confusing.

3.2 User Backgrounds

We found users by emailing out to our respective dorms. Those who responded participated in our user test. Because we did not get a response from an MIT faculty/staff member, we approached one in person and was able to elicit the person's participation. From our user tests, we identified three representative users:

1. An undergraduate student
2. A graduate student
3. An MIT staff member

Users were of the age range 18 to 50 and were of both genders. Our initial target population were students, faculty, and staff. In retrospect, anyone computer-literate can use TravelTech if he/she wants to plan a trip. We specifically identified students and faculty/staff because they would be traveling more often and be more likely to look for other people with similar travel plans.

3.3 User Briefing and Tasks

Users were briefed with a simple description of TravelTech's goals, located here. We felt that a demo was unnecessary because TravelTech is easily learnable and provides enough cues to the user. Then users were given the same tasks they received during paper prototyping. They were given the following tasks:

1. Input a trip and save it
2. View all trips and find a list of contacts
3. Edit then delete a trip

Task 1: Input and Save a Trip

A user was read the following in stages: "Please tell me all the trips that you currently have. Click on the trip you just made and tell me how many people are near you. Get me this person's email."

Task 3: Edit and Delete a Trip

A user was read the following in stages: "You are no longer traveling to Indianapolis, Indiana. Instead, you want to go back to Newton, MA. Make this change in your trip. You decide you don't have enough money to make a trip at all. Delete it."

3.4 Usability Problems and Proposed Solutions

Task 1: Input and Save a Trip

You are planning a trip to Newton, Massachusetts from May 17, 2012 to June 12, 2012. Please enter this information. How many people will be within 200 km of you during the date range you just specified? What are their names? How many people are within 360 kilometers? Who is/are the new person/people given this new specification? If you changed your trip's end date to June 13, 2012, how many more people will be near you? Change your trip's start date to July 13, 2012 and end date to August 11, 2012. How many people are within 360 km of you? Finally, change your location to Indianapolis, Indiana, but keep the dates July 13 and August 12. Who is the only person within 200 km of you? Add your new trip."

Task 2: View Trips and Generate Contacts List

A user was read the following in stages: "Please tell me all the trips that you currently have. Click on the trip you just made and tell me how many people are near you. Get me this person's email."

Task 3: Edit and Delete a Trip

A user was read the following in stages: "You are no longer traveling to Indianapolis, Indiana. Instead, you want to go back to Newton, MA. Make this change in your trip. You decide you don't have enough money to make a trip at all. Delete it."

3.4 Usability Problems and Proposed Solutions

Task 1: Input and Save a Trip

1. The MIT staff member:
   1. Save trip button (minor): She hit the save trip button on the first page immediate after inputting a destination and start date. She proceeded to finish the rest of the task on the my trips page rather than the home page. Thus, she never saw the information displayed in the chart and did not use the first page at all. The placement of the save trip button could have been misleading; instead, moving it to the bottom of the page may alleviate confusion so that the user stays on the first page longer.
   2. Markers on map (minor): Since the user never used the home page and almost exclusively relied on the my trips page, she did not realize that the markers were clickable and depended completely on the contacts list for getting a user's name and email. Had she been asked for the user's traveling date range, she would not have been able to tell from the contact information. The fact that the markers were clickable is an extension of Google maps and had the user stayed on the home page, she would have had to click on the markers to find information about other travelers. Fixing the location of the save trips button should
   The MIT staff member:
   1. Save trip button (minor): She hit the save trip button on the first page immediate after inputting a destination and start date. She proceeded to finish the rest of the task on the my trips page rather than the home page. Thus, she never saw the information displayed in the chart and did not use the first page at all. The placement of the save trip button could have been misleading; instead, moving it to the bottom of the page may alleviate confusion so that the user stays on the first page longer.
   2. Markers on map (minor): Since the user never used the home page and almost exclusively relied on the my trips page, she did not realize that the markers were clickable and depended completely on the contacts list for getting a user's name and email. Had she been asked for the user's traveling date range, she would not have been able to tell from the contact information. The fact that the markers were clickable is an extension of Google maps and had the user stayed on the home page, she would have had to click on the markers to find information about other travelers. Fixing the location of the save trips button should fix this too.
2. Undergraduate student:
   1. Autocomplete / search (major): This user had trouble searching for a specific location because he chose to click on the appropriate entry in the autocomplete drop-down menu and then refrained from clicking the "search" button. This issue could easily be avoided by changing the functionality of the autocomplete.
   2. Map radius and zoom (minor): He commented that he did not like how the radius was reset to 200km each time the search button was pressed. He also would have liked that the map zoom in/out as the radius is changed. Both of these issues could be solved by changing the default behavior of the search button and radius slider.
3. Graduate student
   1.  Markers (minor): John didn't know that the markers on the home page were clickable and therefore had trouble acquiring the proper information for the first task using the home page.  He also didn't know the markers were clickable on the my trips page.  A possible solution to this is to have a marker already selected when the user loads the page.
   2. Calendar (major): John had a few issues with the calendar on the home page.  After a location is entered and the user hasn't changed any of the dates, the graph isn't generated.  Only when the user has selected a new start and end date is the graph generated.  Also the calendar allows you to set an end date before the start date if the user hasn't changed the initial start date.  A possible fix for this is to treat the initial selected dates as if the user had input them.
   3. Circle radius/zoom (minor): John didn't like the default radius of 200km as he thought it was unreasonable and also didn't like that it was always reset to 200km.  He thought that zoom of the map should scale with the radius of the circle.  This could be fixed by fixing the zoom of the map with the radius of the circle.

...

• UI design requires both detail-oriented and big-picture vision: Over the course of the semester, each of us came to learn that the UI design process is a delicate one. Every detail matters, but it is also important to establish a goal and direction early on in the design process – and also make sure to remain goal-oriented throughout.
• Usability testing is an involved process: Standardization is important and necessary in order to obtain valid and accurate responses from potential users. A key skill is knowing how to interact (and remain silent) with users during the testing process; there is a fine line between too little and too much when explaining the interface to the user. Additionally, it is important to test a variety of users, as some may be more experienced or knowledgable about a certain topic than others.
• Less is more: Throughout this process, we came to understand the importance of simplicity and minimalistic design. When an interface is crowded with several features, each of them loses significance – we decided to focus on a few important aspects that eventually created what we believe to be a successful product.

4.2 What Would We Do Differently? (Meta-Level)

• – and also make sure to remain goal-oriented throughout.
• User/usability testing is an involved process: Standardization is important and necessary in order to obtain valid and accurate responses from potential users. A key skill is knowing how to interact (and remain silent) with users during the testing process; there is a fine line between too little and too much when explaining the interface to the user. Additionally, it is important to test a variety of users, as some may be more experienced or knowledgable about a certain topic than others.
• Less is more: Throughout this process, we came to understand the importance of simplicity and minimalistic design. When an interface is crowded with several features, each of them loses significance – we decided to focus on a few important aspects that eventually created what we believe to be a successful product.
• Heuristic evaluation is a powerful tool: Having individuals who know the elements of user interface design analyze and provide feedback is an extremely powerful method on improving a user interface.
• The user is always right and it's hard to think like a user: It is hard to distance oneself from the role of the developer and forget the things you know and the attachment you have to what one has created.  It is important to get objective opinions about a user interface, and usually the ones who designed the interface will be some of the last to determine certain problems.
• Not everyone interprets things the same way: Sometimes we would get feedback or would observe the same user action during testing but when we came together, we each thought we had seen something different or that the cause of the behavior were different factors.  It is always important to have someone recording the results and user actions as they happen and also to ask the user questions questions about their behavior/choices when using the user interface.

4.2 What Would We Do Differently? (Meta-Level)

• More users for each of our tests: Though the amount of usability testing that we conducted was sufficient enough to provide us with valuable feedback, we feel that testing both the paper prototype and initial design on a wider variety of users would have given us more insight into our target user population.  Additional paper prototypes would have saved us a great deal of time and provided more user feedback during additional iterations.
• More rounds of testing: We also believe that we should have done more iterations of testing after coming up with new designs after GR4.  We were too focused on creating a final product that was what we wanted instead of ensuring that from the beginning that we were focused on something that that our user population would want and could use.
• More stretch: We think we should have zeroed in on the fundamentals of our user interface earlier so that we could have spent more time adding stretch.  Stretch was the challenging part of the UI that allowed us face difficult decisions and utilize user feedback.
• More detailed computer prototype: While we had a computer prototype that enabled testers to get some sense of our user interface/project, we would have had a much easier time creating a more cohesive and better UI for our final implementation if our computer prototype had been further implemented before being heuristically evaluated.
• Focus the idea: We spent too much time initially trying to make a site that did too many things (and much of them were repeat functionality of already existing web applications).  We should have more immediately focused on the elements of an idea that proposes unique and challenging UI problems
• More testing: Though the amount of usability testing that we conducted was sufficient enough to provide us with valuable feedback, we feel that testing both the paper prototype and initial design on a wider variety of users would have given us more insight into our target user population.  Additional paper prototypes would have saved us a great deal of time and provided more user feedback during additional iterations.
• We also believe that we should have done more iterations of testing after coming up with new designs after GR4.  We were too focused on creating a final product that was what we wanted instead of ensuring that from the beginning that we were focused on something that that our user population would want and could use.