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.
Personally I think we shouldn't move away from the concept of: URI <=> resource, just for some short-term gain. I think that metaphor will be a lot more useful in the long term.
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.
Agreed. I think this idea would be better implemented by the application itself as a navigational aid; maybe as a small bar stuck to the window on the bottom (as Facebook's bar was done).
> "Training users to recognize URLs is vitally important"
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).
Except that the URL string doesn't translate well in meat space. I cringe every time I hear someone on the radio or television read off a URL: "Log on to double 'U', double 'U', double 'U' dot mylonganduglywebsitename dot com, forward slash, long directory name, forward slash, yet another long directory name AND click on the partially hidden link". Surely there's verbal short hand that can be implemented?
For a start we should try to get rid of all those www: that will be the greatest help. The rest should be pretty easy: a website can always set a forwarding link so that, say:
www.cocacola.com/offer
goes to the page of the actual offer.
> "This idea fails even on its own, since it presumes that URLs have structure, even within a particular site."
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
I design a popular browser for a living, and I also liked breadcrumbs enough to write up this quick hack back in 2003: http://bodytag.org/crumbler/
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).
This UI would be similar to Windows 7 Windows Explorer's location bar, which shows "breadcrumbs" of libraries or folder directories by default, but changes to actual filepath upon click.
I didn't like it at first, but took the opportunity to spend time getting to know it.
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.
As a long-time user of the Up button, I completely agree.
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.
Backspace takes you "Back". If you open C:\ and then click on Downloads, pressing Backspace will take you to C:\ and pressing Alt-Up will take you to C:\Users\YourUserName. Of course, if you are currently in C:\ and open the Windows folder, pressing either Alt-Up or Backspace will open C:\ again.
The first thing I do when I install Ubuntu and open Nautilus is to turn this feature off. It's so much faster to type "~/Scripts/some/hierarchy" than it is to click through that. Then again, I (probably like most of you) believe in the commandline.
I think that'd actually be a great idea. The new button thingies can make any URL easily human-readable, but then if you click inside the new URL bar it converts to text that you can copy/paste.
> "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."
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.)
What was the historical reason? I know that originally the actual domain name was written from "largest" to "smallest": com.google, for example.
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. :)
We don't, actually. We have http://google.com/path/ . The URI scheme, the 'http:// part, that is, is actually meaningless and could be replaced with shorter and meaningful 'web:', which was, I believe, the main point of a poster you were replying to.
I think the main point of the poster was about the ordering of the address, subdomains and paths screw up ordering because they arent linear, its like american dates.
some.sub.domain.com/and/a/path
vs
.com/domain/sub/some/and/a/path
Both were my mains points, but I see the "http:// problem bigger. It's too unpronounceable prefix for every-day use (because of combination of letters h+t+t+p and three punctuation marks after that!), so people simply skip it. Because normal people still need some standard identification string to recognize a website address, the site owners configure the "www." subdomain for that purpose, although it's totally unnecessary component (but made sense historically when the www was just one marginal service among others).
Yesterday, I wanted to show a friend a video and typed http://hulu.com/top-chef, and the show's page came up. This seemed natural and efficient to me, but my friend could not get over this "magic".
he he... I do that often for Wikipedia... even though I don't get why Wikipedia hasn't implemented a nicer looking URL (in particular removing the middle /wiki/). :(
Even if optionally disabled, hiding the resource location seems very dubious while the breadcrumb structure isn't applicable to all sites. I would much prefer that sites be developed with good REST techniques, with the goal of making easy to understand URLs. Over time I think more sites like Amazon will get on this and make cleaner URL structures.
It's not a bad idea and possibly even worth pursuing. One of my little favorite things about frameworks like rails is how much effort was put into making human readable URIs: http://www.foobar.com/products/kitchen/blenders/1, in most cases working your way up say to foobar.com/products/kitchen "does the right thing".
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.
Us developers get a hard on when we create these pretty urls, but I recently switched an app to have nice urls and not one user mentioned anything - to them, navigation is in the application, not the url.
It depends on your userbase. Completely non technical users have completely blocked out URLs, they might as well not even exist to them. They'll even go to foo.com by typing "foo.com" into Google.
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.
The 1 isn't required, it's common to use the item's ID in that position, but if you can ensure unique names or some other property to be unique, you can use that too. Even with the opaque 1 I still prefer this format of URL over the gobbly gook sites like Amazon, Ebay, Microsoft, etc generate.
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.
Trained in the sense that, over time, many of them have learned, or read or been told to pay attention to the URL for security reasons.
They are trained by their friends, by blogs, websites, (my bank website frequently reminds me to check the URL), articles in print media, etc.
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:"
http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.shtm
I know of one non-geek who spotted a strange URL and actually looked deeper. My mom, who's rapidly improving her computer skills - she noticed a login redirected to a massively different URL. Missed that it was still the same domain, but now she understands the parts of a URL better.
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.
Actually, one needn't extend anything in order to accomplish this sort of device.
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.
Had the same idea over a year ago, still planning on putting it into my custom browser (I'm kind of lazy at dev). I'm surprised it's taken this long for someone else to write about it. There's a crap load of ways that this will make browsers better, and no real reason not to do it. You can even put the http back in the link, and have the same kind of drop down to select from http/https/ftp/etc (but with user friendly names like Web, File, etc).
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.
Elevating user experience one article at a time - tagline from UX Magazine About page made me laugh. Their homepage design is antithetical to that statement.
I'll chime in with a rant about the URL bar because I've spent so much time thinking about how much I hate it.
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.
> Users (...) 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.
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.
>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.
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.
I would just eliminate the URL bar and the back button entirely. These concepts are relics from the Internet 1.0 age and no longer have the correct meaning. Some sort of bookmark/search/wiki replacement navigation system needs to be developed.
I totally disagree, the back button is the single greatest UI improvement of the web.
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.
Very much agree, especially as it imposes stateless behaviors in websites, and as so many sites have poor navigation (even as bad as different on every page).
(this comment is aimed at you, but it's sort of pertinent to the article also)
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. ;))
Opera has had tabs above the address bar for as long as I've been a user. It makes it much more clear that the address bar and controls are actually associated with the tab, not the application. A key feature of this choice is that the search box and address bar will switch contents when you switch tabs, and if you switch back you will see what you had originally typed.
The problem with the back button is it should not be the sole way to navigate.
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.
> it would be preferable to just move these concepts (navigate back and up) right into the web page, or the web application
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.
>This would make it even less consistent, wouldn't it?
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.
It annoyed me that Apple removed the top tabs from Safari without providing a option. I still use it as my primary browser but on my MacBook I'd have liked to keep those extra pixels.
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.