Is Auto-Scrolling Good?

1 Dec 2008 - 6:05am
5 years ago
8 replies
893 reads
Oleg Krupnov
2008

It's been a classic design principle that any scrollable view should
auto-scroll when an object is dragged outside or close to boundary of
the view.

Here's what Alan Cooper wrote in his "About Face" book:

"Auto-scroll is a very important adjunct to drag-and-drop. Wherever
the drop target can possibly be scrolled offscreen, the program needs
to auto-scroll. Any scrollable drag-and-drop target must auto-scroll."

However I've suddenly realized that I've never seen any implementation
of auto-scrolling (including my own :) that would not SUCK.
Auto-scrolling is perhaps the most awkward feature associated with
drag-and-drop that I would name.

IMHO, auto-scrolling sucks because:

1. It lacks control over precision. Variable auto-scroll rate sucks
because when I want to scroll faster (and I always do :), I often
over-scroll. Then I need to drag the object to the opposite side of
the screen and auto-scroll back.

2. It is not informative nor it is flexible. At the beginning, you
don't see how far you may need to scroll, so I usually pick the
fastest rate and over-scroll, as in 1. or have to wait too long if I
take a low scroll rate. The transition from lower to faster scroll
rates appears abruptly and often cause over-scrolling.

3. It is slow. First, you have to wait until it starts in vicinity of
the view border, then wait until it scrolls with a particular speed.

This all ends up in that with auto-scrolling I never feel comfortable
and confident, but often strained and lacking control.

This made me think about good alternatives to auto-scrolling. What do you think?

Comments

1 Dec 2008 - 6:49am
Diego Moya
2005

Two quick ideas for alternatives:
- a zooming user interface would remove the need to scroll. With a zoom out,
both origin and target of the drag-and-drop can be viewed at the same time
no matter the distance between them. This would lack accuracy in selecting
the target position, though, unless some form of semantic zooming is used.

- replacing autoscroll with a list of possible targets (list elements,
chapter titles...) - hovering over a target would instantly scroll to show
that item.

1 Dec 2008 - 8:55am
mark ahlenius
2008

Hi

I use the auto-scroll feature (as I understand your def.) every day
and find it works well for me. In Thunderbird (email) I have quite a
few folders for tracking many projects, jobs, etc. One of my
subfolders itself expands well beyond the height of the screen. With
auto scroll, it's very easy to take an email and drag it from the
inbox folder to a local subfolder. I find this quite intuitive to
use- bit I am a techie at heart. Perhaps you meant something else?

'mark

Sent from my iPhone

On Dec 1, 2008, at 5:05 AM, "Oleg Krupnov" <oleg.krupnov at gmail.com>
wrote:

> It's been a classic design principle that any scrollable view should
> auto-scroll when an object is dragged outside or close to boundary of
> the view.
>
> Here's what Alan Cooper wrote in his "About Face" book:
>
> "Auto-scroll is a very important adjunct to drag-and-drop. Wherever
> the drop target can possibly be scrolled offscreen, the program needs
> to auto-scroll. Any scrollable drag-and-drop target must auto-scroll."
>
> However I've suddenly realized that I've never seen any implementation
> of auto-scrolling (including my own :) that would not SUCK.
> Auto-scrolling is perhaps the most awkward feature associated with
> drag-and-drop that I would name.
>
> IMHO, auto-scrolling sucks because:
>
> 1. It lacks control over precision. Variable auto-scroll rate sucks
> because when I want to scroll faster (and I always do :), I often
> over-scroll. Then I need to drag the object to the opposite side of
> the screen and auto-scroll back.
>
> 2. It is not informative nor it is flexible. At the beginning, you
> don't see how far you may need to scroll, so I usually pick the
> fastest rate and over-scroll, as in 1. or have to wait too long if I
> take a low scroll rate. The transition from lower to faster scroll
> rates appears abruptly and often cause over-scrolling.
>
> 3. It is slow. First, you have to wait until it starts in vicinity of
> the view border, then wait until it scrolls with a particular speed.
>
> This all ends up in that with auto-scrolling I never feel comfortable
> and confident, but often strained and lacking control.
>
> This made me think about good alternatives to auto-scrolling. What
> do you think?
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

1 Dec 2008 - 9:41am
Andreas Ringdal
2008

A solution to the variable scroll speed might be to add a speed
indicator along the "scrolling edge".

When the scrolling starts, place a scrolling indicator just below the
cursor, and let the users move position the mouse a little further
up/down on the indicator to adjust the speed.

