With infinite scrolling, do scrollbars still make sense?

Question

I noticed this today on Google Plus:

Virtual Scrollbar in a Google+ Gallery

This is a virtual scrollbar, as opposed to native scrollbars everyone on Windows or pre-Lion OS X does know.

Now this happens to be a scrollbar in an infinite scroll context: that is, the actual document (the gallery) is much longer, containing about 3000 pictures.

Yet the scrollbar acts like a native scrollbar: its whole length represents how much was downloaded to the client, rather than how long the actual document is, and the scroll itself gets smaller as more parts of the document are downloaded, until it reaches a minimal size still comfortable to drag with a mouse pointer.

I guess I'm one of the last guys here who said "no thanks" to Lion and perhaps everyone else is used to these tricky scrollbars popping up everywhere, from smartphones to desktop interfaces, so perhaps I'm one of the last scrollbar user on the whole World.

Still, it brings me a question: are scrollbars useful still, esp. with infinite scroll / large data?

The original scrollbar concept was simple: you have a document, and you're viewing only a part of it:

With traditional scrollbars, the scroll tells the size of the viewed part compared to the whole as well as how far we've seeked from the beginning

But with the advent of infinite scrolling, we've got this:

In infinite scroll situations, the scrollbar has no direct relationship with the size of the document

So, we see the downloaded part of the document. While this might be a technical limitation of native scrollbars, we're talking about a virtual scrollbar here: this actually had to be programmed by hand, and most possibly UX-designed.

Historically, a word processor (like, excuse me, Word) didn't load the whole document: rather, it stored the geometrical size of all objects to be loaded, added them up, made a scrollbar, and loaded only the part which was viewed, or already viewed. (*)

So my main question is: is there a need for a scrollbar in 2012, if there is, how should it look like (including fallbacks) and if there is not, what should come instead? Why, why not?

Our context would be consumer community sites, so, photo galleries and newsfeeds (whatever we call the "Your friend XY did something on our site" pages) , target audience 30+-5, in possession of a smartphone but using a desktop computer for certain tasks.

