- Do they really need to see* http:// or https:// if immediately to the left is the icon which indicates secure/insecure (which is more than just "protocol is https or not")?
- Do they really care to see* if they are at www.site.com or m.site.com or site.com or do they just want to know they are at site.com which they expect to be as they make their purchase or log in?
* noting that bookmarking, copying, or editing the URL operate on the full URL and this is just a visual change otherwise
And voila now the leftmost (first) text they read is not a bunch of jargon it's the thing people look at the URL for the most.
That you couldn't think of any reason tells me you didn't try not that you disagreed with the reasons and had an actual lesson to share about why. Again: "it changed, change bad" people impossible to distinguish from "it changed, actually bad".
While somewhat a bad form for general web browsing, its definitely possible for www.site.com and site.com to be entirely different hosts. In newer versions of Chrome, you would never know which one you were actually on unless you select in the address bar.
Maybe dropping the protocol definition in the URL is debatable, as probably 99.99% of the time in Chrome a user is going to be either http or https, but dropping a part of the hostname is unacceptable in my book.
Would dropping .com be acceptable? All a user wants to see is that they went to Google, to an average user the .com could be seen as redundant clutter as well. Might as well have the address bar show "google" or "cnn" or "facebook" in it, as clearly that's what a user cares about.
Possible and reasonable are different things. If www.google.com gave you gmail and google.com gave you search users were confused before www was hidden post load.
You can't really get rid of the TLD without breaking the security model of the web (e.g. a lock icon and google.com is different than a lock icon and google.gtld). Would it be nice to refactor that? Probably. Is it reasonably possible at this point? No.
> Do they really care to see* if they are at www.site.com or m.site.com or site.com or do they just want to know they are at site.com
www.example.com == example.com is an assumption that has never been true and I have seen it screw over regular users countless times. Quietly rewriting the URL and hiding that fact will just make that worse.
As for m.example.com, that is even further from standardized. Me and and at least one person I know have personal websites with short aliases like mike.lastname.tld == m.lastname.tld, not to mention the plethora of sites that don't have matching paths on mobile vs desktop. Even if copying the URL quietly switches it out for the real one (which is bad on its own), that break the surprisingly common workflow of writing down the URL you see on a piece of paper.
Thank you for talking about a real use case :). The m. causing a new workflow issue to be introduced is exactly why they decided "m." should not be treated as a trivial subdomain when they rolled it out, it was only that way during testing.
As you said www.example.com being functionally different from example.com was already a broken workflow, users weren't differentiating it. Continuing to display something users haven't understood for 20 years was not considered a strong enough reason to simplify the URL display now in a way that causes the same errors users were commonly making anyways.
You mean the strawman repeatedly trotted out by people defending shitty changes as justifications for why their shitty change is necessary? Ever wonder why so many things suck nowadays?
Nope, just mean "not the guy that writes the webapp who needs to see if he is currently connected via HTTP or HTTPS".
Can "the larger group" be used as an excuse for a bad change? Sure! But so far the only reason mentioned as to WHY this change is bad is "www.site.com and site.com could technically be different sites" and I'm not sure how that is supposed to be clear regardless if www shows post load or not or how that's supposed to outweigh the advantages.
> Nope, just mean "not the guy that writes the webapp who needs to see if he is currently connected via HTTP or HTTPS".
HTTP currently shows "Not secure" to the left of the URL. It's still easy to differentiate.
(I do think hiding www is stupid, but hiding http vs https is reasonable so long as they're still marked differently. Ideally http should be a more noticeable error, like it is if there's any user input box, or better yet a massive error like it is for self-signed certs and HTTPS.)
- Do they really need to see* http:// or https:// if immediately to the left is the icon which indicates secure/insecure (which is more than just "protocol is https or not")?
- Do they really care to see* if they are at www.site.com or m.site.com or site.com or do they just want to know they are at site.com which they expect to be as they make their purchase or log in?
* noting that bookmarking, copying, or editing the URL operate on the full URL and this is just a visual change otherwise
And voila now the leftmost (first) text they read is not a bunch of jargon it's the thing people look at the URL for the most.
That you couldn't think of any reason tells me you didn't try not that you disagreed with the reasons and had an actual lesson to share about why. Again: "it changed, change bad" people impossible to distinguish from "it changed, actually bad".