Making the URL bar useful again: Where the Breadcrumb should have been all along

This idea fails even on its own, since it presumes that URLs have structure, even within a particular site. So if you want to add a new page, even a one-off for a special occasion, then you have to start thinking about where it fits in your ad hoc URL/navigation scheme, too. Also, if you want to redesign navigation, you have to change all your URLs. URLs are brilliant because they are separate from navigation; that's a feature, not a bug.

But it's also philosophically wrong. The URL -- a simple string that can be used to fetch any resource -- is the single greatest innovation of the web. A simple string can pass through literally any human communication system. Speech, print, text messaging, anything. A URL is not an inherently intuitive concept so it is not all that usable. But it's necessary. Training users to recognize URLs is vitally important, or we are back to relying on AOL^H^H^HFacebook to provide navigation tools.

Here are a jumble of quick thoughts, please don't take them as the opinion of the team:

1. The reason we didn't pursue anything like this is because sites are easily capable of doing it themselves in their own UI - the URL bar itself needs to come with expected behaviors, and when sites are able to overload it, it becomes more unpredictable. Standardized web UI has been a dream for many years, but the chaotic cacophony of the web is where all the beauty and innovation lies. Though it's a long way from the old ideals of User Agents, a modern browser's job is to get out of the way.

2. Windows Explorer is also able to get away with this style of UI because most people rarely type anything in that field; in the case of the browser, people are typing things in there all the time. Conflating menu-based and text-based navigation is hard.

3. Even though people are generally familiar with the structure of their own filesystem, navigating through it using the breadcrumb-menu interface is somewhat foreign - people don't like to think about sibling pages, especially for pages elsewhere in the stack. This becomes worse when you're dealing with random websites, where you don't know the layout of each.

4. Many websites don't map to a standardized navigation - products can exist in multiple categories, and sites like Wikipedia completely mess with the notion of tree-based structures. Building a notion of site structure into the browser was too prescriptive (see rant at end of point 1).

That's simply bad design. I would say opposite – the trend is towards friendly URLs. And seriously, I don't remember seeing Java-based (applet) navigations since 1999.

While I love the URLs in string form, I agree that they could have less cryptic syntax, e.g. "web:com.google/path/to/resource". (Yes, I'm aware of the historical reasons for the current syntax.)

REST FTW.

I also like how easy this guy's idea would be to implement in a framework like rails. By that I mean generating the required <nav> elements would be trivial for rails to figure out.

1) Legacy: URLs are fundamental to the way the the web is architected at too low of a level to change. We could change the browser to not display them, or display something else, but trying to make a web-wide change to put the prettiness in the URL isn't going to happen.

2) Security: There are already many attacks involving using unicode strings to allow an evil website masquerade as a good one. The URL is the one way a user knows whether they are on mybank.com or evilbank.com While its not a sufficient security system, its the best we've got so far; and its taken too long to train users to this level to just throw it away.

If we were starting again from scratch, bundling better navigational metadata would be worth doing - but thats just wishful thinking, and only the tip of the iceberg for what we might change.

There already exist link element relationships for next and previous, a user agent need only keep track of those and render the URI bar accordingly if it was desired.

The problem is with bad Urls, not the idea or execution. The trend towards friendly urls is getting stronger, as is the trend away from flash sites and other fat and crummy navigation tools.

The Url is the foundation of the hyperlink, and the hyperlink is the innovation that glues the entire WWW together.

First, slapping a simple breadcrumb menu over the text URL bar wouldn't be so hard, so it's a worthwhile experiment, at least just to see it in action. I'm all for experimental software. Consider how much of the web already use sitemap.xml? It's not much further of a leap to adapt sitemaps into a better description of whatever menu structure your web site uses. Browsers have always been vehicles for UI, and users have always suffered a million different web UIs. The web has become "Mystery Meat Navigation" all over. http://www.webpagesthatsuck.com/mysterymeatnavigation.html

I say kill the URL bar. The raucous against the "breadcrumb bar" seems to be mostly from technical types who are not so good at thinking from the perspective of non-technical end-users. It's difficult to go along with change, and throw out our floppy drives, I know this, but it must be done.

The URI bar belongs in text-mode UI land for one. As one who lives inside a Unix terminal, I'm generally biased against anything that exposes text-mode UI to users. Users just don't do text-mode. At least not since the days of DOS. They are already struggling with a graphically-based conceptual model of computers and the Internet, so showing them a flashing console cursor where they can type dozens of commands is just too much of a mind-blowing conceptual leap. It can often be difficult for technical & engineering brains to look at something complex and rather than figure out how it all works, all the way down to the bare metal, most users just want to follow the minimal path of effort to use their computers.

Using a single interface to represent both a graphical and text based input is generally a UI mistake. An error, a goof. The vast majority of users have no idea what a URL is, nor do they want to know, so they won't. Thus all the benefits of a text-based input is entirely lost to them. That URL bar space then becomes unused screen real estate. It's never good to waste limit screen space, and there are so many other redundant UI elements across every single web page nowadays, so it makes perfect sense to do something else with that space. How about let's take something users will never learn to use, and give them some other UI feature which they will love?

Also, the URI bar is why we have so many users typing Facebook into Google search, going to the first result and then flooding whatever random forum with complaints about "the new Facebook", without realizing they weren't even logged onto Facebook's site. Most people don't know what a web page is, and they lack the conceptual model of linked documents, not to mention they will never know about DNS or Internet protocols.

The URL bar contributes to a lot of confusion amongst basic web users. We recently saw the Google Chrome video asking pedestrians to explain the difference between a browser and an OS, where none of them them could do so. The average Internet user will never know what a browser really is. Face it, this is the horrible, sad truth you must face if you're making web browsers. Users know just enough of the rat-box tricks, which levers to push or pull and where to move, in order to use the web in the most basic way. And the simple UI they use for interacting with the web becomes identical to their conceptual model of the web. I would argue that this reveals a point of failure of web browser design. Web browsers have a long ways to go to perfect their UI. From a design perspective, it is an impressive achievement to take something as incomprehensible as the Internet, and reduce it down to a handful of learned behaviors that become the lowest common denominator of usage.

We programmers instinctively think "oh the web, it's just tcpip, routers, port 80, a web server, a path to the document resource, http headers back and some plain text to be interpreted and rendered." Contrast that with what the average end users thinks: "oh the web, I have no idea what a browser is, so let's open the Internet, it's here on my desktop, type in some text for Google, now surf around clicking links." You think these users are using browser tabs? Bookmarks? Customized home pages? Any kind of content aggregation, RSS, etc? We developers need to face it—the majority of the "gee-whiz" amagical tech just waiting to be done on the web is only going to confuse users unless we can whip browsers into better UI shape.

And that means moving as much redundancy from web sites into stand-alone UI elements in the browser itself. Let each site have it's own browser chrome if it wants. It would be fantastic to have an API that allows integration between sites and the browser "chrome" itself. i.e. context dependent behaviors, menus, buttons, login, status updates, etc.