Problem/Motivation

So that the linearity of the workflow can be understood and the states can all be seen in one place, style it like a button bar.

Proposed resolution

The design looks like this:

Which is a direct screenshot of the preview from this codepen example of how it can work: http://codepen.io/tkoleary/pen/zZjKpe?editors=1100

It borrows styles from button classes, uses no javascript and is natively accessible since the markup is just checkboxes.

Remaining tasks

Make patch

User interface changes

Instead of a select box there is a bar of buttons for the states.

Comments

tkoleary created an issue. See original summary.

tkoleary’s picture

Title: Style transition select as a button bar » Style state select as a button bar
Issue summary: View changes
StatusFileSize
new35.76 KB
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
timmillwood’s picture

This shows a linear workflow process. What if the process is not linear?

tkoleary’s picture

@timmillwood "My only concern with that @tkoleary @yoroy is are all workflows linear?” No, but lining them up does not necessarily imply linearity (although an average user will benefit from a linear and easy to understand flow). The primary benefit is that they see them at once.

Example of non linear would be:

"Draft, Ready for legal review, Ready for editorial review, Published,”

where not all pieces of content require legal review. You can still line them up.

I practice I think it’s more likely in examples like above that users will just make another workflow for legal.

andrewmacpherson’s picture

Issue tags: +Accessibility

Feedback about the design:

In some configurations this could fail WCAG 2 SC 1.4.1 Use of Color.

  • Where there are three or more states, the selected state (radio) is inferred from appearing as the odd-one-out.
  • However in the case where only 2 states are offered, it's not possible to tell which radio is selected. The only difference is color, and the odd-one-out affordance doesn't apply. Browser-native radio style indicate the selected option with a different shape (dot in circle).

The "Add workflow" action creates such a workflow, with just two states (draft, published).
Could we have a "tick" icon in the selected state, next to the text label?

Feedback about the codepen:

  • Works fine with keyboard.
  • Works fine with ChromeVox. Should test with other screen readers, but I'm not expecting any surprises, the DOM looks OK. A minor issue is that the screen reader's visual cursor surrounds the area of the hidden input, not an area the size of the visible label.
  • <label for="edit-moderation-state-0-state"> points to a div, which doesn't work. When this is implemented in Drupal, I assume the state select is just a FormAPI '#type' => 'radios' with some custom styling? If so, there isn't an issue here, as FAPI radios are labelled with fieldset/legend.
  • The radio inputs are hidden behind the labels with opacity and z-index. We might be able to use our existing visually-hidden class.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

This feature request assumes a linear workflow with just a few workflow states. However, it's entirely possible to have a workflow that's a tree, or that has more states than are usable in a line (IIRC 5-7 items is the point at which it becomes hard for users to understand in a horizontal list of buttons).

E.g., it might be that an "Review for placement" state can transition to all three of (say) "Approved front page news", "Approved internal news", "Approved email digest news", etc. that create queues for editors to do other stuff with, and it could be that none of those states can transition back to "Review for placement" They might all be able to transition to and from "Review for placement", but what would be displayed when it is in "Review for placement"?

Basically, any flow is possible, so we can't assume it's a line. I also don't know if it makes sense to magically pick a line when the workflow is linear and switch back to the select box when it's not.

sam152’s picture

The current field is configurable on the form display, meaning we can contrib any widgets we like for it and use those if we please. Writing one, I found there were a few blockers if anyone is interested in looking at those:

#2914839: The current moderation state in the "meta" region on content entity forms is coupled to the moderation_state field widget.
#2915384: Alternative moderation_state field widgets do not receive the same access/visibility treatment as the default ModerationStateWidget.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Issue tags: +wcag141

Tagging

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.