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.


Given when this piece was written, it was a very interesting addition to user design and user interaction. Unfortunately, well constructed URLs (a mentioned) should serve a very similar purpose. Most importantly though is the way in which the browser have developed so that th now the URL bar is also a search bar, thus changing the way in which users now expect the URL bar to bar and behave.

I'm not convinced all websites will or should have a breadcrumb representable navigation scheme to begin with. Many experiences are far less linear or structured.

Interesting idea indeed. Only issue that I see is how far does the breadcrumb go? and what about tiny url bar, like on the phone?

Interesting article.
In my understanding of the article, I see the URL bar acting as another navigation menu. I believe if the website layout/menu items are well structured, then probably the navigation on the website should be useful to the end user in terms of what is mentioned above and the navigation capabilities from the URL might not be needed

Have to say I agree with @isemann (#4423) and telic (#4425) - Clean urls already provide the information trail that you're talking about, and turning the url bar into what amounts to a secondary navigation is making things more complex, not simpler.

Saying that, who says that site navigation has to be on-page? Incorporating it into the url bar is a nice concept which does work but which I think needs more exploration.

Interesting article - definitely following up for more :)

john: "On the other hand, i think it's interesting to think about this subject from a design point of view. Is there a way that a new user interface design could change the way the user sees and interacts with the URL without changing the back end functionality in terms of the way the URL mechanically works?"

Yes, that is in fact what I am suggesting.

and Michael:"where taxonomic structure exists breadcrumb trails can be helpful. in lots of cases taxonomic structure does not exist. taxonomic structure should not be encoded into uris."

Agreed - but most websites, whether they have a taxonomic structure to their URLs and resources or not, work in a drilldown/categorical way. All that needs to be present is a movement from general to specific, or large container to small container. Furthermore this is not encoded into the URI, it's an optional resource on the page, loaded as part of the html.

Just to point out that the URL bar accepts things other than 'http:' - for instance 'ftp:' or 'file:'.

Most, if not all, also accept 'javascript:'. It is through use of the 'javascript:' scheme that we're all able to make use of bookmarklets/favelets (whatever you want to call them).

Simple example, paste:

javascript:{alert('Hello World!');}

into your URL bar and hit return.

Every time you use a service that tells you to drag a link to your bookmarks bar, this is what you are actually using, they all work via the URL bar.

That's already pretty useful.

@marcus with all due respect that's ridiculous. it's unix file systems that got us into this mess in the first place. most early web sites were serving flat files off a unix file system. so urls mapped to filing systems. which made lots of people believe that uris were somehow nested hierarchical sets. they're not and never were. uris are identifiers (not labels) for resources. nothing more, nothing less. they are not supposed to identify the location of the resource in any taxonomy. most modern websites go nowhere near the unix file system (beyond apache); a request is routed to a controller which queries a model which queries a database which returns some data to the model which gives it to the controller which passes it to the view. no-one is lionising the unix file system in this debate

that said @reda's explanation of restful uris is also inaccurate. rest is about the persistence of a resource identifier and using http to operate on it. sometimes that results in hackable uris, often not. hackable uris are orthogonal to rest

none of this detracts from that fact that the uri is the most important attribute a web page has. the fact that it doesn't map to a hierarchical structure is sometimes bad design and sometimes a consequence of good restful design

getting back to the point of the post. where taxonomic structure exists breadcrumb trails can be helpful. in lots of cases taxonomic structure does not exist. taxonomic structure should not be encoded into uris. therefore mapping uri taxonomic structure to something more ux-y is stupid

none of this has anything to do with unix; it has to do with the web

This is a interesting thought, but I'm not sure that it is really worth all of the effort required to change the structure of the URL to be more "informational" to the human user. Somethings stay the same for a reason-- because they work well, and there are no problems will the way it currently exists. I'd argue that this is true of the URL structure.

On the other hand, i think it's interesting to think about this subject from a design point of view. Is there a way that a new user interface design could change the way the user sees and interacts with the URL without changing the back end functionality in terms of the way the URL mechanically works?

