Raw

The memory palace, also known as the Method of loci or memory walk is a technique for remembering things. Basically you start by memorizing the physical layout of a place such as your own home. When you need to remember something, in your mind you put it somewhere in that place. To recall the thing, you look in the place. The trick apparently works well for things like memorizing lists. It was known by the Ancient Romans. It relies on the fact that we have fairly good spatial memory.

Many of the metaphors used around the Web reflect a spatial model: Netscape Navigator, Internet Explorer, the Information Superhighway. We do seem to be predisposed to think in this way: when talking about mathematical structures, the structure is conceptually a kind of map, comparable to the way we make maps of the physical world. With information retrieval on the Web it's quite hard not to think in terms of a library, not far removed from a physical library with books on shelves. Not to mention Files, Folders and Desktops.

So anyhow, the other day I was pondering whether there was something more around the memory palace idea that could be applied on the Web. Instead of putting a piece of information in a place in the mental model, HTTP PUT it in a place on the Web. I didn't get much further with this line of thought, you need the mental model of a familiar place to start. But another metaphor did occur to me.

What have the Romans ever done for us?

Well, the invention of concrete is usually attributed to them. It "...freed Roman construction from the restrictions of stone and brick material and allowed for revolutionary new designs in terms of both structural complexity and dimension.". Concrete clearly has had a role in the development of the modern city. There's a watchable old TED talk from Steve Johnson on the Web as a City. Concrete is made from aggregate, cement and water, not such a bad analogy to HTML marked-up text. You can mould it into whatever form you like. But what's lacking there is something corresponding to links.

So...how about reinforced concrete? Concrete on its own is good under compression but not extension, it needs something to tie it together if you want to make really big structures. The answer is to embed steel bars in it. Links as rebar, ok.

While this metaphor is a bit limited regarding the flexibility of the Web, it isn't bad for explaining the role of links to bind everything together. Given that links are data, the metaphor isn't bad at explaining how Web of Data relates to the Web of Documents. One is made of steel the other, concrete. Together they make a composite or hybrid material with properties that are greater than their sum of parts.

Comments to G+ please

Browsers have certainly evolved since the WorldWideWeb browser in 1990 into pretty sophisticated pieces of kit, supporting rich views of HTML and many other media types, along with a powerful version of code-on-demand through Javascript. But in certain respects they're still very primitive. It was probably unavoidable, but there's a significant conceptual gap between what the browser can do as a general-purpose tool and what it can do as a container for site-localized Web Applications. Take Gmail as an example of the latter - very much the same ballpark as desktop mail applications. But move away from that domain and all gmail's functionality becomes inaccessible. We're still a way off a genuine Web of Applications.

One obstacle to maximizing the Webiness of Web Applications is found around the way buttons are used, directly mimicking the behaviour of desktop applications. But on the Web, the best affordances are associated with links (i.e. URIs + HTTP). In this context we should expect more of Web Applications - that the application should be built primarily as a Web API, i.e. a regular Web Site, so that the affordances are available to other applications. It should be trivial for me to check the contents of my gmail inbox from the comfort of my own Home Page. However I'd hazard that the business models of the big Web brands are likely to hinder development in these directions - Google, Facebook, Amazon etc. run somewhat counter to the open Web, in that they are motivated in keeping you in their domain (or in extreme cases like Apple and MS, in their own devices). Web Intents seem to me to be a good start towards enabling more flexible yet uniformly accessible interactions.

Over the years the read/write nature, or rather lack of it, has been discussed an awful lot. Even though the first browser included an in-place page editor, the current model still doesn't really support this. One big reason for this is that HTML - even HTML5 - falls short of supporting the full range of HTTP methods. The predominant approach to writing to the Web is through major intermediation by Content Management Systems. While CMSs are generally a very good idea, the fact that they're built on an effectively hobbled client means they aren't as Webby as they should be. There are genuine technical obstacles to generic writeability, notably those related to authentication and authorization, though hopefully WebID will help there.

The metaphor of the browser is itself quite limiting. Generally we only have one Web document open - visible on the screen - at a time because we can only read one thing at a time. Even with the development of tabs, the browser still essentially reflects this modal model of Web resources. I think I read about work on accessing data across tabs, but as far as I can see it doesn't exist yet. Ok, desktop applications are also under the restriction that we can only look at one thing at a time. But it's a lot more common to interact with multiple independent data sources/sinks and processing components there.

A browser can pretty much support a general-purpose HTTP client (through script), but because we're so used to thinking in terms of the Web of Documents and requirements there, the one page at a time modality is deep in the mindset. Service mashups, be they client or server-side, all really aim towards focusing down on a (primarily read-only) single-document view. A critical aspect is that traditionally the link has basically just one meaning - navigate to another page (do a GET and display the results). But while a link on a Web of Data could correspond to the same thing, it could also mean 'GET the data and merge it into the local store' or 'use this URI to filter the current view' or any number of pivot-like operations.

Ok, this is in danger of turning into another rant...let me sidestep by highlighting one specific browser affordance.

The Turn-Around Button?

One link-oriented metaphor for the browser Back Button could be walking down a footpath, junctions in the footpath corresponding to the available links presented to us on a Web page. Clicking the back button has the effect of walking backwards to the previous junction. We are still facing in the same direction. But what if we metaphorically turn around? Ok, the outlinks on the page will look just the same, but other data is available, our whole history. Why not present the current page alongside a recent history page (like chrome://history/) so we can hop back further - a turn around button. Yes, the Back Button may drop down a list showing the history, but richer information could be provided in the main window such as the links followed as a tree.

From a data perspective, variations on a Back Button might mean 'remove this data from the local store' or simply 'Undo'.

Dunno. Work needed on RDFAffordances.

See also: Identifying Applications State