Hacker News new | past | comments | ask | show | jobs | submit login

In general, that's the sane argument against feature bloat.

In this instance, is the effort required to maintain a layout option really that much more? I don't know the answer, it's a genuine question.

Also, was there no benefit? I didn't even realize the feature existed because I searched for it before it was introduced and moved to Firefox.

I know nothing about the history of this feature in Chrome, but from 10000 feet, this looks like a heavy handed move to remove a feature instead of making it optional, especially in the times of large + tall touchscreens.

Disclaimer: I don't know what I'm talking about, there may be, and probably are some good reasons for these.




It's clearly a "controversial" decision by the Chrome team, but IIRC they have a fairly strict rule about "options", so they seem to like to err on the side of "less options" in most cases.

But in terms of the "cost" of something like this. When you run at Chrome's scale, it can be quite a bit. From documentation, help articles, UI team costs (okay now we need to make sure all UI changes look good and work well in both configurations), development costs (when 1% of your users represent over 10 million people, there is a WIDE configuration of devices it runs on), and testing cost (either automated or manual, it scales VERY poorly with the number of options as possible permutations required to fully test it goes up at an insane rate).

At a certain scale, the better option (at least in my opinion) is to "choose" for the user if you are fairly confident that the extreme majority will be happy with it, doubly so if the default option doesn't "break" anything for most.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: