Prototype photos:
Figure 1: Iteration 1: Relative node view, clicked venue is highlighted on the list.
Figure 2: Iteration 1: Available times for scheduling venue A on Day1. With alphabetized list.
Figure 3: iteration 1: entering information
Briefing:
You are a Jazz band from California. You are flying to Boston on March 21st, to start a tour from Boston to New York City on the 22nd. The tour is five days long and you want to use VenView to help you find venues to book along the way between your concerts on the 22st (in Boston) and on the 27th (New York). You’ve heard that New Haven has an emerging underground jazz scene and so you decide that you definitely want to pass through.
Scenario Tasks:
Task 1: See all smaller Jazz venues on your path (max capacity < 300).
Task 2: Add New Haven as a city you’d like to visit.
Task 2: Book venues for at least 3 days of your tour.
Task 3: Process your final itinerary(?)
Get the trip itinerary after entering all your selections.
| Wiki Markup |
|---|
*Observations: (1st round)*
1\- Change relative view to map view: since distance is important in the user’s decision making process then there is no reason to remove that reference (we don’t wish to distort it).
2\- Add dotted line to show path so far (in addition to the original path, drawn incrementally as the user “books” venue).
3\- List venues based on distance from start point (radially outward).
4\- Will we allow multiple bookings in the same day? \[gray out only conflicting times, not the entire day\]
5\- Different views on spectrum of colors to hint at better booking candidates (some favored more binary system, others thought a range would be useful)
6\- Most users skipped the year field or didn’t take the time to fill it out. Perhaps it can be preset or fixed? |
| Wiki Markup |
|---|
*Observations: (2nd round)*
1\- Change “book it\!” to “cancel it\!” after selection to allow user to remove venue if he changes his mind
2\- The entire schedule would pop up when they click “book it\!” to give the user full information about his time. And whether the gigs are an adequate time apart. (this might be solved by the suggestion in 5)
3\- The placement of the select path option changed from next to the map, to be with the rest of the features (Makes it more self-explanatory)
4\- Not sure whether to put City and State next to alphabets on the list, so the user can click directly on what city he wants. Instead of passing over multiple venues to see where they are and if they are in the city he wants. One suggestion was to have a bubble popup in the list when you hover over a venue \[too much I think\], but if that bubble appeared on the map isn’t that distracting? \[might not be\]
5\- Give instant feedback on time scheduling, so the time that was booked appears instead of the “book it\!” button, with a “clear” or “cancel it\!” button next to it.
6\- Change “add more locations” to “add stops along route” that shows that the stops are intermediate stops between the start and the end. And it’s externally consistent.
7\- How do you know which times were “grayed” by selecting which other venues. The suggestion was not to gray out other options, but to give a pop-out message saying it conflicts with what.. (also can somewhat be solved by 5) \[don’t know how to phrase this one\]: IT means that say you book venue “K” on day 3 and then you decide you want to do another venue, but before you cancel “K” you want to see what your other options are.. “Graying” removes some information, even though it gives some feedback\!\!
8\- give ratings of the venues.. Say a user has the option of venue “M” and “N”. He wants to choose based on the most popular.
9\- Will a venue that is not available gray out on the map as well? |
Prototype Changes (before Round 2 of observations)
Updated to map view. GR3