I’m worried this will sound banal but it’s been a helpful guiding principle for us and we’ve caused ourselves a lot of grief by violating it in the past, before we got our heads around it. So if it sounds banal I bet I’m either conveying it poorly or you’ve already internalized it!
The Anti-Magic Principle is that software shouldn’t do anything seemingly magical. It should be as simple and transparent and predictable and convention-following as possible. It can apply to big things like the auto-widening yellow brick road, and 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.
Here are some 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.
- Having data magically know to display in HH:MM because you used the string “hours” as your goal units: bad idea.
- Trying to intelligently decide whether to have the road dial expanded or collapsed in an attempt to avoid confusing newbees. (See an example of this causing confusion though in the meantime we found a compromise that seems ok.)
- The odometer reset feature probably never should’ve been allowed by the Anti-Magic Principle but it is admittedly very powerful and useful so maybe it’s an exception.
- 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) is another violation that I think I’m ok with.