

Making the URL bar useful again: Where the Breadcrumb should have been all along - amirmc
http://uxmag.com/technology/making-the-url-bar-useful-again

======
neilk
This is a well-intentioned but terrible idea.

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.

~~~
terrapinbear
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?

~~~
nanairo
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.

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

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

~~~
vidar
I have to admit that I and most programmer types that I know hate that feature
but maybe its helpful for those less tech savvy.

~~~
Goronmon
Well, count me as a programmer type that enjoys the feature and is having a
hard time figuring out what there is to hate about it.

~~~
d2viant
I don't hate the bar, I hate the lack of a button to easily navigate up to the
parent directory.

~~~
city41
Alt+Up Arrow takes you up one directory. Annoyingly though, Alt+Down does not
descend into the currently highlighted directory, instead Enter does.

~~~
MartinCron
Backspace also takes you up one directory, I didn't know about Alt+Up.

~~~
darinpantley
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.

------
Yaggo
_> "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.)

~~~
nanairo
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. :)

~~~
Yaggo
<http://news.ycombinator.com/item?id=881278>

------
djacobs
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".

REST FTW.

~~~
nanairo
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/). :(

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

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

~~~
smiler
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.

Better to keep the breadcrumb there I say

~~~
city41
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.

~~~
astrange
> or 4Chan users going by "/X/"

When will the nightmare of capitalization end? I've never even seen that
second form before.

------
ddlatham
Just make sure I can still copy a link, give it to a friend, and let him get
to the same page.

------
feral
This won't work for two reasons:

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.

~~~
Groxx
> _and its taken too long to train users to this level to just throw it away._

Users have been trained? Since when?

Though I do agree this is likely to only make things worse in that area.

~~~
feral
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>

"A phishing site may look exactly like the real site, but the URL will look
strange." [http://www.ehow.com/how_5236627_avoid-online-like-fake-
paypa...](http://www.ehow.com/how_5236627_avoid-online-like-fake-paypal.html)

<http://www.microsoft.com/protect/fraud/phishing/spoof.aspx>

There are a plenty of examples of similar articles.

~~~
Groxx
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.

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

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

------
brc
The Url bar never stopped being useful to me.

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.

------
raheemm
_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.

------
korch
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._

~~~
acqq
> 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.

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

~~~
hebejebelus
(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. ;))

~~~
JeffJenkins
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.

~~~
hebejebelus
I wasn't really arguing that, though it brings up the fact that if you do it
for long enough, it'll eventually become the standard. ;)

