The browser is an excellent tool. It's ubiquitous, simple to operate, and extremely powerful. What's more, it is almost entirely composed of useful surfaces. The window design (like an actual window) is focused on the content, with minimal but functional tools for navigating that content—and increasingly, even those tools are being hidden or marginalized.

There is one part of the browser, however, that has not changed since the earliest days of pre-graphical clients: the URL bar. It is the one piece of the browser UI that has remained opaque to end users. Even the status bar and advanced preference panes are framed in plain English: "Loading images…", "Disallow script?", "Could not connect to server". These are all things that bring obscure information to the top layer of user experience in plain, direct English. Even if the user can't react to the information or even comprehend it, they appreciate being addressed in their own language. Why is the URL bar the sole survivor of command line language being presented to the user?

I propose that the URL bar be modified to fulfill a significant purpose for the user other than just displaying long strings of characters mostly irrelevant to, and mostly ignored by, the user. A user should be aware of his location on the Internet at all times, and of any relevant information that he has requested or transmitted in getting there. The way the URL bar presents that information is completely inadequate.

Before I go on, it's worth mentioning that many websites are already moving towards practically URL-free navigation in the form of Java- and Flash-based input and navigation. Web apps like Grooveshark and Picnik, for example, forgo traditional navigation by using scripts to hide or replace information usually found in the URL. These sites already recognize the uselessness of the URL bar and have abandoned it, but if it were to suddenly become useful again, they might take it back.

The task is to lay another layer between the URL and the user—one that makes the URL intelligible to him. So how do we make such techno-gibberish readable? A procedural abstraction layer on top of a URL string wouldn't go very far, because of the many variations in directory order, script formatting, and so on. An automatic URL wrapper could make sense of the domain and a few odds and ends that show up on every website (image locations, standard search functions, that sort of thing) but on websites with more unorthodox organization, it would break.

What needs to happen is the establishment of a standard set of URL meta tags. I'm going to make up a standard for the purposes of this article: a meta tag called <nav>, with a few standard parameters. These would go in the HTML document header along with other browser-level stuff like page title and favicon.

Let's take as an example a typical browsing session on Amazon. The user is looking for an item, and may have clicked on a few things, logged in, and so on. He's poking around in the kitchen area and decides to check out a new stovetop espresso maker. Here's what the URL bar holds, at least for me:

Good god! First of all, it's just incredibly long—and they get much longer. There is hardly any information even recognizable to the user in the first place, and what he does recognize he likely won't understand. What's critical? What's secret? Will this link work for a friend? And what part shows where the user currently is, where he came from, and where he can go?

Another caveat worth mentioning is that most websites get around this problem by simply having the page itself display where the user is (the "breadcrumb"). This is good, but completely unstandardized. And this is just my opinion, but shouldn't location information be located in standard place? What if every website moved your file menu to whatever position it thought handy, or moved the back button or reordered your tabs? No—this is information that should be available, at least partially, in a standardized and reliable format. The user puts things into this bar to go places; the user should look to this bar to see where he is.

Let's put my idea into practice by applying a set of my <nav> tags to the first URL.

<nav order="1"></nav><nav order="3" name="Bialetti 6-cup espresso maker">Bialetti-Express-6-Cup-Stovetop-Percolator/dp/B000CNY6UK/</nav><nav order="2" name="Kitchen goods and Appliances">ref=sr_1_1?ie=UTF8&s=kitchen&qid=1280010827&sr=1-1</nav><nav order="0" name="Logged in as Devin"/>

As you can see, there are a few attributes added in: ordering for the navs, names to display, and a few extra things to make things easier on designers.

Different browsers could render the navs differently, but here's a quick mockup of what that snippet above might look like:

Mockup of the nav order system

The graphic component would be skinnable client-side like any other browser UI element, but always separated into these visually distinct "navs."

The first nav (Amazon) would have to be determined in a secure way, of course; we couldn't have Site X claiming to be Amazon just by typing it in. The last nav (order="0") would be a little more freeform, since it doesn't refer to any part of the URL.

These navs must be interactive, of course; each navigational unit should be clickable and have predictable results. Clicking on Kitchen would bring you to the kitchen section of Amazon; clicking on Amazon would bring you to the home page; clicking on Logged in would bring you to your account. These are buttons and shortcuts already available on the page, but like I said, why can't such rudimentary navigation be included in the address bar, where supposedly it is collected and presented to the user?

