Date

(Note: this article talks about ThNdl v1.0. You are now reading v2.0 which, sadly, doesn't have side scrolling)

Many of you are probably reading this on a device that looks something like this.

The "tall thin slab full of screen" form factor for phones seems to be becoming the norm as we move away from hardware keys. The biggest variable these days seems to be size, which is quite proportional to price.

Others of you will have a bigger device - some kind of tablet - looking something like this.

The common factor with these two classes of device is probably that they have large capacitive touch screens, and no keyboard.

A few years ago when people started to seriously try and use the web from devices other than PCs, sites were all "Best Viewed at 1024x768" or even "800x600".

Squeezing those sites onto small portrait-first screens was a challenge for mobile browsers. Zooming in to make text readable often gave columns that were too wide to fit, and panning round to find everything was a frustrating experience.

This was solved eventually by the emergence of special layouts and sites for mobile devices, that squeezed the site to one screen width of readable text, and as many pages high as needed to show everything. Now that paradigm already seems ubiquitous.

But during that shift, we forgot a dimension. Now we are all happily flicking up and down, going forwards and backwards through our giant articles and lists. But what about the x dimension - left and right?

When I started thinking about how ThNdl could look and be used on a portrait touchscreen phone, I wanted to find a way for effortless navigation both within and between articles.

I wanted to avoid the need for you to have to find some button to press to change article. And I wanted to avoid something involving layers of content that moved independantly, because making that kind of design work everywhere with good performance is a challenge.

While exploring the options, I found out support for CSS columns already seems to be widespread in most current browsers. That allows you to display items split over a specified number of columns, like this::

div{
-column-count: 2;
}

The resulting item will be as high as needed to show all the content. Unfortunately however, splitting a long article like that makes things worse. Now when you get to the bottom of the first column, you need to scroll all the way back up to the top and right to continue reading.

However, CSS columns can also be set to automatically add as many columns as needed to display all the content. All you have to do is specify the height. And of course the height to use on a mobile device should be the screen height, so that now you only need to scroll right to continue reading.

As long as the columns are taller than wider, this is <i>theoretically</i> easier to use than the single column view, because you have to scroll a shorter distance to get the next lump of new text fully visible.

And when column support isn't available (cough*IE*cough), it falls back gracefully to a single column.

So columns seemed viable for articles, and also quite natural since people have been reading articles that way on paper for a long time. The x dimension was claimed for navigating within articles. That left the y dimension - up and down - free for browsing between articles, with just one screen-height of scrolling needed.

With the articles all aligned at the left, a quick flick left should take the reader quickly from the end of an article back to column containing the start or all articles - much more quickly than doing that same in a single vertical column.

Conceptually it looked something like this.

So much for the neat theory... as always, the practical reality quickly gets messy and complicated.

With some javascript to deal with the usual browser differences, a resizing function got the basics in place. On a portrait phone screen you see one screen height column. Panning right takes you to the next column.

On larger screens, the resizing tries to avoid too wide or too thin columns, and chooses either 2 or 3. For instance, on an iPad you should see 2 columns in portrait, and 3 in landscape.

The resize gets triggered by a window resize, which happens on an orientation change in most environments.

Now, text is quite breakable - it doesn't mind too much what column it's in. But images are a different story. The CSS column model can be persuaded to try not to break items in the middle, which works on some more recent browsers. But it leaves a big gap.

If the column height gets smaller than the biggest image, then all bets are off, and the images will get broken in an ugly way.

Unfortunately, landscape phone screens turn out to be the case where the screen height is very squeezed due to system and (in Chrome's case) browser UI taking up space at the top.

Another problem was the breaks between articles. When the CSS model expands columns, it doesn't seem to give you a way to find out how many columns it actually made, or how wide the result really is. So the breaks were either too wide or too thin. I had to workaround that by checking different values in different browsers.

What about usability? One big advantage of normal one dimensional scrolling is that you can be very sloppy when flicking - it only moves up or down anyway. But when the page is wider than the screen, sloppy flicking takes you away from the article. Mobile Safari tries to constrain to either horizontal or vertical scrolling, which helps, but it stays stuck in one mode until scrolling stops which can be annoying.

And then there is the good old desktop. Mac users and some PC touchpad users have it ok with horizontal and vertical two-finger scroll gestures, but in other places horizontal scrolling is a pain. Dragging scroll bars with a mouse pointer is also a bit hopeless.

Keyboard scrolling works, but it's often jerky, and with speed based on key repeat intervals. And there is no Page-Left, Page-Right key to help (which is a bit odd when you think about pages in books!).

I tried Javascript tricks liks snapping from onscroll after a little while, or overriding cursor keys, but so far they have always hit compatibility problems in different places

Regarding Javascript, ThNdl web site is currently "App like" - which means the code you first get from the server contains none of the articles - they are fetched afterwards with Javascript. So, no JS, no articles - it turns out that's a problem for some users, and other sites showing summaries (like LinkedIn).

So, what next? Well, I introduced a full-content RSS feed as an alternative (1D, no JS) way to read, because many people just don't want to have to read with a browser, full stop.

The landscape phone layout has been tweaked to use a smaller font which should improve it. And I'm going to see if I can do something to help desktop/mouse/keyboard usability - for instance some keyboard shortcuts. After that, we'll see.

But I'm not too keen to have to learn to forget that x dimension again.