Today I had a fun lunch with Web developers at Shift (not all of whom work there). It was a follow-up on a short discussion at Kiwi Foo about columns on the Web. My goal was to brainstorm with some Web developers/graphic designers/user experience people about ways to display lots of text on large screens, and in particular to tackle the difficult problem of what to do when the text can't all fit.
We talked through various options. There was quite a lot of interest in using fixed-height columns and adding columns horizontally for overflowing content, and having users scroll horizontally to see the content. This is pretty well supported by the CSS3 columns spec and the Gecko implementation, although to make it more useful we'd have to work on horizontal scrolling UI and implement viewport units so an element's height can be related to the window size.
There was also quite a lot of interest in using fixed-height columns but adding overflowing columns vertically below the first set of columns, giving the effect of a set of pages laid out top to bottom. This is currently not supported by the spec or our implementation, although it wouldn't be too hard to add. This would require more UI work, to make it easy to scroll up or down by exactly the height of one of these pages. Continuous scrolling mechanisms like mousewheels would be hard to integrate.
Either of those approaches could be modified to try to avoid scrollbars and instead offer a UI based on pagination --- "next page", "previous page" buttons or even "next column", "previous column".
Another idea that Ross Howard raised, one I hadn't thought about, is to have scrolling actually happen *within* columns. So there's a fixed number of columns of fixed height; if content overflows, then initially it's not visible beyond the last column. But there's a UI "scroll down" action which removes content from the first column and pulls the rest of the content "up" through the columns to fit.
A good point that was raised during these discussions is that smooth scrolling is important to help users not lose their place during scrolling. It's not clear how that would work with the scroll-within-columns idea, though, since moving content within columns has to change the layout at column boundaries to choose tasteful column break positions.
It would be cool to provide support for a variety of options, but I need to think about the right syntax for expressing them and how hard various options would be to implement. Adding support for viewport units would be useful yet relatively easy (a brand-new volunteer, Keith Rarick, implemented 'rem' units recently). Adding some kind of "series of pages" feature would have many uses and wouldn't be too hard to implement, it's a lot like columns that stack vertically instead of horizontally. On the other hand the "scroll within columns" feature needs a lot more thought. The scrolling UI issues need more thought too.
One person asked me why I was interested in this problem. Partly it's because Web developers want a solution. Partly it's because screens have been getting bigger, on the desktop anyway, and letting users use them effectively is serves users better. It's also partly because proprietary platforms like Flash and WPF have some of these features and the open Web needs to keep up.
We had side discussions about fonts, typography and analytics. These Web developers would really love some data about how certain browser commands are used by visitors to their sites.
Thanks to Ross and co for a fun and helpful discussion, and the pizza!