10 ms·

This is a new UI experiment that's deployed to a small fraction of users. We're looking at a few key metrics to see if this change is a net positive for Chrome

This is a new UI experiment that's deployed to a small fraction of users. We're looking at a few key metrics to see if this change is a net positive for Chrome users. (I imagine it may help defend against phishing). 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

nanidin 12y ago
Genuinely curious, what kind of metrics do you use to measure the effectiveness of a change like this?
- ZoF 12y ago
  I'm curious as well, specifically how would you go about tailoring those metrics to different features as they're released. Seems like that could be a pretty awesome/multi-faceted question to see the raw data behind. 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.
- joosters 12y ago
  This seems to hint that Chrome reports its settings back to Google, so they could discover how many people disabled the feature. Is this true? Does Chrome phone-home with details of user settings?
  - StavrosK 12y ago
    Yes, it asks you when you first run it.
    - RegW 12y ago
      Hmm, so I guess their stats are likely to be skewed. Being based on the choices of those that don't know or care how the web works.
      - AndrewDucker 12y ago
        Or those who are happy to contribute their behaviour despite being aware of both of those things.
      - jasonlotito 12y ago
        This is only in Canary, so these are choices being made by people who are opting in to using that version. It will be skewed toward early adopters. If you are using Canary and NOT reporting back, you don't know how Canary works and shouldn't be using it.
        altcognito 12y ago
        Should we use the "report an issue" option in Canary, or file it under: https://code.google.com/p/chromium/issues/detail?id=368725&q=origin%20chip%20url&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified#makechanges https://code.google.com/p/chromium/issues/detail?id=368725&q... ?
- antr 12y ago
  I'm going to be a cinic: if the Chrome team sees that users use Omnibox/Google more to got to the desired URL, that would be a positive thing (for them). Why type the URL when you can go via uncle Google?
  - Cthulhu_ 12y ago
    It kinda depends on the Chrome team's goals and whether those are absolute / which ones take precedence; I'd say in this case it's a compromise between usability / user-friendliness / not chasing away their users, and subtly increasing usage of google's search services. 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.
  - akerl_ 12y ago
    Except given the recent trend, too many decisions like that would likely result in LibreAlloy or something similar. They have a lot more breathing room to behave that way with gmail and Youtube and similar, where the value they are providing is in serving the content, as opposed to Chrome where the code is more or less available and their value is in developing the open source environment. 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.
    - magicalist 12y ago
      It would actually be much easier than with most products, since this is just a change in the UI. You could fork Chromium while still keeping Blink upstream, and build whatever UI you want (somewhat similar to what Opera is doing).
  - ithkuil 12y ago
    what happens if you directly paste an URL? does it still perform a search or the browser will go to the URL (and then hide it)?
- blueskin_ 12y ago
  >Implying Chrome use metrics rather than just ruining what they want and telling users to deal with it
blablabla123 12y ago
It's funny that people say not relying on URLs would be anti-web. IMHO this causation is made only on a selection of empirical observations. In fact I think, you could also draw other conclusions from empirical observations. 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.
- userbinator 12y ago
  but am I supposed to edit them as an end user or draw conclusions from their look? 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.
sandeshd 12y ago
I loved it in the start, but in development it's kind of frustration for me. Specially while doing API design you'll get frustrated easily.
tfinniga 12y ago
I agree that it's absolutely awful. 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.
- rspeed 12y ago
  > The new change would just make the whole thing a search field. 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/" http://www.facebook.com/") will default to visiting that URL.
  - tfinniga 12y ago
    I think we can probably agree that the text field on google.com is a search field. 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" 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.
yaph 12y ago
I can't imagine using a graphical browser without an address bar. Regarding the possible benefits, I think phishing would become a lot easier, if users don't see the URL any more, anyone can still link to phishing pages.
- joelanman 12y ago
  phishing should actually be harder - the only thing now shown is the domain - the important part, without the whole path to add noise
  - nnnnni 12y ago
    I think that a better way to do it would be to make the domain bold and the rest of the URL lighter.
    - billmalarky 12y ago
      Chrome already sort of does that. I guess it could be emphasized further.
