The history and bookmarks features of web browsers have traditionally been separate. Which is strange, since they’re conceptually similar. Each is a title and a link. One represents a place *you’ve already been*, and the other represents a place *you intend to visit in the future*.

For me, they’re also similar in that I don’t really use either of them. At all. Between Google searches and location bar type-ahead, I’m always able to retrace my steps to something I remember seeing. To manually maintain a bookmarks list would be like manually maintaining a contact list in my email—why do it by hand, when Gmail can simply remember everyone I’ve ever corresponded with, and then guess who I mean as I start typing their name in the to-field?

Mozilla have recognized that power users ignore the two features, and have also seen their fundamental similarity. Firefox 3 will introduce a unified feature called [Places](http://wiki.mozilla.org/Places), which attempts to bring a more sensible and usable interface to the browser.

I’ve been thinking about this problem for a number of months, however, and I don’t think Places goes far enough. I’d like to propose not only a unification of history with bookmarks, but a complete integration of that unified feature with browser tabs.

### Tabs as Queues

In my day-to-day browsing, each session begins with a small number of primary hubs. For me, these are [Google](http://google.com), [Bloglines](http://bloglines.com), [Reddit](http://reddit.com), [Facebook](http://facebook.com), and [Tron09](http://tron09.com). On each of those sites, I click many links that take me elsewhere on the net. For some of those links, I may finish the page and close it; for others, I may open a number of new links from them, and continue to explore elsewhere, especially if it’s somewhere like another blog or Wikipedia.

This is not linear browsing. This is a network of pages expanding outward from central nodes. To try to force this into a series of parallel tabs is frustrating and inaccurate. In data structures terminology, my browsing pattern is a [depth-first traversal](http://en.wikipedia.org/wiki/Depth-first_search). I drill down to the bottom of my current train of thought, and when this is exhausted, I back up and explore a new branch.

The mechanics of it are not difficult; I simply queue up the pages I mean to read in the tabs across the top of my browser, and then iterate over them one at a time. But using tabs in this way is awkward and hackish, for several reasons.

### The Trouble with Tabs

Implementing a depth-first search using tabs as they are in Firefox is cumbersome. In ascending order of importance:

* Each tab has a memory cost. Some–the ones that use AJAX to update themselves behind your back–have a processor and network cost, too. Firefox has enough memory problems as it is, without loading up 20+ tabs that just sit there.
* You can only put new tabs at the far-right of the queue, instead of the immediate right of the current tab. IE7 behaves in the opposite way, but neither is fully appropriate, and the mere ability to re-order tabs is not a full solution.
* You can’t see them all at once. Even with the hacks that let you squeeze more tabs into that limited horizontal space, it’s not enough. Once I have to roll my mousewheel to view more tabs, I’m frustrated.
* New tabs have no parentage. There are extensions that copy history between tab spawns, but this is not enough. I don’t just want to know that I got to a given article through reddit, I want to know *which reddit tab* I was using. This is important, because I might have been scrolled to a particular part of a comment page at the time, maybe even with a half-finished comment I’d like to complete.

Each of these problems has obvious solutions to it; when the solutions are compiled into the same project, an interesting new view of browsing emerges.

### The Four Pieces

**Vertical Tabs.** There are a number of CSS hacks out there that do this, but it’s time it came of age in a proper plugin. Screens are getting wider faster than they are taller; it’s absurd to consume precious vertical space when a strip on the right side would serve just as well. The tab strip should be vertical.

**Party-Shuffle Tabs.** In iTunes, there’s a special playlist called *Party Shuffle*. You can queue items up in it, and eventually they play, but it’s a completely transient state. I believe the “tab” bar should be the same way. Make the current tab always one third of the way down the screen, put everything I haven’t yet viewed *below* the current tab, and put everything I have yet to view *above* it. Unviewed tabs are like tiny bookmarks, and already-viewed tabs are like quick history. If there’s something in the “already viewed” section that I know I’d like to see again, I can easily promote it back to the end of the “not yet viewed” queue.

**Smart Loading and Persistence.** If I already have twenty pages queued up to look at, why waste RAM downloading another page that I may not see for five or ten minutes? And if I’ve already done with a tab, why not unload it for me, without me explicitly having to close it? The default is for me to be done; if I want otherwise, I can send it back to the end of the to-read queue. Or, alternatively, flag it with the same do-not-unload-me behaviour that should be applied to JavaScript-heavy web applications.

**Better Inter-tab Relationships.** It should be possible to find the exact page that led to the page in the current tab. This falls under the general domain of back-button behaviour, but I think again the implementation could be simplified. When the back-button is activated, jump to the tab that opened this tab, or if it’s not there any more, *open a new tab with the page in it, at the head of the view queue*.

### Conclusions

I haven’t had the time or energy to play with an actual implementation of these ideas, but I wanted to get them out there. Lots of people have talked about ways to [change](http://www.flock.com/) the [browser](http://worrydream.com/Scrolltabs/), but there seems to be very little in the realm of actually breaking the back/forward mechanism of browsing.

I’d be curious to hear any thoughts on these ideas, or any pointers to projects that have attempted more radical changes to browser functionality.

Mike

← Earlier Later → Posted at 9:24 pm to Geekery.