Prototype Overview
April 15, 2004
Prototype Overview
On all pages, we changed the navigation text to white, so it stands out more clearly against the background.
The front page has been changed to a default front page, where users need not sign in or register before using Road Sage. The default front page includes a small "sign-in" entry form on the side, and later when registered users return to the front page, the sign-in form will disappear. We added a "Forgot your password?" link to the sign-in entry form.
We also added a note on the front page, indicating that Road Sage functionality is currently limited to the Bay Area.
We added additional help to the front page, in response to the heuristic evaluation, to clarify why it doesn't make sense to specify an exact date (say Monday, April 11, 2004). Because traffic predictions are based on historical averages for a given day and time, it only makes sense to enter your travel time for a "typical" (non-holiday) day. We added the word "traffic on a typical day" to denote this. We also added popup help windows to further explain how the predictions are made.
We also rearranged the layout of the predicted travel entry form. To conserve space we put the departing at/arriving at radio button group on the same line as the day of travel menu. We also removed some of the ellipses to provide more consistency with the from/to destination box.
To further clarify that predictions are made for a typical day, we added a function that checks whether the upcoming week has a holiday. For example, if the user select "Monday" for day of travel, the function checks whether the upcoming Monday is a holiday. If so, the system prints a red alert notice with the traffic prediction page, warning that predictions are only accurate for non-holidays.
To bring more attention to the title of our Live Traffic page, we changed the title from "Traffic Right Now" to "Live Traffic", with the time and date printed prominently with the title. The time/date represents the time when the map was last refreshed, and the map refreshes every 10 minutes. We also changed the wording on the page from "Adjust Trip" to "Change Trip." Finally, we changed the route displayed to include more side streets in the map, thus illustrating our extensibility to non-freeway routes.
On the Traffic Forecast page, we changed the wording
above the map from "the trip you specified on Monday"
to "the trip you specified for Monday." This addresses
a "Speak the User's Language" violation, clarifying any confusion
about whether the map displays the trip for a Monday travel time vs. the
trip the user entered on Monday. We also changed the wording on this page
from "Adjust Trip" to "Change Trip".
We also improved slider functionality. Clicking on the slider now produces a different map display, with the slider shifting over to the time selected.
In the Profile page, we added a "Rename Trip" option for users who wish to label their daily commute with a trip name like "My Commute". We also added in a sample trip, from Minna St. to Niagara Ave. within SF, which doesn't involve freeway driving. This exemplifies that our system could extend beyond freeways. Although our task scenarios currently involve freeway driving (because we only have traffic data for freeways), we are building this system as an extensible model in hopes that traffic sensors will one day be installed on all non-freeway roads in the Bay Area.
Heuristic Violations Not Addressed
We did not extensively address the "help and documentation" due to time concerns. We did add the popup help windows to the front page, where users enter their predicted travel plans. However, we did not thoroughly revamp the Help site in the interest of time and priority.
We did not allow the user to enter in an exact day/time for predicted travel, because Road Sage predictions are only for a "typical" day and time... we did however, add the popup window warning that predictions are not accurate for holidays.
We did not change the route descriptions on the Traffic Forecast and
Live Traffic screens. In response to the heuristic violation that "these
route descriptions seem limited by freeway: users may have routes that
are entirely on city streets," we disagree. We believe that a high-level
route description (580->80->101) is the best and simplest solution
for summarizing the route. For more details, the user can click the "Directions
for this route" link. Our current task scenarios involve freeway
driving, so the printed route summary would include a freeway.