planet drupal · the economist

Economist/Drupal – Complex Editing In Place

Edit In Place

Following on from our work in Sprint 1, I’ve been conducting some research today to establish whether or not we’re going to continue down essentially a traditional ‘admin’ system path or whether we’re going to pursue the altogether more challenging (read: scary & hard work!) route of trying to do as much of the content creation and editing ‘in place’ (which effectively means in as much of a WYSWIG environment as possible).

The research today involved some simple walk/talk throughs of two very basic prototypes that I had made using Omnigraffle and showed in the ‘Presentation’ view (probably the fastest way I’ve found to build relatively complex application interfaces using a mix of screengrabs and wireframes that you can click through). For those who are interested, those and this blog post are going to form my ‘demo’ materials for this Scrum sprint.

Predictably (although also happily) everyones main priority is for things to be ‘as simple as possible’, however there was a strong leaning towards the ‘in place’ solution which I found somewhat surprising, as previous research had almost indicated the opposite. (Yet another reason to research as iteratively as you design!)

So, for the next few days I’m going be working on more detailed interface designs for this ‘edit in place’ approach, and to that end, I wonder if you can help me… I’d *love* to see some good examples of relatively complex edit-in-place/WYSIWYG interfaces. Obviously Flickr is the poster child for fairly simple in-place interactions, but are there good examples of being able to add and create new content elements, move them around on page, maybe even manage a few versions of the page… relatively complicated stuff.

If you could point me to any examples, I’d be incredibly grateful!

