Bug 15681 - Improve visibility of place hold option when checking out an item already checked out
Summary: Improve visibility of place hold option when checking out an item already che...
Status: RESOLVED DUPLICATE of bug 15821
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: PC All
: P3 enhancement (vote)
Assignee: Aleisha Amohia
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-27 16:29 UTC by Owen Leonard
Modified: 2016-02-29 10:41 UTC (History)
5 users (show)

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


Attachments
Screenshot of the proposed change (18.35 KB, image/png)
2016-01-27 16:29 UTC, Owen Leonard
Details
Bug 15681: Improve visibility of place hold option when checking out an item already checked out (7.51 KB, patch)
2016-02-10 22:47 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Screenshot of a test case (45.76 KB, image/png)
2016-02-11 13:43 UTC, Owen Leonard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2016-01-27 16:29:13 UTC
Created attachment 47356 [details]
Screenshot of the proposed change

Bug 1983 adds a link to place a hold on an item instead of checking it out when the item is already checked out. Sorry to be late to the party, but I have a couple of issues with the way it works:

1. Saying "click here" is almost always redundant, and doesn't represent the different ways in which users might interact with links (touchscreen? keyboard navigation?).

2. I'm concerned that the link is not very visible and doesn't well represent what is going to happen next. I think the link is a third option with equal weight as the confirm and cancel buttons and should be represented as a button even if the button text makes it big.

I would love to hear comments.
Comment 1 Jonathan Druart 2016-02-01 10:15:47 UTC
Yes, I completely agree.
I have asked when QAing bug 1983, and was not really convinced by the answer. But let it pass anyway.
Comment 2 Aleisha Amohia 2016-02-10 22:47:04 UTC
Created attachment 47880 [details] [review]
Bug 15681: Improve visibility of place hold option when checking out an item already checked out

Have converted icons to font-awesome!

To test:
1) Check out an item to a user
2) Attempt to check out the same item (ie same barcode) to another user
3) Confirm that message box says 'Please confirm checkout' with 3 newly styled buttons
4) Confirm 'cancel checkout and place a hold' button is styled the same as the other two buttons and clicking it takes you to page to place holds (reserves.pl)
5) Confirm behaviour of other two buttons works as expected also

Sponsored-by: Catalyst IT
Comment 3 Owen Leonard 2016-02-11 13:43:12 UTC
Created attachment 47891 [details]
Screenshot of a test case

In testing this I randomly happened to pick an item which was both checked out and on hold for someone, so this dialog got pretty complicated.

Currently buttons in dialogs have a special style which is different from other buttons. As you can see the patch doesn't modify them all. I would prefer to not use the Bootstrap style buttons here and keep the existing dialog button style. I think if we want to change the style of dialog buttons we should do it across the board.

I'm beginning to do so--at least for the icons--with Bug 15785.
Comment 4 Aleisha Amohia 2016-02-11 20:11:57 UTC
(In reply to Owen Leonard from comment #3)
> Created attachment 47891 [details]
> Screenshot of a test case
> 
> In testing this I randomly happened to pick an item which was both checked
> out and on hold for someone, so this dialog got pretty complicated.
> 
> Currently buttons in dialogs have a special style which is different from
> other buttons. As you can see the patch doesn't modify them all. I would
> prefer to not use the Bootstrap style buttons here and keep the existing
> dialog button style. I think if we want to change the style of dialog
> buttons we should do it across the board.
> 
> I'm beginning to do so--at least for the icons--with Bug 15785.

Ah I see! I think we should be changing all of the buttons and icons to be consistent with the buttons all over the site. Should I make a patch for circ templates like you have for acquisitions and add it to your bug or just make a new bug for each module?
Comment 5 Owen Leonard 2016-02-11 20:23:52 UTC
(In reply to Aleisha Amohia from comment #4)
> Ah I see! I think we should be changing all of the buttons and icons to be
> consistent with the buttons all over the site.

I see a value in having (slightly) different button styles for different areas, but this isn't a rule that anyone has discussed or agreed on. For instance: Toolbars get one button style, dialogs get another, everything else a third. This obviously isn't something we're being consistent about now because many new template changes are using Bootstrap-style buttons by default wherever they are.

I'm interested in hearing your (and anyone else's) opinion about that idea.

Koha really needs a style guide. More work, though, boo.

> Should I make a patch for
> circ templates like you have for acquisitions and add it to your bug or just
> make a new bug for each module?

I think a new bug for each module makes sense so that it's easy to keep track of which patches depend on which.
Comment 6 Marc Véron 2016-02-12 08:33:58 UTC
(In reply to Owen Leonard from comment #5)
(...)
> I see a value in having (slightly) different button styles for different
> areas, but this isn't a rule that anyone has discussed or agreed on. For
> instance: Toolbars get one button style, dialogs get another, everything
> else a third. This obviously isn't something we're being consistent about
> now because many new template changes are using Bootstrap-style buttons by
> default wherever they are.

+1

(...)
> Koha really needs a style guide.

+1

(...)
Comment 7 Aleisha Amohia 2016-02-15 21:04:10 UTC
Will fix this in patch for Bug 15821.
Comment 8 Jonathan Druart 2016-02-29 10:41:12 UTC

*** This bug has been marked as a duplicate of bug 15821 ***