Regarding button sizes again. Fitt’s law is well researched and documented, yet its implications are too often ignored in tool UIs.
It’s a problem when a button is very small (say… 16×30) and it is to be used repeatedly and often (without having to change options every time). Aiming at such a button from the center of the screen 200 times a day is uncomfortable and definitely not fast. We can probably agree that a good productive tool should be fast and intuitive to use?
Also there are some other UI design principles that can be useful.
i don’t use buttons with different height. I always use default mxs, or .net, or Windows button height. The most important is not a size of a “key” button but its placement. A “key” button has to be isolated, not buried between other UI elements.
It’s a problem when a button is very small (say… 16×30) and it is to be used repeatedly and often (without having to change options every time). Aiming at such a button from the center of the screen 200 times a day is uncomfortable and definitely not fast. We can probably agree that a good productive tool should be fast and intuitive to use?
Again… the size is not very imported. If you have a button repeatedly pressed by user 200 times a day you have to find a special place for it. It can be a viewport control, tool (macroscript) button, some isolated floating dialog…
Also there are some other UI design principles that can be useful.
this article is about interfaces for ‘housewives’. an interface for technical people is different. that’s why Caddy Controls in max looked silly and why most users said “Thank you God” when they got a chance set them back to old look and functionality.
that’s exactly the right example where we must prompt.
there is another place where we absolutely can’t leave without a query. Merging and XRefering…
Both these operations kill undo history. They are using full Garbage Collection. So the undo stack is always wiped after calling these methods. And a developer has to ask and warn “This operation kills your undo history. Continue?”
I keep especial attention for both these cases and they are usually wrapped to be quiet during a ‘batch’ using.
I do not agree with some of that…
Whether you’re a housewife or an experienced modeler who also plays way too much first person shooters, you will hit a 30×70 button faster than a 15×35 button; whether you are a housewife or a pro animator, you will hit a control that is 5 pixels away much faster than one that is 500 pixels away. (Of course it has to be used reasonably. A tool that takes up half of screen introduces other problems…)
When you state that ergonomics apply to housewives and not to “professionals” (the term “technical people” probably implies that we don’t write tools for artists?), and that the size of a button is not important (while the research seems to say otherwise), please provide your reasoning why.
True about key button placement; a key button has to have a logical, visible and “important” place within the UI hierarchy. For housewives or not, that’s good UI design.
As for caddies – they were useless and frustrating, because their placement was completely unpredictable and their ui elements were easy to mix up, transparency made it worse; all of that made their use slow and error-prone. Even housewives would not be happy with that, no matter how cute and web 2.0 they looked. That is a good example of counterproductive and outright bad UI design by Autodesk. If you read that “ui design for housewives” article, you will notice that caddies don’t fit any of the article’s recommendations; rather, they make the “mistakes” mentioned: hidden controls, unpredictable placement, difficult to distinguish controls, inconsistent with the rest of UI.
I can give another example that relates specifically to the Fitt’s law I mentioned; “Edges and corners of the computer monitor […] are particularly easy to acquire with a mouse […] because the pointer remains at the screen edge regardless of how much further the mouse is moved, they can be considered as having infinite width”. In 3ds max 2013 the whole interface goes right to the edge of the screen, making the “file” menu square really easy to hit with the mouse, same goes for all the quick buttons at the very top of the interface. Guess what they did in 2014? That’s right, introduce a 2 pixel padding to the whole 3ds max window, for no other reason than to waste more screen space and make the benefits of the earlier design go away.
I prefer my button sizes a little larger than max default size, generally 30 or 40 pixels high.
The more important or common the button the larger I make it.
I do think placement matters more than size : I try to arrange my button to appear “in order” that the user would typically execute them in their workflow. Buttons that are optional to the basic workflow are smaller and “off to the side” so to speak
I think and prefer make script’s UI much as possible indistinguishable from 3dsmax. But 3dsmax must lead the way … now max’s UI is something like “Frankenstein of UI” and I’m afraid any coding standards in maxscript UI meaningless for end user.
I’m even more curious why almost always people use letter “o” when comes to loops like
for o in objects etc. Occasionally there is “i” or “c”. Regarding fn I use it since I have discovered it can be written in this way however the more exceptions the easier to make mistake taking in to consideration there are thousands of command in maxscript.
