Preston created a prototype for this while we were at DrupalCon. Let's get it uploaded here and then test it!
*Hopes it's in the top right*
100% agree. Preston is tweaking the prototype a bit - hopefully it should be ready by end of today (Sept 11). I will start with the usability test prep.
After several discussions within the team and previous usability findings, the design is undergoing change and is not ready for testing yet.
Corresponding meta issue: #1586416: [Meta] Make Save/Publish distinction clearer.
When will the prototype be ready and the usability findings be posted?
Apologies for the late response, Wim. The prototype is finally working... yay! I will be testing this on Monday/ Tuesday (19 and 20 Nov) and should have the results by Wednesday (Nov 21)
Great, thank you!
On November 19 (Monday), I conducted a usability study on the new iteration of edit-in-place for Spark that focused on:
The study was to be conducted with 5 content creators/maintainers. However, after 3 sessions, the issues were clear and the researcher is confident that more sessions would not yield any new insights.
Participants easily understood how to edit their content (title, body). The effectiveness rating for the task was the highest (5 out of 5). It is also worth noting that the task rating has gone up to 5 from 4.2 (previous design).
However, saving/ publishing content (rating of 2 out of 5) and revision history (rating of 2.1 out of 5) still needs work.Major issues:
1. Does “Revert” auto-publish my content?
Refer Skitch Image attached in the next comment.
Participants were thoroughly confused if revert was changing their published content in real time and hence gave poor ratings to the task (2 out of 5, 5 being best). This is because of the following reasons:
“I don’t know if it is published or is it just viewing [the revision]… I have no idea what is this telling me.” (P3)
“I want to see preview or show difference. Also, without show difference you can’t see the changes that you or someone made to the revision” (P2)
Requests to revision control:
2. Since this article is already published, is hitting “Save” auto-publishing my content?
Participants thought that saving fields is saving the page and since it is already a published page, it is also pushing the “saved” changes LIVE.
Reasons for this problem:
"I don't want this on my prod site" [P2]
3. Up/down arrow on revision control not useful [Minor Issue]
2 of the 3 participants did not immediately understand what’s the purpose of up/down arrow on the revision control. Once they did understand, they thought it was “useless” as it is easier to click on a particular revision from an exposed drop box than to go to one revision up or down.
This is definitely worrying, I have seen earlier iterations and it seems like this is a tough nut to crack. The overall trend seems to be that it is hard to communicate to users, that your "front end" isn't necessarily what your visitors see but could just be a new revision. That whole concept, seems hard to communicate - and rightfully so, we generally keep the front-end reserved for the end result unless you make an explicit step to "demo" something.
I guess the whole idea of "please don't forget to press save" what we have on blocks, now just turns into "please don't forget to press publish". Partly because its not really clear, what the version is you are looking at "Current" (as of now does not signal that) and that you need to "Publish" to get it to show to visitors, "Save as draft" will do something to help there but there conceptually will still be a disconnect - there is no large "you are not looking at the live thing". The fact that you uncovered even more issues with reverting, to me only sounds natural that is quite tricky functionality. Concrete 5 for example, has a really flow around this all where there is a clear "preview my edits" and "publish my edits", where preview allows you to continue, publish just does what you mean and there are additional links and forms for revisions, deleting etc.
We use "advanced edit" as a label for the full editing interface, I am not sure about it could scare people of from the only interface you can add it to a menu, add revisions info etc. "Quick edit" is an established label, for inline editing I would love if we could use that.
In general I am wondering if this might be trying to tackle something, that simply doesn't fit this paradigm. Although I am sure we can come up with something that, makes it a little more clear. I am not sure if this inline editing fits audiences where its important to care about publishing workflows - e.g. how does this scale when you have many revisions, authors reviewing, several states the content can be in, and diffing (you would replicate a whole screen in one tiny area). Its probably worthwhile to ask those in such settings, whether they'd deploy this beyond sexiness.
Wouldn't we be much better of, just supporting inline editing and pushing straight to published? And allowing contrib to come up with a model to support more advanced workflows. I guess this is not a popular question, but I am having difficulty following who we are designing this particular part for and it could greatly simplify it for the other usecase.
Bojhan: A small note: this prototype still uses old nomenclature ("Advanced Edit"), we've been using the new nomenclature ("Quick Edit") for some time now in the Edit module. I wish this change would have made it into the prototype as well. AFAIK nobody wants to rename "Quick Edit" to "Advanced Edit".
Tagging for workflow.
we are working on a more generic solution for all pages at http://drupal.org/node/752482#comment-7159496. Check it out and give us your comments.
We did this, it's in core. yay.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.