- November 18, 2010
Responsible Development
- @markhuot
- Development Director
When Happy Cog undertakes a development job, one of our goals is to empower our clients with the necessary knowledge for them to help themselves. We’re not passing the buck — we’re planning for the future. No one likes writing or receiving panicked emails about urgent updates to the legal speak of the footer, or that so and so’s aunt just looked at the website and couldn’t find the button that adds an item to the cart. We work with our clients every step of the way to ensure that, even in those panicked moments, they are able to help themselves.
Invariably that leads to the implementation of a publishing platform: A platform that makes updating the legal speak in the footer as painless as updating your facebook status, without any Happy Cog intervention. This sounds like a developer’s dream: clients updating their website on their own; making, changing, and rearranging pages without the vendor raising a finger. It’s a win-win. At least, that’s the plan.
The Real World
Unfortunately, we don’t all live in that dream world where everything is possible. In the real world we all know publishing platforms can be more confusing than the HTML they output. As you add functionality to your publishing platform you also add complexity. As a result we’re forced to make tough decisions. For example, is the extra form element worth the added complexity, just so our client can update the footer, which may never change?
It’s not just within the publishing platform we’re making these decisions, either. For example, on the front end we must decide if the navigation should be allowed to grow and shrink on demand as pages are added. If so, the information architecture, visual design, and template code must accommodate a ten or twenty item menu just as comfortably as one with just one or two items.
Most importantly, is the client appropriately resourced to support a curated experience? Do they have enough capable staff to make emergency changes to the footer, or update the navigation when navigation emergencies arise? Will they need to update a curated list of articles on the homepage each day, or is an automated approach, such as a listing of recent articles, adequate for the goals at hand?
Unlimited
At Happy Cog we avoid arbitrary limits as much as possible. Character counts. Page limits. Generally, we don’t like ’em. Working within a publishing platform gives our clients the freedom to continually evolve their site as their needs change. Placing restrictions on how clients write copy or structure page hierarchy only limits their creative ability to expand their site.
But Also Limited
When stretching the reach of a publishing platform by adding custom functionality, it’s easy to get carried away. For each unique editable area you add, be it a navigation item, a textbox, a template tag, or a processing cycle; you add complexity. While we avoid arbitrary limits as much as possible, we also avoid unnecessary complexity as much as possible. It’s a constant balancing act; for each block of content we ask ourselves: “is the addition of another control in the back-end worth the added complexity to our site editors and managers?”
These are just some of the questions I’m faced with every day. While I have my own opinions about them, I’d love to hear yours. How far is going too far when implementing a publishing platform? What are the worst risks you take by providing that freedom, and what risks do you take when you don’t?