4 ms·
The issue here for me would be the difference between 'removing' and 'turning off by default'. I don't mind if I can turn the bar back on and put it where I li
by 51Cards 15y ago
The issue here for me would be the difference between 'removing' and 'turning off by default'. I don't mind if I can turn the bar back on and put it where I like it as I consider it to be an essential item for me. If it's just a case of turning it on then no biggie.
I registered a lot of complaints over the removal of the status bar text at the bottom of FF4, and the fact that I now have to run an add-on to get that functionality back. It could have EASILY been made an optional element, off by default, but dragged back into place via toolbar customization. As long as you maintain the option to restore classic GUI options then altering the defaults for the 'typical user' doesn't bother me much. But don't remove something entirely and go 'So sorry, too bad.' when it would have been easy to maintain the option.
- StuffMaster 15y ago>removal of the status bar text at the bottom of FF4 Hell yeah, that was stupid. I really hate the new one for many reasons, one of which is that I have to search for it whenever I hover over a link. And whey the hell can't I turn it back on??? As usual, Seamonkey keeps what Firefox changed to stupid.
- jokermatt999 15y agoExactly. In my opinion, one of the worst things a designer can do is have an attitude of "My change is better, deal with it". It presumes that everyone who uses their product will have a use case similar to them, and the people that don't are screwed. When the change made is actually good, designers will get praised for a "bold new vision" and such. When it goes wrong, it pisses off a lot of people, often to the point where they'll switch to a competitor. Think before you remove that option. "Clean design" isn't worth a damn if your product has become less useful as a result.
- kristiandupont 15y agoBut this is the only way to make progress. There will always be users who oppose changes and maintaining old features cost. Microsoft manages this very well (you can basically make Windows 7 look like 95 if you want) but at a great price. They spend many resources maintaining this compatibility and if they didn't they would have been able to make new software much faster.
- throwaway32 15y agoignoring people's concerns en masse and introducing something almost nobody cares about or wants is not "the only way to make progress".
- kristiandupont 15y agoThe possibility to install an add-on is an option to get the classic GUI back - one that doesn't add to the download size of the program and more importantly, that doesn't create noise in the code base. Maintaining one small feature seems easy but they accumulate.
- 51Cards 15y agoIn my personal opinion offsetting a few KB of extra download size with perhaps years of system resources lost to run an extra add-on makes no sense for something that has been there all along. Not to mention that removal of the 'status bar' required the addition of a new bar to hold Add-Ons, the code to overlay the link preview on the URL bar is far more complex than a single status label, etc. The status text removal made the code more complex, making it a draggable element would have been peanuts extra. Not saying it applies to every case but this one was about as simple as it can be.
- jpk 15y agoI think requiring an addon is optimal, and I'll explain why. I see "why can't it just be an option?" a lot. Maintaining an option has a cost. Every option introduced in software creates an additional code path that must be maintained, and must be made to play nice with other features and their options. This can add up rather quickly, especially when options have many subtle interactions with other options. It's not about how easy one option is to maintain, it's about how easy all options are to maintain when we decide to add this one. In the case of the addon, however, the cost of the option is removed from the main code base and the developers who work in it, and shifted to the addon which is (presumably) maintained by developers who care about the feature. In this way, the cost of the feature is distributed over code and development effort that best serves both the users who care about feature in the addon, and the project's user/developer community as a whole. With the only caveat that the addon api must be sufficient, the addon solution is optimal. There's a mentality that moving a feature to an addon/plugin/whatever makes it a second-class citizen, but I think in most situations, if executed correctly, it's better than trying to maintain it as an integrated feature.