21 thoughts on “Economist/Drupal – Complex Editing In Place

  1. I’m afraid I don’t have any good examples of complex edit in place. But it’s interesting you say that it’s all about keeping it ‘as simple as possible’ because I guess to a certain extent, being able to edit something relatively complex ‘in place’ is very simple indeed i.e. you just click on it and then you can edit it. It’s just possibly very complicated to design and build in a robust way. Participants are always saying ‘Ooh just keep it as simple as possible’, if only they knew how bloody difficult simple can be sometimes.

    1. yes, it’s that old thing of the simplest things resulting from a whole lot of hard work, isn’t it :)

      I guess the reason this is particularly challenging is because we want to do more than just edit a line of text here and there, or add some tags. The kinds of things we want to do is to add different pieces of content from a choice of content types, sometimes create content on the fly and sometimes choose from a list of existing content, move content around, add bits of content to larger bits of content, delete content, potentially manage different versions of a page… and maybe, maybe even a little workflow.

      so, the simplicity – if we can get to that – is probably a complete illusion. (Having said that, I do know that we can potentially present this in a relatively simple ‘form’ format… so we have a fall back position – the ‘in place’ would be idea if we can make it work tho!)

  2. Editing-in-place is a bad idea. It may appropriate for casual users or neophytes, but not for experienced, intelligent editors, writers and administrators working within a well-honed site architecture.

    1. Hrm. Not sure I agree with that (although I am far from wedded to this approach). One of the main reason that in-place is appealing to the end users of this system is that they currently have to do a lot of moving between the live interface and the admin system crafting content to suit the interface. Future designs of the ‘reader interface’ will probably demand this crafting more, not less. So it is not so much about the level of sophistication of the end user but about the tasks they are performing and how we can most effectively support them through interface design.

  3. Unify, the new (still in testing) content editor from Unit Interactive uses what I would call a hybrid between in place and back end editing, showing content block in place and then bringing up a RCE when a block is selected. I think they are still accepting sign ups for beta accounts here:

  4. You can find inlien editing in various modern CMSes. One example is Weebly

    Another one is

    Of course 37signals Basecamp Pages are somewhat inline edited pages.

    And the last which I can remember now is the Sitefinity CMS, which is not exactly inline (tet is not edited inline, but in pop-ups) but is pretty much close – has drag’n’drop etc.

    I recently made a research on this very topic and found several other CMS systems which use inline editing. They are interesting. I even designed our company’s CMS to be inline. So far the results are mixed. We need to do more extensive user research to see if this is the best way.

    1. yes, a good point. BackPack probably deserves poster-child status with Flickr, doesn’t it. Especially for the yellow fade effect. I’ll go take another look and see what we can draw from them. thanks!

    1. yes, i’ll go take another look at Squarespace. I looked at it when we were doing the D7UX design work and considering if/how to use edit in place there and I remember feeling that it was a little heavyhanded in the way the edit in place was implemented, messier than I’d like this interface to be… but let me go take another look. thanks!

  5. Do you mean only inline editing of nodes? I’m wondering how one would inline edit blocks, views, queues, panels, since an increasing number of sites are (or will be when Panels3 is finished) made up of these, too, and sometimes actual content lives within a block or panel or mini panel rather than within a node…

    I don’t mean to go off-track but I feel it is worth looking at all of this as a whole in order to make Drupal sites easier to edit. Drupal’s versatility is fab but it would be great to have a unified plan for both content placement and content editing. Having to click click click into the block admin to edit a custom block or into a panel or mini panel to edit one of those, and then go back out to see if it looks right, and then back again to tweek…is just cumbersome. And blocks and mini panels overlap and we strive to eliminate overlap…

    My main site uses a combination of all blocks, views, queues, and panels (maybe foolishly?). Editors may need to change where a node appears as much as the contents inside the node, and this can be an unintuitive multi-step process as well (especially if the editor did not build the site). Sometimes an editor must look around to see what placed a bit of content somewhere. It would be great if editor role permissions, for example, could allow for overlays or something that inform the editor where to go to edit the content in question (something along the lines of dev module but for editors) and link to it.

    1. yes, we’ll be looking at nodes + some combination of blocks/views/panels/queues etc. The technical implementation is being led by the design so I guess they’ll look at what we want to do and then decide what is the easiest/best way to implement it… but I have no doubt it will be a challenge both for us as designers and for the technologists to implement.

      I’ll happily share with you what we end up doing here, but also keep in mind that a big part of the effort for D7UX was to make the ‘out of the box’ Drupal experience a lot more tailored for content creator/content managers – we didn’t get quite as far as we would have liked with regards to content placement (that was the Site Builder tool that we could never quite get community backing to develop) but hopefully it is one step along the path to a much better user experience for the people who have to create and manage content on sites powered by Drupal!

  6. Right now I’m looking at a redesign of our Drupal based website. I’ve contemplated inline design, but I think we’re going to go sort of halfway there.

    Instead of true inline editing, it looks like the best way for us is to judicially place “Add new content here” or “Add child content here” buttons around the site.

    So, actually editing existing content (by clicking the Edit tab or maybe Edit button) still switches you to the node/edit screen, there will be a new way to quickly add content to an existing section or taxonomy.

    For example, on the ‘News’ page (river of news style) you’d find a “Add news item” button and it would take you directly to a node/add form with some metadata already selected or filled out, because you came from that specific button in that specific place.

    The adding “child content” option is a quick way to make a new ‘sub-item’… think adding a page or gallery to a ‘Report’ like content structure.

    Regardless, I’m following the inline editing quest with interest, because there are a couple of places in our website (and a couple of users) that would benefit from it :-)

    1. yes, what you’re describing here is a possible fall back solution if we’re not able to get the ‘in place’ creation/editing working simply – I’m still not entirely convinced that the effort required to design and implement the in-place editing is going to weigh up with the value delivered to the end user… but we’ll push it along a little further and see what we can do. I think we’d be fairly happy with the partly in place solution you’re describing here tho :)

  7. Leisa, thanks for sharing this content. An out of the box solution I’ve seen which does this well is

    I particularly like the way that only small tasks are apportioned by content type (such as blog or calendar event), which dovetails nicely with creating CCKs and views in Drupal; but it’s still a big task you’re taking on!

    We’re working on a simlar project for deployment to our clients, as the consensus is that the Drupal interface is just not client-friendly enough (a view shared by many I know).

    Much like @fschaap we’re currently settled on a hybrid solution: with a traditional interface for some tasks and the option of inline editing for others, which is obviously not ideal. Needless to say I await your progress with interest!

    Keep up the good work :-)

  8. I particularly like the way that only small tasks are apportioned by content type (such as blog or calendar event), which dovetails nicely with creating CCKs and views in Drupal; but it’s still a big task you’re taking on!

Comments are closed.