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, 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, Bloglines, Reddit, Facebook, and Tron09. 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. 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 the browser, 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.