Being a fan of overly provocative titles, I was tempted to title this “If-Statements Considered Harmful”. Meaning that it’s so tempting to add little bits of intelligence to your app to make it do the sensible thing in different circumstances. And that’s usually perfectly correct but the Anti-Magic Principle says to do that less than you think you should. Be simple and consistent and dumb and predictable!
I’m worried this whole blog post will sound banal but I’m gradually learning to tell that inner critic to shut up. This is hard-won wisdom, people! In fact, it’s been a helpful guiding principle for us for years now and we’ve caused ourselves a lot of grief by violating it in the past, before we got our heads around it.
The Anti-Magic Principle says software shouldn’t do anything seemingly magical. It should be as simple and transparent and predictable and convention-following as possible. This can apply to big things like the auto-widening yellow brick road (facepalm!) or more commonly to little things like suppressing the display of a checkbox in the UI when it’s not applicable. (When a user remembers that a checkbox used to be somewhere and now it’s not, that’s confusing and frustrating! Better to gray something out than to have it magically disappear.)
More Examples
It turned out to be a bad idea to let the default date for the add-data form magically update to the new day when the deadline hit. It seemed so reasonable at the time but led to confusion and frustration when coming down to the wire on adding data. Dumb and predictable and slightly wrong can be better than impeccably right but surprisingly clever.
Having data magically know to display in HH:MM format because you used the string “hours” as your goal units: bad idea. (And, embarrassingly, we haven’t yet fixed this! Long story, and all the more reason to have the principle to prevent us from doing things like that in first place!)
Trying to intelligently decide whether to have the road dial expanded or collapsed in an attempt to avoid confusing newbees with more information than they’d typically want to know. (See an example of this causing confusion.)
We used to magically suppress reminders if you’d already entered data for that day. That made it seem like the bot was randomly flaking out!
Self-destructing pessimistic presumptive reports (PPRs). This one’s very tricky and is worth keeping the anti-magic violation for now but points to the need to eventually do something different with PPRs.
Only showing a search button in the iOS app if you had more than 10 goals. That’s the only time it makes sense to have a search button, sure, but it’s better to just always have the button, even if you only have one goal. Otherwise you’ll have users thinking they’re crazy because they saw the button last week and now they have 9 goals, having crossed a threshold wholly opaque to them, and, rage-emoji.
Now our heuristic is to follow anti-magic slavishly, at least at first. It’s easier, implementation-wise, anyway. Deploy it that way and see how it feels. Only then consider adding the magic, like not showing both thingies if they’re identical or whatever.
Isn’t this just the Principle of Least Astonishment (POLA) or KISS?
We don’t think so! For example, in the last example above, POLA could suggest that users won’t expect a search button when they only have one goal. Anti-magic makes it more clear: just be dumb/consistent, user-surprise be damned. Or check out the standard criticisms of “Do What I Mean” (DWIM). Trying to minimize user surprise by doing what they meant instead of what they said tends to backfire.
Likewise, anti-magic goes beyond mere simplicity. In the third example above, our whole motivation was to make things simpler for newbees. But it violated anti-magic and anti-magic was correct.
(What about “Worse is Better”? That takes anti-magic to a seemingly ridiculous extreme but I’m kind of a believer in that too.)
You can well object that a magically appearing/disappearing search button is what’s more surprising or that magically suppressing confusing UI elements because we think you’re a newbee is less simple, and in one sense you’re right. Either POLA or KISS might always give the right answer if you look at them the right way. But that’s what it means to be a guiding principle: it’s the thing that actually induces you to look at it the right way.
Thanks to Nathan Arthur and others in the precursor to this post in the Beeminder forum for contributing ideas that led to this post.
Image credit: Faire Soule-Reeves