"Navigating through time # The widget initially assumes a time
window of “the near future.” * * This window changes over time,
of course. The widget naturally stays in sync, always displaying
relevant information. A button to manually “refresh” the display
would be almost obscenely mechanical. There are two cases in
which this context is incorrect: The user wants to see even later
trips. The user wants to plan for some other time entirely. #
Relative navigation. To see earlier or later trips, the user can
simply drag the graphic around. A cursor change suggests this, as
well as a brief message when the widget is first started. * *
The mouse scrollwheel and keyboard arrow keys also serve to
navigate through time. The “underlying” graphic is infinite—the
user can scroll forever. Thus, a GUI scrollbar would be
inappropriate. # Absolute navigation. To plan around an arbitrary
time, the user clicks a button to reveal the hours of the day,
from morning to night, laid out linearly. The user can then click
anywhere on the mechanism to jump to that time. # The
mechanism’s labeling is intentionally vague, so the user will
click approximately in the right area, and then continue to drag
left or right until the correct information is displayed on the
chart of train schedules. This forces the user to keep her eyes
on the information graphic, instead of wasting effort precisely
manipulating the navigation mechanism. * * This is the same
concept suggested by the Google Maps prediction list above.
Instead of precise, tedious absolute navigation, offer quick
ballpark navigation, followed by relative navigation in a tight
feedback loop. Unlike the time of day, the predicted date (today
) is probably close—few people plan subway trips weeks in advance
. Thus, the date control is relative"
inspiration for "time marking
- Magic Ink: Information Software and the Graphical Interface
http://r4.sharedcopy.com/112v0j2