Revised Interface Design

Prototype Overview

Storyboards and Screenshots

Instructions for Prototype Operation

First Interactive Prototype

Work Distribution Table

 
Assigment 5: Prototype Overview


Our first interactive prototype includes the following features:

Plan New Trip form on the front page, specifying:
    real-time (current) or predicted traffic forecast; and
    travel time, either departure or arrival.

Predicted or current traffic forecasts for your specified trip, including:
    the fastest route based on historical traffic aggregates for the specified travel time;
    an interactive map showing speed data for the given travel time;
    directions for alternate routes; and
    travel times for alternate routes.

Personalization with
    a profile of saved trips; and
    a personalized front page showing current traffic map for most recent trip.

What Was Left Out
Because the map-based integration with our routing middleware is still in progress, the map in our interactive prototype is a static dummy gif. The GUI is not data-aware yet, though we expect this functionality to be ready soon. We also currently do not show multiple routes on the map, as our optimal routing code uses Dijkstra's algorithm. A well-known limitation of Dijkstra's is that although the top route is easily found, the second and third-best routes cannot be identified with this algorithm. We are currently investigating other algorithmic workarounds.

How to Run the Interface and Scenarios
When testing the interface, simply perform each task scenario as it is written. Start at the front page of Road Sage, the "Plan New Trip" form. The functionality of the interface should speak for itself in order to let you perform the specified tasks.

Tools used
Our first interactive prototype was built in HTML with images, using Dreamweaver and Photoshop. Dreamweaver made creation and quick readjustments of HTML pages relatively painless. Photoshop was useful in creating stand-in images used to mock up the map and slider portions of the interface, communicating how these portions will appear and work before the live versions of these pieces have been built. These tools were useful in creating a "flat" version of the prototype, but the problem with this approach is that (1) none of the information shown is based on the data entered by the user, and (2) the map interactivity, which is a key portion of the site, is not realistically conveyed in this way. Dreamweaver has problems in that it creates "ugly" HTML: for instance, it regularly creates tables and other elements unnecessarily nested within one another. It also makes managing the finer points of layout difficult. But that's a fair price to pay in return for the amount of time that it saves compared with coding a wireframe prototype's HTML by hand. This will not be the HTML code we use in the final project; the final project will reverse-engineer the prototype. Therefore, we don't have to worry about providing perfect, efficient, multi-platform-friendly HTML in this prototype.