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.
Comments
Nice article as the benefits always seem so good – i.e. you see what the page will look like as you create it.
I implemented something like this a while back and it worked very well with the client liking it a lot. To acheive a good user experience while editing involved a fair amount of client side scripting (JS/jQuery) which again worked great.
So all is good right? Not exactly. Where it really fell down was on maintainability. When we came to reworking some of the site, adding new features, modifying pages the overhead in also maintaining the editing features became huge, in large part to the client side scripting and its interaction with the page. Maybe if the client side scripting was structured better this could have been lessened, but then again that is more overhead added to its creation in the first place. All in all the overheads ended up outweighing the benefits and it was just not a cost effective method of working, for either us (the developers/designers) or the client.
The standard model of separating data from UI still seems to fit this example and separating content management from the front end viewable site still seems to be the most sensible approach to me.
Great article, and one I’ll keep in the brain-bank for the next time a client asks about a CMS. I’ve found over the last few years it’s very important to educate the client that a CMS is – to manage your content (clues in the name), it’s not a web-design tool with complete control over look, positioning etc.
This did get me thinking though – perhaps a solution (suitable for perch?) would be to include edit buttons on the front-end of the site (when logged in) that directs through to the relevant area in the CMS. Then the client still keeps the link of ‘this is what I want to edit’, without all the headaches you’ve listed?
I’ve seen enterprise CMS systems that have this, but they’re a massive headache to impliment. I think you have the right approach.
I’ve wondered for some time why more CMS’ don’t have on-page editing. It always does look like the ‘height’ of cool with a CMS. However, you’ve picked up on a lot of technical issues/limitations that I hadn’t considered previously, which make a lot of sense.
Not only would it be a colossal lot of work, but the amount of things that could go wrong probably makes the whole thing a bad idea.
What’s also to consider is the perception of Perch; a very simplified CMS. It’s not trying to fulfill all the bells and whistles, and be able to out-feature and out-perform big CMS’ – it just does what it does well.
I agree on all fronts and this is why we have not implemented in place editing in our cms as well. Thanks for expressing this in such an elegant way. I’d like to add that this is also why we do not use a WYSIWYG editor and prefer a textile or markdown style approach to editing copy. I have to explain the benefits to clients who are expecting more of a MS Word type editing experience. But we get almost no technical support requests.
Hi Drew. I respect that you have greater experience in this than I do, but the logic seems very counter-intuitive to me.
I do much of my development with the Drupal CMS, which has something pretty close to on-page editing for most things. The systems I’ve built with that have a separate admin area are Wordpress, Perch and CMS From Scratch. The feedback I tend to get is that users find Drupal’s on-page editing easier to understand and work with than a separate admin area. One benefit they often cite is being able to browse their site the way they normally would to find content. This seems to help especially on community sites, fora or social networks where regular visitors to the website may, over time, become participants and eventually site administrators. In these cases, they just carry on doing what they always did as a visitor – they just have a few more options open to them.
I’m reluctant to draw objective conclusions from my experiences, as I’m sure that we all find ways of helping our clients to understand and feel comfy with the systems we prefer to develop with. You’ve given me a nudge to perhaps ask my clients for more feedback on their experiences.
There is however one point upon which I have to disagree.
This objection seems a very academic one, and I have never found it to be an issue in the real world. Clients I’ve got on Drupal perfectly grasp that the content they’re editing is not the page itself. They intuitively understand that when they add a news article, or an event, it may show up in a couple of summary listings as well as appearing on it’s own full page.
If you think about it, people are used to this concept in word processors. They edit the footer on one page, and aren’t surprised to find that the footer is changed on every page.
At the CMS level I agree with Drew’s points and concerns. As you move up the stack though there are opportunities to implement on-page editing that works really well. the example I brought up – http://josephscott.org/archives/2011/03/on-page-editing-pro-or-con/ – was the WordPress P2 theme – http://wordpress.org/extend/themes/p2 . At the theme level it is easier to provide a nice, consistent on-page edit feature to the user, in part because it only does it for specific items.
I’ve been considering many of the same issues, and as an implementor whose job it is to fulfill external requirements (meaning I don’t have much of a choice), I’ve been considering dynamically pulling the page element out of its position and replacing it with an iframe containing the editing interface.
I have been developing CMSs for over 6 years now and on-page editing is always on the mind. But as soon as I think “wouldn’t it be great if…”, I remember why I never build it. For starters, there are the hidden elements: the browser title, the meta description, the slug, the site hierarchy. Then there are the non-body fields: the thumbnail, the slug. Many UI solutions come to mind: the lightbox form, the text that turns into inputs, the click to edit blocks of HTML. But that’s not how people use a CMS.
Ultimately, the need for on-page editing rests with the designer, not the editor or the writer. The latter two are confident that their text will be appropriately styled. They have their standard image size and layout. Their tools are semantic-focused rather than design. Instead, they want to have an administrative point-of-view. Show me all the articles and pages, let me create and edit one. Let me edit this page. Show me what my work will look like after I’m done. All this is already accomplished with the tools a CMS like Wordpress provides. As for the designer, s/he will have technical skills to modify the content and add extra style and tags.
A great issue that I’ve gone back and forth about many times.
One implementation I enjoyed developing was an edit link that opened the control panel in a javascript popup. I know, I know, JS popups are kinda annoying, and often struggle with problems of their own, but the clients always LOVED working with it, since they could find their content by browsing but edit within the CP interface. I’m not sure if the site I’m referring to was simply small enough to manage this way, or if it’s actually a nice compromise.
If there were a template ID variable you could have create edit links to the perch admin interface with your own markup and styling right in the templates:
<a href=”/perch/apps/content/edit/?id=#ID#” class=“edit”>Edit</a>
It’s a technique I use with ExpressionEngine and its {entry_id} variable all the time. It’s no on-page-editing but very simple to use for the user.