Interface Design Principles

I want to start compiling a list of user interface design principles. Not necessarily things that I’ve read, but things that I’ve gleaned from working on Graph Sketcher and looking at other UI design work. Also, these include the business side of product design.

1. Make your interface easier/faster than what users can do with their current tools. It’s surprisingly difficult to beat paper and pencil.

2. Constraints: understand what your users do and do not need to edit. Just because the underlying representation is very flexible does not mean the user need be exposed to that full power – the complexities and options could slow them down considerably. Whenever possible, make design choices so your users don’t have to.

3. As I think I detailed in a previous post, good design means inventing good abstractions. Good abstractions ideally have all – and only – the functionality that your users need.

That’s all for the moment.

Features and Wikis

It’s much easier to add new features to programming languages and command-line interfaces than it is to add new features to graphical user interfaces.

I think that is profound, but I’ll have to muse it over to be sure.

For example, to add a new editing command (say, superscript) to emacs, just choose a name or keyboard shortcut for the command. But to add it to a graphical text editor, you need a new button or menu item. It has to be worked into the layout of the graphical interface. Other interface components might have to get moved or kicked out. If you’re Microsoft, you just add it onto the end of a quickly growing toolbar or menu or preference window.

Maybe this helps to explain why wikis are still based on wiki-text rather than WYSIWYG editing. If you want to add a new feature to a wiki (say, superscript), just define some new language tag for the wiki-text, e.g.: ““. But if you want to add that to a WYSIWYG wiki (let’s call it a wizziwiki), you have to design. Put the button somewhere. Decide which features are most important. This is hard! And it is especially hard for open source communities where a vocal minority will get upset at the removal of a feature that they particularly like (or programmed). That’s probably part of why brand new open source projects have to continually get started.

Here’s one solution. A wiki which lets you do the most basic editing (bold, italic, lists, links) as WYSIWYG, but has an “advanced editing” mode which is text-based and allows all those other features. The problem with adding this to current wikis lies in getting a “handle” on the text entry point; that is, mapping back from the graphics into the source. Right now it’s a one-way street: wiki-text to html/DOM. It’s hard to go in the other direction. (The same is true for LaTex.) So maybe we need a completely html-based wiki. Is someone working on this?