[meta] Redesign workflow configuration page to better visually describe the flow

Link to prior contrib issue...

The non-linear nature of states is the main reason this is difficult to visualize generically. Some degenerate cases are, but not the interesting cases.

Are you suggesting giving site admins the responsibility to build a manual data visualization? That seems... unlikely to be successful. :-)

OK, that's less scary. :-) Still, that could very very easily result in complex, visually counter-productive images that don't (can't) take into account things like highly variable screen sizes. (I've been playing with Graphviz for a while now, which would be useful for such cases, but I'm still not sure I trust its auto-layout capabilities in this context.)

#9 actually looks pretty good. It looks like it should scale fairly well. The list of transitions may need to wrap, but otherwise it should work out.

Shouldn't the To state control be a select box? As is, it doesn't look like there's a way to change the to-state after the transition has been created. And of course there still needs to be a way to rename the transition, but that seems doable.

@tkolearly Looks really good. I dont fully understand the top one, is this like a "view" or can you edit this?

@tkoleary Ah, thats a bit confusing. I thought these were just buttons, I would make them look more like navigational items.

This looks quite exciting, I am not too thrilled about the vertical tabs (sadly its almost all we have) but the concept persuaded should work well!

The design looks great, nice one @tkoleary. Couple of questions/comments/suggestions:

• I'm guessing the fact "To state" is "Published" but the label is "Create New Draft" is just an oversight in the mockup?
• What does "Cancel" do? Could we instead just use the "Save" button at the bottom of the whole form for persisting the changes made? I feel it would be a bit less cluttered if those extra buttons were gone.
• Do we need a "Transitions" fieldset at the bottom? I think the fields pictured is all you can really do with a transition right now.
• I'm on the fence if the green background is clear enough about what is actually going on in the background. Generally speaking forward/published/default revisions are quite a hard concept to explain, so this might be tricky. I think at a glance #18 is almost better for understanding at a glance which statuses are enabled or not. The blue gets lst a bit for me in #19.
• Just a heads up, we also now have a 3rd fieldset in HEAD for which types of content the workflow applies to.

I was working on this approach and tried putting it in the context of where Workflow module is. A few notes to consider:

• Since you can to select one of multiple options on the “To state” side I've added checkboxes so that it would be more obvious for users to know what to do, where to click
• Changed the "To state" to dropdown, as you can select one from multiple options when creating a transition
• I would not add more colors (green) for communicating which state is published, instead of that, the states table should have columns that communicate which is published and which is set as default.

Some visual accessibility notes.

The screenshot in #19 fares poorly under WCAG SC 1.4.1 Use of Color:

• Some users with colour blindness will have difficulty telling the green and blue button states apart.
• Users who use a different colour space (in particular, Windows' high contrast mode) may not have the colour differences displayed at all.
• Even with full-colour perception, it's not clear what green vs blue is meant to convey.

Additionally, it's not clear that these buttons have checkbox behaviour.

#22 fares better. It doesn't rely on colour to convey selection state, because the checkboxes are visible. (They don't have to look like checkboxes, so long as there's a shape change which conveys the checked state.)

#19 has an arrowhead which helps, even though "from:" and "to:" appear as column labels.

The colour of the connecting lines is a bit pale - let's give it a stronger contrast like we do for text. These lines convey meaningful relationships, so they aren't just decorative. Strictly speaking the contrast guidelines in WCAG 2.0 only apply to text, but the forthcoming WCAG 2.1 introduces SC 1.4.11 Graphics Contrast and SC 1.4.12 User Interface Component Contrast (Minimum).

Thanks!

This looks really exciting, from andrews comments we should fix the connecting lines.

If you want to make it less "hard" you can try to go with borders on the states that are more gray.

#22 looks amazing! Very exciting!

#22 exactly looks promising. however if we can put some description on what is "Moderation state" and "Transitions" for would really help for new user understanding how to use the function well. Because I think some newbie might confusing on how this module works exactly.

Thanks for the feedback! I made some small adjustments:

- Added arrowheads and changed the color of lines
- Added "Moderation state" and "Transition" descriptions

Lets go ahead with this design, I don't see any significant UI problems. The button placement for adding and removing might need some work, but other than that we are good to go for initial patch work!

What about having those buttons in a separate bar on the top?

*Will need a bit of visual tweaking.

I think it makes sense to use this as a meta and split out different components into sub-issues. There are parts which I can see are going to be technically trickier than others, so I'd suggest slicing it as:

• Add published/default flag from moderation state into workflow states table.
• Create vertical tabs for all transition forms and bring these into the main workflow form.
• Replace the "Transition from" and "Transition to" form controls with a visual interface.
• Add a disabled select list showing the workflow type at the top of the workflow form.
• Allow the user to select entities for moderation without opening a modal (checkboxes on the workflow form).

I like splitting this up because I can see all of these being useful as stand-alone improvements. For example, even if the visual transition from/to element existed on it's own page, I think it'd be a worthwhile improvement. I've also found the mega-overhaul issues are so hard to follow, feedback gets lost.

The changes to the "select entity types" seem kind of loosely defined right now. Not sure what the machine name or descriptions are, but the last issue in the list can go into more detail.

If nobody has a problem with that approach, I'm happy to spin those off and get to work.

Also, unless the latest iteration has been discussed already, it would be awesome if this could be revisited in the UX meeting.

Just looking at this on the UX meeting. While demoing the prior experience compared to the suggested improvements, I noticed we can drag-drop order transitions currently, which is then used to list the transitions in the entity form in the priority set up. That is not anymore possible with the vertical tabs design, is it?

Following up on my comments from yesterday's UX meeting:

I think we are trying to squeeze way to much into one form - and then having to create one-off solutions to make it all fit.
There are at least two delete buttons, there will be one or two sections with drag-and-drop options, one set of vertical tabs, one set op drop-down actions... and all of that with one single save button.

The problems I see in detail:

It would be bad UX to place both buttons to create a new transition and deleting this specific one on the right, and both in grey as proposed in #33. On other pages, we very consistently use a blue (primary) button with a plus in it _above_ the section to add a new item, so we should use the same here.
"Delete" is usually a red link, placed underneath.
I don't even think that these two actions belong together because one refers to the whole transition section, while the other one belongs just to a single transition.

I like the very visual way of seeing which states are enabled in a transition, but using the same blue that we use for buttons is confusing - because this now looks like buttons. Also, as far as I know, just using colour for distinguishing between states, is bad accessibility, so the radio button in the "To" section should probably be visible there.

Also: I thought we got rid of such vertical tabs between Drupal 7 and 8? I'm not sure we should introduce them again. In other cases, where we have different version of the same 'thing', we use secondary tabs. See for example, the different view modes for a content type, or the different block layouts per theme.

Maybe it would be easier to use the UI pattern that we have for content types: one tab with the basic information (such as name, work flow type and entity types), one tab for moderation states, and one tab for transitions. Then we could use secondary tabs for the different transitions with the add and delete buttons placed more in the default way - and we would end up with a set of clearly defined tasks per page.

@ifrik: well the screens were recently merged to improve usability :) (been looking for the issue but cannot find now).

I've just realized that besides the tabs and secondary tabs (for example for display modes for a content type) we also already have an existing design that could be reused: the displays in views.

For sitebuilders it would be good to use one of the existing patterns rather then introducing an additional way of navigating between different options.

As Roy just pointed out on IRC: there's an issue to bring the Views UI inline with the default UI - so using that UI pattern here isn't really an option...
#2489654: Make displays appear like local tasks in the Views UI instead of custom UI design

Those tabs are for navigating though, they are not buttons, which is the use case here. The one element that does correspond with the situation here is the dropbutton on the right hand side :)