Mockup of a selectable parameter in the URL bar

It would be interesting to be able to pass certain values through a nav, too, that would in turn affect the relevant portion of the actual URL. For instance, when on a page that lists items sorted by date, there could be nav elements in the URL bar that give the user control over sort order and method. It would act like any on-page pull-down menu, and the values could be set by the website's designer. I change things like that all the time by messing with bits of the URL, but shouldn't my mom be able have that option, too?

The behavior of the navs could be as simple or as deep as any other browser UI element. The back button doesn't simply go up one directory, even though that's what it used to mean when navigating the Web was more like navigating a file tree. Now the button can resend information, re-query databases, cause user events like dialogs, and have context-sensitive actions like displaying a short browsing history on right click. Navs could be just like that. And sometimes back does mean going up a directory, so sometimes clicking or deleting a nav would simply be like deleting that portion of the URL. The entire nav display, it goes without saying, could be turned on or off with a click.

It's not a foolproof system, of course. I'm not a web designer or security expert, and there are doubtlessly some complications I haven't thought of. But the potential here really is huge and the costs in terms of extra design work, while not trivial, are justifiable. We could have a rich, powerful, and informative set of standard items where now we see a long, largely meaningless string overflowing with characters of little or no value to the average user. The browser is the tool of choice for the consumption of unprecedented amounts of information, and it deserves all the streamlining we can give it.


I think you're on to something here, even if it's not completely there. The implications of such a functional URL bar are not lost on me: we could start cutting down on the complexity of our web sites and applications by perhaps completely eschewing navigation and letting standardized browser interfaces handle that.

Sure, there are problems that need ironing out: Web sites that use the URL bar to pass data between pages, complicated url structures that most of the time fail to reflect the hierarchy of pages, etc. As a developer, if you're using a modern back-end framework (say Rails or CakePHP) you can already pass around whatever data you wish while still keeping your URLs tidy and useful to the end user. A great example of a good URL structure is Apple's website: every URL makes sense and effectively tells the user where she is and where she came from.

This is a good system, but your ideas would certainly improve upon it. I especially like the fact that your system allows for dropdown navigation in the different portions of the URL.

Let's hope someday this becomes a reality!

I like the idea, but I often have to tweak URLs to navigate a site due to poor IA to change database query parameters etc so I don't think we're ready for this but it is time for Google Maps-like URLs to go.

See the behavior of the bar in Windows 7's windows explorer. It's just like a breadcrumb but if you want to copy/paste you just click the empty space and it goes back to being a simple address.

However there is a clear tree structure with the folders there, no such thing on the internet...

This is a great idea. So long as there is still a way to switch back to showing the normal URL as that is still very important. I like though.

And that Locationbar plugin for FF is exactly what Chrome (and Safari?) has always done. It's cool, but nothing particularly new.

As a side note - this site has one of the worst Captcha implementations I've ever used. The validation on it is terrible and to get a new image you have to submit the form. Come on - I thought this was a UX site?

Very interesting suggestion. The add-on Locationbar² for Firefox already handles this very nicely.
I also agree with Henrique on URLs not correlating with navigation directly. Most users aren't bothered on the URL being displayed for the most part.

One huge caveat with the urls, that would still exist after this is that many websites use them for keeping session relevant information across pages. So when users copy paste the urls - say for a link in a mail to a friend - they might lead to error pages when that url is later used outside a session. As of your interesting draft this would still be an issue, but perhaps you could add a copy-url meta-tag to it?

Nice idea, though I as a webnative tend to refer to those ugly urls as some kind of indentity card of the webpage for my security.

It's a good idea, although URLs don't correlate directly to navigation.

Love the intuitive concept behind a more purposeful URL bar and the 'decluttering' of the site itself.

Perhaps this manifestation could benefit from an "experimental" standard breadcrumbs markup pattern recently proposed by Google?

So you are suggesting a black box with the mandatory navigation (in any site) replaces the url bar, blinding the user... Just get a bigger screen if your URL bar is ocupingn too much of it

Do you know HTML link types which can be applied to <link> and <a>? Most of them are intended to be used for navigation (first, prev, next, last, home, up, search, archives, …). Opera can use them in its navigation toolbar and (some of them) with keyboard shortcuts.

It’s not displayed in the URL bar, i know, but that’s just UI. What i’m addressing here is the HTML code, and FYI: <nav> is already occupied. ;)

Sorry. is already taken by HTML 5, for navigational elements.