Journal tags: stream



Home stream

Ben wrote a post a little while back about maybe organising his home page differently. It’s currently a stream.

That prompted Om to ask is “stream” as a design paradigm over? Mind you, he’s not talking about personal websites:

Across the web, one can see “streams” losing their preeminence. Social networks are increasingly algorithmically organized, so their stream isn’t really a free-flowing stream. It is more like a river that has been heavily dammed. It is organized around what the machine thinks we need to see based on what we have seen in the past.

Funnily enough, I’ve some recent examples of personal homepages become more like social networks, at least in terms of visual design. A lot of people I know are liking the recent redesigns from Adam and Jhey.

Here on my site, my home page is kind of a stream. I’ve got notes, links, and blog posts one after another in chronological order. The other sections of my site are ways of focusing in on the specific types of content links, short notes, blog posts in my journal.

Behind the scenes, entries those separate sections of my site are all stored in the same database table. In some ways, the separation into different sections of the site is more like tagging. So the home page is actually the simplest bit to implement: grab the latest 20 entries out of that database table.

I don’t make too much visual distinction between the different kinds of posts. My links and my notes look quite similar. And if I post a lot of commentary with a link, it looks a lot like a blog post.

Maybe I should make them more distinct, visually. Because I actually like the higgedly-piggedly nature of a stream of different kinds of stuff. I want the vibe to be less like a pristine Apple store, and more like a chaotic second-hand bookstore.

Going back to what Ben wrote about his site:

As of right now, the homepage is a mix of long-form posts, short thoughts, and links I consider interesting, presented as a stream. It’s a genuine representation of what I’m reading and thinking about, and each post’s permalink page looks fine to me, but it doesn’t quite hold together as a whole. If you look at my homepage with fresh eyes, my stream is a hodgepodge. There’s no through line.

For me, that’s a feature, not a bug. There’s no through line on my home page either. I like that.

Scrollin’, scrollin’, scrollin’

A few weeks ago, when I changed how the front page of this site works, I wrote about “streams”, infinite scrolling, and the back button:

Anyway, you’ll notice that the new home page of 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).

That’s exactly what Kyle Kneath is trying to solve with this nifty experiment with infinite scroll and the HTML5 History API. I should investigate this further. Although, like I said in my post, I would probably replace automatic infinite scrolling with an explicit user-initiated action:

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.

Kyle’s code is available from GitHub (of course). As written, it relies on some library support—like jQuery—but with a little bit of tweaking, I’m sure it could be rewritten to remove any dependencies (hint, hint, lazy web).

URIslands in the stream

For over a decade the home page of this website has effectively been a splash screen.

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 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 /newest?page=2 or /popular?start=10 than you are to see /newest/page2 or /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:

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 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.


I tend to compulsively sign up to just about every new web-based tool or social networking site that comes along. Most of my accounts then languish unused because the service turns out to suck in a fairly fundamental manner.

I signed up for Tumblr a while back. On the face of it, it doesn’t really have anything new to offer; it’s basically just a blogging tool but one designed for micro-content rather than long posts. But there’s something about it that’s—forgive the nineties term—sticky.

Tumblr allows you to pull in feeds from other places. At first, this is what I did but I realised that there wasn’t much point in that because I already have a lifestream. The lifestream aspect of Tumblr just made it harder to filter the Tumblr-specific content. Jaiku does a better job of that, allowing not just the author, but also the reader, to filter content by source.

I don’t use Tumblr for posting links—I’ve got for that. And I don’t use it for photos—that’s what Flickr is for. So I focus on the things that Tumblr is particularly good at handling: videos and quotes.

The Tumblr bookmarklet is pretty clever. If I click it when I’m on YouTube, it guesses that I probably want to post that video. If I highlight some text on a page and then click the bookmarklet, the selected text will be added as a quote. Most importantly of all, the process of posting is very fast and unobtrusive; one or two clicks and I’m done. That means there’s no tagging, which might make refindability difficult, but the speed and ease of posting makes me more likely to click that bookmarklet.

Tumblr has a kind of casual throwaway feel to it and that’s how I’ve been using it: videos and quotes that don’t quite warrant a blog post or a link. Tumblr isn’t the most fully-featured service out there but that’s also its strength. If you’re interested, you can look at my Tumblr account.

Watching the stream

Ever since I hacked up my little life stream experiment and wrote about it, it’s been very gratifying to see how people have taken the idea and run with it. Emily Chang has written about the resources she came across when she was putting her life stream together. Sam Sethi has been talking about life streams as a rich vein of attention data (which reminded me of John Allsopp’s thoughts on why blogging as we know it is over).

Of course this idea of mashing up time-stamped (micro)content—usually through RSS—isn’t anything new. Tom Armitage touched on this during his presentation at Reboot in Copenhagen last year:

Whenever I publish anything with a date attached, there’s a framework for ongoing narrative. The item published is our narrative, but the date gives it ongoingness. It takes time for the pattern to emerge; initially, throwing data at that black box, it seems random. For instance: I upload photos to Flickr at arbitrary intervals. I go silent on my blog without explanation. It may seem, in the short-term, like a blip, but in the long-term, it’s an important part of my story. My blog is full of delicious bookmarks right now because I’ve been busy at work, and writing this talk. That’ll be reflected in the longer game, when I write my post-Reboot blog entry, and suddenly the pattern becomes clear.

If you haven’t yet done so, I strongly urge you to read the rest of Telling Stories — What Homer, Dickens, and Comic Books can teach your (social) software. It’s quite brilliant and discusses many issues that are even more relevant today with the rise of OpenID and the clamour for portable social networks.

Jeff Croft has been pioneering the life stream idea for quite a while now, originally calling it a tumblelog. His implementation uses APIs rather than plain ol’ RSS. He’s right in thinking that APIs are a more robust solution for long-term archiving but I think of my life stream as being a fleeting snapshot of current activity.

As Jeff points out:

The result is that most people’s lifestream looks great for the first several days back, but then get all sparse at the bottom, where only one or two sources are still providing information.

CSS to the rescue. I’ve updated my life stream to give vibrant colours to newer entries and faded, eventually illegible colours to older, less relevant content. It’s kind of like Shaun’s recent experiments with age and colour.

I love APIs but when something as simple as RSS does the job, I’ll go for the simple solution every time (hence my love of microformats). In fact, I see RSS as being a kind of low-level short-term API or, as Rob Purdie put it, the vaseline of Web 2.0.

The ubiquity of RSS is what makes Yahoo Pipes possible. Now anybody can make a life stream by plugging in some RSS feeds into a pipe. Here’s one I made earlier. When I tried to do this a few days ago, I couldn’t get it to sort by date properly: it was sorting the pubDate field alphabetically—that seems to be fixed now.

Using Yahoo Pipes isn’t quite as straightforward as it could be. It still feels kind of techy and intimidating for non-geeks. This is the same problem that Ning used to have. Its services were ostensibly being provided so that non-techy people could start mashing stuff up but the presentation was impenetrably techy. That’s all changed now.

Ning has completely rebranded as a social network builder. Personally, I think this is a brilliant move. After just a few seconds on the front page, it’s absolutely clear what you can do. By providing example sites, they make the point even clearer. You can still make all the same stuff that you always could on Ning—videos, photos, blogs—but now it’s all wrapped up as part of a clearer goal: creating your own social network site.

When Yahoo Pipes launched, it looked like it might be competing directly with Ning. Now that’s not the case. The two services have diverged and are concentrating on different tasks for different audiences.

I’ll be keeping an eye on Ning to see how it deals with the issue of portable social networks. I’ll be watching Yahoo Pipes as a tool for creating life streams.