Thoughts of a Serial Tinkerer

Developer-Enforced Design Flaws

Posted on 04 Nov 2011.

This morning, I happened upon “Wired’s Essential Apps for 2011” and quickly found myself frowning. I wasn’t frowning because of the Wired editors’ decisions about which apps are the best, it was because I was frustrated with a glaring design problem in their article and I suspect I know the reason it looks so bad:

Developers Built it That Way

Developer-enforced Design Flaws

It’s not an isolated problem, really. A developer is given a functional spec that calls for a grid display of ‘apps’ which will have a company name and the app name. Seems reasonable, and with most modern CMSes, probably not too hard to build, either. It looks great with dummy lorem ipsum content when shown at the design review meeting, no one ever stops to wonder if their content will actually fit the requirements, though. And then when it comes time to put the real content in both company name and application name are required fields, so when you come to a company that is self-publishing an eponymous app, like Netflix, then your editors are stuck. They are forced to do something they know is wrong and they put the same name into both fields.

It’s easy to pick on Wired, but this is something I see (and, I’ll admit, have done) on any number of websites. Maybe it’s the nature of building and using content management systems. I do a lot of work with Drupal at Treehouse Agency and I think it’s safe to say we run into this problem somewhat regularly. We build interfaces and want them to be easy–excruciatingly easy– for editors to use to create and manage content. So we separate content out into separate inputs in the content creation screens, we make different ‘content types,’ we create arbitrary divisions between what is content and what is ‘auxiliary content.’

Recently, there was a bit of a scandal in the WHATWG around one spec editor’s personal plan to deprecate the <time> element and replace it with something he saw as more appropriate. Jeremy Keith wrote a blog post about the event and in it talks about one of the key decision-making guidelines for the HTML spec: the Priority of Constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

It seems to me that this would be a great guiding principle for CMS developers, too. Of course, with CMS development you might have many types of users: visitors, commenters, contributors, editors, managers, administrators, etc.; so how do you decide who should get precedence? I think the Priority of Constituencies still speaks to this scenario: privilege the visitors of your website over your content creators and staff over your developers.

What do you think? Do you see developer-enforced design flaws in the sites you visit? In the work you do? How can we bring the Priority of Constituencies into our work as website and CMS developers?

This post originally appeared on Treehouse Agency’s blog.