#11818 closed enhancement (wontfix)
"Bulk Actions" as default for bulk actions drop down slows me down
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | minor | Version: | 2.9.1 |
Component: | UI | Keywords: | 2nd-opinion |
Focuses: | Cc: |
Description (last modified by )
"Bulk Actions" as default for bulk actions drop down slows me down
ENV: WP 2.9.1 r12301
When I think about the non-actionable default of "Bulk Actions", I don't think it helps the new user much. It's already pretty clear, and learnable.
The (table) framing makes it clear these are bulk actions. It being a drop down makes it clear there are additional ones.
"Edit" would be a better default. It's immediately actionable once items are selected.
Change History (10)
#3
follow-up:
↓ 4
@
15 years ago
We need some kind of "nothing selected" value (currently -1) so the form functions properly. Can probably replace "Bulk Actions" with "--Select--" or leave it empty if needed.
On the other hand it seems to work well at the Edit Posts screen: "Bulk Actions", "Show all dates", "View all categories".
#4
in reply to:
↑ 3
;
follow-up:
↓ 5
@
15 years ago
Replying to azaozz:
We need some kind of "nothing selected" value (currently -1) so the form functions properly. Can probably replace "Bulk Actions" with "--Select--" or leave it empty if needed.
Sorry for my ignorance, why do we need a "nothing selected" value for the drop down? What are the disadvantages of 'Edit' always being selected by default?
#5
in reply to:
↑ 4
@
15 years ago
- Keywords 2nd-opinion added; UX removed
Replying to lloydbudd:
Replying to azaozz:
We need some kind of "nothing selected" value (currently -1) so the form functions properly. Can probably replace "Bulk Actions" with "--Select--" or leave it empty if needed.
Sorry for my ignorance, why do we need a "nothing selected" value for the drop down? What are the disadvantages of 'Edit' always being selected by default?
I believe azaozz was referring to the fact that the entire page is a single form, and we need to make sure that the submission was a bulk action.
That said, since we first check a form submission for which submit button is pressed (doaction and doaction2 are the "Apply" buttons, for example), I can't say we need a "nothing selected" value.
The requirement to select something from the box and then press Apply has been cited by Jane as good for UX (and explains why there is no AYS), and I agree.
I like this as long as the default doesn't require AYS. But while you have "Edit" on Posts and Pages, but none of the other drop-downs (plugins, media, links, tax/tags/cats, ...) have a non-destructive action we could safely use as a default.
So while it will speed up bulk editing on posts and pages, you're then creating an inconsistency across the admin UI. Perhaps something we can live with, perhaps not.
Tagging as 2nd-opinion, I think Jane would like to weigh in on this.
#6
@
15 years ago
Now that I look at it, I'm finding some quirks in the code. Running WP_DEBUG, we have some notices that prevent redirects from executing, but that's not the main quirk.
Check a post, then select "Edit" in the top select box, and "Trash" in the bottom drop-down. Now click the bottom Apply button. It should trash a post, but instead it does a form submission that makes it think a bulk edit occurred.
This is rather easy to fix -- we can check for which submit button was pressed, then use the corresponding select box. (Right now, we simply check if the top select box ! -1, use the top, else use the bottom.)
This belongs in another ticket and I will handle that, but first it would be good to know if there is traction to re-work it so "Edit" can be the default. (Either way, perhaps we should code it so you could easily remove "bulk actions" via JS if you so desired.)
#7
@
15 years ago
On a multi-select action dropdown, having the label for what's in the dropdown is generally better than defaulting to the first action. It helps with wayfinding (you always know whether you have submitted the request or not), and lets the user know in a glance what the menu is for. As a note, Gmail and many other applications use labels for their multi action menu default states, so we are also following an accepted web practice. For power users who resent the extra click, we have our fancy keyboard shortcuts for bulk actions, which eliminates the need for touching the menu at all. :) http://codex.wordpress.org/Keyboard_Shortcuts
Would like to close as wontfix unless someone has a strong reason not to do so.
#8
follow-up:
↓ 10
@
15 years ago
Side note: things like this would probably be better served being posted in the Ideas forum so general users can weigh in on them, rather than here in Trac, which is limited to developers. Things like this shouldn't really wind up in trac until there's already been some discussion of opinions, so that when it gets to trac, the discussion is more focused.
#9
@
15 years ago
- Milestone Unassigned deleted
- Resolution set to wontfix
- Status changed from new to closed
#10
in reply to:
↑ 8
@
15 years ago
I'll leave this as wontfix though this experience still doesn't pass my smell test.
Replying to jane:
On a multi-select action dropdown, having the label for what's in the dropdown is generally better than defaulting to the first action. It helps with wayfinding (you always know whether you have submitted the request or not), and lets the user know in a glance what the menu is for.
This UI experience is obvious.
Based on the support tickets I've worked, "Bulk Action" does not seem to be a term that people seem to relate to.
The consistency that nacin notes is overrated.
As a note, Gmail and many other applications use labels for their multi action menu default states, so we are also following an accepted web practice.
Are you really referencing Gmail as good UI ;-) Besides Gmail does not include textual context and their drop down menu includes a down arrow marker.
Replying to jane:
Side note: things like this would probably be better served being posted in the Ideas forum so general users can weigh in on them, rather than here in Trac, which is limited to developers. Things like this shouldn't really wind up in trac until there's already been some discussion of opinions, so that when it gets to trac, the discussion is more focused.
The ideas forum seems like no better place for this type of issue because of it's specificity and expert knowledge required.
I stand by the current experience being subpar.
Oh, and "edit" being a multi-step action would feel faster by not having to choose it from the drop down.