(*) (For technical history on this, read Design Patterns from the Gang of Four: this is called the "Proxy" pattern

Update: to make it clear: I'd like to see explanations, patterns, wireframes. "It depends" is not an answer: of course it depends! It depends on what, and "for example if X", what do you recommend, "but if Y", what do you recommend, examples, ideas, mockups.

Infinite scrolling is abundant today, and scrollbars are here with us since about the 80s (perhaps it's a Xerox Star pattern). Yet I feel their current combination is meaningless, nonsense. Given that we have the computing power to implement our own scrollbars, how that virtual scrollbar should look like for infinite scrolling? Why?

(Even with 50 as bounty and 15 upvotes, noone has any alternatives?)

Answer 1

So, a few alternatives.

Emulating a "real" scrollbar while maintaining infinite scrolling

Emulation-oriented approach restore the usual scrollbars while still providing infinite scrolling. They're useful if the content actually has a reasonable end.

An image gallery like in the above example is such a thing, while a counter-example would be 9gag's "Vote" section - I'm sure it doesn't have a definitive end...

Row-oriented approach

First off, the above solution of G+ is bad. You can easily calculate the total size of the page from limited metadata. You need:

• the width and height of the window
• the height of one image (it's constant)
• the width of all images as they appear (a series of numbers, like, 480, 480, 640, 480...) in general case, the number of rows in this special case (did you notice that it's justified?)
• index of the topmost row you're seeing

If you know the height of one row, it's easy:

Basically the "physical length" of your scrollbar is:

height of one image * number of rows

But its display equals to window height. Therefore a single row of images is represented by:

single row = height of window / number of rows

How much does a scroll represent? It depends how much rows are displayed.

nr of rows on the screen = height of window / height of one image

therefore, the size of your scroll is:

scroll size = single row * nr of rows on the screen = 
              (height of window)^2 / (height of one image * number of rows)

and the size of your offset for the scroll is always:

scroll offset = (index of topmost row / nr of rows) * window height

That's a bit of math but you can live with it

Whenever the user scrolls down (by grabbing the scroll), you can calculate which row to start to load, by applying this in inverse, so:

index of topmost row to load = (scroll offset/ window height) * nr of rows

By using this simple math, you could act like a word processor, having a full scrollbar at hand, voila.

Page-oriented approach

If you don't know your rows,perhaps, there's still a trick: you could always load (roughly) the same height of information in one page. Page on web is more-or-less arbitrary, usually it contains 20 elements, but this could be offset by one or two elements without the user noticing it.

The basic math is the same (replace row with page), however, you need to have a grid-oriented page design, and some parts of the application needs to be aware of this grid. Also, you should calculate your own average characters / line, so that the backend is able to count it.

So the backend might do such a calculation:

article size = headline (const.) + sum of margins (const.) + 
               height of text + sum height of images

height of text ~ length of text (in characters) / average characters in a line

And serves you, let's say, 20+-5 results based on what would be closer to the ideal size.

Of course, whenever layout change happens, this method breaks.

Pager-scrollbar

If we don't want to calculate all these, we could still have a "digital" scrollbar: such a scrollbar is in fact a vertical page indicator. It still helps the users to orient themselves within a larger context (the whole document), but it forgets about the actual screen real estate. It moves "digitally", that is, if you drag it, it "snaps" to the next page.

It could be side-implemented with an "in-page" scroll inside, that way, the user is able to navigate both in the larger context of the full application, and the local context of the currently viewed page.

With a scroll-within-scroll solution on a pager-scrollbar, the user is able to quickly navigate both within the larger context of the website and the local context of the loaded pages as well.

This is actually pretty easy to implement: you implement a normal pager, visualize it a bit differently, then when you download a new page from the server, you load it into a single div. jQuery is quick to tell you how large your div is, so:

size of outer scroll = height of window / nr of pages

offset of outer scroll = page number

size of inner scroll = height of window / height of current page

                         offset from top of webpage - (sum of height of loaded pages -1)
offset of inner scroll = _______________________________________________________________
                                               height of current page  

Visually indicating to the user that an infinite scroll is in place

Sometimes, the data is just too long to make a meaningful scrollbar, or we just don't want to deal with actual calculations. Still, I guess we need to give a visual clue that this site has open-ended pages.

A fine example is tumblr: while a single tumblr-user is not quick enough to collect infinite amount of data, the data is long enough.

Please do understand that in this case, there needs to be other kind of navigation as well: timeline-based solutions (pages based on days or so) might do.

The "spring" model

Infinite scrolling always has a "scroll sensitive area": when the scroll sensitive area becomes visible (usually if there's less than a screen's worth of data to be shown), the application starts to load the next page:

Now in fact, we could make this area visual. Those scrollbars who don't have this area at the bottom are "normal" scrollbars, while those who have are inifinite-scroll scrollbars.

A good metaphor would be the spring: Imagine there's a spring at the bottom, and your mousewheel is a kind of force, like gravitation. If you push the spring, it compresses first, but then it tries to expand: this is how pinball launchers work.

A pinball launcher spring could be a good metaphor for the scroll sensitive area

In our case, the force is so great that actually the scroll gets smaller after the jump: this is not entirely an unknown phenomenon: if you eject form a cockpit of a jet fighter, you get a few centimeters shorter. Our spring is really strong :-)

This logic actually might work pretty well, but it needs to be tested.

Blurry scroll

In case we don't want elaborate animations denoting a single, simple metaphor, we could go the easy way: the information we have to tell to the user is that we don't know yet where it ends. There's a "fog", we can't see the end of the road.

A kind of "fog" hides the end of the document. We could denote endlessness by using a blur or gradient

Truly infinite data

Data can be "truly" infinite. I'm using facebook since about 2007. If I scrolled down on my newsfeed down until 2007 (I know it's impossible, it stops after around 10 pages), that would be huge.

Or go to 9gag (don't, if you're at work), and click on "trending" or "vote". That data is "truly" infinite, in the sense that they're dealing with thousands of pictures every single day since about 2005.

Also, while I'm scrolling down, new information may appear on the "top"! 9gag images are posted continuously, but this goes to facebook as well: while I'm browsing downwards, new news could appear.

In these cases scrollbars don't make sense: there's simply no well-defined beginning of the data, nor well-defined end of it. You're watching an endless stream of information. while it might be important to go back a few elements, since the stream itself is endless on both directions, you can't have a grasp of progress within the information.

Also, infinite scrolling would hurt your browser: browsers aren't designed to "forget" data you've already downloaded. Therefore, the browser starts to eat your memory.

It'll run out pretty fast, so the so-called swapping needs to be done (writing non-used parts of memory to harddrive and pretending it is part of the memory), which in case you don't have an SSD harddrive, slows down your system - in case you do have an SSD harddrive, its lifespan is shortened literally by years.

What matters this time?

• the post I'm watching
• the page I'm standing at
• I might remember about, let's say, the last 40-50 posts I've seen today
• How many new items were posted since I started to move / the page where I started.
• where I am chronologically
• where I am compared to where I've started
• how many pages / items did I step.

Also, what matters is linkability. It's pretty annoying that you can't really link a whole page in the middle of an infinite scroll, right?

Therefore, the scrollbar can be replaced by clues.

Simple item navigator

The simplest case is that we differentiate "pages" (for fast navigation) and "items", and we hide the scrollbar:

Whenever the user uses scroll, we change the color of the item navigator to a different one (or blink it), denoting that it's working.

We may denote that it's not the end of the document by using a "fog" (blur or simple gradient) on the bottom of the page.

Single-page scroll

Besides these,we could always have a scrollbar for the currently viewed page only. What happens with the pages before? We hide them. It's not that we remove them from memory (perhaps that's a solution as well), but we could always show them based on the current offset: if the offset reached zero, we're at the end of the next page.

This method is actually modelled after how OS X Preview handles pages.

We'll need a buffer area as well: while we're displaying the end of the current page, we already show the beginning of the current page.

How large this buffer should be? Exactly one-screen-height large!

We load new content into this limited space, so that we could display it. Whenever it reaches the top of the screen, we swap pages.

(See it in large here)

Final thoughts

These were some of the solutions I've thought they could be eligible for answer.

I would have accepted any of these, and I still do accept (in the next 23 hours) for bounty any answer which is similar to these.

While dollbaby was right that we need additional navigations whenever we talk about infinite scroll, I still don't feel it's eligible for a bounty, as scrollbar wise, she still recommended maintaining the status quo.

I think creativity shouldn't stop at maintaining a status quo. As Ford once said, "if I were to ask what people want, they would have said: faster horses"

Some of these solutions are quite mathematical: I don't expect everyone to understand them, and it's sure they're hard to implement, but I hope worth them.

As for easy implementation, blurry end is the simplest.

Yet, none of these are implemented, nor user-tested. I think most of them also depend of your actual need. I tried to provide some contexts on where could they be useful. I hope some day someone will implement them,test them, and report the results back.

In case these examples foster your imagination, you could be still eligible for a bounty. Just provide an example which is not found here.

Answer 2

Where there is a list of content, scrollbars are imperative. Users are being taught to understand scrolling to the end of loaded content & then being able to scroll more after more content is loaded through use of platforms such as twitter and facebook. The scrollbar is no longer necessarily seen an indicator of the length of lists when on a web application.

Scrollbars are a recognised element that allows users to view extended lists of items. For extremely large lists it can be difficult using a scrollbar alone because trying to reach items that are far down the list requires a lot of scrolling.

For extremely large lists, an additional meta-scroll should be provided to the user so that they can jump to a specific part of the list and then use scroll to view items local to that point.

An example of where this works is facebook's timeline - facebook has an 'infinite' scroll, but allows users to jump to specific time periods.

Clarification in response to the question:

"is there a need for a scrollbar in 2012, if there is, how should it look like (including fallbacks) and if there is not, what should come instead? Why, why not?"

My answer is that yes, they are needed. They should not be changed as they are recognised functions. Changing recognised functions impairs usability. For infinite scroll a 'meta scroll' feature should be implemented as per user needs. Further justification below.

Scrollbars are an established method for browsing large amounts of content. Removing them is irresponsible and reckless. Changing it so that it either behaves differently or looks too different that its unrecognisable is also irresponsible and reckless. Google's jscript scrollbar is OK as it looks similar and behaves similarly to a regular scrollbar.

A pattern has already been established for infinite scroll within the context you are talking about (ie social) - users browse down to the bottom of loaded content and wait to load more. Users have learned this pattern and it does not impede usability.

This works fine for users' needs because users only usually want to see local and recent content - they are not looking for something specific. They also do not care about viewing all 3000 photos.

The only exception is when they want to view local content specific to some time period in the past - which makes infinite scrolling difficult. This is why a meta scroll is useful, such as facebook's feature that lets you jump to specific time periods within a user's timeline. **This is simply a set of links within the content area that allow users to 'jump' to various locations within the large set of content.

For scenarios where users might want to find specific content based on metadata such as category, date, tags etc you could provide a filter option, a sort option or a search option. The use of these features depends on the content and users. Eg. you might instate this for flickr, but not for g+. Both fit in the context of your question.

Creating a new way of browsing this content would mean a new interface that users would have to learn how to use. Avoid this at all costs. Draw on existing mental models to create features that are intuitive, ie. use functionality that is established.

Answer 3

Sausage.js provides a interesting pattern that may solve the usability issues of infinite scroll in relation to the scrollbar. Similar to your "pager-scrollbar" example - it creates a "sausage" for each section of a page which links to that section. The regular scrollbar is still present.

For an infinite scrolling page, instead of the sausages representing page sections, a sausage could be created every time a new batch of content is ajaxed in. This would allow quick access to all sections of the ever-growing "page".

You'll have to experience the demo to see the sausages in tandem with the scrollbar.

Though this does not answer the question of "does the scrollbar still make sense", it provides a meaningful alternative in the infinite scroll context. The regular scrollbar could still function like your pinball lever example - we are still in the web browser, so I'm not too sure that getting rid of it would be wise.

Answer 4

I think the standard scrollbar satisfies the most common user task, which is scrolling through the content that has already been downloaded.

For cases where the user may wish to scroll much further down the list (in the case of Facebook, further back in time), I could envision a scrollbar that works just like the standard scrollbar except with the addition of start and stop "range bugs" that you can move up and down to indicate the content you'd like to scroll through.

The mockup below shows an example for a page that is showing content organized over a long period of time (again, as with Facebook). This could also work with content organized by name, number, or some other useful category.

^{download bmml source – Wireframes created with Balsamiq Mockups}

An important aspect of this design should be to maintain the "download on demand" aspect of the page. Obviously, if you try to download three years of content at once, the user will be waiting a long time. Hence, the page should be mostly blank and content should only fill in when the part of the page where that content would go is revealed. The faster this process can occur, the more seamless the UX, but that's dependent on bandwidth, server and query performance, database indexing, etc.

Answer 5

I think it makes sense the scroll bar being showed, because the user can see where they are between the content they saw, and the content downloaded on demand.

Even the content being infinite, the scroll bar can be used to the user navigate to the top or middle, or too look for some content he saw.

Answer 6

Yes for me scroll bar is still useful. But now, the scroll bar needs more functionality: Its should have marker indicators. I have explained my understanding of advanced scroll bars over here: https://ux.stackexchange.com/a/25127/17466