@Reda, you may be ale to guess that deleting portions of the URL will have meaningful navigation behaviors, but it seems like people keep on forgetting that we're not like the vast majority of users. We know what browsers are. We know what the URL does and how it works. We can make educated guesses based on our experience about how to tinker with URLs. But honestly what percentage of people are really capable of that? I know people resent designing for the lowest common denominator, but what's the point of calling yourself a UX pro if you only want to design things for yourself, or for the people you wish your users were, instead of who your users actually are?

A lot of this conversation feels a little like "Unix is the backbone of the operating system. It's simple, powerful, and everyone should know it. So why would we want a graphical UI covering up the magnificence of Unix?"

If Amazon's url's aren't usable, it's amazon's problem not the web's.
A lot of modern websites already embrace some kind of REST urls, or simply url's that reflect the breadcrumb, or the site architecture :

As you see, these don't need any layer on top, you can easly guess that /blog/2010/10 shows a list of posts on October (just like a directories in your OS)

Given that breadcrumbs are only occasionally relevant, and URL's kind of need to be shared explicitly, I see this causing more problems than the perceived problem it solves.

Also if it's not universally implemented then you gain a lot of inconsistency, and therefore the feature could often be ignored by default - there's also nothing to say that it would be implemented well by the developer, leaving as many usability issues as with URL naming.

Very interesting concept and thought exercise, but definitely not something I'd buy into.

hi devin

i've read and re-read this several times but still fear i'm missing the point. anyway, my take:

1) this is the web we're talking about. web design isn't just about making better / less cluttered pages; it's about designing for links. uris and http are what makes links happen. the url bar is the most important part of any web page

2) without links we have no web and no google and no twitter. as you say "many websites are already moving towards practically URL-free navigation". if i can't dereference a uri for each nugget of a site then what they've made isn't a website; it's a cd-rom delivered via the internet

3) the job of an http uri is to identify (and allow me to get) a resource. it is not the job of a uri to identify that resource's place in any taxonomy; that's the job of the resource. building taxonomy into uri design is almost always a bad, bad move. with no taxonomy there's nothing to map the crumb trail parts to

4) urls and the url bar are designed to be identifiers, not labels; use the page title for this if you have to do anything

5) breadcrumbs are a broken, legacy analogy for web navigation. filing things is fine if you work in a library, it doesn't work for hypertext:
replacing the most important part of the page with a navigation system better used on DVDs is not clever

6) if your urls contain additional chaff for user tracking / sessions etc then it's as much a ux failure as a tech failure. urls are not designed to be seen (the first browser had no url bar) but end up being seen so at least make them tidy. this is not difficult

7) the fact that many ux professionals don't contribute to the design of urls is not the fault of urls. if you wanna make them shorter / readable / hackable do some work. the most important thing is to remember they're identifiers not labels. don't make them readable if you can't guarantee persistence

8) ux shouldn't be about perfecting navigation within a site. again this is the web. design for navigation in and out of silos

9) "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". the web was not designed to be navigated like a file tree. the file tree metaphor came about when companies wanted to build walled gardens or "the original "atom" of the web was the page, now it is the server. Servers link very rarely to other servers" from the back button takes you back thru your history. it has no interest in directory structures, real or imagined

10) "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." "location" does not and cannot exist on the web. there is no "home". the desire to overcome this (at least within the boundaries of a single site) is stifling opportunities for real "ux" breakthroughs

11) finally the title: Making the URL Bar Useful Again. how useful do you want?

Breadcrumbs are contentious UX device at the best of times:

"we must lose the crumbtrail word. you are not hansel and gretel; you will not find your way 'home'"

Creating this kind of functionality in the address bar starts off flawed because it focuses away from the core dynamic of browsing.

Link types for breadcrumb…

Nothing much would forbid to implement this by using links and type. There is for example Add-ons for Mozilla which shows icons but it would be entirely possible to create a breadcrumb with it.