kevingadd 12y ago
I respect that Google is disciplined about shipping features like this only after extensive testing, but it troubles me that despite obvious problems with this approach - like the external appearance of funneling users to Google search for all their web navigation (regardless of whether this was an intentional purpose behind the design) - it made it all the way through design, implementation, testing, and code review without anyone realizing what the reaction would be. It seems likely that if a noisy user hadn't noticed and blogged about it, this could have made it through multiple channels and gotten close to the release channel. 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.
- dredmorbius 12y ago
  I'm currently discussing the issue of vetting and "user-first" committments with a Google employee on G+, though concerning issues other than this. To put it mildly, I'm not at all convinced by developments I've seen at the company over the past 2+ years, if not longer. Actually, I'd pin this on when Gmail was first released. Prior to that, Google was simply something you used, but not as a registered user. I've since elected out of Google search as my browser's defaults.
- DouweM 12y ago
  Note that in the case of "XSS on a google-controlled domain," the malicious actor could just use JavaScript's pushState or replaceState APIs to modify the path in the address bar to "renew_subscription" or whatever.
loceng 12y ago
My guess is the real perhaps unannounced goal (?) is that Chrome wants more people using the Search bar to search Google. 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.
- pbhjpbhj 12y ago
  People do this already - they type "facebook[.com]" in to a searchbox (or addressbar with search enabled). They arrive at a SERP and click on the first link in that listing. Occasionally the first link isn't the right one, occasionally they'll notice and click the correct one! Ordinary users. 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.
pietro 12y ago
I've enabled it to try it out. First impression: 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.
- rspeed 12y ago
  That's actually fairly old behavior. If you copy the full contents (which is selected by default) it includes the protocol.
cninja 12y ago
Opera did something similar back in 2010 in v11 with the opera:config#UserPrefs|HideURLParameter configuration variable. I found I was wanting the URL information often enough that I turned the feature off. I wonder the old Opera team had any metrics they gathered.
- uptown 12y ago
  In Opera 20 I haven't found a way to re-enable fully expressed URLs. They adopted Webkit, and stripped out most of their configurability that was previously available from opera:config.
blueskin_ 12y ago
This feature is horrible.
albertsun 12y ago
It might test well in metrics, but this is the kind of thing that points out why purely data based decision making can be dangerous. A-B testing assumes users will all behave the same in the future as in the past. But people's future behavior is dependent on their present behavior and experiences. With repeated exposure to URLs more people will learn how URLs work. Hiding URLs means that people will never be able to learn.
- mreiland 12y ago
  I already really dislike that win7 hides the filepath, and lies about it in many cases. 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.
  - ndomin 12y ago
    I hope you've never used a mac in that case. Good luck finding a filepath with them. One of my biggest annoyances with mine right now.
    - vitd 12y ago
      You can choose "Show Path" from the "View" menu in the Finder. At least it isn't as hard to understand as "Enable origin chip in Omnibox".
    - LeoPanthera 12y ago
      View > Show Path Bar (⌥⌘P)
    - harywilke 12y ago
      right click on the title of a finder window.
    - Domenic_S 12y ago
      Highlight a file in Finder, press command + i. Info pane shows path. Or, drag a file from Finder to the terminal --> terminal prints the full path to the file.
alternize 12y ago
I've been using it for a few hours now. while my initial reaction was "how could they!", after a while, it's not that annoying anymore. 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...
- wtbob 12y ago
  I'm sure many people don't use the bar for anything other than searching, but I often use it as its own interface, when hacking around with REST work. I'd hate to have them remove it.
