Problem Statement, Solution Overview
Description: Final Interface Design
Description: Final Interface Design
Functionality
Routing: the user can specify points
of departure and arrival and intended departure or arrival time into the
system; the system will display the optimal route for that time amd day,
along with the estimated travel time.
Current traffic (now) vs. typical traffic
(at a given time): the user can switch between a map
showing the latest traffic conditions (refreshed at 15-minute intervals)
in terms of color-coded freeway speeds and a map displaying typical highway
speeds for a given day of the week and time.
Interactive map: To provide the other
features, Road Sage displays map images with color labels etc. It also
includes standard map-related features such as zooming. The mapping features
use the freely available time map (tm) Java mapping software, which was
developed as part of the Electronic Cultural Atlas Initiative (ECAI) project.
Time slider: This feature allows the
user to quickly explore alternate travel times by clicking on various
hour and minute ticks.
Day selector: allows the user to change their day of
travel (Monday through Sunday).
Help: various help screens to guide and assist
the users throughout the system.
Unimplemented items: The following features were discussed
and/or prototyped in the initial stages of development, but were eventually
left out due to lack of time required to implement and debug this functionality
in a comprehensive manner:
Current traffic incidents – mapping any highway accidents as reported by CHP.
A link to public transportation data that would have allowed the user to compare their intended commute with a BART/bus/other public transit trip.
Registration (prototyped) – provides the ability for users to create an account with the Road Sage system and save their frequent routes and any other trips.
Interaction Flow Diagram: Main Portions of the Interface
The following image provides a visual overview of the main task flows that users are expected to follow in using the system, in carrying out tasks similar to those that we examined in usability tests.
Tools used for user interface prototyping and implementation
For low-fi prototyping we used paper, clear plastic overhead-projector
sheets, post-it notes, pencils, markers, large erasers, scissors, rulers,
and transparent tape. We used Dreamweaver and Textpad for HTML prototyping,
Adobe Photoshop for image processing and graphic creation, Javascript
and PHP for some dynamic interface features, as well as some Unix editors
(vi, emacs) for quick edits. The prototype's middle and back ends were
designed along the lines of a standard three-tier structure: We use Oracle
9i as the database to store the speed and travel time data; the middle
layer was implemented in Java; the web interface includes some PHP and
Javascript components. We also used some Perl, sed, and other Unix shell
tools for various peripheral tasks related to data aggregation and formatting.
CVS was used for source control (i.e., to ensure that we could work simultaneously
without overwriting one another's changes).
These tools' pros and cons
The low-fi prototyping tools worked well, although a set of blank common interface elements (buttons, radio buttons, etc.) printed onto very small post-it notes would have sped up the process and made it more understandable to the users.
Dreamweaver is handy for quickly building prototype tables and pages and for doing sitewide searches and replaces, but it often produces "ugly" code that's inefficient, and it sometimes interjects unwanted tags. These are not huge problems for rough prototype production, and Textpad came in handy for smoothing out the rough edges. For final implementation of this productwe highly recommend that professional Web engineers reverse-engineer the screens, building new ones from scratch that are standards-compliant and that test well across browsers and platforms.
Photoshop is a fantastic image-processing tool in the hands of an expert, but its steep learning curve makes it difficult for novices to use efficiently.
Of all the tools we used, CVS probably produced the most problems. In an environment in which multiple people are working on the same files it's important to implement source control, but CVS is extremely unintuitive. Its unnecessarily obscure and complex interface encourages mistakes, and it doesn't always operate properly or consistently. Unfortunately CVS may well be the best option; Visual Source Safe suffers from a host of its own problems and we're not aware of any very usable and reliable source-control systems in existence.