This became especially apparent while reviewing the #308272: Improve test selection page patch: it's placing a checkbox in the table header, which is consistent with what other pages like admin/content/node are doing, but it looks like a bug.

Only local images are allowed.

I'd lke to see the usability of this meme in core improved, as it's very non-obvious that that's what that checkbox is there for.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Ideas kicked around in a brainstorm session in #drupal:

Gmail/PHPMyAdmin use links for select all, select none, etc:

PHPMyAdmin
Gmail

A select all / deselect all button (don't know what this is from; found it in Google image search):

Hotmail and Horde do it basically like we do:


webchick’s picture

It's also possible that what we have there is perfectly fine, and the only reason it looks so bizarre is because it's not obvious where the page header stops and the table header begins.

emmajane’s picture

FileSize
52.01 KB

Yahoo mail tells you how many things are selected. I think that's kind of nice. (As you can see from my welcome message being the only mail in the folder, I'm not a huge Yahoo! mail user...so I can't say if this is a feature that I actually love to use.)

yoroy’s picture

Just fixing the alignment and bringing all table header content a bit closer down to the table body would be a solid improvement.

Another thing I noticed now is that in Drupal table headers do not have the convention of having slightly darker background colors. This is another factor that adds to the lost-in-spaceness of our little checkbox there.

There is a 'select-all' class assigned to the th element, but I couldn't find a
"th.select-all" in core's css files (checked on 6.4 though).

Maybe something to be added to admin.css?

floretan’s picture

#308272: Improve test selection page doesn't use the default tableselect.js to add the "check all" checkbox (I'm not sure it was intentional). This might be what causes the unusual alignment issue.

However, I agree with Yoroy that table headers are generally not clearly defined visually. This could definitely be improved, but I'm not sure how it would work with Garland's design.

yoroy’s picture

The checkbox is consistently mis-aligned in other admin pages with other core themes as well, for example in admin/content/node

catch’s picture

I reckon the missing background for Drupal tableheaders is partially to blame.

There were many, many followup patches to the sticky tableheaders towards the end of the D6 cycle, all kinds of alignment issues etc.

I personally quite like gmails 'select all' link - but I'm not sure if it'd be any good when it's only one link.

webchick’s picture

Well, if we went for links, we'd need at least two: All and None.

I'm kind of leaning more towards a patch that just does what's suggested in #4: fix the alignment of the checkbox and move the table header closer to the table so it's more obvious they belong together.

catch’s picture

If we could have All, None, and 'Invert selection', that'd make me so happy. But fixing how the existing checkbox works ought to be done anyway.

illuminaut’s picture

Using a checkbox for "select all" is fine, but #4 and #5 are correct in that the main problem is the table header. It's not clear where the table header begins and ends, or that in fact it even is a header. Properly aligning the header columns with the table columns and giving the table header a background would make this more usable.

catch’s picture

While we're on this subject, it'd be great to have a select all checkbox at the bottom of the table as well as at the top. The amount of times I jump to the bottom of the screen, then have to go back up the top, then back down the bottom to press the button.. well a big amount.

p.brouwers’s picture

FileSize
56.58 KB

I read this topic and I agree with #8
A link with All and None are a bit more clear.

I'd also like to see these links at the bottom of the bottom, with the update options (See attached image)
Though this should only be useful if there are allot of nodes on the page and you need to scroll, but I feel that having your actions also at the bottom of the page after selecting your nodes is more user friendly.

Think about it, you're selecting your nodes and you're at the bottom of the page then you need to scroll all the way to the top again to do your actions.

If we could decide what's best within this topic I'd be happy to make a patch for it.

edmund.kwok’s picture

Component: usability » base system
Issue tags: +Usability

I'm seeing that the alignment issue is fixed in HEAD? The header row's checkbox is aligned with the rest of the checkboxes.

For the node admin screen, I also prefer the Gmail links as suggested by catch and webchick. And the Update options at the bottom as suggested by p.brouwers in #12 also improves usability as the user won't need to scroll up to perform the update options. Gmail also has the options control at the bottom ;)

edmund.kwok’s picture

Attached patch implements the Gmail type select operations - All, None, Invert

The operation links are added at the top and bottom of the table. Check screenshot for an example on the testing page.

edmund.kwok’s picture

Status: Active » Needs review

Changing issue status.

edmund.kwok’s picture

Add additional select options in node admin form, Published and Unpublished. Not sure if it's best for the select options being declared in the node_operations hook. Seems like it should be a hook on it's own.

Thoughts?

bcn’s picture

FileSize
27.85 KB

I tested both patches (#15 & #17) and they both work as advertised. I definitely think that we should go with text links vs. a checkbox, and putting the links on the top and bottom of the table is crucial (for usability) as well. Attached is screen shot of the patch from #17.

At first I really liked the idea of having the ability to select 'published' or 'unpublished', but I'm leaning toward the idea that "All", "None", and "Invert" are sufficient.
1) Keeping this patch simple will increase the chance of it getting in sooner;
2) As you point out, using the _operations hook seems like a hack and might not extend cleanly to the other objects (e.g. users and comments) and will likely hold up this patch (file another issue to create a select operations hook?);
3) You can use filters to limit the results, and then use the "All", "None", or "Invert" options;
4) If you have "Invert", you only need "published" or "unpublished" not both, since you could just select "publish", then "invert" (okay, that's not a good reason against)...

Other than that, I think that we should continue to look to gmail for some inspiration. Specifically, if (in another issue) we could come up with some way to select ALL (as in, across all pages) items, that would be a HUGE time saver. The other thing gmail does nicely is to put the split the common operations out into buttons, and keeps the less common ones into the dropdown...

catch’s picture

I really like the idea of being able to select published/unpublished like this (and then hopefully simplifying the node admin filters a bit as well) - but it shouldn't be introduced with this patch - can we move the additions in #17 to a followup issue?

However #15 looks like a viable patch to me, would be great to get some reviews both from the UX team and some javascript people.

catch’s picture

Title: Improve usability of "Select all" feature » Text links for 'Select all/None/Invert'
Bojhan’s picture

Status: Needs review » Needs work

This patch looks sufficient, the position seems good - we could try moving it slightly more towards the chechboxes, not sure if garland allows this (but even without that, good patch).

I would say, remove the option "invert" as the use case for this is quite rare and adds a lot of clutter (mentally - what does it mean again).

yoroy’s picture

Status: Needs work » Needs review

Yep, agreed with the above:
- try to move it a bit closer to the table
- remove 'invert', it makes people think. thinking hurts :-)