rnirnber 12y ago
It's going to be annoying for developers. We often put special query string hooks to test functionality or debug queries...it'd be kind of a pain to have to enable flag in chrome just to be able to type in the URL.
tristan_louis 12y ago
TL;DR: URLs matter; we as developers need to make them relevant again; hiding them is a terrible idea ===== 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 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 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.

nanidin 12y ago

Genuinely curious, what kind of metrics do you use to measure the effectiveness of a change like this?

ZoF 12y ago
I'm curious as well, specifically how would you go about tailoring those metrics to different features as they're released. Seems like that could be a pretty awesome/multi-faceted question to see the raw data behind. 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.
joosters 12y ago
This seems to hint that Chrome reports its settings back to Google, so they could discover how many people disabled the feature. Is this true? Does Chrome phone-home with details of user settings?
- StavrosK 12y ago
  Yes, it asks you when you first run it.
  - RegW 12y ago
    Hmm, so I guess their stats are likely to be skewed. Being based on the choices of those that don't know or care how the web works.
    - AndrewDucker 12y ago
      Or those who are happy to contribute their behaviour despite being aware of both of those things.
    - jasonlotito 12y ago
      This is only in Canary, so these are choices being made by people who are opting in to using that version. It will be skewed toward early adopters. If you are using Canary and NOT reporting back, you don't know how Canary works and shouldn't be using it.
      - altcognito 12y ago
        Should we use the "report an issue" option in Canary, or file it under: https://code.google.com/p/chromium/issues/detail?id=368725&q=origin%20chip%20url&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified#makechanges https://code.google.com/p/chromium/issues/detail?id=368725&q... ?
antr 12y ago
I'm going to be a cinic: if the Chrome team sees that users use Omnibox/Google more to got to the desired URL, that would be a positive thing (for them). Why type the URL when you can go via uncle Google?
- Cthulhu_ 12y ago
  It kinda depends on the Chrome team's goals and whether those are absolute / which ones take precedence; I'd say in this case it's a compromise between usability / user-friendliness / not chasing away their users, and subtly increasing usage of google's search services. 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.
- akerl_ 12y ago
  Except given the recent trend, too many decisions like that would likely result in LibreAlloy or something similar. They have a lot more breathing room to behave that way with gmail and Youtube and similar, where the value they are providing is in serving the content, as opposed to Chrome where the code is more or less available and their value is in developing the open source environment. 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.
  - magicalist 12y ago
    It would actually be much easier than with most products, since this is just a change in the UI. You could fork Chromium while still keeping Blink upstream, and build whatever UI you want (somewhat similar to what Opera is doing).
- ithkuil 12y ago
  what happens if you directly paste an URL? does it still perform a search or the browser will go to the URL (and then hide it)?
blueskin_ 12y ago
>Implying Chrome use metrics rather than just ruining what they want and telling users to deal with it

blablabla123 12y ago

It's funny that people say not relying on URLs would be anti-web. IMHO this causation is made only on a selection of empirical observations. In fact I think, you could also draw other conclusions from empirical observations. 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.

userbinator 12y ago
but am I supposed to edit them as an end user or draw conclusions from their look? 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.

sandeshd 12y ago

I loved it in the start, but in development it's kind of frustration for me. Specially while doing API design you'll get frustrated easily.

tfinniga 12y ago

I agree that it's absolutely awful. 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.

rspeed 12y ago
> The new change would just make the whole thing a search field. 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/" http://www.facebook.com/") will default to visiting that URL.
- tfinniga 12y ago
  I think we can probably agree that the text field on google.com is a search field. 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" 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.

yaph 12y ago

I can't imagine using a graphical browser without an address bar. Regarding the possible benefits, I think phishing would become a lot easier, if users don't see the URL any more, anyone can still link to phishing pages.

joelanman 12y ago
phishing should actually be harder - the only thing now shown is the domain - the important part, without the whole path to add noise
- nnnnni 12y ago
  I think that a better way to do it would be to make the domain bold and the rest of the URL lighter.
  - billmalarky 12y ago
    Chrome already sort of does that. I guess it could be emphasized further.

