User design

Some things to think about that are worth noticing about user design:

• Design for recovery
• Living with complexity
• The virtual control panel
• Limits of information based behavior

Design for recovery

Users make mistakes and don't always understand what is happening. States that you can't recover from is bad in particular, because it is not always the intention of the user to enter that state.

For example, in a drawing software, the user can always undo the last action if they are not satisfied with the result. They may hit a button by accident that activated a tool, so there should be a way to cancel a tool or undo the effects.

For example, in a popup dialog, there is often a "Cancel" button. This makes it possible to go back without saving the changes. Some tools lets you test the changes before you save them.

Libraries that deal with user design need to consider recovery.

Living with complexity

Complexity is not the same as confusing, and simplicity is not the same as understandable.

This lecture by Don Norman might be helpful to put words on thoughts around complexity in design and when simplicity can be confusing.

https://www.youtube.com/watch?v=flRuSn0df8Q

Understanding:

• Organization & Structure
• Modularization
• Conceptual Models

Guidance:

• Signifiers
• Systems Thinking

The virtual control panel

A physical control panel is a user interface that is connected through cables to a machine. Adjusting a setting on a control panel changes how the machinery operates.

• Everything the user wants to do is accessible through the control panel
• The machine responds to the settings in a sensible way

Many user interfaces and interactions can be thought of as a virtual control panel. Even in game programming, it is common to use custom text formats to adjust settings. This affects how you write the code, and it is conceptually similar to how cables connect a control panel to the machine.

Assume that you have a function:

fn render() {
    // Draw scene.
    ...
}

In Rust, where global variables are immutable, you can't do this. What you need is:

• The data you need for rendering
• The settings that determine how it looks

A good way to solve this is by starting designing the "virtual control panel" and then break it down into the parts required by that particular function.

fn render(render_settings, scene) {
    // Draw scene.
    ...
}

// break down application structure.
render(app.render_settings, app.scene);

This process is repeated until you do the simple operations, for example adding two vectors.

The point is to emulate how a physical control panel is connected to a machine, by "anonymizing" the data that the machine operates on.

Limits of information based behavior

If I send you two bits of information, then I can't encode 5 bits of information within it. No matter what the two bits mean, they can not make you respond consistently in 5 different ways.

In user design, the way information is communicated limits both the behavior of the user and the behavior of the machine.

For example, if you want to build a physically based game, how is the user going to interact with it? There are some things that can be hard to do in some types of games and easy to do in others.

The point is, no matter how much effort you put down into something, what is a good user design for one thing might be bad design for another thing.