I made these questions for poll exactly in purpose. I was absolutely sure that most of you answer the “Other”. I would like to see discussion, and not just simply voting ;). And we have a discussion!
as i have a time i will tell my concept for UI designing.
I have an idea. I love icons, and I have a very strong wish to make together with you – CG community, a database with different icons, where people could vote – which of them is closer to max and which of them is more obvious. A programmer then could open – let’s say refresh icons:
and there will be an option to – sort by rating + download! We just need such a mechanism and a page apart for Max Icons.
There are still a lot of icons to discuss – import/export/camera target and a lot a lot of them.
i love icons too. couple weeks ago i checked my icon library. all of them are unique and drawn by myself. the library is 435 icons. (later i made another six :))
icons is a very delicate matter. there is the strong rule of using them. once i asked Autodesk about can i or not use max built-in icons in my tools. and you will be surprised – the answer was more like “NO” than “YES”.
you can’t use .NET and Windows icons.
you can be easier sued for using someone else’s icons then someone else’s code.
so we can discuss an icon look, but we can’t make an icon library for share…
here is my principles of ui design for my tools:
#1 it has to be a part of max UI. it should not look as an alien
#2 it has to have an originality. so as people can say – this is denisT’s tool
#3 the tool has to be compact as possible but not tiny
#4 it has to look the same good in both dark and light schemes
#5 i use only one set of icons for both schemes
#6 i use only 16 colors different that gray scale across all my tools
#7 i use only mxs rollout controls in plugins UI (geometry, modifiers, etc.)
#8 all controls are perfectly aligned
#9 in a resizable dialog all controls are docked properly
#10 every control has tooltip
#11 every dialog stores its size and position (and display settings) after close. so being open next time it keeps exactly the same location and look
#12 every tool uses the same size spinners and limited number of variations of button sizes.
#13 never use different fonts in controls (the only exclusion is an info line)
…
…
#14 i prefer floating window (maximizable, minimizable) vs dockable (tool window)
#15 almost all icons in my UI are gray scaled. the colored icon means something very special
#16 the same rule is for button fore color (text color)
…
…
#17 every control that can’t be currently used (for example “Deselect” when nothing selected) must be disabled and grayed
#18 the same rule for menu items. the menu item must be grayed in a situation where it can’t be executed, and/or it has to be hidden when it’s action impossible doesn’t make sense
…
couple examples for the rule #18:
“Delete All Cameras” in situation where there is no cameras in the scene has to be grayed and disabled
“Reset Width For Selection” has to be hidden if there is no any object selected with #width property
#19 following rules #17 and #18 i don’t like to popup warning boxes. i prefer to disable functionality than popup a warning dialog “You have to have cameras to get them deleted”
couple words about query popup dialog…
the most common query – “Do you really want to delete it?”
well. a user pressed the button “Delete It”. his is not mentally disabled. my function is undoable. so what is the reason to ask a conformation?
just think about this possibility… what if this function will be used in any batch process? that means having this query i have to make extra mechanics for suppressing this query in ‘batch’ mode.
so
#20 use a query popup modal message box where it must be only
My thoughts:
About Tiny vs Big :
I used to make tiny UI buttons because I felt them cute and I didn’t want to take a lot of space in max interface. But experience shown me that too small buttons (even smooth & well placed) are simply not visible nor clickable. Now for me, buttons are bigger when action is important.
Full featured vs Main actions :
Keep minimum actions in UI. “Keep it simple and stupid !”
Users want a tool to be quick, efficient and quickly understandable.
No need to confuse them with tons of options/buttons. So options have to be in a second layer of interface. Make an “expert mode” with full-feature interface, but only if user want it.
Minimize vs floating :
I used to prefer minimize/maximize UI style but now I’m bored with the too many minimized dialogs over my timeline ! So I prefer to keep my dialogs floating (with dual screen it’s easy to put them away from viewport), and when I don’t need them, just close. I always have a custom toolbar to open them back quickly.
I think UI have to be composed as an image, finding good balance of colors (icons or images, have to be in the same aesthetic and color scheme), align and arrange controls by their size so space is well filled. Respect rules for typo/text …etc
But UI design is a long work, and often my tools are coded dirty and UI are not so clean, but job is done !
@Denis : for your rule #20, sometimes a querybox saved my ass when I clicked by mistake on a delete button while I wanted to clic the next button :argh: !!! Maybe querybox can be launched out of the function that is batched …
just trust me… if you can accidentally press any wrong button or pick any wrong menu item that means the only thing – you’ve organized your UI not well.
check the max… you can select any node and press “Del” or “Backspace” to delete it. no warnings, no quires. it just confirms what i told …
trust me – a ‘foolproof’ part of code sometimes can be bigger than the code itself.
the well organized tool is not that gives an user a warning about any possible damage, but which prevents any wrong action or allows an action but makes it revertible.
This is a great point Denis. Except that I have found that some actions programmed (in MAXScript) cause Max to crash when the user tries to use the Undo function in Max. I have certainly learned ways to avoid most of those over the years… but there are still times that the user presses Undo and Max crashes. I’m sure that I have a new tricks to learn… but in those cases where we may not know how to avoid this, using a query box and disabling Undo is sometimes a viable options.
Funny – i fully agree with those 20 rules and they are pretty much what i’m doing when building/designing the UI.
Maybe the spinner width part is a bit to strict: there may be different areas of the UI where the spinners hold totally different value types ( precise float vs. integer values like precents etc… ). And of course writing tooltips for all controls in more complex UI’s is a bit tedious …
But overall this is a pretty good list …