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...
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.
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.
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.
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 continously, 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.
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)
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.