I wonder how relevant the first point regarding fits law is (the one about the edge of the screen) when considering web apps. With today’s 16:9 screens it’s unlikely that the edge of the web ui corresponds to the edge of the screen.
I hear you with the eject buttons though. I guess in real life the buttom would have a little perspex box that you have to flip up before pressing it. Pitty we can’t do that on the web (and I don’t mean using dialoges shudder). I’ve often wondered if the web would be better if there were more ways to vary interation with controls. Ultimately almost all controls on the web today are activated with a single click (whether links or buttons etc.). I like apple’s ‘activate keyboard slider’ on the iphone as an example of assessing whether the user really meant to do something. Of course, we can do some fancy things with jQuery etc., but then we moving away from standards.
@Meki - The safety cap would only work if it required more than a click. i.e. you had to click and drag the cap up. I have seen a LOT of users who double-click EVERYTHING, EVERYTIME. It’s like they don’t even know they can single click. Of course I’ve also seen several people who don’t know the difference between the left and right buttons on a mouse and just jam them both every time. Maybe they were Mac users in a former life…
@Fjordaan OS X wasn’t designed to be used across multiple screens, so I would argue that is a corner case, though I am thinking about how they will sell dual 30’ Cinema Displays for the Mac Pro.
I agree with Robin. The scary part about having the Eject button in between Radio and Cabin lights is not just that you might accidentally eject while you’re flipping the lights, but also that you NEED to eject now, and be fumbling around with the light switch. Instead of a small button for an infrequently used button (like Eject), I think it needs a special, very large RED button.
Related to Mecki’s comment about OS X’s menu bar, one of the things I always miss when using windows is the alt-click to move a window thing you have in gnome-based UIs (not so sure about KDE, but there’s probably an analogue). I move windows around all the time and when you press alt you just have to drag the window, not go hunt the comparably smallish title bar. Saves a lot of effort when working in a dual head setup.
Sort of like how the confirmation-less “remove tag” button on Stack Overflow is right next to the link to that tag? I inadvertently hit the “remove tag” button at least once a week. It’s hard to take this post seriously when Stack Overflow does exactly the thing you caution against. At least Google (sort of) gives you the option to undo.
@Fjordaan: The worst part is, the Ctrl-X/C/V set was apparently chosen because those letters were ‘conveniently’ placed close together.
And an example from the world of the command line: The crontab command can take three options, two of which use letters placed right next to each other on the keyboard: -e says: please edit my crontab file, while -r says please … delete my crontab file. Of course there is no undo.
The third option is -l for list. What a relief you’re never going to type that one by accident.
Just a little detail about the Wordpress-update-vs-trash example.
I’m pretty sure I have read on different places that, on a website, a button should be used for something likely to actually do something while a link should be used only to move the user to another webpage. In few words, links should be side-effect-free (go to see an article, open a new tab or a new window, etc) and for every action that changes the state of the model (post something, delete another thing, send a third thing, save a fourth one, etc), a button must be used. I think that makes sense even though that usage is not respected everywhere.
Then, the usage of a link here seems pretty bad but in the same time, it has the “convenience” to be harder to click than a button. Finally, what should be used ?
Nice article (as usually) though. Congratulations and keep on writing.
Ejector seats make a fascinating UI design case study. On surface ejector seat activation has two contradictory UI requirements: (a) it needs to avoid unintentional activation and (b) the pilot needs to be able to activate it in a hurry and while under a large amount of stress.
The way this UI problem is usually solved in fighters is that a large ejector handle is placed somewhere pilots would never normally put their hands when flying the airplane. Typically the handle is placed under the seat or behind the pilot’s head. The action on the handle is also usually very stiff with an intermediate detent (kind of like the half-press on a camera shutter button) to act as a further warning. The upshot is that a pilot can find and activate the ejection handle in a hurry and while under huge stress but is very unlikely to do so while operating the plane normally.
Most of the time the purpose of composing an email is to send it. I think calling it an “Eject Button” is quite a stretch.
Also regarding the bar of buttons. Their grouping makes sense to me. They all basically make the selected emails “dealt with.” And they were given two options. Hide the ejector seat lever, or turn it into something that isn’t an ejection seat lever. They made the mistake trivial to recover from. And as other people have mentioned you can turn the send button into a non-ejector seat too if you want.
They certainly shouldn’t make the buttons I hit 90% of the time harder to hit. When I compose an e-mail I don’t want to search for the send button. When I’m looking at my inbox I’m either reading something, archiving it, or marking it as spam.