Making Long Scrolls on the iPhone Not Suck

Advertisement:

POWERED by FUSION

The designers of the iPhone had an immense amount of courage. They finally removed the scrollbar, a persistent and harmful UI anachronism. Given the amount of time spent scrolling on computers, requiring the move from your locus of attention to the small target that scrollbars represents has wasted immense amounts of time. If you calculate it out conservatively, the scrollbar widget wastes almost one complete day a year. And that’s only if you scroll once every 6 minutes. Multiply that by number of the 300 million Firefox users and you’d find that the scrollbar wastes over three-fourths of a million man-years of web browser’s time. Every year.

No wonder we have scroll wheels and two-finger scrolling. They remove the 4 seconds of back-and-forth targeting the scrollbar. They save the world millions of man-years of wasted time.

Fennec (Firefox Mobile) and the iPhone go the next step and get rid of the scrollbar all together. There just isn’t enough room on those little screens. They both use pan-to-scroll, which solves the problem with the exception that getting around on pages so over-flowing with length that they stretch for half an infinity (like the Line of succession to the British throne) takes half of forever. The problem is so horrific that mobile Safari had to implement a band-aid UI patch for jumping back to the top of a page.

There has to be a better way of solving the problem, one where you get the immediacy of touch-and-drag to pan but where you also don’t get stuck scrolling the scenic route.

Here are two thoughts on how to solve the problem.

Sticky Scroll Indicator

The obvious solution. When you start to scroll, the scroll indicator fades in. After you stop scrolling, the scroll indicator remains and can be interacted with for some amount of time. Time based solutions are always a tricky — the timeout is never the right length for everyone — but this one seems pretty pit-fall free. The scrollbar is there when you need it and gone when you don’t.

Scroll-to-zoom

The more visually impressive solution, although I’m not convinced it is better than the obvious solution. During long scrolls, the page automatically zooms out. Optionally, the longer the scroll, the further the zoom. The zoomed out page can be panned, and the now-present scrollbar can be used for quickly jumping around. A single tap zooms you back in. This gives you a wonderful visual table-of-contents map of the page you are moving about, but at the potential cost of simplicity.

Other solutions

Are there other solutions?

About this entry

You’re currently reading “Making Long Scrolls on the iPhone Not Suck,” an entry on Aza’s Thoughts

Published:: 8.24.09 / 5pm

Category:: WEBLOG

Dave Malouf 8.24.09 / 6pm

Maybe it should act as the click-wheel does on he iPod. Based on speed and duration of said speed (or rate of acceleration), the scale of scrolling changes.

On the click-wheel if you go fast for a bit of time, it changes from scrolling entries to scrolling whole letters in the alphabet.

What if there was index scrolling and then page level scrolling? Of course the pages have to be ‘defined’ somehow either systemically or by design.

Another thing I’ve noticed is that either you to index scrolling which is slow, or you are jumping to the top or bottom (or anchor). If the former, there is nothing to do. If the latter we can put a gesture behavior in the scroll system that recognizes (top, bottom, or lets you choose from programmed latter; only showing up if the page/screen is read to have such anchors)

those are my thoughts.

= dave

tef 8.24.09 / 6pm

Use a different gesture instead of up and down ?

For example: Doing clockwise and anticlockwise circles to scroll up and down.

With this, you don’t have to take your finger off the screen to continue the motion, and you can use the acceleration to speed up the scrolling.

Another option might be to use more fingers to scroll faster.

Albeit this only mitigates things a little, pages & lists keep getting longer :)

lqd 8.24.09 / 6pm

Like i said on twitter, i was toying around with these similar concepts:
- a way to scroll faster and to specific landmarks already exists, for instance with contacts where a scrollbar can take you to the letter G for example. Maybe this principle could be applied here, with shortcuts to every major section of the page (which could be based on a microformat, or linking to all h1 tags or whatever) and could contain shortcuts to get to the top or bottom, or scrolling up or down the size of the visible viewport.
- the fast flick already scrolls an amount that is relative to the speed at which you flick. i was wondering if we could introduce the position on the page into the picture. For instance, a full force flick would always result in going to the bottom or top of the page; a less forceful one to the first or third quarter, etc. At first I thought this might be disconcerting because it would mean depending on the height of the page, which the user doesn’t know before scrolling. So it could only be applied to really strong flicks for instance, and they would always have the same result; But really this is how scrolling behaves on the desktop already anyway (since the only information a scrollbar gives you is whether the page is big or not by looking at the thumb’s size, which is not that much of an indication) and thus maybe this assumption wouldn’t be such a problem after all.

