Re.

I’m back. I’ve finished my exams and some of my free time returned. Not all of it though, because of my work at Deck13 where I show up a little more often than my contract requires me to. After all, it is a fulfilling kind of work and it’s always nice to be slightly ahead of schedule than slightly behind.

I won’t spoil any project-related information from Deck13, but my work there isn’t quite project-related anyway. The thing is: Projects tend to have deadlines and students as me tend to have not enough time to be assigned any critical or semi-critical tasks. That’s why I’m working on Deck13’s game engines editor. And to be honest: As boring as it sounds, I’m quite into it. Editor development is something I actually like and I’m always trying to create tools and GUI controls that just “feel” right. While it’s not hard to create a purely functional user interface, it can be very challenging to create one that obeys all the little rules and side-notes of usability and is actually both efficient and fun to use. I’m probably not the most experienced guy in UI design, but here are some hints and rules I always try to keep in mind:

• Clear structure: If you open up a form or dialog, the first thing you see is how the available space is partitioned what regions there are. Each region should represent a single responsibility or task the user wants to execute.
• Less is more: Always try to achieve the needed functionality with the least number of controls. The more controls there are the more time it will take for the user to understand how it works.
• Intuitive workflow: Lets see.. the user needs to assign object A with a property of object B.. yes, you may let him open several menus and dialogs to establish the connection he wants – or you could just let him drag-drop A to B. DragDrop is a great feature. Don’t overuse it, but support it where reasonable.
• Avoid inconsistency: Assume a list of objects and an area that displays properties of a selected object. If you click on an object in the list, the area will update and show the selected objects data. Pretty straightforward behaviour. However, don’t forget to also update the displayed data if the user changes the selection with the arrow keys, deletes the formerly selected object, does a multi-select, etc.  Seriously, ignoring things like that just kills the “feel” of using a tool.
• Feedback: If the user does something wrong, give him feedback. If he does something right, also give him feedback. Whatever, just give him feedback every time he does something.
• Meet expectations: Ask yourself what you would expect a new tool to work. Where would you search for option X? What options would you expect inside a rightclick menu? What common shortcut keys would you expect to work? In what context? While it’s important to meet those expectations, it is even more important to always meet them exactly the same way. For the same action, don’t use key X in one control and key Y in another.
• Avoid destructive behaviour: If the user closes a form without explicitly saving his changes, ask him if he is really sure. He could have hit the close button accidently. In general, don’t destroy the users work without asking or requiring an explicit user action that is unlikely to be performed by accident.

I guess most of them are pretty obvious, but I’ve seen a lot of GUIs that ignore half of it. Which is a pity, because a GUI may just work – or be fun to work with. However, all of this is assuming you have a sufficient amount of time to design a tool. Deadlines can really mess things up.