Live data from Hacker News

Chrome 69: “www.” subdomain missing from URL

bugs.chromium.org

211–220 of 919 posts

Re: Chrome 69: “www.” subdomain missing from URL

#211

Earlier quoted context omitted.

You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name. It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes m…

Clicking doesn't reveal the URL. You have to click and use the left arrow key, at which point the protocol and www prefix appear. Just like when Chrome hid the protocol part of the URL, you can even click in the URL bar and copy it without seeing the protocol (or, now, www prefix) at all. I think it results in a confusing experience when you paste it. (Ordinary users will say: "I copied example.com but I pasted https…

Or double-click - basically get into the editing mode of the URL bar.

Re: Chrome 69: “www.” subdomain missing from URL

#213

Earlier quoted context omitted.

>there's a difference between "www.example.com" and "example.com" Can you link to a site where these two are different?

From one of the comments there: http://www.pool.ntp.org vs http://pool.ntp.org One takes you to the website about the project, the other goes to a random ntp server.

Those go to the same place for me

Re: Chrome 69: “www.” subdomain missing from URL

#214
post #30

This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties wit…

You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name. It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes m…

> This is just making it easier for the average user to see the most important thing to them, which is the domain name. It's not like they're just changing stuff randomly.

Can you link to the user study or general cost/benefit analysis or something else saying it's not random? I'm having a hard time concluding that the cost of removing parts of a domain name only in some cases is outweighed by the benefit of removing a few characters from the user's address bar.

Re: Chrome 69: “www.” subdomain missing from URL

#216
post #60
post #30

This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties wit…

99.9% of users have no idea what any of the words you just said mean. The change was made for them, not for you (the .1%)

99.9% of users don't know either way. The change neither improves nor harms their experience, it merely obfuscates what's actually going on under the guise of "user friendly."

Re: Chrome 69: “www.” subdomain missing from URL

#217

Earlier quoted context omitted.

>The change was made for them, not for you Except, those same users also don't care about things in the address bar. So the change hurts the group of users that actually do care.

They didn't care so far because it was so confusing. The hope is that by showing something that's user-relevant (the name of the website name and the security level), it will become more useful for the average user. Why should a user see: https://www.wikipedia.org/wiki/Canada?utm=asdioasd&arg=j210d... when all they care about is "Wikipedia.org/wiki/Canada"?

Because arguments aren't always useless like in your example. Might as well just do away with the whole URL bar and just have a green checkmark if Chrome thinks it's the site you want.

I mean, why should a user see "Wikipedia.org/wiki/Canada" when all they care about is "This is the Wikipedia Page for Canada"?

Re: Chrome 69: “www.” subdomain missing from URL

#218

Earlier quoted context omitted.

>The change was made for them, not for you Except, those same users also don't care about things in the address bar. So the change hurts the group of users that actually do care.

They didn't care so far because it was so confusing. The hope is that by showing something that's user-relevant (the name of the website name and the security level), it will become more useful for the average user. Why should a user see: https://www.wikipedia.org/wiki/Canada?utm=asdioasd&arg=j210d... when all they care about is "Wikipedia.org/wiki/Canada"?

I like how HN cuts off the end of that url.

Re: Chrome 69: “www.” subdomain missing from URL

#219
I am in favor of the change. I do not think hiding technical information from non-technical users is a bad thing. Making it impossible for technical users to work it out is the bad thing.

If technical users want their own browser mode, where all these things are readily available, then I'd be all for that.

Clicking on the browser location bar should reveal the full URL. But the noise of the protocol, the www. prefix, and the param string is all irrelevant to the experience of the casual user of web browsers and should indeed be hidden. We're already hiding a ton of stuff from them already, if you want to go see it, you can always "view source".

One argument in the thread was that 'www.pool.ntp.org' and 'pool.ntp.org' go to a website and a nameserver respectively. Nontechnical users will never want to use a web browser to access a nameserver, so there's no UX benefit to distinguishing them. From a URL entry standpoint, it should go to the URL that was typed into the location bar. There isn't a conflict.

Re: Chrome 69: “www.” subdomain missing from URL

#220

Earlier quoted context omitted.

From one of the comments there: http://www.pool.ntp.org vs http://pool.ntp.org One takes you to the website about the project, the other goes to a random ntp server.

Those go to the same place for me

Some small subset of pool servers run an HTTP server that redirects you to www. Not all of them. You just got lucky.
Post reply on HN