Justin Dolske 8.24.09 / 6pm

My old Sony Vaio touchpad had a useful feature where dragging along the extreme right or bottom edge worked as if you were automatically dragging the scrollbar. EG, a drag from the top to bottom (at the edge) would scroll the page all the way from the top to the bottom. Not very discoverable (and confusing if you were not expecting it), I think it was an optional feature in the mouse driver.

The touchscreen / panning equivalent of this would be to activate the scrollbars when when you touch the edge of the pannable area. It still has some discoverability issues, but at least it’s a bit less surprising.

xeen 8.24.09 / 6pm

What works really nice and what I use on the desktop is implemented in the “scrollbar anywhere” extension. I’m not sure how it’s implemented exactly, but it boils down to “move the cursor 100% of the screen, scrolls the page 100% into that direction”.

I.e. if my cursor is on top of my screen and I want to scroll down, I move the cursor down. This way it’s possible to scroll to the bottom equal fast, independent of the length of the page. Unless the page isn’t ridiculously long that’s even better than using the scroll wheel because it allows for more direct input. However, a “speed limit” might solve this as well, so long pages still can be easily navigated using this method.

xeen 8.24.09 / 7pm

What I suggested is basically what Justin Dolske posted, just that you can do it anywhere. Maybe like “two finger scroll”?

Has it been so long that I last used a scrollbar that I forgot how it works? Geez…

David 8.24.09 / 7pm

Adding more interface mechanisms for the user to learn should be avoided when there are already-existing mechanisms that can do the job. I can already think of two ways that existing interactions can be useful here.

What seems like the obvious solution to me is what one would naturally do on in a ZUI: zoom out until the top of the page is visible and zoom back in. Since zooming is already a known interaction, the user doesn’t need to learn anything new. This would require that the browser actually allowed one to zoom out far enough to see the whole page. If Fennec doesn’t allow for that, then I would consider that a bug.

Your ‘table-of-contents’ comment made me realize that this could be improved by the addition of semantic zooming: when zooming out past a certain level, paragraphs shrink even faster while headings enlarge relative to paragraphs. This would effectively create a table of contents, allowing one to zoom back in not just on the top of the page but on the top of any section.

My less-obvious solution has already been suggested in the comments: acceleration. Certain mouse drivers already do this for scrolling, and Firefox is getting native scroll acceleration. It makes sense to extend this to panning. Every time I flick the screen, the added velocity would be proportional to the page’s current speed. Thus, the more I scroll, the faster the page moves. Getting to the top of the page would requite only a few flicks of the finger. (This is similar to how warp speed increases velocity exponentially: no matter how long the page is, warp 10 will get you to the top.)

JYOuyang 8.24.09 / 8pm

One attempt at long scrolls:

http://code.google.com/p/networkpx/wiki/Using_QuickScroll

Zack 8.24.09 / 8pm

When there’s space for it, the scroll bar still serves the valuable function of providing a visual indication of how long the document is and approximately where you are in it.

Tom Coates 8.24.09 / 9pm

There are other options I can think about, although how good they are is unclear to me. One would be to have dedicated scrolling functionality, along the lines of a soft joy pad appear on screen when you start the scrolling process, that you could interact with. There are lots of related scrolling interfaces related to other forms of interaction - like the scroll wheel. Touch an area and keep the finger down triggering a in-place on-page widget. Then as you move your finger down further in relation to the widget, the page scrolls with increasing speed.

Another might be to use gestures - one finger is one speed of scroll, two fingers is a faster scroll, three is ultra-fast. It’s not immediately discoverable, though, and some of the gestures might already be occupied.

Another version might be to not think about scrolls as much as skips - how much of the structure of the page can be intuited along the lines of the stuff Snow Leopard does with Preview - can you present a structure of headings where available for rapid scrolling or skipping to the appropriate section of a web page (for example). You could stick it at the top of the page as a link (chapters, essentially).

I bet you could think of a good chunk of other ones that have established precedents. Not sure many of them would be much good though…

Another angle would be to try and collapse the page a bit, so you don’t need to scroll. The faster you go, the more some areas evaporate or contract.

MarkC 8.25.09 / 4am

Here’s my suggestion: When you start scrolling a zoomed version of the page gets overlaid on the opposite side of the screen (i.e. the right edge if you’re scrolling on the left of the screen). This zoomed version roughly represents the structure of the page, rather than being an accurately zoomed version, and it’s scaled to fit the whole page in the vertical space on the screen.

