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

Microsoft Word does not have a back button. What operation should a back button perform in Google Docs?

>"Back" and "Up" are virtually indistinguishable for an average user.

Sometimes you want to go "back" to the main page of a domain. Other times you just want go to the previous page. Other times you want to leave the website entirely. Other times you want to "undo". It simply makes no sense for a web browser to try to support all these features based on a simplistic web browser history based on URLs. It's an ancient way of thinking about the web.

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.

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.)