Design 
Figure 1: Final design of our project combines map view of open venue with venue listing per day of trip
Process
Previous iterations cross referenced these separate views. However when we implemented an older design, we found the screen space limiting. 
Figure 2: GR4 design included a graph and a grid of buttons.
...
Figure 5: GR5 design: clicking on book immediately pops up calendar showing the scheduled event. We divided the calendar view into fifteen-minute slots motivated by our interviews with musicians.
Implementation
Route and Venues along the route
- Our application used the Google Maps API to get routes. It used the intermediate cities entered by the user as Waypoints to request from the Google direction renderer.
- The number of intermediate cities had to be limited to three to reduce calculations. The calculations ensure right behavior when removing the first city and adding a new one. i.e. The new one would be placed at the end and not as the first. It also ensures that the cities are fed to the waypoints in a route in the right order.
- The application used the Google Places API search to get venues within a 500 radius around the origin and destination. The initial design was meant to use this search service to get venues along the path, using the (longitude, latitude) of points along the path. However, Google restricts users from iterative calls to a service and the data along the path had to be hardcoded. That problem took a long time to figure out, it should of have been specified in the Google API documentation.
Venues: map and list
- The system used random algorithms to choose venues open in a certain day, and similarly to choose the time openings of those venues ensuring no collision in time openings, yet allowing venues to be open on more than one day. This information was saved in a list that resets every time the application is restarted.
- The application used Google markers to indicate venues that are open along the path at a given day. It used different colored markers to indicate venues: that are open, that have been booked in another day, and venues that are currently selected.
- The behavior between the list and the map: the application stored a list of venue names per day, and the longitude and latitude of a respective venue. This information was used to calibrate the venues on the list and the venues on the map. i.e. selecting a venue on the map would make the list scroll to it, highlight it and show its available bookings. Vice versa, selecting it on the list would make the marker on that venue change color to green and an information window would appear on the map, to give the user feedback of the venu’s location on the map.
Standard Behavior
The application was made consistent with other applications by having any selected element be deselected if the user clicked on another element. i.e. if the user clicked anywhere on the map and a marker was selected, it would be unselected and all expected behavior would propagate to be reflected on the list. Additionally, when the user is in the “view schedule” mode and he clicks outside the schedule, the schedule automatically closes.
Booking
After the user enters the travel information, we generated random number of booking objects for each venue, on each day of that trip. These bookings are all assumed to be open and are associated with the venue object and its marker on the map. These bookings are then displayed in the html table for each venue on that day. Upon clicking on a venue, the marker on the map is then highlighted, and the available slots to book are displayed. Vice versa, when a marker is clicked the associated venue in the table is also highlighted, and the available times are displayed.When a user selects the booking, the opening slot is immediately designated as ‘booked’, and the schedule pops up showing the booking. In addition the marker is highlighted in a darker color to designate that the venue is booked.
Scheduling
Scheduling was done by just drawing formatted html table as a calendar. When a venue is booked, the cells associated with that time in the table are just highlighted and formatted to reflect that booking. The schedule pops up immediately as feedback for booking.
Implementation problems affecting usability:
The inability to detect and warn of conflicts in scheduling really affected the security of using application.
Additionally, in order to allow for multiple window sizes and because we used blanket, we were unable to create schedule rectangles of set width/height/location. This meant that schedule rectangles representing a booked-gig could not be interactive as we had originally planned. Instead we filled in corresponding cells in the schedule table and made the schedule purely a view (the user could not unbook slots from the schedule-popup).
Evaluation
“Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.”
Testers were mostly friends willing to test our UI. One user was a musician we had interviewed in GR1 and was happy to look at our final design. Tests were conducted by just briefing the user verbally with a quick description of the UI, and what it can accomplish. Next they were given three tasks to accomplish: 1) Find the venues along a tour they are planning. 2) Book at least one of the venues. 3) Check their schedule. Then the user was given the freedom to explore the UI while the observer took notes, and the facilitator just guided the user at some points if they had questions or were stuck.
Tester 1
User was a pianist friend. She does not perform very often but was quick to impersonate the role of an independent musician on tour.
...
Solve this by giving the user a tooltip or hint about what it means. Also showing a clear change in path style when this parameter is changed.
Tester 2:
MIT course 6 friend in concert choir. Not exactly a touring artist but a performer and familiar with concerts.
...
Cross-application Calendar. Be able to download scheduled events into Google Calendar. Heuristic: Efficiency. Severity: major.
Solve this by implementing google calendar in the application. That way it’s easier for the user.
Wiki Markup
Solve this by+ making the map visible at an earlier stage of entering inputs. As in when the origin and destination are entered, the map appears showing the intermediate cities.
Ordered list. list orders venues from origin to destination \ [Good: intuitive\]
Tester 3
Swiss saxophonist who we interviewed for GR1 and inspired much of the UI design. We got in touch and he was interested in seeing our work. He tours frequently.
...
Unclear as to how to initiate booking process:
User guessed that clicking venue names would display more info about the venue, not necessarily initiate the booking-process for that venue.
Solve by+: Labeling Venue-name column with “Book a Venue,” or automatically reveal available times for the first venue in the list (display buttons for different available times as if the first item had already been clicked to entice the user to either book those times or click other items in the list to display more information).
Tester 4
MIT friend with a music minor. Performed with gamelan group at MIT but otherwise does not tour.
...
Day on top of the map unclear. The user wasn’t able to tell that it’s a day by day map until a while after she started. Heuristic: Learnability. Severity: minor.
Solve this by making the dates and days bigger and clearer. The user eventually figured it out. It is only a matter of first time using.
Reflection
While we did each step of the spiral design process and tested with users along the way as described in lecture, I think we failed to think deeply enough about the implementation along the way. Had we thought more about the details of our implementation ahead of time, we would have perhaps updated to our final view earlier on in the process and would have been able to iterate on the exact details of it further. Other aspects of our design did benefit from this process (such as the left-hand column view in which additional intermediate cities are added).
...