Headings are preserved as readable text, if possible (as per some of the suggestions above), but lines of body text, or whole paragraphs, get replaced with simple grey boxes representing the shape of the text. Images may get replaced with placeholder boxes, or with scaled versions of the images themselves (better for navigation, but could be too small/distorted to be of use).

A translucent box is overlaid onto this scaled page view, representing the position and size of the area currently in view.

The user can continue to scroll as usual by sliding their finger up/down. Moving their finger sideways to the scaled view would let them drag the box up or down for fast scrolling.

Basically this idea combines your sticky scroll indicator with the idea of showing a zoomed version of the page which maintains the key elements by which the user is likely to navigate.

bodhi 8.25.09 / 5am

Aza, have you looked through the HCI literature to find useful research about the topic? Andy Cockburn has done several experiments in this area

http://scholar.google.com/scholar?q=zoom+scroll&hl=en&btnG=Search

http://www.cosc.canterbury.ac.nz/andrew.cockburn/papers/speedScroll.pdf

Andy Cockburn has done several experiments in this area, maybe some of his work could be of use? (I think my earlier comment was eaten by a spam-filter, so links omitted on this one)

Martijn 8.25.09 / 7am

What a terrible idea to remove the scrollbars. How would I know if content is scrollable that way?

Martijn 8.25.09 / 9am

What a terrible idea to remove the scrollbars. How would I know if content is scrollable that way?
Sorry, forgot to add great post! Can’t wait to see your next post!

Ankur Jalota 8.25.09 / 11am

Sticky scroll is better when the user is familiar with the page - and wants to jump to that part of it immediately. Perhaps this will usually be a short distance.

Scroll-to-zoom is better for visual scanning - and will perhaps be for scrolling longer distances.

So it seems like a good solution might be to initially use sticky scroll, and when a certain threshold is reached, use scroll-to-zoom.

Francois Laberge 8.25.09 / 1pm

Having hyper zooming, scrolling when gestures originate on the edges would be great. Perhaps with some sort of undo modeless guard that pops up when you accidently do it.

This undo would also be great for returning to your original zoom/pan position.

The problem now is that at least on the iphone is that the new text selection mechanisms have similar gestures.

Rémi Cardona 8.25.09 / 6pm

http://www.lri.fr/~appert/website/orthozoom/orthozoom.html

Shameless plug, this interaction technique was designed by coworkers in the HCI lab I work in. I’m pretty sure it can be adapted to just about any really long document.

Hope that helps, cheers!

James 8.25.09 / 7pm

1 finger: ‘normal’ scrolling
2 fingers: Scrollbar Anywhere scrolling

David 8.25.09 / 7pm

I like JYOuyang’s suggestion. It has a nice advantage over scrollbars and the sticky scroll indicator: it’s 2-dimensional. Not only can you easily get to the top or the bottom of the page, but you can also easily get to the left side, the right side, or any corner. That’s going to be increasingly useful as zooming becomes more of a standard form of interaction.

And this reminds me of another solution from the world of ZUIs: the interactive thumbnail overview. Google Maps uses one in the bottom-right corner. Now, instead of needing to build a mental modal where the scrollbar is somehow mapped onto the page in a not-immediately-obvious way, there is now a clear and direct mapping between the overview and the page and between the draggable window on top of the overview and the visible part of the page. Since this is a thumbnail (perhaps with the table-of-contents view discussed earlier), it is also now possible to pan quickly to other landmarks on the page.

However, instead of showing this extra interface element all the time, the overview could appear only when the page is being dragged/scrolled—just like sticky scroll indicator. It could also appear briefly when a page first loads. Thus, the overview would not get in the way when one is simply reading a page. More importantly, the affordance the scrollbars allow (mentioned by Zack) has now returned. Since I see the overview when the page first loads and whenever I interact with the page, I will now tacitly know where on the page I am, even if the overview is not currently being shown. Well, I hope that would be the case.

Philip Ganchev 8.25.09 / 11pm

A scroll bar 2 pixels wide should always be visible to indicate position in the page without needing to interact with the document.

Gerv 8.27.09 / 4am

Philip: I don’t agree; if you do that, people will try and interact with it and you are back at square 1.

How about hyperspeed scrolling? It would work as follows.

Observation: If someone is trying to scroll a long way, they first do a fast top-to-bottom finger flick to get the thing shifting. The 1:1 mapping of finger movement speed to scroll speed, which is so useful at low scroll speeds, means that it does get going reasonably fast. But, how can you make it faster? You have to move your finger faster.

