Encoding Context In Links

A page in a web application shows formatted objects, menus, or things that pertain directly to the application domain. Like lists of objects from the database, or a single object, selected from the database and presented to the user. Lists of objects, or a single object, are part of the link the user has clicked, or pasted into the browser address bar. No matter actually, it's the notion uniform resource identification — the mechanism realizing this idea is secondary. The goal is that the link text identifies a resource within the application. But is that the extent of the information encoded into a single URI? Or do applications, as they become more sophisticated from a user interface perspective, need to provide context to the pages that render these URIs?

Links, not long ago, pointed to something radically different than stuff found in the web application arena of today. It used to be that the link pointed to the physical page itself, residing on the server's drive somewhere. Or, perhaps it's still just your typical page, but has the added functionality of templates. The concept still holds, however, that user's idea of a page in the application isn't all that far off from that of the developer's idea. This easy to manage, and is how the web has worked for years. Lately, however, with the introduction of single page web applications where the notion of a page has transformed itself into something dispersed all throughout the client code, and nestled in the API. Yet, we still try and carry out the URI idea. Some applications are capable of actually emulating the properly-formed URIs that we're used to seeing everywhere on the internet. The challenge, however, is that we lose the separation of user interface context when we surrender the idea of pages, and navigating between them.

If you think about a web page, however it gets realized in the server technology isn't as important as the idea that different things have their own page, you'll realize that the page is it's own encapsulated unit. When developers are able to separate user interface components like this, each page has it's own self-contained context, different from other pages. So depending on the application object we're attempting to render in this page, we get our own unique stage on which to display it.

This isn't as straightforward with single page applications, despite being able to emulate real URIs as though the user is browsing the web as always. It helps, but in these dynamic, Ajaxy environments, we have to emulate our own page contexts. This isn't so easy to do, and we can sometimes forget the simplicity that we're missing out on with multi-page web applications. But the issue remains, how do we provide context to the user interface that now has to display the object this user has asked for? One solution is to encode the context in the URI. Web applications already do that today. As in, /short/hardware/36 and /hardware/36. The same application data, different representation. Except, the multi-page approach probably has two distinct templates for the task, while the single page app needs to do it's own internal template lookup.

At a more fundamental level, as applications grow in scope, we need to somehow preserve the usefulness of the URI while making sure our applications stay responsive and current. Perhaps we need to take a close look at the context we build into the user experience itself. The context in which an object is rendered. And these contexts are a tricky issue, because they can nest, down to arbitrary depths. This shouldn't be represented by the URI. So the simplest way of making sure that doesn't happen is by investigating the value add before doing so in your own user interface. Keep the context simple, and the URIs even simpler.