I would like to know your own theories about usabilities for tools. What are the thing you keep in mind when designing the Ui for a tool? Do you look for usability in a tool or does it just have to work good? Are there some basic rules or is it trail and error?
I’ll throw a concept in here; how about anthropology? Study your clients and how their behaviour changes when they use the tools.
Watch them see how they use or don’t use features and get that feedback loop going.
Tom Kelly has a few words on this http://www.youtube.com/watch?v=VeXO1gQJ__M
I’m of the mind of writing a UI that makes sense to the end user(artist) and not to me. This can be a challenge when developing. If a tool doesn’t make logical sense to an artist, they usually use it wrong. You have 2 strikes(give or take) of a tool not working as intended before it’s written off.
I usually latch onto a more technical minded artest for development and if it makes sense to them usually the rest of the team will be fine. So I’m more usability minded, but the tool has to work as intended as well.
I have been working with artist who don’t believe in scripts, they wud rather get the work done in 5 more steps than trusting a custom tool. So my approach has been to make the tool easy to use, which means minimum clicks or requirements. My philosophy is that if you waste more time in setting up the scene or an object to use a tool, then it defeats the whole purpose of having that tool on the first place. Coze the time saved by running the tool is been eaten by the setup time. I spend extra time on UI making buttons more flexible, e.g. say, there a maxscript that removes all the isolated verts. I’ll make sure that the script works on both editable poly or mesh, works on single or multiple geometry. Which means that I have a single button on my utility GUI, instead of 4 buttons. I try to have names of the button which are sort of self explanatory. My technical director wudn’t approve any tool what requires a lot of doc or need a 15 min tut on how to use it. His philosophy is that it shud make you work less, not more.
I have found it to be very useful to test my scripts for any given situation and let the script guide the user on using it rite way.
Personally, I like tools that are simple and easy to use, with less congested UI, can handle any situation and doesn’t crash but at the same time are feature loaded.
+1 LOKO.
I’m huge on minimalism. If you have a GUI, the more simple the better. Have solid error handling, make it flexible, fast, easy to use. Make sure you can go back, etc.
Don’t have features no one will use, or fluff in your GUI.
[QUOTE=shawner;6107]I’m of the mind of writing a UI that makes sense to the end user(artist) and not to me. This can be a challenge when developing. If a tool doesn’t make logical sense to an artist, they usually use it wrong. You have 2 strikes(give or take) of a tool not working as intended before it’s written off.[/QUOTE]
this should be printed on the desk of every tool programmers 
nothing worse than having someone spend weeks (months?) of work on something that doesn’t address the real concern of the end user, or address it in such a way that it can’t be seamlessly weaved into the end user usual work flow.
Whatever tool you write, it is going to suck.
Inevitably, your tool is going to need to do 3x than you designed, and 1/2 the functionality is used better elsewhere. You must set up your tools so that they are built for change- sometimes complete and total change, or even for the scrapheap. That means, building a robust framework not tied to the tool directly, and component-izing as much of your tool as you can, so you can use different components in different places. I’ll give a quick example:
We built this framework of controls that can get and set properties on an object that implements a certain interface. Each property had a certain attribute that declares which type of control to create. So three things happened:
-We started using these controls outside of their designed context, in multiple tools- basically, wherever we wanted to allow the user to get and/or set a property via the UI.
-To change the control for a property, we only have to change it in one place (where we declare which type of control to use), and the change is reflected across all tools.
-We are able to change significant parts of any tool, without affecting other components. For example, we can change from a listview to a node-based item layout, without affecting the property controls.
First I’d learn framework design, then UI design. Any ninny can design a tool, but having a good framework will allow you to create great tools, even if the initial design sucks, and probably eliminate a number of tools entirely.
Rob, since you mentioned framework, do you have any good resources on awesome frameworks? I’ve begun to build tools more modular and flexible, but I still feel there is a ton more to learn.
I think it all depends on what the artist needs to do, how many artists need to use it, and things like that.
In general, I try to keep these in mind:
-
keep the number of choices down to a minimum - one click or button if possible.
-
Fail elegantly! If the artist clicks the button, and the selection is wrong, make sure there’s a message telling him why he’s not getting the expected result.
-
Make the failure useful! An example - I made a script that creates a camera in the proper location with the correct FOV / aspect ration settings to render a selected rectangle border-to-border in the image. If an artist clicks the button without a plane selected, it creates a plane for him with parameters he can set to control the camera.
-
Listen to your artists. Sometimes you can see a “better” way, but if it makes your team hates the tool and feels like you don’t listen to their requests, you aren’t doing anyone any favors.
-
Iterate quickly! Use something like http://balsamiq.com/ to mock up the UI. Mock up a pretty version in Photoshop. Prototype quickly, and assume the first three versions are primarily to find out what not to do.
-
Start thinking in terms of frameworks and plugins. Noone likes seeing 500 processes running in the background; and my happiness with my desktop decreases proportionately to the length of my taskbar. Grouping small applications into a common, easily updatable UI is a great idea, and everyone benefits from all the tools having a common access point for documentation, options, and things like that. Updates are easier, and bugfixes/updates get shared among all the tools! Woot!
I’m a fan of the one button solution. Even if that standard is sometimes impossible to come by. Most of my UI’s have 1 or less buttons. They tend to be single minded in what they do. When I first started I added as many features as I could building Swiss army knives. But they where confusing making them hard to use. So now its just some text and a button if I must.
I also spend a lot of time making my tools expect the unexpected. If an artist can use it on anything or nothing there needs to be a test in the tool that will give a error message that helps out the user in figuring out what the tool didn’t like.
[QUOTE=allblues23;6145]
I also spend a lot of time making my tools expect the unexpected. … [/QUOTE]
I like this aswell, figuring out what the artists will do with my tool, and even though I keep this in mind, the artists always find some way to screw it up anyway. So, a tool can expect the unexpected but it can expect what an artists will do 
I agree with all of the comments, and I’ll add that I also spend some time in the polishing phase where I make sure that controls are being disabled and enabled as needed. Like if a tool requires the user to specify an object before running, then the “Go” button will be disabled until that requirement is met. I think it helps to keep the tools usage easily discoverable, and reduces frustration caused by clicking on buttons or changing settings that don’t do anything in the current context of the tool.