Further Tuning to SDAZ to Address Overshooting and
Techniques for automatic zooming based on scrolling
speed, and the SDAZ implementation in particular, are variations of rate-based
scrolling. In SDAZ, a zooming out action is used to replace the increased in
scrolling speed, resulting in rapid navigation through the information space
without overly fast visual flow. I found this technique to be particularly
interesting because of my particular interest in visualizing textual data and
numerical financial data. The most demanding aspect of an investment analyst’s
work, in my opinion, is to absorb a large body of news articles as well as
numerical data quickly.
Usability tests by Igarashi et al. and Cockburn et al.
showed very positive results compared to traditional techniques such as a
scrollbar or rate-based scrolling. However, users also reported several
problems with the technique. In a map viewer application with SDAZ, users tend
to overshoot the target and then become confused during course-correction,
since the user has to change the speed of their mouse movement. Thus, the
target will swell-up and drop-down like violent waves, potentially causing more
overshoots. Even in the document browser application, where SDAZ showed the most
promise, the potential of automatic zooming was not fully exploited by users.
Many users, instead of scrolling fast to zoom out and move toward the target,
chose to zoom only a little bit while moving slowly toward the target. I would
like to make several hypotheses about the situations and psychology that lead
users to these problems, and then implement several modifications to SDAZ in
hope of addressing the problems.
The implementations will be done in the Java
programming language for portability. An OpenGL back-end will be used for
graphic acceleration, ensuring smooth screen updates. The modified SDAZ
interface will still be controlled by a mouse and one mouse button. I thought
about using other input devices, or more than one mouse buttons, but decided
against it. I use a netbook with a touchpad that has only two buttons, which is
actually the state-of-the-art in most laptop and netbook touchpads. Even as I
am an experienced gamer, I find that using two buttons simultaneously on a
small netbook touchpad is a physically challenging task. To simplify the
gathering of data, I would implement SDAZ on a real map navigation application,
with a very large map of Canada
(or the world, if I can acquire a detailed enough map). The map navigation
application is also identified by Igarashi as having significant problems. Provisions
for user testing, such as facilities for recording target acquisition time,
will be implemented as well. However, due to time constrain, a full usability
test to validate the hypotheses and the proposed solutions will not be
From my own experience with
SDAZ, I made several hypotheses:
- In scrollable application with only one degree of
freedom, users can be disoriented by the swelling effect whenever they
overshoot their target and have to backtrack. However, in applications with
two degrees of freedom, such as a map or a very large scatter plot, this
sudden change of zoom level can happen even as the user is moving toward
the target. My own mouse motion toward the target is imperfect, especially
in a navigation task where I am trying to find the target for the first
time. This imperfection causes my scrolling speed to change enough to
trigger zoom-ins even as I move in roughly the right direction.
- The strategy of scrolling very slowly so that the
document only zooms out a little, then wait until the target approaches,
may be caused by an apprehension of the overshooting/course-correction problem.
The sudden zooms-in-and-out can be very disconcerting to the user’s visual
spatial memory. These mistakes can also be self-fulfilling, as one
scrolling misstep can cause hesitation or anxiety (of possible
overshooting), leading to more mistakes. Since I eventually adopted this
coping strategy as well, I believe that users might have chosen not to
contend with the swelling altogether, minimizing the potential of
- Acquiring the target while the view is still
zooming up is a very challenging task requiring keen hand-eye coordination.
If the target is near, or the overview itself is small (in terms of screen
space), sometimes the users might have already overshot the target while
SDAZ has not zoomed out completely. The zoom-out speed is modulated so
that zooming does not start before the scrolling speed is above a minimum
for a sensible reason: to avoid a very rapid catapult upward. The
resulting zoom-out speed may be too slow unless the overview itself is
large, the information space is small enough (so that less zooming-out is
required to reach the overview), or the search targets are far away. This
problem can be experienced easily on Igarashi’s Java SDAZ demo; the
overview was actually looped so that users can overshoot and then come to
the target in the next loop.
I would like to propose
several potential solutions:
- Instead of continuously zooming in and out as the
user changes scrolling speed, I would like to sample only the first half a
second or so of scrolling. This time is a parameter that will need to be
tuned, of course. What I aim to do is to capture the intention of zooming.
If the users have a rough idea how near or far the target is, they will
have a rough idea of how fast to scroll, or what zoom level to be in. The
early motions that they make will show this intention, and my modified
SDAZ will bring the user to (or close to) this intended zoom level only.
This also has the side effect of limiting the time taken to zoom, reduce
the potential of overshooting during the zooming motion.
- From here, the algorithm will revert to
rate-based scrolling without changing zoom levels. The main risk with RBS
is a “blurring” caused by overly fast visual flow. However, the initial
zoom-out would have mitigated this problem to such a degree that it likely
takes an unrealistically fast scroll rate to cause a problem.
- After the initial zoom out and the rate-based
scrolling, the user would be reasonably close to the target. However, to
achieve the fine motion to place the target underneath the cursor, it
takes a bit of dexterity that is hard to achieve if the scroll rate (let
alone the zoom level) keeps changing. A break in the movement here provides
comfort. I propose to increase the minimum speed where scrolling starts (Vo in Igarashi’s scale equation) *only* after the
initial zoom-out. This let the users slow down enough near the target that
scrolling stops entirely, letting them simply move the cursor on top of
the target. This change will be reset once the button is lifted. Like
Igarashi’s implementation, mine would also abstract “speed” as the
displacement of the mouse from its initial screen location. Vo in this case can be understood as a minimum “region”
where moving the mouse causes no scrolling. This particular change will
encourage the users not to adopt coping strategies by removing the main
source of apprehension, a lack of dexterity near the target.