The (not yet a) pattern we're looking for here seems to be for "Add-button that applies to a section (not the whole) of the current screen".

In terms of taking steps that radically improve our UX, the navigation to me is a small issue. The representation is a major win, and we should get that in regardless of the other elements being "right".

Bojan,
the navigation might be a small issue to you, but to sitebuilders on complex sites, it is a real problem when navigation is time and again different per module.
For core modules we have the responsibility to set out a good standard, because contrib modules can take a lead from there, and if we introduce yet another navigation pattern - especially one that we already describe as "not right" - then we are just making matters worse down the line.

Also, I really think these three different sections don't belong on one page, but on three. Can somebody point me to the issue where they were put together on one page?

It was probably as part of #2779647: Add a workflow component, ui module, and implement it in content moderation it seems. That was reviewed in the UX meetings at least a couple times, @yoroy was involved for example :) BTW with #2830584: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait it is leaning towards an even more views like experience.

https://www.youtube.com/watch?v=xB-AbupfDxY This video explains why it is better to have it on one page rather than forcing users to go to multiple pages in the Drupal administration which he might not know where to find. 1 place for 1 task sounds better than 4 places for 1 task :)

We're now discussing details of an otherwise solid design that improves this particular interaction and we want to move forward on.

Lets update the issue summary to reflect that. There's a better design we can link in the issue summary and in #34 @Sam152 proposes a way to tackle the implementation. Is there anything that keeps us from doing that?

Wearing my product manager hat, +1 from me as well for the overall concept. It's a really sizable UX improvement over the status quo.

Linking #30 from the issue summary. We can swap that for #33 if it included the whole design. I think there have been some good criticisms of the designs so far, the reordering sticks out as the big one for me but those can be discussed and addressed in sub-issues. I don't think there have been any issues with components like Replace the "Transition from" and "Transition to" form controls with a visual interface.

One thing mentioned in the issue summary was user testing. How does that fit into the process from here now that we broadly agree the suggested changes are an improvement?

I have created the following:

#2910708: Add published/default flag from moderation state into workflow states table.
#2910709: Create vertical tabs for all transition forms and bring these into the main workflow form.
#2910710: Replace the "Transition from" and "Transition to" form controls with a visual interface.
#2910711: Add a disabled select list showing the workflow type at the top of the workflow form.
#2910712: Allow the user to select entities for moderation without opening a modal (checkboxes on the workflow form).

If anyone can see dependencies between these, that would be good to know but I think they all stand on their own in terms of usefulness. In terms of addressing the original point of the issue I think #2910710: Replace the "Transition from" and "Transition to" form controls with a visual interface. is the most important.

Cross posting #2830584: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait, which to my knowledge also looks decoupled from these improvements. But worth having on the radar here, as it'll impact how people use the workflow configuration page.

Regarding design placing the different transition on one page: According to the UI standards Vertical Tabs should used for settings that the users could ignore such as metadata or settings with good defaults.
https://www.drupal.org/docs/develop/user-interface-standards/vertical-tabs

Can you summarise that on #2910709: Create vertical tabs for all transition forms and bring these into the main workflow form.? Going to try funnel the conversations about the individual bits into more manageable issues.

Not tagging stale-issue-clean up but this came up.