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.
|