Microsoft’s operating system has many advantages, but “beauty and grace” are not among them. Gates figured out early that compatibility and ubiquity trumped looks, grace, security, stability and efficiency, which made him a billionaire. I complain about it, but he’s a billionaire and I’m using Windows, so… hm.
I understand that Microsoft does not have a company culture that fosters a lot of ease-of-use minded development. And that’s fine, I guess. I don’t expect high class at Wal-Mart, I don’t expect heartfelt and bittersweet indie Gen-Y character studies from Lucasfilm, and I don’t demand photorealistic graphics from Telltale Games. Companies all have their strengths and weaknesses, and they usually do well to stick with what they know rather than mimicking what their differently-designed competitors might be doing.
But sometimes the ugliness of Microsoft seems almost willful. Many years ago – back in the 90’s, actually – I ran into an article that revealed Apple’s approach to dialog boxes: If you’re going to throw a show-stopping question in the user’s face, then there are a whole bunch of rules and guidelines for what sort of information should be available and how it should be presented. The most important guideline was that buttons should contain verbs, or actions.
The classic Microsoft dialog is a popup window that says, “The files you are installing are older than the ones already installed. Do you want to keep these files?” This box would have Yes / No buttons, and maybe a Cancel button if the programmer was feeling really generous.
The user reads the box and still has no idea what “keep THESE files” means. Keep the old ones? The new ones? You can read the whole dialog twice and still not be 100% certain what will happen if you hit “yes”. Even if it was worded less stupidly, there’s still a chance that the user might read “Do you want to keep the newer files?” as “Do you want to REPLACE the newer files?”, thus inverting the question. Yes, it’s their fault for skimming, but part of designing a good UI is minimizing and mitigating destructive user mistakes.
According to the Apple document I read, a better design would be to replace Yes/No with “Install Older Files” and “Keep existing Files”, or something along those lines. Even if the user misunderstands the description, the buttons make it clear what will happen when pressed.
(Another pet peeve: Popups should always identify themselves. A foolish programmer is likely to title the dialog something like, “Installer”, not realizing that this can lead to chaos when someone has the installer running in the background, or run automatically, or is auto-run when putting in a disk. The user will see this dialog pop up and have no idea which program is asking this question or why. Is this drivers? Windows? An update for a game I installed eighteen months ago and haven’t played since?)
To be fair, I don’t use Apple products and I have no idea how faithfully they follow the ideas I read. I tend to admire Apple from a distance.
I’ve always wanted to follow this advice myself, but even after all these years, Microsoft is still mired in the interface design the 1980’s. That is not an exaggeration. They are stuck in the stone ages. They keep mucking about glossy semitransparent window titles with drop shadows, but they haven’t even lurched into this century when it comes to interacting with the user. (Nitpick shield: I’m talking about desktops. I don’t have any experience with their mobile offerings.)
The reason for this rant is that I wanted to create a little three option popup:
“Hey, you’re trying to delete this collection of objects. Do you also want to delete all the children objects?”
The buttons would be something along the lines of “Delete just this one”, “Delete this & all children”, and “Oops. Don’t delete anything.” Or whatever. You get the idea. The point is, the buttons should describe the actions being taken. But when I read the Microsoft docs I see they haven’t changed how popups work. You can create popups with fixed combinations of buttons. “Ok, Cancel”. “Abort, Retry, Cancel”. Or just plain-Jane “Ok”. But as far as I can tell, if you want to break from this behavior you have to go all the way to the foundation. You have to create your own window, buttons, text field, and arrange all the elements manually. We’re talking about a hundred or so of lines of code.
Rather than sink a bunch of time into that, I just stuck with the built-in “Yes, No, Cancel” dialog. Sure, it’s stupid and it sucks, but it’s one line of code and if I wanted to spend all day coding interface features that ought to be built into the OS then I’d send Microsoft my resume.
And thus the problem is perpetuated.
This always induces a certain degree of coding paranoia. Back in 1984 or so, some young pup of a coder was throwing code together, trying to get the Windows 1.0 project off the ground. The young man couldn’t see that the interface paradigm decisions he was making would still be shaping the way people used computers over a quarter century later. Of course, his decisions could have been modified or overruled later, but they never were. The interface design lingered into the age of 32-bit computing, into the internet age, into the age of Web 2.0, and now into the age of smartphones. The whole world is changed, and yet we’ve still got int WINAPI MessageBox() sitting there under the hood, shaping our software.
We coders never know just how long our code will last. I’ve had projects where I spent more time coding an application than was spent using it. I’ve had other situations where a quick two-hour utility would end up lingering for years.
Writing code is a dangerous act. If you’re not careful, the stuff you write might end up making a difference, for good or for ill.
A stream-of-gameplay review of Dead Island. This game is a cavalcade of bugs and bad design choices.
There are two major schools of thought about how you should write software. Here's what they are and why people argue about it.
The Witch Watch
My first REAL published book, about a guy who comes back from the dead due to a misunderstanding.
The Plot-Driven Door
You know how videogames sometimes do that thing where it's preposterously hard to go through a simple door? This one is really bad.
The Strange Evolution of OpenGL
Sometimes software is engineered. Sometimes it grows organically. And sometimes it's thrown together seemingly at random over two decades.