September 1, 2012
I don’t cook every day. But when I do, I enjoy it and I especially like to make oven-dishes (they give me time to clean up and wind down while the stuff is simmering away in the oven). Today I made two small one-person chicken-leek pies and several things struck me about my oven that one would categorize under GUI flaws were my oven to be software. I’ve noticed these things about most ovens/stoves I’ve ever owned so it seems to be pretty systemic.
- Why is the light inside the oven exactly the kind of colour that makes everything look done? Why doesn’t it have a —say— daylight spectrum so my food actually looks like its supposed to look?
- Why is there only one light inside the oven? It’s very easy to cast shadows onto food if you use more than one level now.
- Why is the glass front covered in a fine grid of black dots? If I want to see inside my oven I have to move my head like a chicken on crack just to stop my eyes from auto-focusing on the pattern.
- The metal grid that covers the gas-burners is made up of two pieces. They too big to fit into the sink so I have to wash them in the shower. Why couldn’t they have made it four pieces?
- Why are there so many narrow creases near the bit where grease tends to spatter?
- Why do the gas-burners whistle at certain settings?
- Why is the smallest burner on the lowest setting still too strong to let creamy sauces simmer?
May 25, 2012
Graphic Interface design —or User Experience (UX) design as it is nowadays called— is not a science. And when you see 99% of all the interfaces out there you’d be hard-pressed to call it “art” instead. To many software developers UX seems to be a necessary evil. On one end of the spectrum we find the applications that seem to have an interface that exactly represents the program code. If there is an SDK function called MergeReferencedTemplateStructures() there will be a menu item called Merge Referenced Template Structures Ctrl+Shift+Alt+M. In many cases I wouldn’t even call this “design”.
Other programmers seem to treat UX design as a challenge to make their software as distinctive as possible. At this end we’ll find hand-crafted GUIs that do not in any way conform to the OS standard. Have you ever noticed for example how all virus scanner software looks completely unlike any other software? Virus scanners use custom images to represent tabs, buttons and toggles. They tend to reserve large areas on the main interface for logos and background images. I do not know why this should be so, the only logical explanation I can think of is that virus scanner developers believe that end users won’t trust software whose purpose is to protect the system if it seems subordinate to that system. The result is that it is often not clear what parts of a virus scanner window are clickable, and due to the non-standard nature of the interface, tooltips are often missing entirely. Not all UX that breaks away from OS-standards is bad by the way. Sometimes there are good reasons for re-designing a UX standard. Adobe LightRoom and Blender are good examples of non-standard UX design that seem to work very well.
The most important part in any UX decision is the U. The interface serves only the user. It is not there to make you feel good about being a UX designer. It is not there to provide good screen shots for marketing brochures. It is not there so you can show off your Photoshop icon skills. The only guiding principle worth a damn —and I cannot stress this enough— is the user. There’s just one problem; the user doesn’t exist. Unless you’re writing a program for a single client, you’ll have to deal with users, and as soon as there’s more than one of ‘em there will be conflict. All users want features specifically crafted to help them with the idiosyncrasies of their unique and individual tasks. All users want not to be confronted by features made for others. Some users want shortcuts, some users want drag+drop, some users want all features to be in the main menu, some users want all features to be in context menus, some users want toolbars, some users want command-lines, some users want text, some users want icons, some users want animated icons with text. It is easy for a software company to say that they listen to their users, because once you have enough users, every single possible opinion can be distilled from the hubbub. It’s like reading tea-leaves.
April 9, 2012
I’m often struck by how even the most straightforward and standard interfaces are cumbersome to get right. I know, I know, I’m the first to admit I don’t get stuff right all that often, especially not at the first go, but hear me out. Imagine the following object:
It’s something which is used often in hardware control panels, but less often in software UI. Most notably, when it is used in software it’s mostly when the software is specifically designed to mimic hardware, such as audio mixing boards. This is actually a shame, because a dial provides a number of benefits over linear sliders. For one, it is potentially infinite. You can keep turning it and turning it all the while changing the value. This is not possible with a linear slider. Also, the farther away the mouse is from the dial, the more accurate the control becomes, as the angle between two adjacent pixels is much smaller from the dial’s point of view:
The angle α is larger than β because the green pixels are closer to the dial than the blue pixels. So as users we can adjust how much effect a radial mouse displacement has simply by moving the cursor towards or away from the dial. Although one could implement a similar effect in linear sliders (the further away the mouse from the slider, the less the effect of a mouse translation), it would not be anywhere near as intuitive and controllable as the native behaviour of the dial.
But I came here to complain about boring interfaces, and a tuning dial is not boring, even though you might feel it is annoying. The boring bit comes in when we need to make the dial behaviour customizable. Is the value limited to some domain? If yes, what is this domain? What is the range of a single full turn? And so on and so forth. Simply putting all these values on a window would certainly allow users to adjust the dial and I’d bet a lot of programs simply take this approach and leave it at that.
But there’s a problem, some user settings depend on other user settings, which means not all possible values result in valid states, allow me to elaborate. The minimum limit should not be equal to or higher than the maximum limit and —conversely— the maximum limit should not be equal to or less than the minimum limit. How do we enforce this rule? Take some time to think about how you would encode this constraint.