Things that aren’t conceptually related should not be linked in interfaces. This design principle is called orthogonality (if I may slip into italics for a moment). The classic example of a non-orthogonal interface is that of the helicopter:
A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.
It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you’re constantly dancing on all the controls to keep the helicopter stable.
A better, less confusing example of a non-orthogonal system is the late 20th century sink faucet:
The left knob controls the flow of hot water and the right knob to control the flow of cold water. This interface is non-orthogonal because it links the two conceptually unrelated concepts of water temperature and water flow rate — it’s impossible to change one without affecting the other. (This interface is plagued by more than orthogonality issues — e.g., it gives no indication which knob controls hot/cold or which direction one should turn a knob to increase flow).
How can we fix this interface? First of all, we can make it orthogonal:
Now lifting the handle increases the flow, and rotating it changes the temperature — it’s possible to adjust one without changing the other. This implementation also makes it clear which direction is hot and which is cold. Finally, it’s now possible to control every aspect of the system with one hand.
Is there still room for improvement? Consider these observations:
Users don’t need granular control over flow rate, they just want it to be always set at something reasonable when the faucet is on.
Users don’t need that much control over temperature. The faucets in both figures allow the user to choose between hundreds of temperature settings, far more than people need.
A better solution would be one that gives the user only one choice of flow rate (off v. on) and 4 or 5 choices of temperature. Unfortunately temperature preferences vary, and thus it would be difficult to settle on which 4 or 5 temperatures to provide (without costly calibration). Furthermore, it’s pretty easy to control the flow via the interface in figure 2 as if it only had two settings (i.e., handle fully up or handle fully down).
Ignoring the temperature problem for now, we could simplify the interface by removing the user’s ability to pick flow rate via a faucet functionally equivalent to this one:
Opening it even a little increases flow to the maximum level and sets the temperature to cold. Further opening it increases the temperature (while keeping the flow level constant). This is simpler than the interface in Figure 2 because the user only has to operate it on a single dimension (turn left / turn right v. lift / depress & rotate left / rotate right). Despite its simplicity, this interface has two disadvantages relative to the one in Figure 2:
It’s not clear which direction one should rotate to make the water hotter v. colder
You have to make the water maximally cold before you can turn it off (though you can mitigate this by turning it off quickly).
So yeah, who among us is able to unbate his breath while awaiting the faucet innovations coming in the next century?
What is up with your URLs, eBay? When you click a link from an eBay search, you go to a URL that looks like this:
http://cgi.ebay.com/Bernard-Madoff-Ceramic-Coffee-Mug-Hard-to-get_W0QQitemZ200319297841QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item200319297841&_trksid=p3286.c0.m14&_trkparms=72%3A1205|66%3A2|65%3A12|39%3A1|240%3A1318|301%3A0|293%3A1|294%3A50
This is obviously insane — there’s no reason URLs can’t be both unambiguous and human-readable.
Some guidelines:
The domain should make sense. What the fuck is cgi? This is gibberish to any non-technical user. The domain should just be ebay.com (I’m looking in your direction, www2.seamlessweb.com).
Since URLs need to unambiguously point to a single page, it won’t always be possible to make them entirely human-readable. However, you should limit the non-human-readable portion of the URL to the shortest string necessary to ensure uniqueness.
URLs should include additional text to make them easy to identify. eBay actually does an okay job of this by including “Bernard-Madoff-Ceramic-Coffee-Mug-Hard-to-get”, but ideally this should appear at the end of the URL.
Here’s a quick improvement on that eBay URL:
http://ebay.com/auctions/123456/Bernard-Madoff-Ceramic-Coffee-Mug-Hard-to-get
where 123456 is the auction’s unique internal id. Of course http://ebay.com/auctions/123456/ should work as well (since the auction is uniquely identified by the numeric string).
This is a good generic solution, but we might be able to do even better. I.e., there might be a more human-readable way to make the URL unique than embedding the auction’s internal id. For example, eBay could use a Blogger-like strategy:
http://ebay.com/auctions/end-date-20090315/Bernard-Madoff-Ceramic-Coffee-Mug-Hard-to-get
If two auctions with the same name share an end date, append a number to the end of the URL. If you want to avoid this, you could add information about the seller to the URL:
http://ebay.com/auctions/seller-rogrpodcater/end-date-20090315/Bernard-Madoff-Ceramic-Coffee-Mug-Hard-to-get
The nice part about this solution is that you could have http://ebay.com/auctions/seller-rogrpodcater take you to a page listing all of rogrpodacter’s auctions. The downside to this solution is that now the URL is getting pretty long.
There will always be a tension in URLs between human-readability, unambiguousness, and brevity. The important thing is making sure that you don’t sacrifice one value without improving another.
But what if I want to customize my template a little; for example by increasing the size of my blog’s title or changing the color of the date headlines?
Ugh. I have to look through the raw HTML to find the right CSS class or id:
Click “Edit HTML” in the Blogger Layout tab, find the right CSS selector, and then enter the color I want in hexadecimal format:
Making this minor change requires the same level of expertise as creating an entirely new template.
One thought is to go as high-level as possible: let users adjust page elements' properties by right clicking on them. To change the color of the date headlines, just right click on one and select “Change color”.
This interface is friendlier, but its ease of use comes at a cost. Consider: when you select “Change color” on a date heading, how can Blogger determine whether you want to change the color:
Of every date heading on your blog
Of the first date heading on every page
Of just this particular date heading (perhaps it’s your birthday)
HTML/CSS is no fun to work with, but it has the benefit of allowing the user to unambiguously specify which one of these he means.
So while my proposed WYSIWYG interface for configuring Blogger templates could supplement the existing interface (say by only allowing you to use it for blog-wide changes), it’s not powerful enough to replace it.
This shortcoming is actually an instance of a more general class of problems that plague all WYSIWYG editors — i.e., an interface that only lets you modify the way an individual element in a document looks cannot always capture your intent (since changing the formatting of an individual element can be in aid of any number of higher-level goals).
This is why using Word is such a pain in the ass. There’s no easy way to specify whether you’re bolding a line because it’s a chapter heading (and therefore you want all other chapter headings to be bolded automatically), or just because you’re trying to emphasize it. Word’s default behavior is to assume that every change is local, which is fine until you have to change the font of 50 chapter titles manually.