Bug 16421 - Move hold edit actions into dropdown menu
Summary: Move hold edit actions into dropdown menu
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL: /cgi-bin/koha/reserve/request.pl
Keywords: Academy
Depends on: 23501
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-02 18:38 UTC by Owen Leonard
Modified: 2020-11-30 21:44 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot showing proposed interface change (63.69 KB, image/png)
2016-05-02 18:38 UTC, Owen Leonard
Details
Bug 16421 - Move hold edit actions into dropdown menu (19.70 KB, patch)
2016-05-31 18:16 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2016-05-02 18:38:35 UTC
Created attachment 51111 [details]
Screenshot showing proposed interface change

I propose that we re-work the way existing holds are displayed in the staff client so that many of the actions associated with a hold are moved into a dropdown menu. I would also add some additional information about the status of a hold into the "details" column.

This change would accomplish a few things:

- Make the display more compact
- Make clearer some information which may not be clear. For instance, that a hold is suspended until a particular date, or that a hold is set to lowest priority.
- Make clearer the meaning of the hold priority icons. Using text labels with icons, the meaning of each is explicit.

Unfortunately Font Awesome doesn't have the equivalent of the "move to top" or "move to bottom" icon, so I've tried to fake it with a border. It's not perfect buy may be passable.

See attached screenshot.
Comment 1 Katrin Fischer 2016-05-08 12:24:24 UTC
I like it!

But something I wonder about: do we really need all 5 options for changing the holds sequence? 
We have the pull down which allows you to select a new number, we have up, down, to the bottom, to the top.
The first and the last 4 allow you to achieve the same thing - with the first option being the most flexible, as you can do all 4 with less clicks.
Am I missing something?
Comment 2 Owen Leonard 2016-05-09 21:38:58 UTC
> first option being the most flexible, as you can do all 4 with less clicks.

I don't think the dropdown menu with the numbers is necessarily the most convenient if you have a lot of holds. For instance, moving hold number 50 up one space would required a lot of scrolling through numbers.

I think it could be argued that by moving the arrows into a menu I have taken away the convenience they offer by being visible all the time.

At my library we don't monkey with holds priorities much, so I don't use the options in a real-life situation very often.
Comment 3 Katrin Fischer 2016-05-10 11:39:41 UTC
Hm, I think we should try and get more people to look at this :)
Comment 4 Owen Leonard 2016-05-31 18:16:57 UTC
Created attachment 51935 [details] [review]
Bug 16421 - Move hold edit actions into dropdown menu

This patch modifies the view of existing holds in the staff client so
that holds-related actions are moved into an 'actions' menu. This
includes priority-reordering controls, suspend, and cancel.

This patch also modifies the display of details for each hold so that
its suspension or priority status is clear.

To test, apply the patch and view holds for a title with multiple holds.

- Test the priority-reordering controls and confirm that they work
  correctly.
- Test the "suspend" link and confirm that the suspension form is
  displayed correctly in a modal window.
  - Confirm that suspensions are saved correctly with and without a
    date, and that suspension information is displayed correctly after
    saving.
- Test the "Cancel hold" link.
Comment 5 Kyle M Hall 2016-06-17 15:56:43 UTC
 It does make moving a hold a number of places up or down a bit more cumbersome, but it's also more self-explanitory. I'm torn. Even in it's current state it's a bit cumbersome with the page reloading between each move. I think this table would really benefit from the re-ordering being done via ajax in some fashion.
Comment 6 Christopher Brannon 2016-09-07 14:56:31 UTC
Kyle and I were talking about this, and he brought up the idea of just rearranging the elements physically (drag and drop).  So what if you removed all the move options (except for pin to bottom) and did something like that?  Kyle pointed out this code:

http://jqueryui.com/sortable/

Worth a discussion.

I still like the action menu, but we could have less in the menu and even get rid of the priority dropdown.
Comment 7 Katrin Fischer 2016-09-07 17:43:32 UTC
I think it might be worth having both, options in the menu and drag & drop, because the latter is probably not accessible.
Comment 8 Christopher Brannon 2016-09-07 17:56:13 UTC
(In reply to Katrin Fischer from comment #7)
> I think it might be worth having both, options in the menu and drag & drop,
> because the latter is probably not accessible.

Then how about in addition to the drag and drop, having a single "Move hold" action item with a submenu that shows possible rankings, and defaults to the current ranking position.  Just click on the new ranking placement, rather than bumping up or down, or bumping to the top or bottom?
Comment 9 Katrin Fischer 2016-09-07 18:08:56 UTC
Hm, if there are a lot of holds a submenu with the positions might get out of hand. Let's keep thinking about this a bit more.
Comment 10 Christopher Brannon 2016-09-07 18:25:32 UTC
Yeah.  Kinda thought that.  Okay.  How about this: An action item that says "Change hold priority" and then a modal box asking for position?
Comment 11 Andreas Hedström Mace 2017-02-23 22:18:04 UTC
Patch doesn't apply for me.
Comment 12 Andreas Hedström Mace 2017-03-21 15:45:19 UTC
It seems I was a but quick when I looked over the comments for this bug, I assumed there was a working patch that I could test but reading the comments again (more thoroughly!) it seems it was more in discussion? Should I change the status back to Needs Signoff or maybe In Discussion?

My two cents is that a drag and drop option, combined with an action menu to be accessible, sounds like the best way to go. (Actually the holds page in the staff interface is the one who got singled out as most in need of re-work when we did some UX work on Koha, and anything that can be done to make it easier/more understandable is great!)
Comment 13 Owen Leonard 2020-01-22 00:25:38 UTC
This interface still needs work but it's going to end up being quite different after Bug 23501 so I think this should be closed.