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.
What we may do, and to be honest it's starting to happen already, is to get rid of the address bar as an always-visible user interface feature. It could just be an overlaid window for those times when you actually want to type in the url (or if you jus want to check its value) that disappear once one click enter. And to be honest this is already happening in mobile phones where space is limited.
The breadcrumb idea, especially if as customisable as the author suggest, should be done in the site... which we already can do.
This raises an interesting side question. What kinds of things should present day computer/net users be aware of? In other words what would you consider 'basic training' for your average user?
The reason I find this question interesting is because I'm sure many years ago that a grasp of the command line was considered important (but then 'average user' also meant something different).
Don't sites usually have regular URL structures. Or, at least, could be organized into regular structures? In Rails, we have routes that map to URLs, like
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).
IMO, it is a better way of navigating around. If I'm wanting to go a child of a folder three levels up, I just click the little arrow next to the appropriate parent, then choose the child. As opposed to up-up-up-scroll-click.
Plus, I still have the option of manually editing it, if I so choose (but that takes an extra click).
It took me forever to notice the "search" box, though. That's another really nice feature, once you get used to it.
With the new system, the parent button (i.e. "Up", as NumberFiveAlive pointed out) is always in a different location, labeled with different text. How confusing! Microsoft replaced the notion of "I want to go up" with "I want to open folder X". Great for new users, not great for me.
The new system makes a lot of sense for people who don't understand nested file-systems and just want to open Folder X... "oh look, there it is, click". Also, the old Up button doesn't make a lot of sense in the context of a hierarchy laid out horizontally, so I can see why Microsoft would want to revamp their interface.
For those of us who do understand that directories contain other directories, the option to enable the Up button again would be a welcome "new" addition to the address bar. Sometimes it's more convenient to click on a button than to reach for a hotkey.
You can pick and choose what options you want. My explorer is currently configured to be a bit of a cross between Windows 7 and XP.
I'd use it.
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.)
I find my perfectionist side slightly annoyed by the current form, but then if we ever change it we should move to year-month-day too, and putting the currency symbol after the number, and use decimals everywhere (no more hours but centi-days ^_^)... oh well, I guess the world is nice because it's imperfect. :)
In most cases, the same is true of www., but sadly not in all.
I love good URL design. I think hulu was pointed in this direction by its use of Rails.
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.
Better to keep the breadcrumb there I say
But other users appreciate the nice URLs. Take reddit users refering to subreddits as "/r/subredditname" or 4Chan users going by "/X/". Of course these are more technically inclined users, but in many cases probably only marginally so.
When will the nightmare of capitalization end? I've never even seen that second form before.
(But incidentally, you can remove this part and the URL still works.)
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.
Users have been trained? Since when?
Though I do agree this is likely to only make things worse in that area.
Now, this doesn't mean users won't still be conned. But its important not to be blase about the worth of that accumulated knowledge. It takes a lot of time - and cases of fraud - before knowledge like "I should check the URL" filters down to the average user. This knowledge, having been thus accumulated, shouldn't be casually discarded, or undervalued, by those of us who do computers for a living. Its hard to train users to follow security procedures at the best of times, without changing the rules.
Examples of what I'm talking about, from a quick Google:
"look for indicators that the site is secure, like a lock icon on the browser’s status bar or a URL for a website that begins https:"
"A phishing site may look exactly like the real site, but the URL will look strange."
There are a plenty of examples of similar articles.
This, from years of being the geek-as-tech-support for quite a few people. Non-geeks (ie, those who do not understand URLs to a minimum-safe degree) who even look at the URL while they browse are, in my experience, exceedingly rare. None I've even seen notice the "revoked certificate" flag, and many people browsing at school have clicked right through the phishing / scam / malware warnings to get to their game.
People. Do. Not. Understand. URLs. There's no mapping to the real world, certainly no obvious mapping, and understanding how they work and what's important requires far more tech knowledge than the average person has.
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.
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.
I don't agree. Any user that writes anything on the computer (I exclude the ones who don't know to use the keyboard) expects to be able to type something in the computer and that the computer gives meaningful results.
The success of Google proved that.
It also proved another thing: where to type must be clear and obvious and the results must match the expectations.
I'm at a loss then. If you're recommending getting rid of the address bar, exactly how are users supposed to navigate anywhere? If your solution is Google or the search bar, that doesn't solve your given example of users searching and missing facebook. I fail to see how removing the address bar will make users better searchers.
There are a lot of non tech savvy people out there who are so afraid of breaking things that they won't even open context menus in Word without saving their document first.
All of those use facebook and the web like champs because they can never totally screw up because the back button takes them to safety. Don't forget, many grew up during times when using technology wrong meant that you would loose an arm. Back button fixes that anxiety.
You simply can't rip out a UI convention like that. Think about how many browsers there are. Virtually all of them use the back button and an URL bar. Say you made a browser without those, with an innovative new navigation system. Think it'll catch on? Extremely unlikely.
When you take out one of the oldest conventions in the book, people are going to use it for five seconds, 95% of them will decide they hate it, and will simply use what they're used to.
Consider iTunes 10. iTunes 10, released only a week or so ago, changed the UI in a minor way. Somewhat minor, anyway. Here's a screenshot: http://cl.ly/2OWb
Now, this looks a little different to your average Mac OS X app. Judging by my twitter feed, about 80% of my followers changed the window controls back to the old style (http://cl.ly/2ODf) as soon as the option became available.
They did this despite the fact that it makes sense. Having the controls vertically saves space and provides an extra thirty pixels (or so) to view their music.
Making sense doesn't matter in even rather minor UI changes like that. Like the old adage, a frog put in boiling water will jump straight out, but a frog being boiled will never notice.
Consistency is key when it comes to UI conventions, and it's _extremely_ hard to change the tide. The only way to do it is if other leading people do it also.
For example, Opera started using tabs on top at about the same time as Chrome did (don't quote me on that, I'm trying to make a point). Then Safari tried it, and now Firefox 4 has tabs on top as well. The only way to facilitate change is to not be alone in making it.
Furthermore! "Some sort of bookmark/search/wiki replacement navigation system needs to be developed." Do you have any ideas as to how to implement that? (I'd honestly love to hear them, I'm not trying to bee too much of a sanctimonious dick. ;))
It really needs to be split into 2 buttons: "Back" and "Parent" (or "Up"). People use the back button for both purposes. And when you involve Iframes and Ajax-heavy web applications, the context of "back" gets entirely lost and broken.
It's a big problem. There is an HTML5 api to give some level of control over the back button, and this may help to a certain degree. But I really believe it would be preferable to just move these concepts (navigate back and up) right into the web page, or the web application.
There is absolutely nothing preventing web applications from giving a superior navigation experience than a one-size-fits-all web browser buttons.
By web application, I presume you mean for example google docs, rather than a browser.
This would make it even less consistent, wouldn't it? Some pages/apps wouldn't have these controls, or they would look different or be in different locations across different pages/apps.
"Back" and "Up" are virtually indistinguishable for an average user. Hell, I'd be surprised if I could give a good description about the difference, and I know computers inside-out.
> There is absolutely nothing preventing web applications from giving a superior navigation experience than a one-size-fits-all web browser buttons.
Except for the users...
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.