5.0 Edit On Page

Screenshots updated 4 June 09

Shows the ‘Meta’ header. Large image here.

Shows the Hover State. Large image here

Edit In Place
Shows Edit In Place. Large image here.

Description: Refers to the ability for users to be able to edit/manipulate content from the website page, potentially using a combination of ‘in line’ editing where appropriate, and triggers to launch editor tools in overlays.

Current thinking/roadmap:

  • On clicking the ‘Edit’ button in the header, regions of the page would be defined as clickable (eg. nodes, blocks, navigation). Depending on which was selected, the appropriate editor tool would be shown
  • Nodes would be able to be edited inline (special handling for images?), blocks, views, navigation would launch an overlay with form based editor tools
  • Clicking ‘Edit’, ‘Save’ or a click in clear space would switch out of edit mode (auto save)

Aggregated Feed (Pipe) of Related Discussions

Status: Handed on to Acquia for development

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_5_0

go back to Project Framework to view all project components

45 thoughts on “5.0 Edit On Page”

  1. Instead of Edit button then clickable regions, how about along the line of ‘block editing’ like in zen, and admin_hover module for node, where the editor tool appear on hover for user with permission? IMO it is less steps and more intuitive.

    Inline editor is nice.

  2. Like CK Ng mentioned, I really like the “hover” of zen’s block editing. It gives a truer idea of what the page looks like in construction than it would with the extra icons all over the page. Second, it seems less cluttered, but easy to get at.

    It does have the problem of “how do you know you should hover?” and I’d say a simple pop up each time you click the “edit” button that explains the hover very briefly and has a check box to make it never show up again would be sufficient.

    Truthfully, the edit button could be completely removed if the hover capability is built-in. Then clicking the “Edit” button would just explain the process of editing and not actually change anything. Less steps means easier to learn right?

    The Views module also uses this with their Views_UI doesn’t it?

    Of course, both the examples I’m thinking of are text, not icons, but I don’t see why that should be a problem.

    1. HUGE -1 on hover links

      They block content, are buggy, and I generally turn them off.

      Edit buttons, however, don’t break designs as much as you might think AND they don’t cover up content.

      1. I’ve been working with both show-on-hover and always-on edit buttons on the last site and current site I’m working on.

        Edit buttons that don’t cover up content will “break” design. That’s a fact of life. Edit buttons that show on hover will block content. Another fact of life.

        Always-on is -1 on aesthetics, and it makes the nose wrinkle on our designers and creative director. Messes with the vertical spacing. True, it TYPICALLY doesn’t really _break_ the layout, but it does warp it.

        Hover is -1 on utility because it can cover up something that you need to use. For example, I have a block the sole purpose of which is to display a shopping cart link, as an icon. When the admin user is logged-in, it’s impossible for them to click on this link because the on-hover “Edit” link is bigger than the whole block.

        Note, though, that this block would totally break if there were an always-on button associated with it. I would lose the option of doing layouts using that kind of micro-block.

        My point: They’ve both got downsides, and from my perspective it’s not clear which is better. Ultimately I guess I agree with you that the always-on buttons are slightly better, but then I’m a functionalist. I have to live with these visual people (and I’m considerably lower on the totem pole than they are — that’s just how MarComm works).

        So I think the option to toggle is great.

  3. As I said in a previous comment, I really really would like for this to happen.

    That being said, I worry about the client’s perspective in inline editing, giving that some things will be editable, some thing won’t some things will but in a different fashion, etc. For example, a view probably can’t be edited by a client, but a client will NOT be able to understand why because a page is a page to most people.

    This is different from the current situation because clients understand that only things on the “Content List” can be edited, but if you’re editing in place, that distinction goes away. Point being: it’s VERY important that editable features are distinguishable form non-editable features.

    1. Most users I train don’t know anything about the Content list unless you train them to use it.

      The default mode for most people to find stuff for editing is to browse to the page and edit it by clicking on the “Edit” tab. (Which I always format as a button for a bunch of pragmatic reasons I won’t go into.) This lets them edit a page by just browsing to it. Very natural, very easy. People who’ve used other CMSs often go “oooh” or “aaah” right then — it’s like being in an Apple dog & pony.

      So they do get puzzled, right away, when they can’t edit a View the way they can edit a node.

      The more important question is: Why wouldn’t they be able to edit-in-place the Header text on a View Display? Especially if the edit-in-place implementation uses “overlays” or “lightboxes”, that strikes me as an eminently do-able proposition, and one I’d really like to see. As it is, pages generated by Views are a black box to my clients right now (especially given the very imposing [to say the least] UI on Views 2).

  4. Not wanting to sound like a broken record but how do you imagine inline editing of a node (or a block …)? Let’s say you have [node:123] and a filter which turns this into a link to node 123 and the link text is now the title of node 123. So you click edit on the node text and then if you see [node:123] that’s not WYSIWYG. On clicking [node:123] do you get the node 123 edit form in a popup?? That will quickly turn into madness…

    Once again, to repeat myself from http://www.d7ux.org/d7ux-initial-concepts-direction/#comment-456 there is no simple 1-to-1 relation between a piece of a text in a database and on screen.

    1. hey chx, sorry for making you repeat yourself, hopefully this is the last time. It’s not that we’re ignoring your point, we’ve just not moved any further forward with thinking on this at the moment… partly because we seem to be getting differing advice on whether and how doable this is.

      Mark & I aren’t the right people to either say whether or not this is technically feasible and if so how… but we’d love to see a vigorous discussion around the idea and how it might work and we can move forward based on the outcome of that discussion. Inline editing is certainly not critical to our overall strategy but, if doable, it could be v nice! 🙂

      We’re v glad to have you representing the edge cases – as you say, they’re v important to consider and all too easily overlooked.

    2. I’m going to say that each field would have to be configurable to indicate whether it was editable inline or not, and that it would be specifically saying “I want to edit this node” and more “this field in this node says it is editable, I would like to edit it”.

      1. Ok, I think this inline comment edit dialog is crap 🙂 And it looks bad in Safari 3. But I digress.

        correction: … that it would not be saying “I want to edit this node” but rather “this field in this node says it is editable, I would like to edit it”.

      2. Why would you need to be able to configure each field that way?

        Of course some fields (e.g., ones that aren’t explicitly displayed) won’t be editable in place. Are you talking about preventing additional fields from being edited? If so, what would be the use-case?

  5. @chx:

    How about a WYSIWYG system with it’s own API that includes support for adding custom filters which are executed in the same fashion as Drupal’s current filtering system. Doable?

      1. Think he just means it’s important to be able to undo the last 10 or 20 or however many changes, instead of just one. This is important with autosaving because otherwise, if I edited something, and then decided I didn’t like it, I’d have to manually take it back to the way it was since my changes have already been saved (unless I had multiple undoes in which case it would be easy).

        Of course, Drupal handles revisions (which is an area I’d like to see better integrated in D7), but it just isn’t the same.

    1. Draft module illustrates one way to approach that:


      They use the revision system to save drafts, but keep track of when the last real save operation happened. When you commit a real save, it wipes out all the autosaved revisions (i.e., everything since your last real commit).

  6. I’m voting a big -1 for inline editing.

    * Add + Edit should have the same interface, consistency is very important!

    * As a UI for blog post this might be good, but Drupal posts are made up of various fields (text fields, text areas, selects, radio buttons, fieldsets containing various other field combinations,…) – I can’t see how this UI can work once you start thinking about those. Having it as ‘when appropriate’ will introduce a lot of inconsistency and frustration for not much gain.

    * I love the idea of a modal Lightbox style Add and Edit interface because by de-cluttering the page you allow people to concentrate on content, which I think is the primary goal for this part of the UI.

    1. Consistency is over-rated. A slavish pursuit of consistency, in my experience, often leads to convoluted and arcane procedures.

      In any case, configuring after the fact (sometimes a.k.a. “editing”, thanks joshmiller) is usually a qualitatively different experience from creating. Trivial example: You don’t fix a car by putting it on an assembly line and un-building it piece by piece. Nobody who actually uses, mods or fixes cars expects it to work that way.

  7. I think there are a lot of different ideas being mashed together here, not all of which make sense and certainly not all of which belong in Drupal core… However, if we put aside inline editing, etc, for a moment and focus on the most basic aspect of what’s being proposed here (which would need to be implemented before any of the others anyway), then I absolutely LOVE this.

    The basic idea is simply that when you go to a page in Drupal, any object on that page (regardless of whether it’s a view, block, node, etc) should be able to have an “edit me” link on it. That’s a really simple, great idea that would be an amazing step forward for Drupal — right now, for example, if you have a Drupal site and look at a page and see the “Recent Comments” block and think “gee, I want to edit this”, good luck figuring out where to go to do that 🙂 This design would solve that problem and a million others like it. It would be a great addition to Drupal core, and I think it’s achievable.

    Now… whether the ‘edit me’ component of each object is “themed” like a regular link or a modal dialog or inline editing or whatever is a totally separate issue. As mentioned by others above, there are plenty of situations where that could cause all sorts of nasty problems. Some of these ideas would make a lot more sense to implement in contrib modules anyway (which have more freedom to work around/ignore the edge cases than core does). But core should keep them in mind, of course, and try to facilitate them as much as possible…

    Thinking about that last point and also looking at Nathan’s screenshot got me thinking about the following: Since we now have the Field API in core, how about also providing an “edit this field” functionality? If you could edit one field at a time rather than always having to edit the entire node, some (but not all) of the problems would be easier to solve.

  8. I agree generally with David and others that providing links on every object (similar to what Views2 does) to edit or admin every object to a page would a great step forward.

    However, I disagree about trying to have some general notion of editing a field based on viewing an object – see chx’s comment above. The content of one or more fields may be all over the page or transformed or combined arbitrarily. If they are rendered as part of the node body how do you track what came from where? Sounds like a rathole to even try.

    1. To clarify, I wasn’t thinking that “edit this field” would help much with inline editing, but more with the problem where the edit form looks nothing like the content being displayed and is too long to fit in a modal dialog window.

      There would still be issues in some cases such as the Title field in Nathan’s screenshot, where you would just see “!title” when you go to edit it which is not that immediately helpful, but I think that kind of situation could be dealt with by having appropriate links in the help text.

      Fields that aren’t being rendered or that are being rendered in some crazy nonstandard way would simply not get an “edit this field” link at all. I can’t say I’ve thought too deeply about this, but I do know that CCK currently puts CSS classes on each field as it’s being rendered, so an “edit this field” link is probably something that would be available to render at the same time and in a similar way.

  9. How will things be backward compatible to millions of those who has been using and “learnt” the ways ? Will there be an super admin option to have the “classic” look just as Win XP or vista provides to have a Win98 look and feel ?

  10. Kristjan Jansen, an interaction designer and information architect, has posted some sketches recently on how he thinks we could drag and drop content around on pages, not just edit it place. I know, this is awesome stuff. He also says in the video he has ideas on how to deal with what some up above have mentioned as flaws of this method: RSS, Images, Longer Forms, etc…



    1. Have a look at Invision Blog.
      They have done ot long time ago.
      Not just diagrams but you can have a nice demo. And since Invision is open source there is possibility of some inspired code-lifting.Create an account and do some dragging, dropping, adding. Things are miles ahead of WP and anything better than this appears a;most impossible.

  11. +1 on the comment by Leisa about “special handling for images.”

    In general, Drupal’s default content creation interface is weak (compared to alternative CMS’) when it comes to non-text media within a page. At the moment, Drupal treats images, video, …, as an add-on – an attachment – rather than as an element of content that it needs to manage overall in the system.

    As a wake-up in this area, go watch the getting started videos for Plone (http://www.archive.org/download/EditingwithPlone/editingwithplone.mov ). I note that the Plone movie is really demonstrating the use of their preferred WYSIWYG editor (Kupu), and that some of that simplicity is due more to the editor than the CMS. But it illustrates that images, video, and audio are “normal” content now – not just attachments to a page. It also illustrates that it should be this easy “out of the box” to add media when creating content in Drupal – and it’s not today.

    Joomla has a different interface / approach, where images are listed in the content with a special tag, and images are listed (on the content creation page) in the order they should be included – along with metadata like size, borders/margins/…, etc. I do note that their approach can be used independent of which WYSIWYG editor is in use, providing an indication that Media handling doesn’t necessarily need to be tied to editor choice.

    Whatever the actual method, the content creation for Drupal MUST (imho) consider non-text content as something _every_ page will have, and Drupal needs to make it make sense to the content creator how they’d add the non-text content.

    Integral to this process, imho, is a basic “media management” interface. This, too, is built into Joomla – a way for users to upload images into a hierarchy of folders, and then select which of these they desire to incorporate when writing a page. I note that the Joomla UI isn’t perfect in this respect; it’s more useful as a way to suggest the need for this type of thing to be part of core (as in Drupal core) in some way.

    1. Actually from my perspective one of the problems with Drupal is the tendency of the community to assume that media needs to be “managed” somehow.

      I was overjoyed with I figured out that I could configure IMCE and FCKEditor to let my users upload images and PDFs as-needed without turning them into some kind of high-concept CMS object that they need to learn a new management interface to deal with. (A.k.a. a NODE.) They just upload them, and they’re done. If they want to use them in the future, they just use the IMCE dialog to browse what’s already been uploaded — and they’re done.

      I gather this is even simpler in TinyMCE.

      Unless a “media manager” interface can be that simple — roughly as simple as Finder or Windows Explorer — it adds no value over IMCE, IMO.

  12. Ahh OK now I understand why there’s an “Edit” button on the lower header. Should have read this first!

    Edit-on-page seems to be 2 things:

    1. Easily being able to access editing mode for any item on a page.
    2. Editing content whilst seeing it in context with the other content on the page.

    Number 1 is the important part from a UX point of view whilst number 2 seems to add little value to the editing process and throws up a whole host of logistical problems for anything but the simplest content (and Drupal is often much more than simple content).

    I do use the “Edit on hover” links in the Zen theme but they can be awkward, so I like the single “Edit” button on the lower header approach.

    I like the additional header with the “Save” and “Cancel” buttons at the top. Bit worried about the space taken up though – is it still necessary to see the “Add” “Edit” etc buttons in the lower header at this point? Seems like once you’re concentrating on a single task when editing a piece of content, so maybe worth considering putting these items in the lower header area rather than adding another header.

    1. #2 would be perceived as adding a great deal to the editing process to my creative director. She complains bitterly about how poor Drupal’s preview mechanisms are.

  13. my first thought on this is why not give the edit button some kind of hover where you can point with your mouse and the element you are on will be highlighted on the page. so you could edit the video in a modal window for example. also you could list all blocks for editing.

  14. If the content is in a block view, does the “edit me” link go to the view or the node?
    In most of my websites a lot of the content comes from views.

    1. Yes, that’s correct. If the content is a block, view, or any other ‘type’ of content that isn’t directy editable on-page, then when you click ‘edit’ the system will fire up an overlay to edit that specific bit of content.

      1. There is the need for a selection of the content piece you want to edit, isn’t it?

        So if you have a block you can

        a) edit the block settings
        b) edit the content source of the block (node, view, module settings)

        perhaps this could be done in a tabbed modal window where you select at the time of editing or you select before the editing.

  15. I think folks are over-thinking this.

    What I see here is an interface for editing VISIBLE CONTENT.

    This interface does not PRECLUDE any interface for editing NON-VISIBLE CONTENT.

    (Mind, we haven’t seen that interface yet; this would be a good time for Mark or Leisa to tell us how that fits into this scheme [or where else it fits, as the case may be].)

    Audience is a problem in this forum: The vast majority of the time either Verity or Jeremy are going to be editing VISIBLE CONTENT. That’s what happens on stable websites — i.e., sites that are out of teh development and launch phases.

    We may have a hard time understanding that because many of us:

    a) aren’t involved past launch phase;

    b) are involved, but only to develop or implement new features;

    c) are continually in a development mode on our sites.

Comments are closed.