For over a decade the home page of this website has effectively been a splash screen.
A splash screen! The only person with a splash screen these days is— Drew McLellan (@drewm) July 27, 2010
Well …not exactly. I mean, it’s not as if it contained an animation and a “skip intro” link. But it has been very minimalist: a brief one-sentence explanation of what this website is and a brief one-sentence description of the latest post I’ve published.
Most blogs are standalone sites—i.e. the blog isn’t part of a larger site—so the home page and the latest blog posts are one and the same. My site is a bit different. The blog part—my journal—is just one piece. There’s also the links section and the articles section. That raises an interesting question: exactly what should the homepage contain?
I’m a great believer in well-designed URLs but oftentimes the home page is something of an exception (one of the reasons I advocate designing the home page last). The URL
/ doesn’t tell you anything about the resource. There’s basically two different ways to go: keep it really, really minimal (like I’ve been doing for ten years) or make it a patchwork containing a little bit of everything (the way that most news websites work).
For the past few months I’ve been contemplating making the switch from the minimalist to the maximalist approach for the home page of this site. On the one hand, I think it’s RESTfully correct to have the URL
adactio.com/ return a terse description of what the site is, with links to further resources. On the other hand …it’s a splash screen.
After much deliberation, I’ve decided to flip the switch.
It’s a bit of a shame. I quite enjoyed being one of the last people I know to have a quirky intro page. But the new home page alleviates a concern I’ve had for a while. I get the feeling that a lot of people have only been paying attention to what’s written in my journal without realising that I post multiple times a day to the links section. The new homepage shows everything—journal entries, links, and articles—grouped by date. It is, if you like, a stream.
It’s exactly the kind of stream that Anil Dash writes about in Stop Publishing Web Pages:
Most users on the web spend most of their time in apps. The most popular of those apps, like Facebook, Twitter, Gmail, Tumblr and others, are primarily focused on a single, simple stream that offers a river of news which users can easily scroll through, skim over, and click on to read in more depth.
Glossing over the lack of definition for “app”, there’s a good point here. The “stream” idea makes a lot of sense …in the right situation. That situation is the list view. If you think about the situations where the never-ending stream has been employed—Twitter, Facebook, Instagram, Pinterest—they are views of lists, usually reverse-chronologically ordered lists.
Going back to URL design, these kinds of list views are the ones that often have a single URL filtered with a query string. You’re much more likely to see
/popular?start=10 than you are to see
/popular/10-20. There’s a good reason for that. While the kind of resource located at the URL remains unchanged—a list of items—the specifics are likely to change every day or hour or even minute—which items are in the list.
So traditionally list views have been paginated using query strings. The streams that Anil is talking about are an alternate way of navigating list views that does away with pagination and query strings. I think that this way of navigating a list view can work well but, as always, the devil is in the details.
First of all, there’s the issue of when to append to the stream. This could be triggered by the user with a link—“load more”—or you could assume that when the user gets to the current end of the list that they’ll automatically want to load more …the dreaded infinite scroll.
As Frank put it:
Infinite scroll is so frustrating for me. It turns every website into a battle I can’t win. There’s no finishing, only forfeit.— Frank Chimero (@frankchimero) July 11, 2012
Quite apart from any psychological implications, there’s a usability issue here. Interpreting one action by a user—scrolling down the screen—as implicit permission to carry out another action—load more items—is a dangerous assumption. It’s similar to the tyranny of mouseover:
If I click on a link, I am initiating an action. If I fill in a form and press a submit button, I am initiating an action. But if I move my mouse over a page element, I am not initiating an action.
Oh, and if your site has footer, please do not use infinite scroll. Think about it.
In case you hadn’t guessed, I’m a big proponent of allowing the user to explicitly request more items to be appended to a stream rather than using the infinite-scroll pattern.
That said, you could introduce a nice compromise. What if, when the user scrolls down the screen, you begin pre-fetching the next items in the list? That way, when the user explicitly requests more items they’ll load lickety-split.
Anyway, you’ll notice that the new home page of adactio.com is still using pagination. That’s related to another issue and I suspect that this is the same reason that we haven’t seen search engines like Google introduce stream-like behaviour instead of pagination for search results: what happens when you’ve left a stream but you use the browser’s back button to return to it?
In all likelihood you won’t be returned to the same spot in the stream that were in before. Instead you’re more likely to be dumped back at the default list view (the first ten or twenty items).
If your stream is self-contained—like Instagram or Pinterest—then there’s no problem. Twitter attempts to get around the problem by showing you the linked content inline where possible (with some judicious use of oEmbed) and by opening external links in a new window or tab—not so much the cure that kills the patient as the cure that ignores the problem.
In my case, my home page stream is crammed full of hyperlinks. Until there’s a way to make unpaginated streams work nicely with the back button, I’ll stick with pagination.
Anyway, I hope you like the new home page. If you do, you may want to subscribe to the RSS equivalent of the combined stream of my journal, my links, and my articles.