Improve usability of Views bulk action form in Seven theme

Thanks kjay,
and thanks for presenting it at weekly UX meeting.

This looks like a good approach to visually separate these two sets of fields and buttons - and not only for the one core admin page for which the problem got noticed, but for any custom view with a bulk operation (with or without exposed filters).

The exposed filters can be any number of fields, followed by the Apply (or Filter) button underneath it. This will always look different depending on how many or which filters are displayed.
The bulk operation in contrast always consists out of the label, the dropdown list and the button.
So the proposed solution of displaying these three items in a box - and in one line on screens that are big enough - works fine.

The proposed enhanced version with the little arrow to point to the tick boxes themselves, could further improve usability of the bulk operations as such - but it removes the gap between bulk operations and the list/table of items underneath it and thereby has a number of possible knock-on effects. For example: where does the "Show all columns" link go on a smaller screen.he one core admin page on which it was noticed, but solves the problem in general for any other custom view with a bulk operation.

The two related issues to this are #2471010: Label for Content and User bulk operations does not fit the action and #2561115: Rollback: Use 'Filter' for exposed filter button text in new views and new installations (instead of 'Apply') that both deal with changing the wording of the buttons.

kjay: I set it to "Needs review" as you said you wanted to test further that the CSS does not introduce any errors anywhere.

I've just tested this with the latest 8.3.x dev, on 3 views:

• Content listing
• User listing
• Custom view with a path starting /admin/

It worked well in all three places. I also checked the other views provided by core (Custom block library, files etc.) but they didn't use VBOs.

As Ifrik said, I think the advanced version may have implications with hidden columns etc., so it might be best to stick to the simple version for now.

For the patch:

+/**
+ * Theme the Views bulk actions form to improve usability.
+ * As used on /admin/content
+ */

This should be in an @file block, and have a blank line before the start of the CSS:
https://www.drupal.org/node/1887862 under 'File comments'
As an example, look at core/themes/seven/css/panel.css

It also doesn't need the following comment, as it's used in several places by core + any additional views with VBO created by the user/other modules.
* As used on /admin/content

+/**
+ * @file
+ * Theme the Views bulk operations form to improve usability
+ */
+

Tiny nit pick: Needs a . after the word 'usability'.

https://www.drupal.org/node/1354#files

Will try and do some cross browser testing.

Adding tag to indicate we need cross-browser testing.

+++ b/core/themes/seven/css/components/views-bulk-operations.css
@@ -0,0 +1,33 @@
+  float: left;
+  margin-right: 10px;
...
+  float: left;
+  margin-right: 10px;
...
+  float: left;

Need an RTL counterpart to these, see how other CSS in core does RTL:

[dir="rtl"] .same-selector-as-earlier {
/* RTL override */
}

@kjay

This is a nice improvement. We should get it in to 8.3.

Is there a new patch?

I'm guessing the RTL additions need to be cross browser tested?

I've just tested the latest patch, it needs a little more work around the ~600 - 620px breakpoint range.

At 615px, the 'Apply to selected items' button jumps to the line below, but at 607px it jumps back inline.

At 600px > ~595px, the 'Action' label sits above the select list, and the apply button floats to the top right corner. This looks odd/out of alignment, it would be better if it sat inline with the select list.

I'm tagging this with "Novice" and "needs screenshots" for the mentoring sprint at DrupalCon Dublin.

I am assigning this to my-self, and looking at this issue.

I'll give it a shot!

Here's a bunch of screenshots.

Looks functional to me, but considering the filter button is on 100%, I'd probably put the "Apply to selected items" to 100% as well

Hi Marameodesign, I have been working on a simular issue - https://www.drupal.org/node/2521808 - and we may want to meet over solutions? Im in the general Sprint at Drupalcon Dublin - are you still here today?

Here's a patch where I just made the button 100% for mobile devices.

+++ b/core/themes/seven/css/components/views-bulk-operations.css
@@ -0,0 +1,56 @@
+#edit-header {

Could we use something else than id to theme this? I suggest that we use form_alter inside Seven theme to add a classes for these elements.

I think that's what tomatkins is doing in https://www.drupal.org/node/2521808

So the proposed solution you listed in #25 is similar to what @scaragucc' worked on yesterday.(We need to add him to the credit) We injected a class "form-wrapper--bulk-form to bulk_action_form_wrapper. " to the seven.theme file, and adjusted css on the form.css file. Should I post my patch to this issue or https://www.drupal.org/node/2521808?

I am currently stuck unable to make the patch file because:
The coding standards read git diff > [description]-[issue-number]-[comment-number].patch

Not sure which issue it should be posted (I am leaning toward 2785051, since that is most directly what we did), just want to get a confirmation.