Opera, as it has been said already implements it natively.

Hey, guys. Thanks for all the thoughts... I wish I'd checked the reserved tags for HTML5 before I picked "nav"! But whatever, it was arbitrary. Could be anything, really.

As some of the commenters have noted, this would be an entirely optional layer on top of the URL, easy to skip for both users and designers. That may lead to a little visual fragmentation of the browsing experience, but it's easily accommodated. I think making a ton of nonsense URLs intelligible would be worth the trade-off.

It also would only be as deep as the designer wanted - each segment would be interactive in a predictable way, but it would be up to them (as it is with current buttons and such) to make it useful to the user. And they can add dropdowns and such if they want them, leave them out otherwise.

Very interesting concept.

My opinion is to keep it as Explorer (Windows 7) where it is just a nav link trail, without the complexities of dropdowns as traditional breadcumbs go. Then if the address needs to be copied the user can just copy it by clicking on the sides of the breadcrumb.

As I've been spending time reading diveintohtml5, there is a particular section that covers the history of how the was created, a very interesting read and could give you some insight as to how to make this a reality- get the browser companies to buy in to this so that they can ship it with their it here

Sidenote- enough with all the comments of the nav tag, if and when this concept becomes a reality then choose something relevant, focus on the idea.

On the subject of copying/sharing URLs:

One of the ideas Devin and I discussed that didn't make it into the article: make one of the attributes of those "nav" tags be something like "copyable" so the site owner could designate which portions of the URL were user/session/nav-order specific (therefore not copyable) and which were elements of a static path. Lots of URLs are mucked up with properties about sessions, security, text encoding, language/country, referring site/marketing campaign, etc. Obscuring those from ordinary users and only having the browser put the actual path to the content in the clipboard might actually improve sharing. Non-English speakers would likely be grateful to have the site re-detect their language, analytics about referrals and marketing campaigns would be more accurate, and we wouldn't have to look at those ugly Feedburner URL appendages anymore ;-)

I know some people will say that sites should just make their URL system more readable, and I agree... but I don't see it as practically feasible in all cases. If you're Amazon, and option (A) is to totally redo your site architecture to ensure URLs are more readable, and option (B) is to create a separate service that creates this nav meta structure as a separate process from retrieving and building the page, you're definitely going to go with (B) because it's much lower risk and can be constructed in a sandbox. The other nice thing about the nav idea is that it'd be a standard that could be employed by every website regardless of how its backend works, or how its URLs are constructed. The logic for creating the nav structure is entirely separate from the inner workings of the site, making it relatively easy to implement without challenging existing systems.

Mike: the point was that many of the objections people have shared in their comments have been derived from their personal preferences, and have to do with their level of technical expertise that allows them to understand URLs. Their preferences and technical experience are miles different than those of average browser users. This is why we need user research to remind ourselves that our preferences and experience aren't the same as the rest of the world. God help us if tech people were the sole arbiters of what was good and what was bad in software... we'd still be working on command line interfaces.

I think the difference here is that the author is proposing a new (optional) feature for browsers because it could be useful to a lot of people, whereas a lot of people are objecting it for reasons that reflect the views of a very small number of people. You have to evaluate this idea from the perspective of how it'd affect most people, not just how it'd affect you--hence, you are not the user.

Got to love the "- YOU ARE NOT THE USER. Don't act like your personal preferences can stand in for what would benefit the majority of users." comment......

And those who are proposing this new fangled 'breadcrumb' BS arent doing just that?

As Yann noted, Alex Faaborg (@faaborg, a principal designer at Mozilla, and a UX Mag contributor) has some good thoughts on this subject:

Thanks also to Frank Taillandier (@dirtyf) for his contribution to the conversation.

Before posting a comment, please consider:
- He's not saying we should get rid of domain names.
- He says explicitly: "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."
- He's not saying the URL will go away, only that it'll have a visual abstraction layer configurable by site owners to make their sites more navigable.
- He's not saying techies would be forced to use this.
- YOU ARE NOT THE USER. Don't act like your personal preferences can stand in for what would benefit the majority of users.

