Discussion
Discussion
The pilot usability study opened our eyes to opportunities to make quite
substantial improvements to our interface.
After being given task 1, two users entered their "from" and
"to"
addresses on the "plan new traffic" page but then pressed the
"enter" key
to submit that data, before moving to the next section and choosing
between "traffic right now" and "a forecast of future traffic"
On the "plan new traffic" page, the "I'm flexible"
section that allowed
him to specify a range of times confused one use. He said he wasn't sure
whether the system would give him the optimal time for that route, and
he
wasn't sure what criteria the system would use to choose the optimal time.
When he specified a time range and moved on to the forecast page, he
commented again that he wasn't sure whether or not the visualized travel
time is the best travel time, during which his route would have the least
traffic. He said that he assumed that it would (which is a correct
assumption), but he said he'd like to be reassured, and that these pages
should notify him in text that the system chooses the best time based
on
low traffic. In many cases when users request specific features,
designers should take these suggestions with a grain of salt, but we think
this is a case where the user's suggestion provides a great solution to
this design problem: just add text to both pages explaining how the system
chooses a travel time within a range. On the form page, rather than saying
"Sometime between [foo] and [bar]," say "The best time
between [foo] and
[bar]."
alternate routes - even though the map pages textually list durations for
the three fastest routes, and presented them as the fastest, she didn't
quite trust the text, yet she said she would be much more apt to trust
these same suggestions if she could see all of these top routes visualized
on the map! (Strangely enough, providing maps showing the top three or
five routes was a very early design that we considered, until we learned
that this would not be supportable on the backend with our tools and
limited resources. The color-coding of multiple routes simultaneously also
becomes a visibility problem where routes share the same sub-routes. This
is a feature to consider designing and implementing in the future,
however.)
An alternative that can alleviate this problem is to provide buttons
or
links next to each alternative route summary that, when moused over, cause
a map for the chosen route to appear on the screen. Or, to show not just
one but three to five maps on the page, for the fastest routes. (Perhaps
the fastest of all would be big and the others would be small unless
clicked?)
One user mentioned that he expected the slider selector to be draggable,
not just clickable. This is something we will consider implementing if
it
doesn't add too much overhead.
A user wanted to see a slider on the live-traffic page so that he might
easily move forward in time to see forecasts, right there. Our first
sketched-up slider-map designs included a slider on the live traffic page,
but at length we decided to remove it because it confused users.
Confusion between the two modes of "live traffic view" and "forecast
traffic view," and which mode a user is in at a given time, proved
to be a
major issue through much of this project. We decided that sliders on live
view pages were a source of this problem, and their removal helped to
clear up much of this confusion.