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.
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?
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.