Further Tuning to SDAZ to Address Overshooting and Course-correction Problems

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 undertaken.

From my own experience with SDAZ, I made several hypotheses:

1. 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.
2. 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 automatic zooming.
3. 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:

1. 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.
2. 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.
3. 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.