|
 Features
Swiss Army Chainsaw: A Common Sense Approach to Tool Development
 Ease of Use Beats Total Control
It's usually worth sacrificing total technical control for ease of use. For example, when setting up GUIs for custom shader parameters, consider abstracting away from the hardware a little bit. If you just expose every parameter or flag available in the render pipeline, the artist will begin to feel that they need a degree in advanced maths to work it all out. Even quite a simple shader model can feel pretty overwhelming when all the parameters are exposed. Instead, find out what concepts they are already familiar with and see if you can make your tool present itself in a similar fashion.
Find out the terminology your users are familiar with, and use that where appropriate. Don't invent your own weird and wonderful terms for existing concepts (unless there is comedy value in doing so).
If you expose every little detailed option, users will miss the ones that really matter.
Don't add options where an automatic decision could be made. Adding options to a tool is all too often a weasely cop-out in disguise. Remember: every extra configuration option is an extra thing that the user could get wrong.
Small Hacky Little Tools Are Tools Too
During the course of a project, you'll probably find yourself (and others) hacking up lots of little tools, plugins and scripts to help out with odd jobs here and there.
It's worth collecting these microtools and checking them in alongside all the proper grown-up tools. You never know when one of them might come in handy. Of course a lot of them will only work in very specific circumstances, so make sure you add some notes outlining their intended purpose and limitations. A concise comment block at the top of the script or source code usually suffices.
The chances are that someone else will need something similar to an existing microtool, and the code can be generalised far enough to cover it. Some may even evolve far enough to be considered 'proper' tools in their own right.
At the very least these microtools provide documentation, of a sort, on how particular tasks can (or should) be performed.
Don't forget to collect tools created by non-programmer team members (eg MEL or MaxScript from artists). These often get overlooked, but they exist because they are useful.
Being a Sensitive New-Age Programmer
When it comes down to it, good tools are really a collaboration between the tool developers and the tool users. If the communication isn't there, you're going to end up with tools that suck.
Try actually using your own tools. An obvious point, but it's amazing how often this gets overlooked. If you're working on a level editor, try actually creating a working level with it.
Learn what your users actually do. For example, if you're working on tools for your art team, spend a day going through the tutorials for Max or Maya or whatever other major apps they use. Gain some empathy!
Sit down and watch over your users shoulders as they work. Don't say anything, just watch for a while. You'll be amazed at how much pain users will endure over little things that could easily be fixed.
|
|
|
|
|
Previous