For the past week or so I’ve been customizing my WordPress install by adding a number of plugins. I plan on writing an article soon about what plugins I’m using, but first I’d like to talk about something that I’ve noticed about WordPress plugins. Installing plugins is easy. There’s plugin directory in every WordPress installation, generally under wp-content and you just drop a plugin folder in this directory and WordPress will detect it. If you’re using a recent version of WordPress, you can actually search the plugin repository and install a plugin from inside WordPress itself. This is really useful feature and makes using plugins much easier. However, the one gripe I have is that the settings to control the plugin get spread all over the WordPress interface.
Here’s a screenshot of my WordPress Dashboard. Along the left side you can see buttons for various drop down menus:
I’m currently using 8 plugins, each of which have various settings and interfaces to change those settings. One of those plugins (StatPress) has it’s very own sidebar menu. Two of them are under the Plugin menu, one is under the Tools menu and the rest are under the Settings menu. That means that if I have to find the settings for a particular plugin, I potentially have to look in 3 different places to find them. For me this is a clear design and organization mistake. Things that do the same thing should be in the same place. I’ve picked WordPress as the example because it’s what’s been striking me most recently, but it’s not the only one. Office 2008 for the Mac allows users to change the default saving format to the old formats. This option is in the same place for Word and Powerpoint, but is different from Excel.
Simplicity favors regularity. User interfaces need to be both simple and regular. Google’s interface is probably the simplest you can get. WordPress’ interface in general is pretty regular and simple, but the organization of the plugins is not regular at all and so there’s an extra level of complexity added in which users really shouldn’t have to deal with. It’s not just user interfaces. Indenting your code properly is also recommended for the same reason. All code that gets executed as part of the same operation should have the same indent level. It’s a visual clue that’s much easier to follow if done right than keeping track of curly braces. One of the criticisms of Perl is how it uses contexts: variables and operations can mean different things depending on what’s surrounding them. That isn’t always a bad thing, but it does mean that you have to consciously keep track of the context your code is in.
Similarly the development of the RISC processor architecture was motivated in part by the fact that most processor instruction sets are highly irregular with lots of instructions that seem very similar but actually operate quite differently (or have some seemingly arbitrary limitations). The book Computer Organization and Design which was co-authored by one of the creators of the RISC architecture, states 4 design principles, one of which is that Simplicity Favors Regularity. I must say I have to agree
While designers should try to contain functionality within regular components, it’s also possible to go overboard. Typical electrical installations in buildings are controlled by rows of identical switches. Very regular, but also perfectly impossible to tell which switch does what. Things that do different things should look different. Clarity is key. In the Design of Everyday Things, the author talks about how employees in power plants distinguish switches on their consoles by attaching different handles to them. One of the reasons that Lisp looks scary to a lot of programmers is that it can easily look all the same, as opposed to C-like languages where a for-loop looks very different from a function call or object creation. To be more specific, the external design of an object (or interface) should suggest it’s possible function. Admittedly this is harder for on-screen software than it is for physical object.
But these two principles seem contradictory. How do we reconcile regularity with easy differentiation. Part of the answer is that there is an underlying concept which is pretty powerful: ambiguity is bad. On Reddit today I saw an article criticizing Xfce’s settings interface. The author couldn’t figure out how to increase his text size. There is some comparison with the Windows 3.1 interface, but the central reason is that the Xfce settings interface is ambiguous: should text size be under Window Manager Settings, Display or User Interface Settings, all of which seem equally probable to the casual user. It’s the exact same case for my WordPress plugins. I think plugin settings should be under Plugins, but it does make sense to put them under Settings or Tools.
So the question then is: how does one avoid ambiguity and achieve clarity, especially when there really are a number of logical alternatives (like WordPress)? In some cases it’s possible to use clear labels to distinguish what operation will be performed. Taking another example out of design of everyday things: a flat bar across a door makes it clear that the door is to be pushed, not pulled. When it comes to designing software interfaces like WordPress or XFCE, it’s not quite so simple because there can be a lot of debate over which design is correct. After all, plugin settings can go under Plugins or Settings. I feel that the key here is to just make a choice and then make that decision known. In the case of WordPress, plugin settings could go in either Plugins or Settings, though I would personally prefer Plugins so that there is one place for all plugin-related activities. But equally importantly, plugins should not be given a choice as to where in the UI to go. The case for XFCE is made more complicated by the fact that the text size for the window title bars can be changed independently of the rest of the UI and hence text size control is spread over two places. I would still argue that the two should be pulled into a single interface, but this is a case where the interface is heavily influenced by the functionality. The thing to remember in this case is that even if something might seem clear and logical for the developer or engineer, it might not seem that way for a casual user. Users don’t want to spend any time actively learning where things are, they just want to use it and they want it to work. Beta testing products with users is a great tool and it’s also essential that design decisions be well documented in easy to read manuals.
In conclusion: ambiguity is the enemy. Fighting ambiguity requires a two-pronged approached. Interfaces must be simple and regular so that the user is not overwhelmed with choices. But at the same time, there must be sufficient cues to let the user know that different objects have different functions and how required functionality can be accessed. This can be done by using labels (different text and images) and by offering easily accessible documentation. However, good design requires many decisions and compromises and the best way to figure out which ones are best is by watching actual users and adjusting accordingly.