The implementation ∝ appreciation rule

Written by Harry Roberts on CSS Wizardry.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

I’ve mentioned this idea to a few designers and developers of late who all seem to agree that it has a point and makes sense, so I thought I’d write up my thoughts on what I call the implementation ∝ appreciation rule. That is to say, anything you spend time building (on top of, as well as and beyond the scope of the base build) should reap an amount of appreciation from the users that is proportional to the time it took to implement.

I have a very aggressive and die-hard approach to progressive enhancement which I guess is to thank, in part, for the rule itself.

Let’s start with a very basic and tongue-in-cheek example. Let’s imagine your client comes to you and says ‘Hi, yeah, I love the site but can we make all the links, headings and image borders the same colour as my chihuahua’s eyes?’ … ‘Well sure, you can, but it’ll take an hour at £xxx and I don’t think that it’s going to bring enough user attention, or even be noticed enough–if at all–to warrant the time it’ll take me to do and the money it’ll cost you to have it done.’ In other words, the implementation is not proportional to the appreciation.

Now this is a very stereotypical and clichéd client-from-hell example, but it does paint a picture of how the rule works; will the time it takes you to change something, or add a feature, reap enough benefits to make it worthwhile?

You can’t really feed this equation any numbers, of course, but that’s where it’s up to you to decide what is the cut off point. If you think that the amount of time it will take you to add a feature is worthwhile and will have a proportional appreciation then that’s your choice, and whilst it may not be the same outcome as the agency down the road, it’s you who is building that website.

A more realistic example was during a build I was on with at work. I saw something in a PSD that I thought was missable enough not to fulfil the implementation ∝ appreciation rule; the time it would have taken me to code a robust, <IE7 solution would have been far greater than the amount of time any user would have spent thinking ‘Wow, I’m glad he did that!’

I had no metrics here, I wasn’t able to say ‘this will take me 45 minutes to get working in IE7 and below and will only be appreciated 0-0.8 seconds by any given user’, but sometimes you just know what is sensible and what isn’t.

I guess that’s part of the beauty of the implementation ∝ appreciation rule; you decide its metrics and make them work for you.

I guess also, given the right account or project manager, a ‘more quantifiable’ or rational, measurable and reasonable stance such as the implementation ∝ appreciation rule could well be a more diplomatic and sensible way to steer clients toward taking the progressive enhancement route; something which nigh on all developers would love!

I think an approach such as this is best introduced either on your own personal projects, or on builds where your clients is okay with progressive enhancement (which, hopefully, they all are!). After that I guess it would be time to introduce your most stubborn clients to it. After all; more often than not you’re building sites for your clients’ clients. Just because your client thinks dog-eye-blue links look cool does not mean to say their clients and users will, and they’re the ones that matter…

Furthermore, money talks. Being able to say ‘this will cost you £xxx and is almost certainly not going to make you a single penny’ (politely, of course) can often be enough to steer even the most headstrong client.

And of course, even if something does not fulfil the rule and your client is still insistent on a piece of work being done; they’re paying you! Even if it makes no sense to you, or in the eyes of the equation, just see it as extra cash!

So I don’t suppose I’ve said anything new here, rather I’ve just offered a semi-quantifiable way to justify a more progressive approach to working for and with your clients. If a user won’t appreciate or even notice it then why bother wasting time and money on it?

The implementation must be proportional to the appreciation.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

By Harry Roberts

Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.