Massless

Pegs, an experiment in page layout and interaction.

Now that I'm thinking harder about page consumption again, I wanted to surface an old experiment from when I was working on Reader. I'm wondering if a better-executed version of this concept could be useful in an era where site navigation and ads are too easily scrolled off-page? (e.g. IMDB, especially)

It seems worth reconsidering ways to optimize content, nowadays.

Demo

The experiment looks like a normal page until the scrollbar is used. Content areas scroll only as high or low as their content.

Try out "pegs" by visiting the demo and scrolling up and down.

ex. Screenshot of demo and concept. Two columns, left column doesn't scroll if small enough.


It's a little...odd. Can't tell if I like using it yet. Needs a trial with real content.

Caveats: It's an early work, still. Watch out for bugs.

How this began

Updated this story because I got it wrong. Crud. Better minds and archived emails now help show the important details I should have included.

All of us working on Google Reader were looking into ways of making navigation and selection state more visually appealing. Mihai Parparita, tech lead of Reader's frontend, suggested we should have two scrolling areas for navigation and viewing but everyone wanted to figure out a better way than to have multiple scrollbars on a page.

It seemed sad that one scrollbar would interrupt selection state by being placed in the middle. I began work on a demo where the scroll bar would be hidden or at least minimized in some way. I wondered if it could work like the way a differential would work in a car. I began experimenting with just controlling both areas with the scrollwheel in one area only. (In my earlier post, I said I'd thought I'd written my "differential scrolling" notes and script after the left-hand-scrollbar experiment. Nope. That came before, it turns out.)

Kevin Fox (who works now at FriendFeed, don'tcha know), also wanted a better way to scroll. While designing things for Reader, and based on other products he'd been working on (e.g. Calendar), he began considering controlling both areas with the scrollbar in one area only. Kevin and I both came up with early implementations of scroll management. (I should've remembered this - my apologies to Kevin - I'm adding it here so that people know that Reader's awesomeness and experimentation has had many sources.) My experiment used an internal scrolling element to control two areas via a fixed area and a header, Kevin's had a single scrollbar over the whole page with no header. Both were incredibly similar as each area scrolled independently of the other.

I'm pretty sure Kevin came up with the name "Pegs", though we're not sure. :)

Kevin's experiment clearly influenced the development of mine. Right after seeing his, I broke out of thinking in terms of an interior set of elements whose scrolling was determined by a master source, and changed my demo to have the master source be at the document level. Much more interesting. Thank you, Kevin.

At the same Nick Baum (among others) had an idea that any "pegged" approach could be smarter about how it managed the other bar, namely that some logic to when each column would scroll should be length-based. This was a huge improvement.

Days later, during a internal launch road map thread, it was Kevin who first mentioned that having the "Scroll bar on the left is a really interesting idea. <div dir="rtl"> :)" and since that sounded intriguing (and given I'd already finished my scroll-managing object that could do this, too) I made a demo of the left-hand-side insanity and sent it for feedback.

ex. Screenshot of the crazy left-hand version.


Whoops. Everyone agreed: It felt weird and alien to use. (Including Kevin and I.) I went back and modified my original demo with improved logic for scrolling. But we'd moved on... only later did I begin to improve the "Pegs" approach for general use.

posted at December 08, 2008, 6:23 PM