Ridicule

A frequent trope of user interface discussion, one often picked up by journalists, is to hold up a bit of bad design to show how cravenly ridiculous it is. This has been going on for a long time – Louis Sullivan’s Kindergarten Chats sometimes border on this – but in tech criticism I associate the style’s roots most closely with the enormously influential Don Norman, the father of information appliances.

Ridicule is closely coupled in practice with a deeply anti-intellectual strain that wants to remove effort, learning, and expression from computing and that valorizes the new user to the exclusion of everything else. Today’s software marketplace exaggerates this: what demos well sells, and once you’ve made the sale, it’s time to move on to the next mark sales lead user. App stores make this worse because they eliminate update revenue and mostly eliminate the demo phase: show the user a pretty screen shot and maybe a two-minute video ad, take their 99¢, and move on.

Artisanal software can resist this, but there remains the insidious call to do stuff right – to polish those tabs some more, to speed stuff up, to make things work. Even things that, maybe, don’t need to work.

Yesterday, I spent most of the day on a problem report.

159: Dragging more than one file at a time sometimes fails to create notes.

To the connoisseur of bug reports, the key word here appears to be sometimes. Either some files never create notes (and we discover this most easily when importing a bunch of them), or some files will fail to get imported the first time because some concurrent process is getting in the way. Both are plausible.

I set out to instrument things to monitor the import process. An hour later, I found that all this analysis was wrong: dragging more than one importable file at a time always created one note. The code was written to ignore the extra files; all the instrumentation was looking at the wrong place.

So: why was the code written to import only one file? Because that was easy and got the most common case out of the way. But it’s obviously nicer to accept a bunch of files at a time, and the generalization shouldn’t be difficult – not if the code is any good, not if you understand Composites. So, I added some more tests and refactored and a few hours later, the tests said we could import a bunch of files.

And a few hours after that, Tinderbox actually would import a bunch of files: the Undo system (of all things) was undoing all our new work and saving only the one file we formerly imported. No one expects the Spanish Inquisition, and what idiot designed that?

So: it works now. It’ll take another day to polish and test and to get all the instrumentation cleaned up and put away. And, sure, it would be pretty ridiculous to require someone to drag a bunch of individual files one by one, rather than selecting them all and dragging. That’s making people work for the machine! What ridiculous design!

But: how often do we do this? I use Tinderbox a lot, and I might import a collection of files once or twice a year. Even then, six or seven files is probably par for the course. How many files could you drag, one by one, if you had all day? And, of the people who need to do that, how many have an assistant or an expendable grad student to do it for them?

I may have spent the whole day chasing style points or hiding from ridicule. Damn.