Please provide a screenshot of how the links look at the bottom of the table as well. Thanks & good patch.

edmund.kwok’s picture

Thanks for the reviews guys. Attached patch removes the Invert operation, as well as Published and Unpublished. Agreed that the latter should be in a separate issue; let's get this in first. The select operations are also moved closed to the table - changed the table's margin-top. It's around 18px top and bottom now.

The onus is on catch to provide more use cases on the Invert operation since I added that on his suggestion ;) Screenshot of top and bottom of table is also attached.

catch’s picture

After discussing the 'revert' thing with Bojhan in irc, I recant my suggestion - very happy with this as it is now.

webchick’s picture

Status: Needs review » Needs work

First, some minor code comments:

+  var strings = { 'selectAll': Drupal.t('Select all rows in this table'), 'selectAllLabel' : Drupal.t('All'), 'selectNone': Drupal.t('Deselect all rows in this table'), 'selectNoneLabel' : Drupal.t('None') };

I know this falls under "wasn't my fault!" but could you please put those onto separate lines so they're easier to read? like:

  var strings = {
    'selectAll': Drupal.t('Select all rows in this table'),
    'selectAllLabel' : Drupal.t('All'),
    'selectNone': Drupal.t('Deselect all rows in this table'),
    'selectNoneLabel' : Drupal.t('None')
};

Same thing with:

+  $(table).before('<div class="select-operations"></span>').after('<div class="select-operations"></span>');

(make it match the lines below where you have the various .somethingsomething indented.)

For comments...

+  // Create select operations link
...
+  // Append select operations link to the top and bottom of table
...
etc.

All comments should "Be formatted like a sentence." (start with capital letter, end with a period/full stop) for consistency.

Other than that, this looks great, and has the Usability team's thumbs-up. :) I am cool with committing it, however, just some food for thought...

Here's a screenshot of Gmail's interface, and what my eye does when I look at it. It is very obvious which part of the table is the data part, and which part is the operations part. This is due to a number of factors, including colour and positioning:

Gmail

Here's a screenshot of admin/content/node, and what my eye does when I look at it. The various "Select" links are invisible to me, because the filtering options and the table data itself are so prominent:

Node Admin

Without turning this into a kitten-eating, bikeshed, train-wreck of an issue, is there something small that we can do here to help alleviate this problem?

catch’s picture

If we gave table headers a background in Garland, then the operations would appear closer to the table. The other option is remove all that crap and replace it with a search filter.

However I think any changes like that are should be in followup issues - there's so much wrong with that page, this fixes a tiny part of it in a very nice way.

webchick’s picture

I thought that might be it, too, but then I looked in Bluemarine, which also doesn't have colours behind the table headings, and it's still more clear there what's going on. This is because of the positioning of the links relative to the table:

Bluemarine

Contrast with:

Garland

So could we try playing a bit with adding/removing some padding and see if that helps, perhaps?

yoroy’s picture

Good feedback and it shows we need large screenshots that show the complete environment.
Notice how Gmail does *not* use a table header at all (not suggestion we should that here).
The other elements being so prominent is what needs fixing next, it's not like we should make these text links blinking, purple h1's to make them stand out, rather tone down the surroundings, esp. the filters above.

