Economist/Drupal – Design Principles for CRUD-In-Place

I’m going to stop referring to what we’re doing as ‘edit in place’ because actually what we’re attempting to do is what is charmingly known as ‘CRUD’ in Content Management System (CMS) lingo, being Creating, Reading, Updating and Deleting content.

I’ve spent this morning reviewing a whole host of existing examples of ‘CRUD-in-place’ (thanks to the great examples that you provided in response to my previous post). I have to say, although there are quite a few examples out there, not very many of them are particularly inspiring… at least for my purposes.

I’ve posted up some screenshots and a few comments on Flickr that you’re welcome to add your thoughts to. As a summary I think that for this project we can absolutely draw the most inspiration from Flickr & 37 Signals (eg. BaseCamp) implementation of edit in place – mostly for their simplicity, which is the entire point of this exercise.

Many of the other examples offered huge amounts of flexibility which is, frankly, the complete opposite to what I want to offer here – we want to offer flexibility within a template (or perhaps templates) certainly not the ability to create templates on the fly (we don’t want to make people whose skills are editorial suddenly have to try to make good design/user experience decisions!).

Two other pet peeves that I’ve developed since I’ve been reviewing these interfaces are the overly liberal use of buttons when a simple text link would suffice, and throwing up a great hunk of a form that was obviously intended for a back end interface when a much more elegant ‘in place’ solution could have been achieved.

Now that I am trying to apply my learnings and inspiration to my particular design challenge I’m finding myself coming up with some design principles that I will probably add to over time and hope to use consistently throughout the system design. I’m going to start posting them here so I can keep them together and you can give me some feedback as we go!

Design Principles for CRUD-in-place

  1. Don’t map the interface to the technical architecture, map the interface to the tasks that users will want to perform. The user/interface shouldn’t have to care about the way that content is grouped in the back end. If I want to just edit the headline of a ‘news package’ I should be able to do that without having to see the form for the entire package. (Eg. fixing a typo in the headline, adjusting line length etc.)
  2. Show as few controls as possible and try to show them only when required. Particularly on the ‘index’ type pages I’m working on at the moment there will be lots of ‘bits’ that will be editable. Showing all of them will result in a hideously scrappy looking page. I’m rather tempted to use the BaseCamp approach and show the appropriate controls on hover, however I’m also concerned that we design an accessible experience, so we’ll need to think more about what we need to do to achieve this principle without sacrificing the experience for people with visual/mobility impairment.
  3. Where possible, choose a text link and not a button. See (2) above – text links are a much less intrusive element on the page and will help us to maintain a clean, simple interface. Obviously, there are some times where buttons are necessary, we won’t get silly with this.
  4. Provide Editorial Tools not Design Tools. The purpose of this interface is to allow editorial staff (writers and editors) to do their jobs well – their job is to craft, curate and communicate content to readers. These people are not designers and should not be asked to make design decisions. The flexibility they require is about selecting, grouping and prioritising content. The design work should be done within the page template and within that framework we provide appropriate editorial tools.

More to follow I’m sure, I’m just getting started. Feedback welcome!

8 thoughts on “Economist/Drupal – Design Principles for CRUD-In-Place

  1. Principle one is so important. I’ve lost count of the number of times I’ve seen an interface developed according to the underlying system, not to the goals of the user, to the detriment of the experience of everyone concerned.

    Certain nameless 3rd party CRM systems, I’m looking at you here.

  2. Interesting set of screenshots. Two things come to mind:

    1. I like the yellow background indicating that something is editable (says, scribble here, like a yellow pad). Click in the yellow and edit.. nice. The yellow might be done a) on hover, or b) permanently for users with certain permissions, so it won’t mess up the display for others. As an alternative to the yellow background a textlink indeed looks best.

    2. Yes, a little button on every editable element on a busy page will not work very well. So, besides tuning the edit tools themselves for simplicity and context, you’re looking to minimise the message of “this is editable”. If you’re going to go for some solution “on hover” then I’d suggest testing that for usability with your target group. I’ve (informally) learned that quite a few people are rather sensitive and dismissive of “pop-out”, “drop-down” or “fly-out” menus. They’d rather click something for a menu (like the menu bar in most OS based applications) than have something pop-up on hover.

  3. On some screens actions only show up when you hover over an element. This might work for people who use a site regularly and/or are trained, but I’m not sure it will work for any site. On some sites I feel like an explorer and I don’t always want to be ;-). I want to know which actions I can perform, not being forced to find actions like easter eggs. Besides, I’m not sure about the effects on accessibility.

  4. I understand the rationale of choosing a text link over a button because of its visuals. However, what about accessibility?

    To fill out a form, I click on the first field in the form. Then I completely fill out the form using the keyboard, without touching my mouse. I tab from one field to the next. And I also tab to a button and press space to click it.

    As far as I know, you can’t do that with text links. So, I’m wondering how you approach that?

    1. As long as I can remember, you can tab through the links on a webpage, as long as the browser viewport is active.

      I just tried it out with my current Ff3.5 on this page: click anywhere in page, hit tab button repeatedly, watch statusbar to see selected link.

      This might however not work when Javascript hides the link… I haven’t checked.

      You can even search for specific links in a page with the backtick. More shortcuts here:

      1. That’s not what I meant.

        However, it seems that current browsers (Safari 4 and Firefox 3 at least), do allow tabbing to links and clicking them by pressing enter as if they were normal buttons. So, my question is void, at least for those browsers.

        Sorry :)

      2. Your’r only able to tab to links on OS X if you enable the setting in System Prefs:Keyboard & Mouse:Full keyboard access

Comments are closed.