There's a great article by Steven Garrity over on A List Apart called Design with Difficult Data. It runs through the advantages of using unusual content to stress-test interfaces, referencing Postel's Law, AKA the robustness principle:
Be conservative in what you send, be liberal in what you accept.
Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:
Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.
In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:
It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.
In other words, be liberal in what you accept from users.
I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems. When it comes to figuring out what specific tools or technologies to use, there's an equally useful principle: the rule of least power:
Choose the least powerful language suitable for a given purpose.
On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?
Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.
Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don't get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.
As a general rule, it's always worth asking if you can accomplish something with a less powerful technology:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
- Instead of using JavaScript to do animation, see if you can do it in CSS instead.
- Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like
required. - Instead of using ARIA to give a certain
rolevalue to adivorspan, try to use a more suitable HTML element instead.
It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about evaluating technology; choosing the most appropriate technology for the task at hand.
There are some associated principles, like YAGNI: You Ain't Gonna Need It. That helps you avoid picking a technology that's too powerful for your current needs, but which might be suitable in the future: premature optimisation. Or, as Rachel put it, stop solving problems you don't yet have:
So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.
There's no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.
After all, if they're good enough for Tim Berners-Lee...
This was originally posted on my own site.