Follow-ups:
- add a darker background to table headers in Garland, probably include the operation links visually (give them the same darker bg color)
- something with totally reworking those filters on the top of the page, we should brainstorm some options for that.

So yes, small steps please :-)

catch’s picture

Cut margin on the tableselect down to 0 for comparison which does indeed seem to help a bit, didn't fix any other issues in the patch.

catch’s picture

FileSize
34.81 KB
39.97 KB

Screenshots.

bcn’s picture

Status: Needs work » Needs review
FileSize
4.84 KB

A re-roll of the patch from #29, with the code comments from #25 incorporated.

p.brouwers’s picture

I see there has been quite some activity since my last suggestion, nice!
I'll see if I can brainstorm with some people on reworking those filters.

skilip’s picture

subscribe

yoroy’s picture

how's this:

skilip’s picture

First of all I don't see why we need to add the select all / none links at the bottom of the table. Since we have sticky table headers, the buttons will be always present.

Secondly, I really like the way GMail displays several selection options, however this is only useful when having more than two selection options. Just for select all / none it is just waist of space IMO. Therefore I'd suggest to keep the buttons inside the table header.

We already have an sort status indicator (the down- or upwards pointing triangle), so why don't we add a simple icon on top of the checkboxes? A single icon would do. You can check all / uncheck all with the same icon.

bcn’s picture

FileSize
43.06 KB

I think #34 looks okay, but I think that if we're eventually going to join (even conceptually) the update options with the select options, we might want to keep the table header below the select links.

Attached is a screenshot with the header below the select options, which I'm not really saying looks better, but is useful for comparison.

webchick’s picture

If we can possibly avoid it, I'd really love to *not* pursue a colour-based approach to solving this issue because:

a) Then we need to have a bikeshed discussion over the exact shade of blue
b) It'll look inconsistent across themes
c) Themers will rail against yet *more* core CSS they have to override.

bcn’s picture

Regarding #35:
Having the select options at the top and bottom is nice if you don't want to have to scroll up to the top of the page to make select all items, which granted at this point (without update options also at the bottom) doesn't make a huge difference. If we are not putting update options at the bottom too, then I would agree that the might not be needed at the bottom, but I think the real win here will be to have the select and update options at the top and bottom of the table.

As far as using an image vs. the text links, I'm strongly in favor of the text links.

p.brouwers’s picture

I see there's a new form element tableselect: http://drupal.org/node/242962
We should try to make the functionality work for this form element too.

Status: Needs review » Needs work

The last submitted patch failed testing.

Bojhan’s picture

Status: Needs work » Postponed

I am postponing this issue, until we touch the update part of the content form. The usability issue regarding select all is addressed by alignment of the checkbox.

Aren Cambre’s picture

jix_’s picture

Interesting. I was just thinking about this while working on #491258: Create issues for UI decisions reached, but not yet implemented

The checkbox works fine for table views I guess, but a Gmail-like text link approach is more bullet proof; it works for other types of views as well, like thumbnails. Plus you'd indeed have the ability to provide more selection options; 'published', 'unpublished', etc.

Example of usage in media library:
http://www.flickr.com/photos/mverbaar/3959012750/in/pool-drupalredesign

Bojhan’s picture

Status: Postponed » Active
Issue tags: -Needs usability review

We dont seem to be touching the "update" part soon, but I have my hopes.

nod_’s picture

Version: 7.x-dev » 8.x-dev
dawehner’s picture

Component: base system » node system
Issue summary: View changes

Move to node module, but in general this page is using a view now

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.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.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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.

larowlan’s picture

Issue summary: View changes
Issue tags: -JavaScript +JavaScript
pameeela’s picture

Issue tags: +Bug Smash Initiative

Wondering if anyone involved in the earlier conversation has thoughts about this issue now? IMO the checkbox is the standard now, even if it wasn't in 2008. Gmail is referenced several times, but it now uses the checkbox too.

Certainly I don't think it qualifies as a bug, but I'm not really sure that it should stay active as a feature request either?

Lendude’s picture

Yeah 12 years on, this looks pretty standard

With a View:

Not with a View:

So without a View, there is no checkbox anymore, so if there is anything still worth doing here it probably needs to be addressed at the Views level.

But I agree with #56 that we should probably just close this.

quietone’s picture

The IS refers to problems with the checkbox, which I agree are no longer relevant. But the title suggests a solution of having links for 'Select all/None/Invert' and supported by catch in #5. Is there a need for a followup to consider that?

pameeela’s picture

Status: Active » Closed (won't fix)

Nine months on, no comments in support of further changes, so I'm going to close this. To @quietone's point though if anyone feels there is additional functionality to be added I think it should be a new feature request.