4 ms·

As usual, they have chosen the worst possible "solution": removed the shortcut, didn't add an option. They did miraculously have time to flash up the two-key sh

As usual, they have chosen the worst possible "solution": removed the shortcut, didn't add an option. They did miraculously have time to flash up the two-key shortcut for back though, when they detect you pressing backspace multiple times. Instead of, you know, taking that opportunity to show a simple popup of "do you want backspace to browse back?". So now everyone has to install an extension that in the usual Chrome fashion can "read and change all your data on websites you visit." I think for the next kind of feature they remove this way I'll add an extension that initially works and then have it auto-update to redirect people from everywhere to a petition site after a random interval. Just to point out the insanity in pouring lots of effort into security, sandboxing and even SSL only to force people to install auto-updated untrusted extensions that can access everything to bring back a minor keyboard shortcut. This is the exact kind of annoyance that will see people click yes yes yes on all kinds of red flashing security warnings.

ubernostrum 10y ago
removed the shortcut, didn't add an option That's the right way. "Never really remove anything, just wrap it in a default-off config option" is a horrendously bad way to build software. Every configurable option is an opportunity for bugs and an opportunity for misconfiguration.
- revelation 10y ago
  If you are going to argue this, you might just as well start arguing that no programmer is allowed more than a quota of 10 ifs per month. Every conditional branch in your program is "an opportunity for bugs and an opportunity for misconfiguration". This is the equivalent of hoisting a white flag. Theres tons of code added to Chrome all the time, it doesn't add configuration options but it sure as hell has the very same effect.
  - geofft 10y ago
    An if is just an inconsistent goto, so, yes. if is often a code smell. For instance, any code like x = some_result() if is_valid(x): do_stuff_with(x) is indisputably an opportunity for bugs. Better would be some construct like "if let" in Swift or Rust, where you can't use x without the condition. For instance, this was the fundamental cause of Apple's "goto fail" vulnerability: the language / API style required that they check each result and run a conditional branch on their own. (The proximate cause was bad language syntax, but the opportunity for bad syntax shouldn't have been there in the first place.)
- BGZq7 10y ago
  I think it depends on the reason for the change. If the reason is primarily to reduce complexity or remove a buggy feature, it would make sense to remove the feature entirely from the code. In this case, the shortcut is being removed because it's often unintentionally triggered by people who are not familiar with it, however there are also a lot of people who intentionally use it frequently. It could be reasonably argued that something like that should be configurable.
- userbinator 10y ago
  That attitude really fucking pisses me off. Not every user is the same. Everyone's needs are different and that is what configuration is for. Stop treating your users like they're all idiots who want exactly the same thing, or that's what you'll really end up with. There is no one-size-fits-all solution.
  - ubernostrum 10y ago
    > There is no one-size-fits-all solution. Meanwhile, long experience has shown that making things configurable instead of just removing features leads to... bugs and misconfiguration. There's a reason why this is widely considered an antipattern in UI; it should be an antipattern in code as well. Not every feature needs to exist, and if not enough people use something, or if it interferes with other features more often than it's directly used (as I suspect is the case with backspace), then it should be removed.
    - another-dave 10y ago
      Does that not depend on the software though — the likelihood that you have "powerusers", the difference in usage between novices & power-users, the learning curve, etc. etc. Look at something like Photoshop — the level of configuration options is immense, but thousands of professionals use it daily without issue. It just has sensible defaults that can be restored easily.
      - ubernostrum 10y ago
        This may be the first time I've ever heard someone seriously praise Photoshop for good UI or software design. Most of the people I know who work with it just barely tolerate its UI and its incessant bugs. Wonder if that has anything to do with trying to support everything everyone ever thought of? :)
- davb 10y ago
  > That's the right way. It's the lazy way. You're right that it adds complexity. Every line of code contributes to complexity, and increases the number of places a bug could manifest. That's just the nature of software development. Most software doesn't exist in a bubble of strictly-defined use cases. Software such as web browsers target a huge (potentially the broadest) range of users. Driving towards the lowest common denominator, as Google have been doing with Chrome by stripping configuration options over the years, doesn't result in a product people love to use. It produces software that performs adequately for the majority, and nothing more. For features like "backspace to navigate back", throw them behind a flag. Make them default-disabled. Don't even worry about putting it in Preferences - tell power users who need it where they can find it (chrome://flags).
  - ubernostrum 10y ago
    If you want an infinitely-customizable web browser which has everything available in a config option you're free to write one; multiple high-quality open-source engines are available to build around. Not every feature is good or widely-used, and removing the ones that fail, rather than trying to keep them around but configurable, is simply the right thing to do.
    - another-dave 10y ago
      You say "removing ones that fail", but surely that's the point here — it only fails for users who don't know what's going on. If I deliberately reenable backspace as 'Back in browser history', I've no right to complain if I lose web app state; and if I get burned often, I'll disable it again. If I use it without any problems, what's the lose on Google's side?
      - random_rr 10y ago
        Exactly. Taking your thought a step farther... You can enable the shortcut yourself via extensions! That way, there's no loss in Google's side. :) they don't have to maintain an obsolete feature, and any problems are yours, not theirs. You seem to have made their point for them. Less code base to cover. Less tests. That's a win for the secs. And you're free to install an extension to retrieve the behavior of you want. Sounds like everyone wins.

