Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Don't be ridiculous. The idea that you should force your users to adopt your (well intentioned, well thought-out) preferences with no options is a very recent idea, and its only adherents are coders and designers. While users don't necessarily like hunting for options, they don't like when they are taken away (ask the Pidgin people, for a well documented fork which happened because of this idea).

The suggestion that this causes the 30 second delay is crap. An empty firefox takes about 2 seconds to load for me; a new window takes seconds. My experience (and a cursory chat with firefox devs) is that it is really memory usage which slows firefox down, and I believe this is being helped in the new version.

100k lines is total exaggeration. I'd suggest that checking for the flag is one line, and implementing it the other way is less than 1000 lines (I would think less than 100, but I'll leave myself some breathing room). It's not like they can remove the whole about:config thing just because this one button is gone.

And if you think that removing a checkbox that nobody uses will make a "noticeably better browser", then you are dreaming.



This comes up pretty often, and there's plenty of literature available that explains better than I can why adding choices actually makes users less happy. Here's one:

http://www.joelonsoftware.com/items/2006/11/21.html

As to the level of effort to get that feature in and maintained, there's plenty of literature out there too documenting the perils of the "you can add this in 5 minutes" feature. For this one, you'll need:

- changes to the settings page

- logic to store the setting

- two parallel rendering paths for the window chrome

- checks everywhere that tabs are touched and special case logic for things that work differently when tabs are in their old location

- special case handling for all future features going forward (such as their new popups) to deal with two possible tab placements.

- unit tests for all the above

- bug fixing for all the above

- maintenance for all the above

- support for all the above

- documentation for all the above

It's a lot of stuff, measured in man years of effort over the lifetime of a software project as big as Firefox. And they can eliminate it all with a simple executive decision.

Tabs are moving to the top of the browser. They've done the research themselves and come to that conclusion. By both moving and not moving them in their next release, they're only making things hard for themselves.


  It's a lot of stuff, measured in man years of effort over 
  the lifetime of a  software project as big as Firefox. 
  And they can eliminate it all with a simple executive 
  decision.
They can eliminate 100% of their codebase, 100% of their bugs, and 100% of their support issues with a "simple executive decision" as well. So what? If you're going to build and distribute any kind of tool, you have to strike the right balance between the issues of flexibility, performance, ease of use, etc. But saying "strip out choices as a wholesale maneuver" is not even striving for balance.

The only positive thing I can say about this mindset is that, since so much software is open source these days, at least forks can be created when products err too far on one side or the other of one of these lines. But is all that duplicated effort really benefiting the community?


Apple tried to move to top tabs in Safari with no easy option to switch back and got major complaints. Despite the four reasons in the video, a lot of people like the tabs the way they are and changing it will just drive them away. Or worse, it will keep people on Firefox 3.5.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

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

Search: