I can't agree at all with the author's basic premise, which makes it hard to agree with the rest of the article.
>> URLs are the building blocks of the web.
The web has lots of building blocks (hyperlinks, requests, the underlying protocols, HTML, and on the modern web: Javascript and XmlHttpRequest). We hide most of that implementation detail from the user because it's non-essential to the task at hand.
How essential to the task at hand is the URL for most users? I may need a building's address to find it; once I walk into the building, do I need to continuously see that address?
>> Every page has a unique URL so that you can identify it and share it with other people.
That's a significant mis-statement of what a URL is. URLs have never been unique (witness www.foo.com vs foo.com), don't necessarily identify the page (witness dynamically-generated pages that are built with information from the client's cookies or state on the server), and their utility as a sharing tool is limited to what the server allows (witness access control). They're uniform resource locators... Nothing more, nothing less.
A URL is a tool. A useful tool, certainly. But I don't keep all my useful tools constantly on display on my desk; I keep them in toolboxes until I need them. So I'd say "See how this experiment pans out."
> We hide most of that implementation detail from the user because it's non-essential to the task at hand.
and then you have tons of security holes and bugs. Remember when browsers thought it was nice to hide loading from the user, and every site had to add "do not click submit twice" and such? what's next? one page apps relying on a share button and then having to write "do not share via the hidden URL"? ...google maps was like that for ages now that i think of that...
We should be coming up with ways to make information denser and more meaningful. not scarcer.
"Do not click submit twice" isn't a side-effect of hiding loading; it's a side-effect of sites taking something that should be idempotent (a single purchasing transaction) and failing to code it to be idempotent. Nothing about the page loading UI would have prevented that issue.
But they're not. Hyperlinks, shortcuts, or similar are. To most people, the internet is an icon on their desktop, that goes to the Google/Yahoo/Bing, with which you can search for Facebook. You're going to be hard pressed to teach this majority on the rules of parsing a URL to eek out the domain before you can even begin to teach them which domains to look out and what not to do with those unrecognized.
Yes, but should this be encouraged even further? I think it should not because the less people know about the technology then easier it is for snake-oil sellers and politicians to lead them where they want them to be.
You know what I recently observed? A bunch of kindergarteners fastening their shoes to their feet with velcro straps.
Their shoes also had little blinky lights on them, so that cars don't run them over, when they chase a soccer ball into the street. Let make all the adults wear velcro shoes with blinky lights on them too.
I started using velcro-fastening shoes when I had a mild stroke that prevented me from tying laces. Now, I continue to use them because (1) they are very convenient and easy to adjust, and (2) I go dancing a lot and find them easier to switch to my dancing shoes.
Considering how often I have to retie the laces while dancing, I would definitely consider getting dancing shoes with velcro.
I do the same thing, and high school was long time ago for me.
As for typing URLs, I do that, too, but autocompletion takes over after one or two characters. E.g., 'ne' suffices to get me to the HN front page. Navigation for me is pretty much all search or autocomplete, followed by normal link following. Except for a couple of bookmarklets, I do not use bookmarks. Back in the nineties, I used bookmarks a lot.
Once in a while, I will manually change a URL already in the location bar or paste one in and modify it.
However, I do look at URLs a lot. They often provide valuable navigational clues. And I appreciate well-structured URLs, such as the readwrite.com ones you posted, and I scorn the opaque numerical messes that some content management systems generate. I agree with the article.
The only thing I still use bookmarks for are saving and ordering of web development libraries and tools. Otherwise I would be unable to find that one specific slider that would be perfect for this specific use.
I still need to open source that collection, because it's huge and has been super useful for me. I'm just not entirely sure what the best way would be.
In re the comparisons to iOS7 showing only the domain name of the site you're on: Mobile browser UI is a completely different design challenge. Yes, I found it jarring at first to see only the domain name, but the full URL was never visible in Mobile Safari on the iPhone, except on the shortest of URLs. But on a desktop web browser, showing the full URL is a critical piece of the UI, and it will confuse far more people than it will help to remove it.
I hope I can always get access to the URL. I frequently have to switch the 'smart' geo tracking language selection in the querystring from de-DE that some shortsighted developer thought meant Germany === German to en-US or en-GB.
I'm looking at you Google as the worst offender. I swear that some developers have never left the US.
Geo location != preferred language.
Accept-Language header in my browser is telling you what I want. Listen to it.
The accept-language header is dead. It's simply ignored by every site. Some crappy sites like Origin even make it impossible to set the language to anything but German even by changing the URL directly. Google took years to even allow me to manually set everything to English, until about 1-2 years ago some settings were impossible for me to reach in English even when everything was set to English.
It's just like with Windows, applications use the location instead of the OS language to chose what language to default to.
L10n is broken. And no one seems to have any real interest in fixing it. The tools are there but they get ignored by pretty much everyone.
Geo-location by IP is one of most horrid abomination ever created.
Try a road trip in Europe, every single day google believes I speak/read/understand a different language. If that's not bad enough, living in a country where one doesn't speak the local language basically means not using the service.
Stuff like .../?hl=en may help indeed (but it has to be put manually.
(I assume it stands for "No Country Recognition" but I'm unsure of that). Visit it once and I believe it stores a permanent cookie on your computer telling google not to re-direct you to a country specific site.
Been using it for about 10yrs now as it annoys me when I get re-directed when accessing sites over a vpn.
My Firefox sends the following Accept-Language: "en-us,en;q=0.8,sv-se;q=0.5,sv;q=0.3".
When I go to Google.com in a new private browsing context, I am redirected to Google.se with English language. When I go straight to Google.se in a new private browsing context, the page is in English.
To be fair. I've just rechecked and you are right. I have the same behavior in Germany. Maybe someone is listening!
Ads though. Still in German. Not sure if that is a good thing or a bad thing. I'm even more blind to them in the wrong language. I guess that is a good thing!
Problem is a lot of site operators don't differentiate location vs. language.
As someone living in the US who speaks English and Japanese, I often get annoyed by the fact changing the language would affect feature set to match the language and vice-versa. I almost want something like ja-US and en-JP!
I agree, it's awful. URLs are the central concept in the web. People should be aware that they are browsing certain URL at the moment. Be able to exchange links.
> I would wager that most people who fall for phishing attacks are not people who look at or understand URLs to begin with. Updating the URL bar to show just the host is not going to cause more people to look at it.
I respectfully disagree that it is less secure. Showing only the domain will reduce the clutter to where the user can determine which domain they are typing their password into. I say can because in the phishing example the user would be unable to determine the domain name.
The full url is only a click away. A click that is going to be happening anyway when the user wants to copy the URL.
I welcome the clean look as user. As a developer I will re-enable the full URL on my development machines, but not on my family members machines.
What's wrong with bolding or otherwise emphasizing the TLD plus one more level of the domain? I wouldn't even mind (I would, but I'd get used to it) the url bar showing com.ycombinator.news/item?id=7694967 to avoid super long subdomains obscuring the main domain. But forcing a click to show the full uri? That's going to eat up a lot of aggregate developer time.
It also does nothing to address a major problem: companies using alternate domains for their services. It does me no good to know what the real domain is without any other distracting information, if I can't tell whether than real domain is trustworthy. The browser would have to maintain a map of trusted organizations and domains they're known to use, and show the trusted official domain in place of other domains. Which is problematic for several reasons (not the least is the effort required to maintain such a list), and could lead to additional security problems in edge cases (domains transferred to new owners, etc).
I suppose this is somewhat off-topic, but confusion of TLDs reminded me of the following story:
When I was still using a dumbphone I figured out that AT&T would let me sync my contacts to the web. I figured I'd try to do that to see if I could make them more manageable (by not having to edit them on a tiny screen with T9).
I searched all over the AT&T account page (att.com - where I view and pay my bills) and couldn't figure out how to access my contacts on the website. Eventually I googled enough to find out that I needed to manage contacts through att.net. That website redirected to a Yahoo page (att.yahoo.net) which didn't take the same credentials as att.com (that is, the att.com user:pass did not work), but if one was signed into the dot.com they could automatically be logged into the dot.net. It's extremely confusing.
Once logged in, I was presented with an interactive flash or heavy javascript page which, if not for the .csv import/export feature, I would find much more cumbersome than even just using the phone.
Before I managed to get logged in I clicked on numerous pages that redirected me to att.yahoo.net. Because it is labeled (and decorated) as a Yahoo webpage (and is, I assume, operated by Yahoo), I was quite confused over what credentials to use and if I was in fact at the proper website.
I actually disagree with the blog. I don't work for Google but I think my parents would be better served with just knowing which domain name they're on rather than having to parse through a huge url.
If that was the case, then emphasizing the domain name within the url would address their needs, while preserving the full url for anyone who needs/wants it. I'm looking at Firefox's url bar as I type this, and the url text is all medium grey except for ycombinator.com, which is black. There is absolutely no confusion about what site I'm on, and no need to parse through a huge url.
The path and query parts of the URL my address bar is /item?id=7694968. To the server, it's vitally important (as is the cookie). Especially to the average user, it's complete noise.
Some path components are not made for humans, but many are.
I regularly type in twitter.com/ and a user name or apple.com/ and a product. Or on GitHub I'll change the page number in the URL to advance 10 pages.
Also, domain names can be just as noisy with subdomains.
How do you define an average user anyhow? I think there's only more common use cases. Everyone has their special needs and uses on the internet.
You'll still be able to type twitter.com/ and you'll still be able to display the URL explicitly, it just won't be visible by default. Most people don't need that feature most of the time.
> The URL is still accessible in iOS by tapping the URL bar, or in the Canary experiment by clicking the origin chip or hitting ⌘-L.[0]
I honestly don't see what the big deal is. So, you have to click the origin chip to modify or share the URL. There's even a handy keyboard shortcut. What am I missing?
The examples in the link[0] show that it's actually beneficial.
> There is a reason they have always been front and center in all web browsers.
Just because a design idiom had prevailed doesn't mean that it's correct or even good. People generally don't care about the url, they care about the site. This is like the browser saying "Starbucks" rather than "Starbucks, 3-1202 21st E, Falseville BC".
While the existing approach may have its flaws, the wholesale removal of valuable information and functionality from the browser UI very likely isn't the right fix, either.
In my opinion, this is up there with the removal of the URL protocol, the removal of the status bar, the removal of the menu bar, the removal of the ability to disable JavaScript easily, and the other similar changes we've seen from Chrome and/or Firefox over the past few years.
This useful functionality is removed under the guise of "increasing usability" or "improving security" or some equally vague justification. So-called "average users" don't even notice any improvement, while power users are forced to endure a dumbed-down, less effective browser experience.
I'm curious if there have been studies about people not caring about the URL or showing it is a more of a usability hinderance than help. I remember arguments about this back in the late 90s (some suggested VRML navigation as a solution!), and the web has still seemed to take off despite no significant changes to the URL bar before the last few years.
In your example, wouldn't the "BC" be the domain name and not "Starbucks?" I don't know if there's any way to know with certainty in all URLs whether the domain name or the path components are more important to a user.
>This is like the browser saying "Starbucks" rather than "Starbucks, 3-1202 21st E, Falseville BC".
Is it?
What if "Starbucks" were your bank? What if you knew that apart from your bank there's non-bank entities mimicking your bank's looks in an effort to get your personal information? Would location still be irrelevant?
A few years ago I got an email advising me my account had been compromised, and I needed to follow a link to get the matter resolved.
Mousing over the link, I saw https://www.bankofamerica.com/[lots of gobbledygook followed by an ellipsis]. So, to see it all, I copied it to the pasteboard and pbpasted it into an open Terminal window. The gobbledygook ended with an @-sign and a domain that resolved to a Chinese IP.
> > There is a reason they have always been front and center in all web browsers.
What's more, the URL is not front and center in any web browser. The window title is taken from <title>, the path and query parts are displayed in lower contrast than the host part, and the address bar is not only hidden on iOS but also on Android when the user scrolls down the page.
This is just the same nerd-rage when Firefox introduced omnicomplete, only with less people vowing to switch to Opera.
The nice thing about this, is that if it's really annoying to users, then Chrome will bleed market share to other browsers. The browser market has shown time and time again that when the developers mess up, they get punished and another browser rises to the top.
Hiding the URL means hiding, or encapsulating, HTTP(S) from the user. Eventually, paving the way for a replacement of that venerable document-centric protocol for something more app-centric. That's my bet anyway.
Thanks, but yes, I think the long-term trend takes us away from documents and towards integrated web-delivered apps. Today's hack of JavaScript, DOM, CSS, and Ajax will eventually be smoothed into a simpler arrangement more suited for apps than documents. I think technologies like Dart, SPDY, HSTS, and Web Components foreshadow that future to various degrees.
I still think this is terrible. It flies against the principles of HATEOS, we have a design idiom that web developers /should/ be following to show us precisely where we are and what is happening in a website, why would we want to lose all of that information.
I would be very unhappy if they removed the option to disable this from chrome, almost to the point that I'd consider changing browsers (and I like chrome...)
I'd argue that this supports the principles of HATEOS by only revealing the entry point URL, and letting the rest of the state of the system evolve from that point without bothering the user with the noise of intermediate details.
> why would we want to lose all of that information.
Because the url past the domain name is not for the user to be messing with most of the time. We the developers control everything to right of the first single slash. Maybe if it was hidden then it would force us to do a better job showing the users where they are in our sites with breadcrumbs and menus and at the same time keep them from trying to poke around in places where they shouldn't be. I think this is a perfect opportunity to open up our minds and build better UI inside the frame.
Um, no. If I want to share a link to a specific page, there's no reason to assume that I want to share any of the query string that is not actually required for somebody else to see the same page (like all of the tracky goodness that seems to be ubiquitous on the web these days) -- and for the same reason, there's no good reason for you to assume that I want to click on a "share" thingy on your page. And while breadcrumbs may aid me in navigation on my visit, the "how did I get here?" stuff has absolutely zero value to anyone who arrived at the page using a deep link. Oh, and if you make any of that compulsory, you won't get a link; your information just became valueless.
Exactly. Right now, there's little or no difference between 'we the developers' and everyone else. Keep doing those changes, there will be one. Developers will be a privileged class. It's no surprise that some people may want to alter that balance.
Hiding the URL is a natural step on the way to total TV-fication of the web.
People search for "facebook" on Google in order to log on to Facebook because it works, and they are not interested in learning a more efficient way, because they are not interested in learning anything, they want to go to Facebook.
URLs look like math formulas, and who cares about that except some geeks? Math is hard, let's go shopping.
I just wanted to point out here that Chrome already emphasizes the domain [1] as this is a common proposed solution in this discussion. The visual clues should/could be stronger though.
I agree that the grey box with the domain name should be more visible. Users who enter their personal informations anywhere do not read the URL and won't see the domain name on a grey button that looks like a "passive" piece of the interface.
>> URLs are the building blocks of the web.
The web has lots of building blocks (hyperlinks, requests, the underlying protocols, HTML, and on the modern web: Javascript and XmlHttpRequest). We hide most of that implementation detail from the user because it's non-essential to the task at hand.
How essential to the task at hand is the URL for most users? I may need a building's address to find it; once I walk into the building, do I need to continuously see that address?
>> Every page has a unique URL so that you can identify it and share it with other people.
That's a significant mis-statement of what a URL is. URLs have never been unique (witness www.foo.com vs foo.com), don't necessarily identify the page (witness dynamically-generated pages that are built with information from the client's cookies or state on the server), and their utility as a sharing tool is limited to what the server allows (witness access control). They're uniform resource locators... Nothing more, nothing less.
A URL is a tool. A useful tool, certainly. But I don't keep all my useful tools constantly on display on my desk; I keep them in toolboxes until I need them. So I'd say "See how this experiment pans out."