[META] As a content editor, I want to make my edits quickly and then hit save

Moving to the Spark queue and re-tagging for this sprint.

And that drives me nuts. ;)

Nope, but feel free to file one. It's not a bad idea at all, just is a bit more complex than we'll be able to get to during this sprint.

Added #1730772: Research "draft revision" modules

Fleshing out issue summary more.

This turned out to be a little bit too ambitious for this sprint (silly DrupalCon :)), so untagging and also unassigning Wim for now. The good news is we made a lot of progress on this design review-wise!

Here's how the interaction is planned to work:

1) When you click on "Edit," the screen does its "white out" thing, as well as showing blue outlines of all "editables" for about 2 seconds so you can see what things are editable. Then those both fade away and you see your site exactly as your user would see it, to help cut down on visual clutter.

2) When you click into a field and make changes, the "Save" button in the toolbar becomes active. You can choose to click it to save interim progress. This will create a draft revision of the node, ahead of the published revision.

3) Changes to a field will *also* be saved when you click outside of the field if there are changes (and just as above, this will create a draft revision ahead of the published revision). Having both of these is important because on a desktop, this will be the most natural behaviour, while on a mobile device being able to actually "save" things is explicitly important since it's hard to click out of a field. Being able to "save" things explicitly is also important for long stretches of typing, even in a single field like Body.

4) When saving is occurring, a little "Saving... " spinner indicator will appear in the toolbar in place of the Save button, and when finished will revert to the Save button.

5) If you want to "undo" a change, you use the drop-down in the toolbar to select a previous draft revision to revert to.

6) Upon clicking the "Publish" button, the draft revisions will get "smooshed" down into just a single revision, so as not to clutter up the node_revisions table, the revision log, etc.

Now. This workflow also brings with it a fun interaction, which is that:

• If the content you're editing has no draft revisions, Edit mode should allow you to edit exactly what you see.
• BUT if the content you're editing *does* have draft revisions, Edit mode is a bit trickier. We think this is the right thing to do:
  • If the draft revisions are all yours, swap out the published version with the most recently updated draft revision in the user's session, and invoke edit mode on *that*. Show an indicator that this has happened, and allow people to go back to start with the published revision if they want.
  • If there are draft revisions by people who are NOT you, then you get a modal dialog saying "WOAH DOGGY" (exact wording tbd ;)) which warns you that newer revisions that exist, so you can either edit the post from there (if you have permissions) or just call frank or whoever on the phone and ask them what's up with them editing your node.

WHEW! Ladies and gentlemen, it looks like we have a spec! :)

And it's possible Collection module could fit in here in that we would "tag" all of the draft revisions we're creating with some kind of naming convention, and then use that tag in order to do the "smooshing."

That, however, would mean that we need the ability to tag revisions in core. I searched and wasn't able to find an existing issue about that, but I reached out to the Phase2 guys to see if they knew of one.

#12: Good question! I've updated the issue summary with the mock of the revisions drop-down.

#13: Maybe. That issue was more about the specific "Draft vs. Live" revision requirement, but the comments in that have ballooned to other outside concerns so it's probably worth a mention over there, too.

Ok, round two. :) Slotting in for this sprint, and Gábor will be taking the case.

Regarding #15, my concern there would be performance, especially on mobile devices, because each keystroke would involve a round-trip to the server. :\

Adding link to image showing revision list.

We are going to de-prioritize this for now this sprint, in favour of getting some plumbing work done on the Layouts stuff in Drupal 8. We'll probably be back in sprint 6. :)

We actually did end up doing this in the end, so yay.