second issue: when I run git diff - it shows the changes to the forms.css file but not the changes to the seven.theme file. Are .theme files are .gitignored?

On the brights side, the code is bullet proof - even on this third rebuild (I rebuilt it on separate sites because I got a little confused with documentation: but the code works perfect every time! :-)

So here is the work @scaragucc' and I completed yesterday. It adds border and background to the bulk action form on core/theme/seven/css/component/form.css and Implements hook_form_BASE_FORM_ID_alter() for \Drupal\BulkForm and Adds class form-wrapper--bulk-form to bulk_action_form_wrapper on core/theme/seven/seven.theme.

Please add @scaragucc' in credit and committing.

+/**
+ * Implements hook_form_BASE_FORM_ID_alter() for \Drupal\BulkForm.
+ *
+ * Adds class form-wrapper--bulk-form to bulk_action_form_wrapper.
+ */
+function seven_form_views_form_content_page_1_alter(&$form, FormStateInterface $form_state ) {
+  $form['header']['node_bulk_form']['#attributes']['class'][] = 'form-wrapper--bulk-form';
+}

Not able to test, but I believe from the form ID _views_form_content_page_1:
This will only apply the class to the content listing page. In core there is also a bulk operation form on the user listing page, and it's possible for users to add bulk forms to custom views. So this class addition needs to be more generic as to anywhere there is a bulk operations form.

I can take a look at this next week if no-one gets to it before me.

Cheers

I've had a chance to test the patch - as expected, this now only works on the content listing page due to the hook_form_BASE_FORM_ID_alter only applying to the content listing.

I've looked at doing a form alter, but there doesn't appear to be a bulk form ID, base form ID or similar that we can use to only target these forms wherever they are used.

I had the idea of checking if the form has a node_bulk_form element, but there could be user_bulk_form etc. as it's based on $entity_type_bulk_form.

Maybe we'll need to look at doing a views hook to detect a bulk form & add a class that way. Alternatively we could keep to the ID for now, as that won't change, and look at changing to a class in a followup issue?