kevingadd 12y ago

I respect that Google is disciplined about shipping features like this only after extensive testing, but it troubles me that despite obvious problems with this approach - like the external appearance of funneling users to Google search for all their web navigation (regardless of whether this was an intentional purpose behind the design) - it made it all the way through design, implementation, testing, and code review without anyone realizing what the reaction would be. It seems likely that if a noisy user hadn't noticed and blogged about it, this could have made it through multiple channels and gotten close to the release channel. 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.

dredmorbius 12y ago
I'm currently discussing the issue of vetting and "user-first" committments with a Google employee on G+, though concerning issues other than this. To put it mildly, I'm not at all convinced by developments I've seen at the company over the past 2+ years, if not longer. Actually, I'd pin this on when Gmail was first released. Prior to that, Google was simply something you used, but not as a registered user. I've since elected out of Google search as my browser's defaults.
DouweM 12y ago
Note that in the case of "XSS on a google-controlled domain," the malicious actor could just use JavaScript's pushState or replaceState APIs to modify the path in the address bar to "renew_subscription" or whatever.

loceng 12y ago

My guess is the real perhaps unannounced goal (?) is that Chrome wants more people using the Search bar to search Google. 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.

pbhjpbhj 12y ago
People do this already - they type "facebook[.com]" in to a searchbox (or addressbar with search enabled). They arrive at a SERP and click on the first link in that listing. Occasionally the first link isn't the right one, occasionally they'll notice and click the correct one! Ordinary users. 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.

pietro 12y ago

I've enabled it to try it out. First impression: 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.

rspeed 12y ago
That's actually fairly old behavior. If you copy the full contents (which is selected by default) it includes the protocol.

cninja 12y ago

Opera did something similar back in 2010 in v11 with the opera:config#UserPrefs|HideURLParameter configuration variable. I found I was wanting the URL information often enough that I turned the feature off. I wonder the old Opera team had any metrics they gathered.

uptown 12y ago
In Opera 20 I haven't found a way to re-enable fully expressed URLs. They adopted Webkit, and stripped out most of their configurability that was previously available from opera:config.

blueskin_ 12y ago

This feature is horrible.

albertsun 12y ago

It might test well in metrics, but this is the kind of thing that points out why purely data based decision making can be dangerous. A-B testing assumes users will all behave the same in the future as in the past. But people's future behavior is dependent on their present behavior and experiences. With repeated exposure to URLs more people will learn how URLs work. Hiding URLs means that people will never be able to learn.

mreiland 12y ago
I already really dislike that win7 hides the filepath, and lies about it in many cases. 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.
- ndomin 12y ago
  I hope you've never used a mac in that case. Good luck finding a filepath with them. One of my biggest annoyances with mine right now.
  - vitd 12y ago
    You can choose "Show Path" from the "View" menu in the Finder. At least it isn't as hard to understand as "Enable origin chip in Omnibox".
  - LeoPanthera 12y ago
    View > Show Path Bar (⌥⌘P)
  - harywilke 12y ago
    right click on the title of a finder window.
  - Domenic_S 12y ago
    Highlight a file in Finder, press command + i. Info pane shows path. Or, drag a file from Finder to the terminal --> terminal prints the full path to the file.

alternize 12y ago

I've been using it for a few hours now. while my initial reaction was "how could they!", after a while, it's not that annoying anymore. 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...

wtbob 12y ago
I'm sure many people don't use the bar for anything other than searching, but I often use it as its own interface, when hacking around with REST work. I'd hate to have them remove it.

rnirnber 12y ago

It's going to be annoying for developers. We often put special query string hooks to test functionality or debug queries...it'd be kind of a pain to have to enable flag in chrome just to be able to type in the URL.

tristan_louis 12y ago

TL;DR: URLs matter; we as developers need to make them relevant again; hiding them is a terrible idea ===== 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 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 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.