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.
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?
> 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.
Hm, I think we should try and get more people to look at this :)
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.
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.
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.
I think it might be worth having both, options in the menu and drag & drop, because the latter is probably not accessible.
(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?
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.
Yeah. Kinda thought that. Okay. How about this: An action item that says "Change hold priority" and then a modal box asking for position?
Patch doesn't apply for me.
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!)
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.