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.

Checkboxes in outer space!

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.

Files: 
CommentFileSizeAuthor
#36 Header_below_select.jpg43.06 KBbcn
#35 table_select_operations-308468.png24.27 KBskilip
#35 table_deselect_operations-308468.png24.27 KBskilip
#31 select_all.patch4.84 KBbcn
Failed: 9680 passes, 0 fails, 1 exception
[ View ]
#30 top.png39.97 KBcatch
#30 bottom.png34.81 KBcatch
#29 table_select_operations_3.patch4.28 KBcatch
Unable to apply patch table_select_operations_3_0.patch
[ View ]
#23 table_select_operations_3.patch4.28 KBedmund.kwok
Failed: Failed to install HEAD.
[ View ]
#23 Table select operations 2.png12.36 KBedmund.kwok
#18 select_all.jpg27.85 KBbcn
#17 table_select_operations_2.patch7.32 KBedmund.kwok
Unable to apply patch table_select_operations_2.patch
[ View ]
#15 Table select operations.png20.41 KBedmund.kwok
#15 table_select_operations.patch4.37 KBedmund.kwok
Failed: Failed to install HEAD.
[ View ]
#12 admin_content.jpg56.58 KBp.brouwers
#3 yahoomail6.png52.01 KBemmajane

Comments

Ideas kicked around in a brainstorm session in #drupal:

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

PHPMyAdminGmail

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:

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.

StatusFileSize
new52.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.)

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?

#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.

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

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.

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.

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.

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.

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.

StatusFileSize
new56.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.

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 ;)

StatusFileSize
new4.37 KB
Failed: Failed to install HEAD.
[ View ]
new20.41 KB

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.

Status:Active» Needs review

Changing issue status.

StatusFileSize
new7.32 KB
Unable to apply patch table_select_operations_2.patch
[ View ]

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?

StatusFileSize
new27.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...

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.

Title:Improve usability of "Select all" featureText links for 'Select all/None/Invert'

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).

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.

StatusFileSize
new12.36 KB
new4.28 KB
Failed: Failed to install HEAD.
[ View ]

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.

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

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?

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.

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?

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 :-)

StatusFileSize
new4.28 KB
Unable to apply patch table_select_operations_3_0.patch
[ View ]

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.

StatusFileSize
new34.81 KB
new39.97 KB

Screenshots.

Status:Needs work» Needs review
StatusFileSize
new4.84 KB
Failed: 9680 passes, 0 fails, 1 exception
[ View ]

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

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.

subscribe

how's this:

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.

StatusFileSize
new43.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.

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.

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.

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.

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.

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

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

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

Version:7.x-dev» 8.x-dev