Hacker News Reader

Comment by School-Cotton | Hacker News Reader

> After the recent missteps by Chrome (mangling the display of URLs)

Me too! I'm not as bothered by software-politics as many of the commentators on here (I don't hate Facebook, and worked there for four years; I don't hate ads; I don't worry too much about trafficking and privacy...) but Chrome fucking with the URL was a bridge too far. I switched to Firefox and when Google walked back their hiding-the-URL business, I never bothered switching back, because I didn't trust them anymore.

Companies take note: users' trust that you won't arbitrarily change their workflow in annoying ways is hard to win back.

View on HN

Yeah I'm still a little pissed about not getting the green bar for payments (and definitely about not being able to see 'https' to verify it).

Green bar for payments?

Enterprise SSL certs, I think.

The EV (Extended Validation) certificate notification inn the address bar was removed in Firefox and Chrome:

https://www.bleepingcomputer.com/news/software/chrome-and-fi...

What's the story with Chrome messing up URLs? I missed that one...

They elide the protocol and www

E.g. "<lock icon> https://www.google.com/example/" would display as "<lock icon> google.com/example" until you interact with the URL.

The problem is it's impossible to separate "this changed it sucks" from "this is actually bad" since the messages are always the same. E.g. in this case you didn't even bother explaining why the new way works worse for you you just said "it changed, I left! Make note!" and I mean that's fine if that's what you actually wanted them to make note of but no company with competition is just going to keep every workflow the same for over a decade and wait for someone else to come out with a better product to replace them.

The lesson is don't change for the sake of change.

If you think of a standard user:

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

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

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.

> If you think of a standard user

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

I don’t care what “a standard user” needs, so what is your point?

I care what I need.

A standard user was probably fine with something like AOL keywords.

Yes, it requires competency and there may not even be a right answer.

In general I prefer to use tools that show me real data rather than transforming it in “smart” ways that are poorly documented and not under my control.

If other people have different preferences, that’s fine! They can keep using Chrome.

Also, even if that weren’t true, change is a cost. It’s perfectly reasonable to complain about change as being intrinsically bad without giving any other reason.

Reply on news.ycombinator.com