I don't know why people's first impulse is to be snotty. Even if an idea isn't 100% spot-on, or even if it's less than half good, it still warrants *thinking about* before responding to it, and responding having given the author a fair reading of his meaning.

Hi, I've done the translation of the article. It can be found on my blog :
Thanks for your authorization @Jonathan.

Also a friend of mine who helped me on the translation gave the link to the ux designer of mozilla here is his response :

I like this idea, if implemented the right way. The main points I feel are valid are these:

- The way Windows Explorer handles the location bar would be an ideal way to handle a URL bar if the URL were right for that kind of navigating.

- Like all tasty bits of metadata, it should be opt-in by the developer and the user. The user should be able to disable/enable it within the browser and the developer should have to mark up their site with the correct bit of code to make the feature actually work. If you're already using URL as UI, why not add a code snippet to the head of your page and make shiny magical URL bar things appear?

- Going off of a method already being used is cool - maybe piggybacking off of the Google Breadcrumb code and making the URL bar display something awesome based on it wouldn't be a half bad idea.

- When all else fails, make an extension. If it becomes popular, it might become part of a browser some day. Isn't that how TabCandy got rolled into Firefox 4?

Change the URL to navigation? *sigh*

Look, the only way you can know *exactly* where you are is to look at the URL. Those times you're on a banking website that might be a fake, what do you check?

It will be easy to spoof some navigational UX in the URL, but you can't do that with a regular domain.

I'll keep my URL, kthx.