ubernostrum 10y ago

removed the shortcut, didn't add an option That's the right way. "Never really remove anything, just wrap it in a default-off config option" is a horrendously bad way to build software. Every configurable option is an opportunity for bugs and an opportunity for misconfiguration.

revelation 10y ago
If you are going to argue this, you might just as well start arguing that no programmer is allowed more than a quota of 10 ifs per month. Every conditional branch in your program is "an opportunity for bugs and an opportunity for misconfiguration". This is the equivalent of hoisting a white flag. Theres tons of code added to Chrome all the time, it doesn't add configuration options but it sure as hell has the very same effect.
- geofft 10y ago
  An if is just an inconsistent goto, so, yes. if is often a code smell. For instance, any code like x = some_result() if is_valid(x): do_stuff_with(x) is indisputably an opportunity for bugs. Better would be some construct like "if let" in Swift or Rust, where you can't use x without the condition. For instance, this was the fundamental cause of Apple's "goto fail" vulnerability: the language / API style required that they check each result and run a conditional branch on their own. (The proximate cause was bad language syntax, but the opportunity for bad syntax shouldn't have been there in the first place.)
BGZq7 10y ago
I think it depends on the reason for the change. If the reason is primarily to reduce complexity or remove a buggy feature, it would make sense to remove the feature entirely from the code. In this case, the shortcut is being removed because it's often unintentionally triggered by people who are not familiar with it, however there are also a lot of people who intentionally use it frequently. It could be reasonably argued that something like that should be configurable.
userbinator 10y ago
That attitude really fucking pisses me off. Not every user is the same. Everyone's needs are different and that is what configuration is for. Stop treating your users like they're all idiots who want exactly the same thing, or that's what you'll really end up with. There is no one-size-fits-all solution.
- ubernostrum 10y ago
  > There is no one-size-fits-all solution. Meanwhile, long experience has shown that making things configurable instead of just removing features leads to... bugs and misconfiguration. There's a reason why this is widely considered an antipattern in UI; it should be an antipattern in code as well. Not every feature needs to exist, and if not enough people use something, or if it interferes with other features more often than it's directly used (as I suspect is the case with backspace), then it should be removed.
  - another-dave 10y ago
    Does that not depend on the software though — the likelihood that you have "powerusers", the difference in usage between novices & power-users, the learning curve, etc. etc. Look at something like Photoshop — the level of configuration options is immense, but thousands of professionals use it daily without issue. It just has sensible defaults that can be restored easily.
    - ubernostrum 10y ago
      This may be the first time I've ever heard someone seriously praise Photoshop for good UI or software design. Most of the people I know who work with it just barely tolerate its UI and its incessant bugs. Wonder if that has anything to do with trying to support everything everyone ever thought of? :)
davb 10y ago
> That's the right way. It's the lazy way. You're right that it adds complexity. Every line of code contributes to complexity, and increases the number of places a bug could manifest. That's just the nature of software development. Most software doesn't exist in a bubble of strictly-defined use cases. Software such as web browsers target a huge (potentially the broadest) range of users. Driving towards the lowest common denominator, as Google have been doing with Chrome by stripping configuration options over the years, doesn't result in a product people love to use. It produces software that performs adequately for the majority, and nothing more. For features like "backspace to navigate back", throw them behind a flag. Make them default-disabled. Don't even worry about putting it in Preferences - tell power users who need it where they can find it (chrome://flags).
- ubernostrum 10y ago
  If you want an infinitely-customizable web browser which has everything available in a config option you're free to write one; multiple high-quality open-source engines are available to build around. Not every feature is good or widely-used, and removing the ones that fail, rather than trying to keep them around but configurable, is simply the right thing to do.
  - another-dave 10y ago
    You say "removing ones that fail", but surely that's the point here — it only fails for users who don't know what's going on. If I deliberately reenable backspace as 'Back in browser history', I've no right to complain if I lose web app state; and if I get burned often, I'll disable it again. If I use it without any problems, what's the lose on Google's side?
    - random_rr 10y ago
      Exactly. Taking your thought a step farther... You can enable the shortcut yourself via extensions! That way, there's no loss in Google's side. :) they don't have to maintain an obsolete feature, and any problems are yours, not theirs. You seem to have made their point for them. Less code base to cover. Less tests. That's a win for the secs. And you're free to install an extension to retrieve the behavior of you want. Sounds like everyone wins.