Ken Coar complains about some of the changes in FireFox 2.0 and mentions:
My basic plaint is as usual: when changing the user interface, don't violate the Principle of Least Astonishment and force the change on the user. Make it the default, perhaps, but always provide a preference option that lets the user keep the old UI behaviour. The user should be in charge of changing his work habits, not the software.
I couldn't possibly disagree more. The rule is if you're going to force the user to change their behavior – make sure it benefits them. In other words, don't make changes that make your interface less efficient and less easy to use. Preferences are not something that make people more efficient – the preference dialog in almost every application is confusing for users and generally unfriendly, the more stuff you put there the worse it gets. You need to keep the number of preferences to a minimum – focussing only on those areas where user needs are truly different – and make your UI encourage pr enforce the most productive work habits (while balancing intuitiveness).
If you make a bad change to your UI that's a problem, but adding a preference to revert it isn't a solution, it's a second problem you've introduced.
Asbjørn Ulsberg says:
Although I agree that adding junk to a preference dialog isn’t always a good solution, I agree with Ken in this particular case. Using Firefox as my primary browser is completely out of the question because of the way tabs work in 2.x. Not that it’s likely I’ll switch from Opera anyhoo, but every time I have to use Firefox, those close buttons and the tab behavior annoys me like a blood thirsty mosquito when I’m trying to sleep.
Adrian Sutton says:
Asbjørn,
I think you slightly missed the point – you shouldn’t mess up your UI in the first place. Given the number of people who complain about this feature and the solid arguments for why having the button on the far right is more efficient, the change should have been made.
More importantly, there isn’t a need to pick one or the other in this case – you could have a permanent close button in the far right and a button on the tab that appears when you hover over it (it is more intuitive to have the close button on the tab when you only want to close one tab).
There’s probably other creative solutions to the problem that would work better than either of those too, it’s just a matter of taking the time to actually do the UI design work instead of just slapping in another preference and considering it solved.
Asbjørn Ulsberg says:
I agree that the UI shouldn’t have been messed up. But I’m pretty sure that when they did, it was for a reason and that there’s now a large number of people finding the new style better than the old one. The ones hating the new one aren’t left much choice, though, since there isn’t an option to switch back.
Anonymous says:
Then they needed to find a way to actually please both camps – like putting the close button in both places. It’s not simple to do, but noone ever said UI design was simple – that doesn’t mean preferences are a solution, particularly since most users wouldn’t think to go looking for the preference if they didn’t like whatever way the default worked.
James C. McPherson says:
My chief complaint with both firefox and thunderbird – starting with v1.5 – is that somebody decided that it should be bloody difficult to actually have two running instances of either program. So if, like me, you rely on having two separate profiles (work via vpn, home), any attempt to just blithely startup a new instance will force the currently running instance to pop to the foreground.
You need to go and set MOZ_NO_REMOTE=1 before running firefox/thunderbird if you want to avoid this.
I do have a legitimate reason for needing two profiles and having both active: I run a host with a vpn connection to work, and a host which is on the ordinary internet. I want to keep my “at work” preferences, browsing history etc separate from my home preferences.
Whoever decided that they knew better than me about what I might want to do with the mozilla suite is very, very wrong.
RoUS says:
You identified my main issue right in your first line: “The rule is if you’re going to force the user to change their behavior..” Software has NO BUSINESS forcing the user to change its behaviour. The software is the servant, not the master.
But I can agree with you on the messiness of preference dialogues. So let me generalise it a bit more: Either don’t violate the Principle of Least Astonishment by drastically changing the UI — or, if you do, provide some way for the user to revert it to accustomed/preferred behaviour. It doesn’t need to be a preference dialogue. As it happens, Derick Rethans showed me that there *is* a way to revert it, so my ire is considerably reduced.
And I don’t understand your remark as stated: “Given the number of people who complain about this feature and the solid arguments for why having the button on the far right is more efficient, the change should have been made.” If there are arguments for keeping the button on the right, and lots of people complain about it being moved, why should the change have been made? Or did you mean *less* efficient, and the feature being complained about was having the close button on the right? Or that the change should *not* have been made?
Adrian Sutton says:
Oops, there should have been a not in there – the change is making people less productive so it’s providing no benefit for the frustration. However, sometimes it’s good for people to have to go through a relearning period in order to be more effective or efficient and a UI designer should understand that trade off and make it when needed. If we never drastically changed our UIs we’d never move forward in computing (your web browser would by lynx, not Firefox) – if we enabled users to switch back to the old mode all the time, we’d be maintaining thousands and thousands of legacy options in our software and users wouldn’t be taking advantage of the improvements we’ve added.
Software isn’t the servant, software is the tool and tools require you to work in certain ways to get the best results. If the tool can be modified in such a way that it is a better tool then it should be modified, even if that requires some relearning.