Amendment of my previous post - it should say ( not ( in link.

So, it seems other readers so far have missed the part where the author specified that this would be another layer above the URL bar. The URL would still be there. Also, any implementation of this would be expected to make switching between URL and 'nav' menu a trivial action.

I like this idea, it would allow designers to position menus in an area that the user has control over, thus the user can hide or do whatever they wish with this area (menus should be something that is in some way under the user's control) and this also gives the designer more room to move now that the menu no longer needs to be on the page.

Also, it would allow the browser to find and display contextual, hierarchical information about the site, with more depth and breadth than just next, previous, first and last, etc.

Another option would be a link tag which links to another file which describes the site's hierarchical construct and the current view's position (page is a rather inaccurate term these days), or even inline XML from another namespace, as it is mentioned here ( that, "Elements from other namespaces whose semantics are primarily metadata-related (e.g. RDF) are also metadata content."

I actually like this idea a lot. As you said, standardizing navigation in the person's language would be nice. Having said that, there are a number of issues to deal with in the larger picture:

1) You are talking about proposing a new standard. How would you deal with URLs that don't fit that standard? Fall back on showing the text URL. That's fine ... new standards might be adopted by browsers and sites alike, and slowly others will join in. But will this standard work for all sites? No. Let's see what is out there right now.

2) First of all, the web has existing standards. The URL expects a hierarchical section followed by a querystring section and then an anchor section. You can turn the hierarchical sections into dropdowns, turn the querystring sections into filters, and turn the anchor into a dropdown based on the ids on the page. The problem is, how are you going to populate these?

3) I presume the language you're talking about would be english. So then the URL would still be unintelligible to non-English speakers. Let's face it, the URL is to identify a site on the internet to COMPUTERS. Once in a while the URL may be human-friendly, so people can print it on a business card. But even these URLs can't always be readily communicated by word of MOUTH, due to ambiguities of spelling.

I guess I'm the only one to see the purpose of the URL bar? It's to display URLs. Every page has one. They're simple strings You can bookmark them, copy them and send them to people. Your idea makes that difficult and creates a lot of potential ambiguity as to just where the user is. Think big company websites are bad at making navigation menus? Now imagine that's all you have.

Sites that put private information in the URL are designed wrong. Sites that have URLs that expire or don't always refer to the same page are designed wrong. Sites that use some hack to "get rid of URLs" are designed VERY wrong. There's not a lot of sense trying to fix their mistakes, and I wouldn't count on them to use this more complex system properly if they can't even use a simple URL.

The URL bar has a useful, standardized, documented purpose. Please don't try to turn a hammer into a screwdriver. If you're looking to co-opt something instead of proposing a new standard to the W3C, I suggest the HTML title tagset as a possible candidate since it seems closer to your ideas of navigation & context

Well, I'd something else in my mind so I've a concept browser design removing the whole address bar.

Most of the time, the address should better display the "Title" of the document. Only when clicked should it display the url.

Obviously, all urls should be bookmarkable.

Note: On most browsers, the title is not readable if you have many tabs, whereas the less usefull address bar is readable, so, let's combine the two.

My 2 cents.


I think this is a great idea - a key to it being successfully adopted though would be for google (or facebook) to be capable of serving advertisements through it. You could call them Navertisements or, comically, nads or whatever.

But website owners will want to be able to use that information as part of their funnel to direct users to places that make them money.

If anything more websites are simplifying their URLs and making better use of the address bar. Flash is still popular of course (but more usable these days) and I'm not sure where you are seeing "Java" based websites (or do you mean JavaScript? Most, like GMail, are pushing useful info into the URL after the anchor.)

There is also the matter of phishing which a transparent URL scheme, and better user awareness, can help in. We don't want to hide the URL.

Your idea is nice though but it would have to be a separate element or add-on to the URL bar.

Also, there are already META tags that you can use to specify the next page, previous page, up a level etc. Firefox and other browsers can display menus/buttons if these tags are set.

This idea is refreshing. I will be interested to see where it leads, especially when HTML5 is more universally accepted.

I love the concept. But if we're going to re-conceptualize portions of the browser, why not the browser title area? You might do the following:

--Leave the URL in the URL bar. It's an important place to verify you are where you think you linked, and this is helpful for bots as well.

--Add functionality to the title bar to link to breadcrumbs. It's already good SEO for titles to go from specific to broad, e.g.:

Steller's Jay | Family Corvidae | All About Birds

So, we could add functionality with links, where a browser with title breadcrumb capability will turn those into links, and a browser without will merely read them as a title. The code could simply check browser version, and if breadcrumb title f(x) were true, it would display the above as links, thusly:

Steller's Jay | Family Corvidae | All About Birds

Love the idea of leveraging different areas to be more functional. Pity that "nav" is already snapped up by HTML5 ;-)

P.S. All About Birds is one of my favorite sites, run by the Cornell Lab of Ornithology. Enjoy!

Like catalin I instantly thought of Windows 7's file path bar in the Explorer. It does just that. And it's one of the things that make me like Windows 7 so much, I even think about switching back to Microsoft. No kidding.

The idea is very cool, i like it ;-)

But the nav tag is taken by html 5 for navigation area. I'm not sure whether your solution is valid.

The nav tag is specially for navigation structure on the website directly and not in the browser url bar?!

nice idea, its looks like location bar in windows 7 explorer.

but i think not all website can implement your concept. Why don't we use HTML5 navigation tag instead?

It'd be useful to change some things in the URL bar for dropdowns and such, but I don't think it's needed.

First of all, Grooveshark does use the URL bar. They use JavaScript to change the hash so that the back and forward buttons will work, as well as sharing the link.

Second, the nav tag already exists in HTML5 for the purpose of in-page navigation.

Lastly, the URL bar, if used properly by the website, can be extremely useful. This site is a good example actually, I know that I am reading an article about technology and have part of the title available to me. The URL being clean also means that it's safe to share it.

Sure, Amazon needs to clean up their links a bit but to others it's much useful and readable. Many users might not understand what HTTP stands for, but that doesn't mean the protocol should be hidden as it's very important. The current URL bar design can be used as is for breadcrumbs, and I have become very fond of how URLs look. There's no need to be changing it.

@Yann, nous serions flatté et honoré si vous traduiriez l'article. Si vous le ferez, nous aimerons bien le voire. Merci!

