This project, by 4 students, sought to look at the problem of the driver of a car getting from one point to another. They developed a navigational aid in a car to address the issue. The aid sought to reduce the mental load on the driver by reducing the effort it takes to find a location, to locate the route and to navigating the route. Reducing the mental load allowed the driver to concentrate on the mechanics of driving. The system presented the information in both a graphics format and a list of written instructions for those who prefer to navigate with written instructions. It will be an aid, at the full featured level, for the tourist, who has no idea how to get to a location or where they are, and at another level, for the everyday driver who may just need alternate routes, but already knows a route or the address.
It proposed, but did not implement,
the system augmenting existing road information such as road signs and
other landmarks, especially during poor visibility conditions. In
addition to providing real-time navigation information and aids, the system
provides for interrogating it again, if you get lost or create navigational
errors.
The user analysis was good, in that
it narrowly defined the driver of a car as one who is not physically disabled,
has correctable vision to driving level requirements, is English speaking,
can read road signs and instructions and is a proficient driver.
The project team scopes their driver space from unknowing tourist to knowledgeable
local driver. These constraints and definitions for the user
make the project doable and shows that they do understand the user.
The task analysis used primarily “Task Decomposition” and in particular HTA, “Hierarchical Task Analysis.” They determined the highest level tasks, of finding one’s way, as the following:
There was no formal use of “Knowledge
Based Analysis” or “Entity-Relationship Based Techniques” analysis.
I thought they did a pretty credible job with the user and task analysis. They clearly defined and understood who their user was. They did a good job listing the tasks that were performed in a user finding his/her way from one point to another.
They used the principal of observation to gather data well. They got different users, other than themselves, to drive from one point to another, and observed and debriefed.
I personally thought the simplicity
of their web pages, without a lot of graphics and other asides, made it
easier to read and pick out the “meat” of the project ideas. It sure
made it faster to print.
I felt that they missed the real HCI part of the problem by not addressing, in a more general and formal way, the memory and sensory issues of “how we find our way around.” What cues, training, stimuli, and mental aids do we need to navigate? Can we navigate as a marine mammal does, or do we humans have other ways? Research and model this first, then design the navigation aid.
Some of the system technical details, features and constraints got mixed up in the user and task analysis. For example, restricting the system to “providing information for a city only” is a valid restriction, but does not belong in the “User Analysis.” Many of the detail design conclusions and comments would be better left for other sections of the project rather than the user and task analysis.
They should have mapped their user/task analysis insights to the formal HCI terms. For example, what HCI concepts are involved in a graphics oriented versus a language oriented aid? What is the relation of Fitts’ Law to the placement of the navigation aid?
I found no analysis of competitive systems, such as those available on the Cadillac or Mercedes automobile, which were in existence at the time of this project.
There appears to be lack of closure in evaluating the original goals of the system.
| Back to Terence D. Hughey's cs6751b Classwork Page | |
|
Back to Gromit Home Page |