The importance of paging

Something the iPhone brought us was amazing scrolling. I’m not a fan of the pinch-zoom, but the flick-to-scroll has been an outstanding innovation. Macbook users will know about the two-finger scroll (which still sounds somewhat riské). We got hooked on scrolling long before that of course, when the wheel on the mouse came out.

Before the mouse wheel we worried about page folds. Would the naive mums trying Netscape 4 for the first time understand that there was more information there, just out of sight? Jakob Nielsen and his army of acolytes made you employ a usability expert to blow your budget stressing over the issue.

Scrolling is a non-issue now. Vertically, I mean. Horizontal scrolling is right out. It’s a no-go, confined to designers’ CVs to show just how radical and out-of-the-box they can imagine.

Paging is another issue. Frankly it’s a bitch. Why should I wait for a page reload, when I can flicky-scroll? Newspapers do it to make sure you’re seeing enough adverts. Tutorials do it to make sure you’re not overwhelmed by learning more than one thing at once. And we hate it. It sucks.

But now the iPad is on the scene. That changes things a bit.

The iPad has a fixed screen resolution for us. And the screen is sufficiently bigger than the iPod for us to start thinking that columns might be necessary. The New York Times has their application on there. Columns and pages.

Columns are useless without paging. Who wants to read all the way down (scroll, scroll, scroll), then have to go all the way back tot he top to continue reading? Paging and columns go hand-in-hand.

A horizontal scroll is still nasty, but maybe there’s a place for paging now. Not page-reloading. But nice, simple paging. Flicking through a paperback is still the best search function. If the iPad Safari lets us have the nice paging function that other apps use, our web apps will be awesomely integrated*.

So how about it? A spot of new CSS and a old-school page transition, for the new world of iPad.

CSS3 has columns, but no paging. We need both, and we need it soon. It could be the new flicky-scroll.

Until then of course, you can just play with my new js-columns newspaper columns plugin.

* One could argue that in fact Apple intentionally do not encourage web apps, because they’d rather lock developers into their app environment. Why else would the accelerometer still be inaccessible from JavaScript? Why else wouldn’t bookmarks appear in your home screens? Not being cynical. Just saying.

The App Store

I was amused by a comment I overheard in the office last week, just after the announcement of the iPad. It went something like this:

People will buy the iPad instead of a MacBook because the iPad has Applications.

My initial reaction was “how daft”. A laptop running MacOSX, or Windows, has access to billions of application, built through the ages. It’s ridiculous to think that there could be more applications available to a souped-up mobile phone.

But it immediately struck me that he had a point. Shareware died in the land of sophisticated web browsers, and the proliferation of viruses and spamware. Thinking back, they were awful. “Proper” software, like Office or Photoshop is priced beyond the realm of individuals.

Really, I can’t believe that we missed it for so long. What people wanted was a safe, reliable, place where they could spend pocket money on little apps that were beautifully built. They found it in the App store. And you know what? I think Apple underestimated it too. Otherwise there would be an App Store for MacBooks.

  • So there’s a review process, hated by developers. But equally, there’s no spamware.
  • There’s no multi-tasking. But equally, there’s no battery intensive, memory-hogging, background-running daemons.
  • Apps costs money. But Apple already has your card details from signing you up to iTunes. They had a micro-payments model, beating Facebook and Paypal (whose customers have been begging for one) by miles. £1.50? That’s only half a pint these days. No problem.

In the land of the laptop, the only competitor (excluding webapps and shareware), is the widgets. We have widgets for weather, clocks, telling the time, calendars, weather forecasts, clocks, and the weather. Handy.

It’s here that I’d like to see the App Store. Why can’t I drop an iPhone app onto my dashboard (or sidebar)?

The iWork for iPad apps are $10 each and will be available at the iTunes App Store.


It’s not often I write a blog post just about a new tech.  For good reason:  there’s always someone out there prepared to dedicate a bit of time to a full tutorial on implementation, pros and cons.

I’d just like to mention Typekit because it’s not what I thought it was, and I’m quite impressed with what it is.

I’d assumed Typekit was a solution to the technological problem of including new fonts on webpages.  Along similar lines to Cufon and sIFR.

For those who don’t know, including fonts is a problem because modern browsers haven’t agreed on a way to distribute fonts with web pages.  IE, oddly, had this solved ages ago, but since MS is so unfashionable at present, it has been largely ignored.

Cufon lets you use a new font by replacing text with little <canvas> image elements.  Ingenious, but quite silly as you have to create loads of these little elements on the fly.  SIFR does the same thing, but using Flash.  Indeed, we once used sIFR for the Cannes Film Festival website.  I remember a very long page-render time…

I’d assumed Typekit was going to be similar. Basically, I’m wrong.

Typekit is a solution for font licensing. It’s always been a pain to get the right licenses for fonts. Often the licenses you buy are both extortionately priced and not licensed to web distribution. (This is because the way you provide a font to a web page is easily hijacked, and the font can be stolen).

Typekit provides access to their sensibly-sized library of fonts on a variety of subscription schemes. Once signed up, including the fonts is a simple matter of a few lines of JavaScript.

Technically, Typekit uses the @font-face download rules. This means it supports a limited number of browsers. But it also supports IE, using the EOT font format (IE’s system attempts to prevent hijacking of fonts too). So it’s not bad.

Downsides are that the iPhone is not supported, as mobile Safari doesn’t seem to support @font-face. Of course, the non-JavaScript browsers out there don’t see the new fonts (but they’ve asked for a lesser experience, so who cares). Also, there can be a FOUC (Flash of Unstyled Content) as the page loads the first time.

Once request I’d make to the Typekit team is the ability to support two sites on the Tester pack. One for my simple blog, one for active development. I know you want me to pay, but my commitment to fonts for personal use is not so great, and since you add your logo, it’s only an advert for yourselves anyway isn’t it.

In summary, I think it’s a great idea. I see Typekit as the Spotify of fonts.