I love your idea, you're definitely on to something.
You have to polish the concept and rethink the whole technical part (why a new tag when you have microdata rdfa and link rel ?).
Also I don't think that a combination of pure hierarchical logic (the breadcrumb) and behavioral logic (order...) is an easy to understand concept but we can solve the problem by putting all the non hierarchical links on a separate part of the bar like the "logged in as" in your example.
Despite all that, the idea is still a great one.
Can I translate it into french ?

In a recent functional design proposition I made recently to one of my clients (International hotel chain). I proposed a similar use for the bread crumb. Not the URL part, just the multi-dimensional navigation through the drop down menu. I think the ideas would work perfectly for a coherent IA system. Ex.
Home > continent > country >

I took it a bit further :
Home > continent > country > Choose a City

New ideas are not always easy to get a client's approval.

take care

For those who keep telling the author "nav" tag is taken.

Simply make it: ""


I think we need to remember that the UX and technology pros who read UX Magazine aren't representative of the broader world of users. What Devin is proposing is to make the URL bar useful to the average user. If it just displays a long string of gobbledygook it's going to be meaningless to most people and useful to fewer. In its current form, it imparts "location awareness" to only a tiny set of users.

Nicely formatted URLs (such as the "friendly" URL of this article) are more informative and easy to interpret, but they're still not, again, useful to the average user. They're not interactive in any true sense. It'd be nice, for example, if users could click on the word "technology" in the friendly URL here and be given a drop-down menu of the other sections of UX Magazine, or click on the "" part to return to the homepage. Advanced users can often make informed guesses about how to manipulate URLs to navigate, but these are still just guesses (bad UX), and very few people are advanced users.

There will always be geek purists, and that's why he's indicated it should be possible to turn this feature off. But just because techies find value in seeing the URL doesn't mean the other 99% of people do.

The reason the URL bar hasn't changed is because it already represents exactly what it needs to. As you said yourself, "a user should be aware of his location on the Internet at all times." URLs are _the_ definitive indication of location on the net, and any obfuscation of them would be detrimental to location awareness.

As isemann points out, URL ugliness is a design problem that can be fixed without adding any new standards. The real problem is that UX designers often aren't involved in URL planning, leaving this important interface to the back-end programmers. Inevitably, this leads to them being _misused_ as a shortcut around common web-programming hurdles (like session tracking). 99% of the time, there are other ways to handle these problems that don't impact the usability of the URL.

In regards to webapps like Grooveshark, I think you are mis-attributing their URL schemes to design. I would surmise that it is due more to side-effects of their choices in technology and the difficulty of creating functional and meaningful URLs for a webapp than to a conscious UI decision.

All that being said, I don't see any reason why browsers couldn't make their URL bars more interactively functional. A lot of header information is going totally unused in most browsers today; no doubt you could use it to inform decisions on how to add simple bread-crumb-like interactions or navigation dropdowns to the URL. The key is to add such functionality without displacing the main purpose of the URL bar: displaying the URL.

This is a super cool concept would save lots of time while navigating through huge sites.

Interesting idea but I'm not a advocate of more complexity.

We already have 'pretty' urls ala - - and ugly horrendous ones ala - -

WordPress has plugins to make urls pretty and I'm sure it's possible for all the different ways of building/developing sites to have something in place to 'prettify' the urls. This means that normal users will always have decent information in the bar without a whole raft of new standards or worse conflicting standards, complexities to be worked through and around etc. etc.

It might just be a problem that doesn't really exist and designers will have their own priority about what does and doesn't appear in the url bar.

My two cents anyway.


p.s. This is a usability site - why the hell Save and Preview as the CAPTCHA options. Submit would be a lot better than Save - and that is not a personal opinion, it's a fact.

There's MVC to solve this problem already...

They're still strings but easy to understand:
hxxp:// or

And as Henrique said "It's a good idea, although URLs don't correlate directly to navigation."

This system would work much better with MVC, but the concept is nice.