Dear ThreeToe and Toady One
The design of human computer interfaces is a relatively overlooked area of computer science (it approaches art-form, but there are still some useful lessons to be found). A basic introduction to HCI design reveals things like the problem of too many elements, eliminating superfluous actions, and the importance of user-feedback; and an advanced pass will involve things like the economy of accommodating new vs expert users, and in-depth design and testing methods meant to figure out the optimal design style to accomplish the specific "tasks" that the interface must support. In short, it's a hot mess of general do's and don'ts, along with some procedural wisdom. I recently completed a university course on HCI design, so I'm writing this to share some of the more obvious implications it has for DF. If I can help to frame some of the considerations you will need to make in a more useful light, I'll have been successful.
The first question HCI design asks is what are the external peripheral devices that the human will interface with (eg: mouse, keyboard, ?touchscreen?, monitor, speakers), and to what extent will they be used? By default DF is purely keyboard controlled, and the hotkey system is cumbersome for new users but very effective for experts (it takes time to learn it and to build muscle memory). It's not just the input devices that must be considered, it's precisely how they are going to be used. For example, in some applications you type commands in the form of words, and in others, like DF, you execute commands by hitting a hotkey or series of hotkeys (generally one is better for less complex tasks, and the other is better for tasks with many parameters; both are strictly keyboard but they use it completely differently). Seemingly simple things like whether or not a "right-click" sub-menu will be available can have sweeping implications on every other aspect of the interface design, and the trade-offs won't all be predictable without prototyping and testing different options. Will options on the interface be fully navigable with left-clicks? Will box-highlights be available, and how will they work? Will the mouse become a requirement? (i.e: are you going to develop mouse support on-top of full-keyboard control as a redundant user-comfort, or will you make using the mouse necessary for some tasks in order to unburden the keyboard interface?). These are all questions worthy of consideration. My intuition says that there might not be much to gain from eliminating any keyboard functionality altogether, but there might be some benefit to making the mouse a primary means of performing certain tasks. There's much to consider here, so you should probably make a list of things that the mouse could possibly support, and then choose from them the options that make sense from a programming angle and which also make the performing of the relevant tasks more comfortable for users.
The number of specific tasks that the interface must support is staggeringly large for DF, which is what makes a system of hotkeys and sub-hotkeys very efficient. Locating a specific task from a large initial menu will be time consuming, but likewise, trying to navigate a menu system that is too general at the top level (leading to a complex network of sub-menus) can be equally hard to navigate. Whether by mouse, keyboard, or touchscreen, a critical point of consideration will be balancing the number of top level options/specificity with the depth or height of the network of sub-menus. One theory coming out of the HCI field is that more than 7 elements is too many for the average mind to remember all at once. In other words, when you show people a list of more then seven choices, they begin to be overloaded by information to where they start to miss or forget details. This isn't a hard rule of interface design, and it would not be useful for something like Dwarf Fortress given its complexity, but it's definitely a trade-off to consider.
In my own experience, the surface menu of Fortress Mode does lean on the side of too many elements, but I don't know if that can be helped. There are probably some utilities that don't see frequent use which can be put into a sub-menu (view nobles/units/rooms and the unit-list could be placed under the [z]Status menu, for instance), but what to keep or add or remove in the end should be very carefully considered. The more you overwhelm the user with a grand list of options, the harder it is interact with it in general, but the more options you eliminate from surface-level access, the more you risk obscuring it from new users (at the main or top level of the menu, optimal design is more important because it is the most frequently used screen). How easily users can move in and out of different levels of the hotkey interface can also affect these considerations (for example, if using only left and right clicks we can go up and down different levels of the interface, more complex menus would be tolerable to newer users, assuming learning the hotkeys takes a great deal of time).
User-feedback is probably one of the most useful points of consideration from the HCI field. When users do an action, if the effect of that action is somehow immediately displayed, it can not only inform the user about the progress, success, failure, or result of the action, it also gives users a certain kind of stimulation and reward that contributes to interface-satisfaction. For example, when a building is scheduled for construction, it is physically represented on screen (to the extent that DF has graphics), and when it is selected it displays the status of the building with bold letter coloring which draws user attention. Auditory responses (such as the Windows "click" or the "beep" of a bar-code scanner) let the user know that the action was carried out, and whether or not it was successful, which can be very useful sources of user feedback while also being inherently pleasant for users. Color changes are also worth exploiting; when something is clicked, some kind of highlight lets the user know that they clicked the right thing, and having a range of color changes can convey information in efficient and compact ways (eg: red is hostile, green is peaceful in the unit list). Flashing colors are great for getting our attention at the periphery of our focus (at the edge of the screen), and interface elements which are at the center of our focus can be imbued with other abstract data (such as shape and size) that corresponds to the type of feedback being received. (high-contrast flashing media at the center of a screen is so attention grabbing that it's often unpleasant and unnecessary).
Making computer interaction easy and comfortable for humans is the entire aim of HCI design, and knowing the intention to make DF easier for new users, you've truly got your work cut out for you (it's reputation as the most brutally difficult game to master precedes it). But since we all already know what the DF interface needs to do (understanding the required tasks is the first step of CI design) and since we know who the intended users will be (a mix of new and expert), the next step is to create and evaluate different design concepts. They don't need to be programmed in any way, or complete; they can basically be a storyboard of sketches, with comments, that communicate the general and essential components and features of the interface. It occurs to me that the DF community represents a wealth of individuals who are on many levels vested in seeing DF become the best game it can be, many of whom would likely be willing to create and submit design prototypes for you to evaluate. If either of you put out an open request for the submission of interface design prototypes (sketches and descriptions; not programs), I'm positive that it would turn up some creative and useful solutions!
P.S: Would this thread be more appropriate for the "suggestion" thread? It's not exactly a suggestion, but it occurs to me that it might be close enough.
Author
Topic: A Letter to Zach and Tarn. RE: Human-Computer Interface Design (Read 3064 times)