The idea: once the scroll is moving at above a certain rate, further scroll actions are _additive_ rather than _adjustive_ of the rate. So if I do a top-to-bottom-fast flick five times, the scroll ends up moving five times faster than my finger, rather than at the same speed as it.

Did I explain that well?

Gerv

Robert Kaiser 8.27.09 / 1pm

I have not yet found any solution that I find better to use personally than the scroll bar. I’m sticking to microB and not being able to make myself use Fennec on my N810 mostly because using the scrollbar on th touch screen is exactly what I need.
On the desktop I could live without, I have a scroll wheel on the mouse there. But on the interactive touch screen, contrary to the usual non-touch display and mouse, there is no time wasted with moving the mouse to the right edge of the window and back to the article, the movement is for free, I just need to touch the location to go or drag the scrollbar thumb, which I end up doing most of the time, actually. And I love it, I’d never want anything else. And I hate Fennec’s panning stuff.

Paul M. Watson 8.27.09 / 3pm

Got to say I like the scroll-to-zoom idea. It really places you in the page.

Aleksander Kmetec 8.30.09 / 4am

Here’s an alternative idea: remove the need for users to scroll to the top of the page. If the only reason for scrolling to the top is so you can reach the location bar, maybe that’s not the best place to put it. In case of Fennec it could automatically pop up when you expose the left sidebar since the left edge of the page is likely to be closer than the top edge.

Also, capabilities of individual devices should not be ignored. If one device comes with a menu button, put an option in that menu that immediately focuses the location bar. Use the same patterns that other apps on that device use or your app will end up looking and feeling out of place. Fitting in with the natives is more important than acting “pure” and better than everyone else.

And please don’t use some poorly documented “magic” behavior like mobile Safari. It’s completely non obvious and I didn’t know about it until today.

Ehsan Akhgari 9.5.09 / 11am

One thing that I have seen the S60 browser do is that for long pages, after a bit of scrolling (as it senses that the user is trying to reach far down the page), it shows a zoomed out vertical preview of the page in front of the page (like a popup window) and designates the currently displayed area with a red rectangle and accelerates the scrolling. This way you have both the small and big pictures in front of you.

That browser of course is for a keypad based device. On a touch screen device, the zoomed out preview popup may appear after scrolling for a while (provided that a considerable threshold of the page’s height has yet to be scrolled into) and stay for a short timeout after lifting the finger off. Faster scrolling can be achieved by dragging the red rectangle on that popup preview.

This way the user has the best of both your proposals, I think.

Henk Jan 9.6.09 / 6am

link to british throne succession is broken.

Please remove closing ) from the URL:
Broken:
http://en.wikipedia.org/wiki/Line_of_succession_to_the_British_throne)

Better:
http://en.wikipedia.org/wiki/Line_of_succession_to_the_British_throne

Philipp 10.1.09 / 12pm

I also noticed this and tried your first suggestion by pure curiosity if it would work.
Getting the fade-out time right is surely hard; I just think of the navbar when entering full-screen in FF, which takes too much time for me (anyone knows a about:config key to change this?), but is a good way to show where it went to the average joe.

The second approach seems a bit of too much action for me. Scrolling down and zooming out while viewing the page is a lot to process.

Why not simply use two/three fingers to speed up the scrolling?

شات 11.27.09 / 4pm

@@Thiinks@@

fahim 1.2.10 / 9am

I really like the way the scroll function works on the iPhone but where it lacks is when you need to go back to the top or to the bottom of the page quickly.

Maybe one way to solve scrolling to the bottom or top of the page is to use a gesture where you’re giving the scroll a ‘boost’ of some sort. let me explain….

You’re at the bottom of a very long page and want to get back to the top quickly…

rather than scroll up and up… you hold down your finger for a couple of seconds (charging it up) and then flick down (release the acceleration) anf it gets you to the top.

Of course, currently when you hold down for a second or two you get the context menu, so some more thinking needs to be done around this part… :)

Fahim

buy 8gb m2 1.22.10 / 12am

If OS 4.0 is only for the latest two iPhones, Apple will face the fury of recent iPod touch users. Mine is only a few months old, and I will not be happy if it doesn’t even run the first major OS upgrade after I bought it.
The digital format is so wonderful because you don’t have to store stuff in 3d space. You are not forced to look through piles to find your item, you simple scroll through the list, ordered however you want (date, file type, name)

Making Long Scrolls on the iPhone Not Suck

About this entry

32 Comments

Have your say

Previous

About me...

Projects