I can't agree at all with the author's basic premise, which makes it hard to agree with the rest of the article.<p>>> URLs are the building blocks of the web.<p>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.<p>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?<p>>> Every page has a unique URL so that you can identify it and share it with other people.<p>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.<p>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."
I observed a bunch of high-schoolers using the web.<p>They go to Google to visit a site. They don't type URLs.<p>They go to google.com, enter "Facebook" and click on the 1st result.<p>Remember the Facebook Login fiasco?<p><a href="http://readwrite.com/2010/02/11/how_google_failed_internet_meme" rel="nofollow">http://readwrite.com/2010/02/11/how_google_failed_internet_m...</a><p>Google showed this post when people searched for "Facebook Login":<p><a href="http://readwrite.com/2010/02/10/facebook_wants_to_be_your_one_true_login" rel="nofollow">http://readwrite.com/2010/02/10/facebook_wants_to_be_your_on...</a>
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 <i>never</i> 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.<p>I'm looking at you Google as the worst offender. I swear that some developers have never left the US.<p>Geo location != preferred language.<p>Accept-Language header in my browser is telling you what I want. Listen to it.
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.<p>I respectfully disagree that it is less secure. Showing <i>only</i> the domain will reduce the clutter to where the user <i>can</i> determine which domain they are typing their password into. I say <i>can</i> because in the phishing example the user would be unable to determine the domain name.<p>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.<p>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.<p>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 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.
The path and query parts of the URL my address bar is <i>/item?id=7694968</i>. To the server, it's vitally important (as is the cookie). Especially to the average user, it's complete noise.
> 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]<p>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?<p>The examples in the link[0] show that it's actually beneficial.<p>[0]<a href="http://jakearchibald.com/2014/improving-the-url-bar/" rel="nofollow">http://jakearchibald.com/2014/improving-the-url-bar/</a>
> There is a reason they have always been front and center in all web browsers.<p>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".
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.
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.<p>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...)<p></rant> (sorry about that)
Hiding the URL is a natural step on the way to total TV-fication of the web.<p>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.<p>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.<p>[1] <a href="http://imgur.com/v04aL41" rel="nofollow">http://imgur.com/v04aL41</a>
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.