My personal opinion is that it's a very bad change and runs anti-thetical to Chrome's goals. I hope the data backs that up as well.
But regardless, this change is far from shipping as the new default behavior and the reaction here will certainly have an impact on the feature's future. As mentioned, please feel free to disable it at chrome://flags/#origin-chip-in-omnibox
I hate how mobile safari has removed URLs, I find it very disorienting. I'm constantly looking at the URL bar to see if I've navigated to a new page or not, to see what the page I'm on is named and its purpose is, and to make sure I went where I clicked and wasn't just redirected somewhere else (sometimes this can be really confusing, for example mobile versions of webpages that dump you out to the main page instead of the mobile version of the page you were hoping for).
While I can see the anti-phishing advantages of emphasizing the domain, hopefully this wouldn't come at the expense of the rest of the URL. Right now chrome grays out the rest of the URL, which is nice, but if you want to be less subtle that's fine too - turn the domain into a button, or draw a box around it or whatever, but please leave the rest of the URL passively visible.
I think a lot of the negative reaction also comes from replacing it with a google search box. Not very classy. There used to be just the URL bar in browsers, then there was the URL bar and the search bar, then chrome simplified it into just the URL bar, which allowed you to search if you prefixed with ?, and now you can search with no prefix. The new change would just make the whole thing a search field. If you want to optimize chrome for people who don't know how to use the internet and won't learn that's google's choice, but don't expect me to use it or recommend it.
I don't even think it would help there. In fact, I think this would help fraudsters. If I think about the various scam attempts on steam for example.
They direct you to a url like www.stempowered.com/q?phishlogin=true or something.
Knowing that a correct steam url would never have this sort of thing in its url would be the first thing to notice if you were already duped into clicking on a link that lead to the above url.
If the browser then only displays "stempowered.com", it would be way more difficult to notice you are on a phishing site. Just because you didn't notice the missing "a". And let's face it. The average consumer/user does not go and verify any certificates.
This is incorrect. Entering a URL into the field produces the exact same behavior as it does with this option disabled. Typing a URL and pressing enter goes directly to that URL. Typing part of a URL that has been previously visited (like "face" => "http://www.facebook.com/") will default to visiting that URL.
However, if I enter "face" into the text field on google.com, then facebook.com is the top result. If I enter a complete URL like "https://news.ycombinator.com/item?id=7677898" or even "news.ycombinator.com/item?id=7677898", it turns it into a link to that page. The only difference between the search field on google.com and the URL field in chrome is whether it knows about my internet history, and maybe that's just because I have web history turned off. Sometimes I get the "Google Search" behavior and sometimes I get the "I'm feeling lucky" behavior.
In cases where the google search gives the wrong response, chrome gives the same wrong response, for example on intranet servers.
So, if it doesn't display the URL, and it behaves exactly like the search field on google.com, and it doesn't correctly navigate to some URLs entered into the field, I don't think you can really consider it a URL field any more.
In other words, it will make the whole thing a search field, with some smart url-friendly behaviors, so that most of the time when you enter a url it will take you to that url.
What? Intranet addresses work perfectly fine in the chrome url bar, unless it 1) has spaces (which aren't technically allowed in urls, and you can type %20 to avoid) or 2) is only letters (which you can avoid by just appending a slash or something).
Also, if the omnibox automatically redirected to sites instead, then yes it would pretty much be identical. But it doesn't and it's not.
Getting back to the earlier question, is the omnibox a URL field or a search field? Well, it's a combination of the two. But it's sort of like a UX version of the ship of Theseus.. if you slowly remove all the behaviors of a URL field and replace them with those of a search field, at what point does it become something different? When does it become a search field with URL behaviors instead of a URL field with search behaviors?
If you look at the screenshot in the linked article, the field says "Search Google or type URL" instead of showing the URL. I think that's the watershed moment. Given all the behavioral changes already, subjectively I'd say that's not a URL bar any more. Even if the omnibox behavior is exactly the same as now, it's no longer showing the URL.
I hope it doesn't make its way into the release version of chrome.
In other words: what Chrome has already done for a very long time.
With repeated exposure to URLs more people will learn how URLs work. Hiding URLs means that people will never be able to learn.
It makes me click on the bar to actually see where I'm at in the filepath, please don't take that design mistake and apply it to the web.
Not including a path bar by default doesn't mean they "try to hide the information", it's just a different UI design.
Or, drag a file from Finder to the terminal --> terminal prints the full path to the file.
From a UI perspective for user it looks like the "Search Google or Type URL" text are would be searching the Amazon.com site - however it sounds like it searches Google?
My guess is that this will drive a lot more traffic to Google and then much more opportunity for a website to the lose that user because Google will be able to show other listings - including ads - prior to showing whatever is on your own site, even if is only your website in search results (which as I said before, looks like won't be the case).
As a developer and website owner this would motivate me strongly against Google and strongly turn me off from Google if they continue to try to funnel traffic back to their own website.
It's right to address this behaviour in the interface design. Rather than somehow telling users they're wrong Google can work with that behaviour. Yes it has benefits for Google in tracking and profiling user behaviour too.
For many-many users the web entry point is the search engine they use as their homepage, that is "the internet" for them. This was the paradigm that AOL developed and there are vast swathes of users that cut their teeth on AOL.
It's probably a good hint that browsers could find success at imitating a similar search interface in the new page/new tab UI. Offer a clean page with a text search field, with very fast results that have good context.
Chrome and FF have a "View History" page with search, but it seems to be fixed by date and with no way to sort for relevance. IE doesn't appear to have a history search (I think this is baked into Windows search instead?).
"Don't be evil" gave way to "Invading privacy for fun and profit" long ago.
Google has avoided being obvious about Chrome giving them more revenue up until now, as far as I'm concerned. Whether this will also swing in their favor or not, I can't be sure at the moment.
And with Safari on iOS 7 only showing the domain name, there is some precedence with the approach described in the article.
Clarification: I'm not sold on the "Upstream goes sour? Time to Libre$thing" trend as a good thing in the long term, but I doubt the potential for it to occur has escaped Google's notice.
Is this true? Does Chrome phone-home with details of user settings?
If you are using Canary and NOT reporting back, you don't know how Canary works and shouldn't be using it.
That said, I sincerely hope that this particular anti-pattern's efficacy in converting people from typing in URL's to searching for websites isn't the most important metric.
Let's look at REST. Everybody is using it for HTTP APIs, or to be precise: everybody pretends to use it. Because, as many know, a REST API is only a true REST API, if it follows the HATEOAS paradigm. A paradigm which is in fact really cool. But why do we think it's cool? Because Roy Fielding found in his thesis that the (human) web is basically HATEOAS. He says the web is so successfully because of that.
But in reality... Hardly any HTTP API uses HATEOAS. In fact many popular APIs hide the HTTP stuff completely from the API consumers. (If everybody was using HATEOAS, we would never have to update the client libs, right?) Something similar goes for normal websites. Most URLs are not human readable, even HN is an example. The URLs are just numbers, there was even a post discussing that recently... Most News websites have even more complicated URLs, they are not made for humans and thus to me something like memory addresses. The GMail URLs (the webs most successful mail client) are also very funny looking, I wonder if there are users who manipulate the URLs by hand, or who bookmark their outbox.
I somehow like looking at URLs but am I supposed to edit them as an end user or draw conclusions from their look? (And is Google? ;))
BTW: URLs were interesting in the 90s for identification because only Geo Cities and friends had domains. Now everybody owns a domain.
Here is a data point that may be of interest: On YouTube, since links are filtered from comments, many users link to other videos by posting the "tails" of URLs - some with "watch?v=xxxxxxxx", some "?v=xxxxxxxx", and some just post the random-looking video ID part with nothing other than "see video xxxxxxxx". In other words, there's evidence to suggest that a reasonably large portion of the otherwise "computer-illiterate" have at least a basic understanding of how URLs work and will edit them manually to get what they want.
Edit: or to put it another way, there are people who, upon having made extensive use of YouTube (or possibly other sites), have been able to notice the patterns in all of its URLs, and use that knowledge to succinctly name a video, without explicitly giving the entire link. They are also implicitly teaching others about this knowledge in the process. This is a perfect example of the kind of learning experience that would be deprived from those whose browser hid the path in URLs.
For me this is another evidence that the main argument is broken. Youtube is super successful but in fact it is really restrictive when it comes to hyperlinking and mashing things together.
Update: just for clarification because of the downvotes, Youtube does not filter Youtube urls.
(I've basically never participated in YT comment discussions. There's definitely a lot of idiocy, but it's also interesting to just observe and see the sometimes surprising positive things like this that can occur.)
URLS are pretty rigid. If tommorow http was swapped out for a different protocol what would happen?
You'd be better off referring to the article posted as Allenpike's article on removing urls (or some such).
Fuzzyness feels more natural. I can bookmark a rigid URL, but what if later it moves? I might be better off bookmarking a signature of the article (a very basic form might be Author and Title).
The search engine's have a signature of articles, and if you are lucky that signature will be matched somehow against your loose search query. The success of search engines depends upon how well they order and match against your input.
Personally I find the HN way fairly readable. I mean item no 7677898 is something I can read and understand and I note similar systems are used for quite a few things in the real world like phone numbers, zip codes and passport numbers.
It's stuff like "https://www.google.co.uk/search?q=address+white+house&oq=add... that I find going on unreadable.
People shouldn't be drawing conclusions from the URL (apart from the query string and the domain part, but that latter is a whole other story). The URLs are supposed to be unchanging and not break, and that's strongly incompatible with having them contain human-meaningful information. And in particular (though not exclusively) with using path-segments to communicate a tree structure for your website. Such tree structures are inevitably torn down and replaced over time on most long-active websites (especially those which are the public-facing homepage of a long-lived organisation), and the result of placing them in the URL is inevitably link breakage. Hiding the URL by default is therefore good, as it should help to prevent the user from seeking meaning in the URL or the site owner from placing it there.
And links (with the exceptions noted above) shouldn't contain meaningful information for automated use either: it's Hypertext As The Engine Of Application State, not Link Structure As The Engine...
(Tree-structured site guides are fine and useful means of navigating, by the way; they just don't belong in the URL.)
Around '99 I did not rely on bookmarks, instead I saved interesting articles to my hard drive because links would break so often. Even today the problem remains and I don't even dare to say whether it got better or worse.
Maybe there are smarter concepts than HTTP-style URLs that we are not aware of yet. Might be also interesting regarding privacy, because many people actually do not want static hyperlinks to their personal information that last a million years.
It's great that you vet these changes on Canary and do user testing, but it's troubling that a change like this isn't first extensively vetted from a perspective of 'does this hurt our users? does it compromise their privacy? does it increase the odds that they will get sent to the wrong websites? does it hide important information in some cases?'
I suspect that this UI change is actually going to make people more vulnerable to phishing in cases where the domain is not a guarantee of identity; for example, an XSS on a google-controlled domain (where the full URL would make the attack obvious, but only showing domain hides it), or an attack hosted on a 'user content' domain that uses subdirectories to distinguish between different users/sites.
A more straightforward example is that all my gmail accounts have 'mail.google.com' as the domain in my browser, regardless of whether one of them is an Apps domain (thus security sensitive) and another one happens to belong to a sibling or significant other or something.
This feature just seems intrinsically misguided and poorly considered. I appreciate that your UX team is trying to aggressively improve things, but they seem to be acquiring a long track record of poor decisions.
I've since elected out of Google search as my browser's defaults.
Oh I don't think that's true at all. They just know that they're big enough that it doesn't matter what a bunch of internet weenies think when most of their audience doesn't know or care enough to understand the UI change, let alone grasp the business interests that drive it.
It doesn't make any sense to hide the protocol when you reveal the URL, and I found myself looking for a "Copy URL" button. Since copying the URL is what I most often try to do when selecting a URL, it would make sense.
It makes browsing feel much calmer, and I'm pretty sure I'll keep it enabled for a while.
I guess this goes to the app-ification of the web.
There's a dangerous slippery slope here. If we're OK with this happening, are we then OK with getting rid of that domain further down the line? What about routing all traffic through Google first so it can check if a URL is "safe" or not. The whole thing strikes me as creating a more locked-down web.
URLs and View-Source are fundamental elements of the vision Tim Berners-Lee. WorldWideWeb, the first web browser had it front and center. Mosaic moved it to the top, where we most know the URL scheme to exist. Safari moved the URL box to the same line as other navigation (what is now more common). Every step of the way, the scheme has been getting reduced for usability purpose.
But the problem with that approach is that it communicates that the web is "hard" instead of educating users in how to understand it and how to build on it.
And we, as technical people have not helped much here. Look at the URL up here. Yes, we know that it's hacker news but what does the ID mean? It has no semantic meaning to a user (unless you know that this is the 7678580th story on HN and care about that). A nice URL would be something like http://hackernews.com/story/google-experiments-with-URLs
Wordpress actually does this by default, even adding a date scheme to it, which makes the web a better place:
http://site.com/year/month/day/story-title-can-go-here is an easy to read URL and yes it's a pain to code properly when you're dealing with a dynamic site but hey it's our jobs to make sure we do things that are beautiful for users.
So maybe this is a wake up call.
I can now see the reasoning behind it - many people I know do not actively use the url bar except for searching. even when they want to check their facebook or favorite website, they just enter "facebook" in the url and use the (google) search results to get where they want to. for such users, the search box is much more important than the url itself, so why waste the UI space...