[Meta] Simplify and reconcile the behaviors of edit-submit actions in node/edit and edit (edit-in-place)

Attaching revised images here so I can reference them in the summary.

revised attached images

Updated images

Revised again

revised images

@bojhan:

Shouldn't we be discussing this at http://drupal.org/node/1678002 ?

Angie felt that this belonged in a separate meta issue since it covers in-place editing, node/edit and workflow.

This is quite overwhelming, there are a lot of button states, animations, close/undo etc.

I think that this stems from the fact that this flow shows everything at once. Each individual button/animation makes sense in the context that the user is in at that point and the user never sees more than three buttons and one status indicator at one time. Having said that there are probably a few things here that can be simplified further.

I understand the ideas for node/edit for both Publish and, publish states. I am not sure though why we would want to deviate from the drop button idea, I always thought that was a nice solution to the problem of many states but still clicking save. I would love to know why you would not want to do that.

Well perhaps some of the things that are not in dropbuttons could be, however I think that it would be essential to be able to dynamically sort the order of the options in the dropbutton so that the primary option shifts based on context. For instance in 3a where if the load draft option is not visible the user may create a new draft that conflicts with an existing draft just beacause they did not realize another draft existed.

Tempstore introduces a number of complexities, perhaps we can battle that by assuming the user always wants to see his own temp version, and not offer methods to switch to other revisions (if they want

I think there is some confusion about how this works. Tempstore is completely invisible to the user. All it does is ensure that if the user is working on something (whether it is a Draft (forward revision) or a published node and something happens, (crash, loss of connection etc,), when the user returns to the page, tempstore will remember a) which version the user was editing, and b) any edits that were made to that version but not saved to the database.

The user has only two options for editing: 1) edit live and 2) edit draft. Per discussions internally editing multiple drafts was considered unnecessary complexity. Any former drafts become revisions which that user can revert to from the revision queue if need be.

Save actions in place - 5) Strange when you edit a field, it still shows as "live" - while the last revision might be live, the thing I am looking at is not live. Its not really clear to me why you would need the "undo" button. Its not something we really have elsewhere, e.g. per field undo on node/edit.

The live/draft indicator shows the status of the content you are editing. Just as in the node/edit form where when you are editing a published node and you make changes in several fields your "published" checkbox does not automatically change to "not published". So it's the "status" of the content—draft vs live—that is being indicated, not the state of the content—saved vs. not-yet-saved. This may be confusing to users but we should not assume that absent testing.

One way that we did this before is having one button for all saving (save & publish, save as draft, save for review, save as unreviewed etc)

The proliferation of these "save as [something]" options is why I suggest abstracting the workflow states into flags in the last design. I'm ok with having just the essential ones (save, save as draft, publish)

I dont fully understand the whole "permanent" moving with you entity toolbar, it feels very much like its attached to each field.

I think the actual behavior of this will make it clear. It will be very similar to Aloha's floating toolbar, so:

1. I click/tap the pencil on the title field. The outline and the title tab appear then the the entity toolbar appears.
2. I finish editing the title field and I click/tap the pencil icon on the body field. The outline and tab for the field appear then the entity toolbar moves from the top of the title field to the top of the body field.

This gives the user the clear impression that "these fields are different things but they share the same toolbar, therefore they belong to a bigger thing". The next question of "what happens when i have multiple entities on a page" should be avoided (as it is now) by giving the user the option to navigate to the page where that node lives in order to edit it in place.

move the save and "status" indicator further from each other.

Why? The status indicator positioned next to the buttons clarifies the context of the action ie. "the status is "draft" clicking "save" will update my draft", or "the status is live, clicking save will update my live content."

@Gabor

(that would need *even more* UI affordances to indicate which pieces of the entity changed, and if anything changed at all to prompt the editor to reload, etc). It quickly becomes scary :)

I agree that the interaction needs to be more explicit with regard to what is getting saved and what the user can cancel/undo/reload etc. I will spend some time revising that.

Here are revisions of the designs incorporating feedback from the UX meeting as well as input from the Spark team. I am prototyping this right now for Dharmesh to test.

Revised images

Browsing related issues I just realized that none of the designs above have preview as an option in the dropbutton. That's an oversight. I will add it to the prototype. Also I have not mocked up how this would all look in the revision queue. I will add that as well.

And just a note on the "x" as draft icon. I did an exhaustive search on this type of icon across other systems and decided to change it to the x in red octagon because it is much more universally known as draft/offline/not live/not published. I am aware that there is a visual conflict with the close "x" but the red and the octagon differentiate IMO.

@bojhan

but isnt the icon you are using for draft, the one we use for errors? Will that cause confusion?

Yes it will. The error icon needs to be changed. :)

The more universal icon for error is "!" in a triangle.

@John Pitcairn

My understanding is that error is an "X" in a red stop-sign (octagon), and the "!" in a yellow triangle is a warning or notice.

You are correct. That is the current Drupal iconography. I am proposing a change here to bring it more into conformity with common usage (thus more usable).

IMHO the conflict between the x icons is resolved by size (close icon is smaller), context (position on the page), color (red vs gray), Labeling (it is accompained by the label "draft"), and shape (octagon vs. circle). But if there's still doubt, Dharmesh will be testing this very soon so if user confusion arises we will know.

@sun

After posting the designs above *and* after talking to Angie about this I have changed the icon again and prototyped the design for Dharmesh to test. It is here: http://invis.io/7QBVSUBG Keep in mind that this is a prototype of static images so there is no hover, clicking in a field automatically updated text "as if" you had typed something, not all buttons are clickable, and the throbber must be clicked on to advance to the completed state (no animated gifs).

On the the x icon for draft I *sort of* see your point in the concern about possible confusion with the error state in DSMs and with the idea that it indicates "something is wrong". I have had some misgivings about that icon and have now changed it several times*.

In the end I did some extensive research on commonalities across other platforms (should not be the sole determinant but worthy of heavy weight because ubiquity establishes user expectations) I found that for "not live", "Not published", "Draft", "offline" the most common icon is the x and the most common color is red.

On the warning nature of red, I think in this context red has another meaning, which is "stopped", underscored by the fact that the inverse is green, "go". So the users understanding is "The green check is live. That means the content is actively being pushed to the public" or "The red x is draft, I have stopped what I am working on from being pushed to the public".

Another thing to consider is the important difference in personas here. The user that will most often come in contact with the x error message is the site owner or site developer whereas the primary user of the the content creation form (both in place and in admin) is the content author. It is arguable that a content author in a well constructed Drupal site should *never* see an error DSM, and in the reverse direction it is unlikeley that the icon will cause confusion for the site owner.

*it began as a page icon, changed to a pencil then an exclamation point, then the check but crossed out and finally the x.

@sun

Also you will notice that I changed the icons to make them less "buttony" per comments from Angie and Bojhan.

@ John Pitcairn

The icons are not decorative or redundant, they are indispensable as a tool for maintaining a constant level of feedback on the the current status of the entity as distinct from actions the user can perform on the entity.

@Bojhan

but isnt the icon you are using for draft, the one we use for errors? Will that cause confusion?

I think the change in the prototyped design addresses this. However after researching common iconography of error/wrning/status, I'm inclined to propose a change to error for core as well. The most common icon for error is

@Sun

Not invented here

See: https://www.youtube.com/watch?feature=player_embedded&v=OqQQBSJj5yc#t=3s On the "not invented here" cognitive bias.

Yes, we can close this one