6 ms·

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

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

dhimes 7y ago
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).
- driverdan 7y ago
  Green bar for payments?
  - deadmutex 7y ago
    Enterprise SSL certs, I think.
  - cpeterso 7y ago
    The EV (Extended Validation) certificate notification inn the address bar was removed in Firefox and Chrome: https://www.bleepingcomputer.com/news/software/chrome-and-firefox-changes-spark-the-end-of-ev-certificates/ https://www.bleepingcomputer.com/news/software/chrome-and-fi...
zamadatix 7y ago
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.
- gdfasfklshg4 7y ago
  The lesson is don't change for the sake of change.
  - zamadatix 7y ago
    If you think of a standard user: - Do they really need to see* http:// http:// or https:// 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".
    - franga2000 7y ago
      > 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.
      - zamadatix 7y ago
        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.
dmix 7y ago
What's the story with Chrome messing up URLs? I missed that one...
- zamadatix 7y ago
  They elide the protocol and www E.g. "<lock icon> https://www.google.com/example/" https://www.google.com/example/" would display as "<lock icon> google.com/example" until you interact with the URL.

dhimes 7y ago

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

driverdan 7y ago
Green bar for payments?
- deadmutex 7y ago
  Enterprise SSL certs, I think.
- cpeterso 7y ago
  The EV (Extended Validation) certificate notification inn the address bar was removed in Firefox and Chrome: https://www.bleepingcomputer.com/news/software/chrome-and-firefox-changes-spark-the-end-of-ev-certificates/ https://www.bleepingcomputer.com/news/software/chrome-and-fi...

zamadatix 7y ago

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.

gdfasfklshg4 7y ago
The lesson is don't change for the sake of change.
- zamadatix 7y ago
  If you think of a standard user: - Do they really need to see* http:// http:// or https:// 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".
  - franga2000 7y ago
    > 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.
    - zamadatix 7y ago
      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.

dmix 7y ago

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

zamadatix 7y ago
They elide the protocol and www E.g. "<lock icon> https://www.google.com/example/" https://www.google.com/example/" would display as "<lock icon> google.com/example" until you interact with the URL.