Downside: users might have a hard thime figuring out what that thingy
underneath the cursor is.

Andreas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36058

1 Dec 2008 - 6:13am
Jakub Nesetril
2008

Oleg,

well spotted - all auto-scroll implementations indeed do suck.

While I can't recall any such example of the top of my head, a good
alternative would be along the OS X Dock (enlarging focused icons) or some
kind of loupe UI - ie. keep the whole context in one page in a scaled down
version, and zoom a selected partial area to full-resolution to allow the
drop. This removes the "variable speed" and "opposite end of window to
reverse direction" problems you outlined.

Jakub

On Mon, Dec 1, 2008 at 12:05 PM, Oleg Krupnov <oleg.krupnov at gmail.com>wrote:

> It's been a classic design principle that any scrollable view should
> auto-scroll when an object is dragged outside or close to boundary of
> the view.
>
> Here's what Alan Cooper wrote in his "About Face" book:
>
> "Auto-scroll is a very important adjunct to drag-and-drop. Wherever
> the drop target can possibly be scrolled offscreen, the program needs
> to auto-scroll. Any scrollable drag-and-drop target must auto-scroll."
>
> However I've suddenly realized that I've never seen any implementation
> of auto-scrolling (including my own :) that would not SUCK.
> Auto-scrolling is perhaps the most awkward feature associated with
> drag-and-drop that I would name.
>
> IMHO, auto-scrolling sucks because:
>
> 1. It lacks control over precision. Variable auto-scroll rate sucks
> because when I want to scroll faster (and I always do :), I often
> over-scroll. Then I need to drag the object to the opposite side of
> the screen and auto-scroll back.
>
> 2. It is not informative nor it is flexible. At the beginning, you
> don't see how far you may need to scroll, so I usually pick the
> fastest rate and over-scroll, as in 1. or have to wait too long if I
> take a low scroll rate. The transition from lower to faster scroll
> rates appears abruptly and often cause over-scrolling.
>
> 3. It is slow. First, you have to wait until it starts in vicinity of
> the view border, then wait until it scrolls with a particular speed.
>
> This all ends up in that with auto-scrolling I never feel comfortable
> and confident, but often strained and lacking control.
>
> This made me think about good alternatives to auto-scrolling. What do you
> think?
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

1 Dec 2008 - 12:24pm
Jakub Linowski
2008

How about sticking to auto-scrolling but removing the acceleration
component. Often the acceleration is what confuses people as the
dragged items speed up too much and users lose control.

What about two fixed scroll speeds. One could have a reasonable
scroll speed assigned to the default drag operation. The other could
be a bit faster, and could be activated during a HOLD SHIFT event,
for the more advanced / hasty people. ;)

Cheers,
Jakub

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36058

1 Dec 2008 - 11:18pm
jabbett
2008

I like the auto-zoom-out idea.

Here's how to refine it: When you approach the view border, zoom out. When
the user slows down/stops his mouse movement (after a delay of, say, 200
msec), zoom back in to allow precision placement.

It hews to the user's mental (well, physical?) model -- look at the whole
sheet when doing major reorganization, then get in close to carefully
position.

Would work well in a Visio/Photoshop/Illustrator-type situation, with a
well-defined canvas... less so with the Thunderbird folder organization
example.

-Jonathan

On Mon, Dec 1, 2008 at 12:24 PM, Jakub Linowski <jlinowski at gmail.com> wrote:

> How about sticking to auto-scrolling but removing the acceleration
> component. Often the acceleration is what confuses people as the
> dragged items speed up too much and users lose control.
>
> What about two fixed scroll speeds. One could have a reasonable
> scroll speed assigned to the default drag operation. The other could
> be a bit faster, and could be activated during a HOLD SHIFT event,
> for the more advanced / hasty people. ;)
>
> Cheers,
> Jakub
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=36058
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

2 Dec 2008 - 8:13am
Anonymous

Teehan Lax has a nice exploration in the iPhone paging and
incorporates zooming in their method. It probably doesnt have much
application elsewhere but its an interesting approach:
http://www.teehanlax.com/blog/?p=818

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36058

3 Dec 2008 - 4:38am
Pietro Desiato
2008

uhm...what about a scrolling feature that,if the user accelerates,
gradually zoomes out? in this way, you would scroll but at the same
time you'll need to scroll less, since the more you do that the more
the pages is visible in its entire height-width

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=36058

Syndicate content Get the feed