1. +++ b/core/themes/seven/css/components/form.css
   @@ -222,6 +222,38 @@ textarea.form-textarea {
   +  background-color: #f7f7f7;
   

   This is not a color from the style guide. The closest is "Eggshell #2" which is #f5f5f2. It should be still sufficiently different from the table head background (#ebeae4) to avoid confusion.

2. +++ b/core/themes/seven/css/components/form.css
   @@ -222,6 +222,38 @@ textarea.form-textarea {
   +  border: 1px solid #e6e4df;
   

   Given that the element following will always be table head we should follow the pattern of no left and right border established there.

3. +++ b/core/themes/seven/css/components/form.css
   @@ -222,6 +222,38 @@ textarea.form-textarea {
   +  margin-bottom: 1em;
   

   The 'enhanced' design in the summary shows no margin bottom. We should go with that.

@tkoleary

The 'enhanced' design in the summary shows no margin bottom. We should go with that.

@tomatkins and I added the bottom margin because the enhanced version ignores the "Show All Columns" text to be above the table. We thought until that was discussed that we would implement the simpler version.

@smaz Is having an array with the likely form IDS and checking the current form ID against that array via in_array() a possibility?

@smaz Is having an array with the likely form IDS and checking the current form ID against that array via in_array() a possibility?

I don't think so - because the user can create custom views with bulk operations, we won't know what those IDs will be and the theming will break on anything the user creates. It also means that any new views in core that have bulk operations added will require an update to the hook - that feels like defeating the point of using a re-usable class, to have php that requires changing every time :)

I should have some more time to look at what hook we can use later today.

So I just tested using drupal data attributes with wildcard as selector and it is working. The wildcard asterisk denotes "data attribute contains this". For reference see this article.

div[data-drupal-selector*="bulk-form"] {
    background-color: #f5f5f2;
}

Assuming the Drupal data attribute for bulk operations always contains "bulk-form" which I believe it does, this gives us a pretty clean way to get at just what we need.

One other thing that occurred to me is that we should use the .button--small class for submits like this one that we wrap in a container.

Just checked Caniuse on the wildcard attribute selector and it's all green.

@tkoleary Nice! I'm only sad I didn't think to look at that. Can you create your own view with VBO and see if your selector catches it?

Can you create your own view with VBO and see if your selector catches it?

We don't actually have configurable views bulk operations in core yet, slipped my mind. But I have tried this out with instances of bulk form in /content and /people, where it works. Doesn't work with comment which is legacy. :/

I'm working on making this work more widely

This patch attaches the variation class we have used to theme this for all bulk operations

+++ b/core/modules/comment/src/Form/CommentAdminOverview.php
@@ -100,10 +100,7 @@ public function buildForm(array $form, FormStateInterface $form_state, $type = '
-      '#open' => TRUE,

Can we make '#open'=> FALSE? Then we could add a small bit of js to open it if items are selected. This would go a long way to simplifying this UI.

1. +++ b/core/themes/seven/css/components/form.css
   @@ -222,6 +222,38 @@ textarea.form-textarea {
   +  background-color: #f7f7f7;
   

   Per #33 this should be #f5f5f2

2. +++ b/core/themes/seven/css/components/form.css
   @@ -222,6 +222,38 @@ textarea.form-textarea {
   +  border: 1px solid #e6e4df;
   

   Per #33. This needs to be: border-top: 1px solid #e6e4df; border-bottom: 1px solid #e6e4df;

Updated the issue summary with screenshot and generally in terms of content. The content admin one does not seem to wrap as intended though:

Chrome 53 on Mac Sierra here.

@gabor @laurii

Looks like the fix for that is targeting the classes instead of just the inputs:

.form-wrapper--bulk-form .form-item,
.form-wrapper--bulk-form .form-actions {
    display: inline-block;
}

I would also suggest adding removing margin from items in this wrapper:

.form-wrapper--bulk-form .form-item,
  margin: 0;
  display: inline-block;
}

And using padding instead to reduce the height of the container to match the height of the table header:

.form-wrapper--bulk-form {
    padding: 6px 12px;
}

Which should look like this:

Accidentally duplicated

#43.1: Yes, if we convert the element to details element instead of container. It would be nice to keep this as simple as possible at this patch and maybe leave that for a follow-up.

I didn't implement #48.2 & #48.3 yet because I wasn't quite sure what was meant to be achieved by this and removing the margin between elements makes it more difficult to see what is happening on the mobile:

Before #48.2 & #48.3:

After #48.2 & #48.3:

@laurii

I didn't implement #48.2 & #48.3 yet because I wasn't quite sure what was meant to be achieved by this and removing the margin between elements makes it more difficult to see what is happening on the mobile:

I see. This makes sense. But wouldn't we only need margin bottom to maintain space between items that break? eg

.form-wrapper--bulk-form {
    padding: 6px 12px 0;
}
.form-wrapper--bulk-form .form-item,
  margin-bottom: 6px;
  display: inline-block;
}

Rather than add another special snowflake I tried to extend the reusable .container-inline and .panel classes already in core. This should actually make the .container-inline class more responsive and re-usable in Seven and subthemes of Seven.

(slightly off-topic)

As we already duplicate the Apply to Selected Items submit button at the top and bottom of the table, could we duplicate the Action dropdown as well (and use JS to keep them in sync?) i.e. adds convenience for users who are near the bottom of the list who don't want to scroll all the way up to the top again because they usually choose the action after selecting the nodes.

@wturrell

That's an interesting idea, but I think it would be a different patch since it is a significant increase in scope. Also, if we are going to put more effort in here the additional feature that would have the most positive impact would be to conditionally show the actions only when table rows are actually selected as you'd see commonly in applications like gmail.

I think that could be a very good followup once this lands or an independent patch.

Drive by review, only coding standards nitpicks

1. +++ b/core/themes/seven/css/components/container-inline.css
   @@ -0,0 +1,40 @@
   +    width: 100%;  ¶
   +  }
   +}
   

   Extra space, No newline at end of file

2. +++ b/core/themes/seven/css/components/form.css
   @@ -127,7 +127,6 @@ label[for] {
   -
   

   Not needed.

3. +++ b/core/themes/seven/css/components/form.css
   @@ -221,6 +220,16 @@ textarea.form-textarea {
   +/* ¶
   + * Styles the bulk operations form. ¶
   

   Extra spaces

4. +++ b/core/themes/seven/seven.theme
   @@ -186,3 +190,12 @@ function seven_form_node_form_alter(&$form, FormStateInterface $form_state) {
   +  $element['#attributes']['class'] = array('form-wrapper--bulk-form', 'panel', 'container-inline');
   

   Let's use short array syntax.

Fixed from #58 and :

git apply --index improve_usability_of-2785051-54.patch 
improve_usability_of-2785051-54.patch:98: trailing whitespace.
    width: 100%;  
improve_usability_of-2785051-54.patch:117: trailing whitespace.
/* 
improve_usability_of-2785051-54.patch:118: trailing whitespace.
 * Styles the bulk operations form. 
warning: 3 lines add whitespace errors.

A completely different approach that should work for all vbo actions.

@tarekdj: how does this work with grid views (eg. as combined with #2834729: [META] Roadmap to stabilize Media Library) or list views? It would be fabulous if this could be made to work for those cases :)

@Gábor Hojtsy : Humm, didn't handle it. Let me see what I can do.

What about this:
Table view : http://image.prntscr.com/image/36727f305d744dbbbd3f7a2289177c3a.png
List view : http://image.prntscr.com/image/7e7e2c940ca849ecbb0aa4edc41720e5.png
Grid view : http://image.prntscr.com/image/4d08bc47604e4ab78710e1179cbb75a6.png

@ tarekdj

Interesting, but it would also have to take in to account places where core injects an element between the bulk form and table header. eg. "show row weights". This could be handled by either moving those links or by making sure that the arrow nub always positioned with the bulk form tools.

Also, in the case of grid view, the down arrows could suggest (incorrectly) that all items in that column were selected. I's suggest having the down arrow in the table view but simply removing it in the grid view.

@tkoleary In #63 the arrows are simply hidden on medium screens. See the table case

@tarekdj

Oh, I see. That works.

@tarekdj

I'm not seeing the arrow tab in chrome.

Also I'm noticing regressions from previous versions but it's hard to see what's been changed because there's no interdiff.

When you are working on a patch please start with the last submitted patch, make your changes, and then provide an interdiff (git diff previous-patch > interdiff-previous-patch-new-patch.txt) so we can see what was changed.

I don't see any arrows either.

Comparing patches 54 and 63, two obvious regressions in #edit-header:
- lack of margin-bottom: 10px; for .panel.form-wrapper--bulk-form means both shaded areas crash into each other
- the background colour in 54 was lighter (#f8f8f8)

Re: @tkoleary's earlier reply to me (#56) about hiding the actions until something has actually be selected - I think that's a good idea, but it's important there's a fixed height placeholder present even when there's no dropdown or buttons (perhaps with some help text). That way the rest of the page won't shift down when someone selects the first item. This isn't an issue for Gmail because they have other things in that top bar at all times. (Aside: interesting how Gmail don't offer any sorting by columns at all, even in advanced search, yet no-one seems to complain about it.)

Although it's great how this issue is moving forward, I'm afraid the design used here is not considering how it plays with the design for filters in this other issue: #2521808: Visually encapsulate the content listing filter to distinguish it from the 'add content' action link. So I'd like to pospone it until both filters and Views bulk action form play well together in one design. There's actually an issue for that: #2721807: Design for filters and bulk operations. We could talk about this on next Usability meeting.

When is the next Usability meeting so I can participate/follow up with progress and see if the the current fix can be implemented?

Thanks @tomatkins, I'll let google do the timezone thing, here's the calendar for ux meetings: https://calendar.google.com/calendar/embed?src=jhj7p0u7link8vvjdqqsqr5qt...

Since the design has already been integrated with filters in #2721807: Design for filters and bulk operations, I think this issue can continue.

#59 failed to apply. Re rolled #59.

Not entirely sure why this was in the theme system, moving to the seven theme.

Re-rolled.

There is a bug with this last patch (2785051-77), to reproduce the bug :

• On a view with filters and bulk actions,
• Ajax enabled for this view,
• Make a search (filtr) on clicking on "filter",
• Then Test any actions from the list of bulk actions,
• Bug: The response: no page relaod, and only a HTML response (Ajax response in small text area containing the HTML response!

The order is important, so begin by testing the filters then test actions. in other way it works fine.

Kind regards,
Djamel

Applied the patch #77. Solution worked. Could not reproduce #78

Working on it

Verified and tested by applying the patch #77 on Drupal 9.1.x and 8.9.It was applied successfully and working fine as expected with Drupal 8.9 but in Drupal 9.1 , the patch was applied successfully but wasn't working as expected getting "Website encountered error".

Steps to test -
1. Go to the admin site.
2. Go to the admin/appearance.
3. Select Seven theme.
4. Go to /admin/content.
5. Verify the UI for Mobile and Desktop.

Before_D8.9_Mobile -

Before_D9.1_Desktop -

After_D8.9_Mobile -

After_D8.9_Desktop -

Before_D9.1_Mobile -

Before_D9.1_Desktop -

After_Patch_9.1 -

The Seven theme has been removed from Drupal 10 core. I confirmed that this issue only affects Seven and no other themes included with Drupal core, so I am moving this to the contributed Seven project.

Hi @kjay,

Moving this now to RTBC because when I am using Seven 1.0.0-alpha1 as a default theme to Drupal core 9.5.6 version, this how it looks now and Bulk action functionalities works well.

Please see the attached screenshots for reference.

Thanks.

Hi @kjay,

My apologies, I will transition the issue back to "Needs work" since the Patches are currently not working.

Thanks.