I get asked quite often why Perch doesn’t offer any sort of on-page editing. It’s something we’ve given a lot of consideration to, and as it’s an interesting software design issue I thought I would document some of my reasoning here.

So what do I mean by on-page editing? In the context of a content management system, we’re talking about the ability to make edits to a page directly by clicking on the content (or a nearby Edit link) and manipulating it in place on the front end of a website. The alternative approach in contrast to this — and the approach we currently take with Perch — is for the user to go to a dedicated control panel to edit the content away from the page.

There are a couple of issues with on-page editing in my mind.

The technical

The big technical hurdle with on-page editing is the necessity for the CMS to inject its UI into the front-end page. At first that doesn’t sound too bad, but the more you think about it, the bigger a challenge that is. The pages own CSS and JavaScript are all going to influence the editing UI in unpredictable ways. The CSS you might think can just be dealt with by using very specific selectors and some sort of local CSS-reset, and you might be right, but what about z-index, overlapping absolutely positioned elements, dealing with Flash? JavaScript is another issue – if the editing UI uses JavaScript, will it conflict with anything on the page? Will the page’s own JavaScript conflict with it? What if the page attaches event listeners to the editing UI by mistake? What happens if two versions of the same library get loaded? What about sIFR?

These are all thorny technical issues that require effort to work around. Are they insurmountable? No – they can all be addressed. However, it becomes a Red Queen’s race to address issues as they arise, requiring a considerable amount of development time (not to mention the associated support) in order to maintain the status quo. If you have limited development resources, taking on that sort of burden could really inhibit your ability to move the product forward. As a developer I want to spend my time making a product better, not keeping it the same.

The touchy-feely stuff

More important than the technical considerations (which can all be dealt with if you choose to take them on) are the usability considerations. Will this be good for my clients editing their site? On-page editing certainly gives good demo, but does it go further than that?

Obviously, the immediate usability issue that has to be overcome is how clients edit content that’s not always visible on the page. Things like modal overlays and JavaScript carousels all requires a lot of thought, especially when you have no idea of the sort of sites where the CMS will be implemented.

That’s not my main concern with on-page editing, however. My main concern is this. One of the primary benefits of a CMS is being able to reuse bits of content around your site whilst maintaining it in one central place. A client can create, for example, a listing of news items on a News page, and also have the latest item or headline display on the home page. This is where on-page editing falls down.

On-page editing creates a model whereby the client is told they are directly manipulating the content on the page. It tells them they are taking a ‘physical’ page and remoulding it to their requirements before setting it down. That’s a really powerful metaphor, and I can clearly see why clients would like it.

However, as soon as you attempt any content reuse across the site, the metaphor is broken. The physical model becomes metaphysical, as a change to content in one place and affect content in another. This leads to unpredictability in the interface, which is the very worst thing for less technically-confident clients. Unpredictability leads to a distrust of the software, which leads to it just not getting used.

The control panel editing experience creates an abstraction from the page quite deliberately. That abstraction is needed in order to be able to make use of the technology in the way that best serves the client. I don’t believe the direct-manipulation metaphor (i.e. on-page editing) can be maintained whilst still offering the labour-saving benefits of managed content.

It’s about giving users confidence

Much of what we do with Perch is designed to give those less technically-confident clients confidence in editing their sites. We don’t want to see designers handing off a CMS to their clients only to be getting a phone call every time some content needs changing. The abstraction of using a control panel for editing enables content reuse around the site – that means the client doesn’t need to remember a long task checklist each time they make a change.

Features like preview, drafts and undo are all designed to give clients the confidence that they can’t make a mess of the site, or if they do, they can back out of it.

On-page editing is a technical and a design challenge, but we’re not afraid of those. There are plenty of instances where we’ve taken on difficult problems because it will make the user experience much better. It’s more that I believe that direct-manipulation is a flawed approach because it is in direct conflict with the goal of using software to reduce tedious, repetitive tasks.

If we can find a way in the future of implementing on-page editing without those downsides, we’ll certainly give it some attention. I want the editing experience with Perch to be the best it can be for clients. At the moment, although on-page editing looks great in demos, I don’t think that implementing it is at all in the client’s interests. In fact, I believe it’s against their interests.