(f)utility

9th June 2009

Text with 1 note

Cartographer

Ever since the web has been browsable, web browsing has been very linear. As a consequence, there are two historical ways one can look back at its navigation path:

• the time-based way, via one’s history, unrelated to windows or tabs. It is mostly used in long journeys backwards in time.
• the sequence-based way, via the toolbar: next, previous and their associated list, linked to the current window or tab. It is mostly used for immediate history.

These are two points of view of the same database which is the navigation history. To achieve this, this history database retains mostly the page URL, the page title and the URL access time. I say mostly because it certainly has more data, and probably only in process memory, not on disk, but what matters is that this is the only user-queryable data.

Since users have been able to open multiple windows, and even more since the advent of tabs, this browsing linearity has been destroyed, making the above history model very hard to use. Open in new window/new tab rules our world and makes history a mess.

There is a third way to get back in time. Bookmarks.

As web usage patterns emerged, bookmarks, or favorites, are of two kind:

• frequently visited
• stored as reference

The first is merely a counter (maybe a bit smarter and statistical, but a counter nonetheless), and Safari’s “Top Sites” covers it, as many other implementations.

Taking the navigator/explorer metaphor, it’s like going to an unknown place without drawing a map, merely noting the location of the place if you ever bookmark it. This teleportation feature is cool, but everyone has felt its most glaring shortcoming: it requires the user to voluntarily mark the target place.

This is why history is so useful. Finding something again you remember having seen, maybe checked as being remotely useful someday but not worthy enough of your bookmarks. Or you bookmarked it, but you do bookmark so much stuff that it gets lost into a mess.

Safari’s use of Cover Flow is smart at using visual memory to find it again, but it’s still lost in a maze of tab forking flattened in a linear world.

How long does it take to find something again in your history? Well you’d rather answer to this one: how often do you end up googling it again instead of looking in your history?

Still, a search engine like google is good at finding new locations based on keywords, but it cannot know where you browsed (barring the seldom known and used search history which is useless anyway if you found the information deeper than first level browsing depth, and maybe you found it via Twitter anyway). This is the role of the browser.

Therefore, here comes the aaaalmighty proposal:

• History navigation should be better stored as a tree: along with title, url and date, history database should contain parent and/or children nodes, so that a user can maintain a real map of not only when but how he got there. The next step is to build a good GUI for that. Maybe a nav’ bar along with the address bar? Maybe merging both? Who knows?

• Also, navigation should store content. Not only as visual snapshots, but as real, textual content (upon which the web is based, even if there’s media in the mix) to be searchable locally.

This way history retains location, content, and context.

Let’s call that, not the Explorer, not the Navigator, but the Cartographer. Let web users build their own map of the web.