Hacker News new | comments | show | ask | jobs | submit login

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

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.

> While I can see the anti-phishing advantages of emphasizing the domain

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.

> 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/") will default to visiting that URL.

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

> In cases where the google search gives the wrong response, chrome gives the same wrong response, for example on intranet servers.

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.

I agree, intranet addresses mostly work. For those that don't work, there are workarounds, like specifying the protocol or adding /. Personally, I'm happy with the current omnibox behavior.

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.

My experience is that chrome works great with intranet addresses if you fully type them out. "gerrit.gps" searches for the string "gerrit.gps". I have to fully type out "http://gerrit.gps" to get to our gerrit server.

Usually for me it loads the search results, but also puts a "did you mean http://gerrit.gps" at the top. Clicking yes to that also remembers it for the future. I'm totally cool with this approach.

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

In other words: what Chrome has already done for a very long time.

except where chrome (or safari) mistakes a url for a for search terms. OT, I know, but since the advent of the "unified search" boxes, I have returned to the late nineties and type "http://" with all my urls because chrome and safari get it wrong so often.

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.

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.

I hate that copying the domain in a modern browser copies the protocol along with it. Highlight just "google.com", copy. Paste it and what is pasted? "http://google.com/". Makes dig/whois really annoying.

Related: Microsoft's decision to hide file extensions by default was arguably one of the worst UI mistakes of all time, leading to naive users launching coolpic.jpg.exe because all they saw was coolpic.jpg, among many other problems.

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.

I think it's quite ironic that you just received four different suggestions of how to solve this problem. None of that would even be necessary if they didn't try to hide the information in the first place.

Apple never showed the path prominently in the first place. Since System 7 you can Cmd-Click the title bar to show a menu with the path, and you can use Cmd-I to show the path in the Info panel.

Not including a path bar by default doesn't mean they "try to hide the information", it's just a different UI design.

One step left until the "recently viewed" filesystem, where paths are a backwards-compatibility bug. That's when you notice you didn't age well...

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

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.

View > Show Path Bar (⌥⌘P)

Drag a file to the terminal.

right click on the title of a finder window.

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.

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.

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

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?

I can actually imagine a lot of users liking that - many people I've seen using a browser will just type stuff in to Google's homepage search box and then follow links. The classic example, yes I've seen it, is people typing Hotmail/Live/Outlook in to Google and then following the link rather than typing in the address [my 8yo did this recently for another site].

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.

I think that's an ok thing. I used to scoff at this sort of behavior but no longer - users who do this are just doing the same thing I do in the address bar, except they're taking up a whole page and an extra click. The address bar is probably too ephemeral and hard to understand.

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

The cynical view is they want people to share using Google+ instead of just sending a URL. The "Share" button is already central to most browsers, but is still uncommon on the desktop.

Of course, that way google can build up more of a profile on them.

"Don't be evil" gave way to "Invading privacy for fun and profit" long 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.

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.

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

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)?

If it is a valid url, it goes to it.

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?

Yes, it asks you when you first run it.

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.

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.

Should we use the "report an issue" option in Canary, or file it under:



Or those who are happy to contribute their behaviour despite being aware of both of those things.

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.

>Implying Chrome use metrics rather than just ruining what they want and telling users to deal with it

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.

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.

Yeah and the "otherwise computer-illiterate" may also think: oh wow, this is a cool feature I should rely on. Eventhough you can just paste the Youtube URL into the comment field and get a nicely formatted link.

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.

They might've changed it with the new comments system, but I know that links of any sort were completely disallowed not long ago. Nevertheless, I still see the posting of bare video IDs in many recent comments.

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

I do think there should be more of a focus on URNS rather than URLs, and his could help.

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.

To me, the question wasn't so much "does it make Youtube more succesful", but rather "does it allow people to notice patterns in the URL and deduct things useful to them from that".

>Most URLs are not human readable, even HN is an example

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.

A confession: I sometimes edit the gmail URLs by hand. In particular, I'm often using multiple google accounts and find that after restarting the browser (or something) a tab's account changes to something else than what I wanted. So I like having the option to just change the user id - the zero based integer in gmail URLs ("https://mail.google.com/mail/u/0/#inbox"). Also, in other contexts, such as google sign in, this id appears as the authuser GET param.

> I somehow like looking at URLs but am I supposed to edit them as an end user or draw conclusions from their look?

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

Even if the URLs on HN or various newspapers are not very human friendly, at least one can copy and save them. How do you propose doing that without URLs?

I'm not saying that URLs are superfluous. But I think their function is exaggerated. Especially when it comes to Web Apps, but even in the case of articles in which hyperlinks are really useful and used a lot. They often seem like C pointers on which you better don't do any arithmetics. But unlike C pointers, often I cannot dereference them. ;)

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.

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.

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.

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.

phishing should actually be harder - the only thing now shown is the domain - the important part, without the whole path to add noise

I think that a better way to do it would be to make the domain bold and the rest of the URL lighter.

Chrome already sort of does that. I guess it could be emphasized further.

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.

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.

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.

it made it all the way through design, implementation, testing, and code review without anyone realizing what the reaction would be.

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.

So XSS attacks and phishing scams don't matter? People who don't want their family's credit card details and passwords stolen by thieves are weenies?

I'm including myself in that group. And yes? Or at least will-be-dismissed-by-google-as-weeines-once-they-decide-what-is-right-for-everyone. But that doesn't roll off the tongue very well.

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.

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.

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

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

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

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.

This feature is horrible.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact