Web client: Action menu requires grid selection when some actions are not performed on selections

Bug #1670457 reported by Kathy Lussier
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
3.5
Fix Released
Medium
Unassigned
3.6
Fix Released
Medium
Unassigned

Bug Description

A follow up from bug 1539089, which, in retrospect, may not have been such a good idea. In that bug, I asked that actions be disabled in web client grids where no rows were selected because most of the actions must be performed on the selected item.

While it might be nice to disable individual actions that require a selection, disabling the entire actions menu is problematic. There are many grid actions that do not depend on item selection, and requiring users to select some random item to use the actions menu is a pain. Some examples of these actions include:

- From the holdings tab of the record: Choose Library for Volume/Copy Transfer Destination and View / Place Orders. See related bug 1670448.

- From the patron's Group Member Details page: Move Another Patron To This Group

- Statistical Popularity Badges: Add Badge (as more admin interfaces are moved to Angular, I expect to see more "Add" actions like this one.)

- Record Buckets, Pending Records: Clear List

- Copy Buckets, Pending Copies: Clear List

We need to decide how we want to handle these actions that are available in grid interfaces, but are not actually performed on selected items.

1. We could continue as is with the Actions menu disabled until the user selects an item. However, I think users will find this to be frustrating. Also, in the case of the "Move Another Patron to This Group" action, if the patron is not already linked to other users, there is no grid item to select. In the case of the buckets, selecting an item may confuse the user into thinking they are only clearing that one selection when, in fact, they will clear the entire list.

2. We could change the code for the grids so that the Actions menu does not get disabled since there are options available that don't require selection. However, in that case, staff may accidentally select another action without previously selecting an item, which will lead to a failed action.

3. We could enable the Actions menu and disabled all individual actions that require a selection. Those actions would then become enabled once a selection is made.

4. We could move this particular action out of the Actions menu and put it somewhere else. If we choose this route, I recommend that we create a guideline that Actions menu should only contain actions that can be performed on selections from the corresponding grid. It looks like some interfaces, such as the patron Bills interface, were designed with this convention. The actions menu only includes actions that are performed on specific bills, whereas the Bill Patron and general History actions are pulled out into their own buttons.

I have a preference for approach 3 or 4. When I first filed this bug, I favored approach 4, but now that I have found more examples of this problem, I have a slight preference for approach 3.

Revision history for this message
Kathy Lussier (klussier) wrote :

I'm going to update the title and description of this bug because the problem extends beyond the original actions reported. When a user needs to perform an action that does not really require a selection, it can be frustrating to perform the action of selecting just to get the Actions menu to work.

Depending on what approach we decide to pursue, I'm willing to perform the work on this bug. But I would like some feedback on how we should address the issue.

summary: - Web client: remove Choose Library option from Holdings view action menu
+ Web client: Action menu requires grid selection when some actions are
+ not performed on selections
Kathy Lussier (klussier)
description: updated
Revision history for this message
Jason Boyer (jboyer) wrote :

I agree that 3 and 4 are the best choices, and I also have a preference for 3 so you always know to look for the Actions menu vs sometimes Actions and sometimes that other thing, etc.

Revision history for this message
Bill Erickson (berick) wrote :

For what it's worth, the grid was designed with #4 in mind. It supports <eg-grid-menu-item/> entries for global actions (the buttons along the top left) and <eg-grid-action/> entries for row-specific actions (in the Actions selector).

"Clear List", etc. noted above probably should have been eg-grid-menu-item entries.

I think this works well, with the possible exception of having too many eg-grid-menu-item's crowding the page. There are probably a variety of ways to handle that, though.

I don't have strong preference for the final look and feel as long as the global actions are easy to differentiate from the row actions.

Revision history for this message
Mike Rylander (mrylander) wrote :

I think there's enough room that we could make it a button, like the checkboxes (just needs the standalone attribute). Or, as an alternative, we could make the library selection an interstitial modal that comes up whenever you try to transfer volumes and copies.

Revision history for this message
Mike Rylander (mrylander) wrote :

(Obviously, my previous comment is specifically about the vol/copy transfer destination selection...)

Revision history for this message
Terran McCanna (tmccanna) wrote :

I prefer for #3 since it keeps all the actions together and doesn't add clutter to the screen. It also seems to be more consistent with traditional user interface practices.

Revision history for this message
Lynn Floyd (lfloyd) wrote :

I like option 3 also.

Changed in evergreen:
status: New → Confirmed
Zavier (zavierbanks)
Changed in evergreen:
assignee: nobody → Zavier (zavierbanks)
Revision history for this message
Zavier (zavierbanks) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: Zavier (zavierbanks) → nobody
Revision history for this message
Terran McCanna (tmccanna) wrote :

There was a merge conflict when applying this to current master - can you please rebase?

tags: added: needsrepatch
Revision history for this message
Kyle Huckins (khuckins) wrote :
tags: removed: needsrepatch
Revision history for this message
Terran McCanna (tmccanna) wrote :
tags: added: signedoff
Changed in evergreen:
milestone: none → 3.6-beta2
Galen Charlton (gmc)
Changed in evergreen:
milestone: 3.6-beta2 → 3.6-rc
Galen Charlton (gmc)
Changed in evergreen:
milestone: 3.6-rc → 3.6.1
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Jason Boyer (jboyer)
Changed in evergreen:
assignee: nobody → Jason Boyer (jboyer)
milestone: 3.6.2 → 3.7-beta
Revision history for this message
Jason Boyer (jboyer) wrote :

Pushed to master, rel_3_5 and rel_3_6. Thanks Zavier, Kyle, and Terran!

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Jason Boyer (jboyer) → nobody
tags: removed: webstaffclient
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.