[Bug 36285] New: Staff UI form fieldset styling needs update
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Bug ID: 36285 Summary: Staff UI form fieldset styling needs update Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs@lists.koha-community.org Reporter: pedro.amorim@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com, david@davidnind.com, | |jonathan.druart@gmail.com, | |katrin.fischer@bsz-bw.de, | |martin.renvoize@ptfs-europe | |.com, oleonard@myacpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #1 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 162969 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=162969&action=edit Bug 36285: [PoC] Move ERM specific styling to all of koha Staff forms This is just a proof of concept 1) Before applying the patch, access some (or all) of the links below. 2) Apply patch 3) Run yarn css:build to rebuild scss 4) Refresh each of the pages and notice the changes Some form examples: <staff_url>/cgi-bin/koha/acqui/supplier.pl?op=enter <staff_url>/cgi-bin/koha/serials/serials-home.pl <staff_url>/cgi-bin/koha/serials/subscription-add.pl <staff_url>/cgi-bin/koha/erm/eholdings/local/titles/add <staff_url>/cgi-bin/koha/virtualshelves/shelves.pl?op=add_form&referer=list <staff_url>/cgi-bin/koha/suggestion/suggestion.pl?op=add_form&branchcode=CPL Side menu changes: /cgi-bin/koha/members/members-home.pl /cgi-bin/koha/serials/serials-search.pl # Press Search A problem arises for some inputs that have the size property e.g. size="4" on the new purchase suggestion form, and others. With this new change, these inputs lose their initial enforced "smaller" size. I think this should be iterated and made more streamlined and use a .input-small class of the size. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #2 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hey all, I've submitted a PoC patch for discussion. Would be great to have others opinions on this to better make the judgement call if this is worth investing more time into or not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #3 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I was looking at forms inside modals this afternoon and I'd love to see some consistency improvements there too ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Pedro, thanks for taking the initiative! Working on this now might even be good timing with the CSRF changes also requiring testing a lot of the forms. I noticed some things, that we maybe could improve on: /cgi-bin/koha/acqui/supplier.pl?op=enter * The pull-downs for currencies and others have a lower height than the input fields. I think it would help readability and consistency if the heights of the fields matched. The select2 pull-downs don't appear to have this issue (edit item form for an example). * Not related to the new CSS... but maybe I can still bring it up for consideration: German labels are often a lot longer than English ones and that leads to quite a lot of display issues we have to counter with custom CSS. I see a lot of the labels already wrap on this form in English already ("Account number". Could we consider making the label area a bit more spacious/flexible in general? /cgi-bin/koha/suggestion/suggestion.pl?op=add_form&branchcode=CPL * Input field lengths appear longer in general - I quite like that in general. But wondering about fields with a set max-length like the copyright year in this form. It's still not the same length as the other input fields with the patch applied, but also not 'year-sized' anymore. Similar for zipcode in administration/libraries. /cgi-bin/koha/admin/categories.pl?op=add_form&categorycode=HB * In the messaging preferences table, the pull down for "days in advance" is now too small to fit the number. Without the patch the width is ok. Hope this helps! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #162969|0 |1 is obsolete| | --- Comment #5 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 175772 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175772&action=edit Bug 36285: Preparation: Move ERM specific styling to all of koha Staff forms This is just a proof of concept 1) Before applying the patch, access some (or all) of the links below. 2) Apply patch 3) Run yarn css:build to rebuild scss 4) Refresh each of the pages and notice the changes Some form examples: <staff_url>/cgi-bin/koha/acqui/supplier.pl?op=enter <staff_url>/cgi-bin/koha/serials/serials-home.pl <staff_url>/cgi-bin/koha/serials/subscription-add.pl <staff_url>/cgi-bin/koha/erm/eholdings/local/titles/add <staff_url>/cgi-bin/koha/virtualshelves/shelves.pl?op=add_form&referer=list <staff_url>/cgi-bin/koha/suggestion/suggestion.pl?op=add_form&branchcode=CPL Side menu changes: /cgi-bin/koha/members/members-home.pl /cgi-bin/koha/serials/serials-search.pl # Press Search A problem arises for some inputs that have the size property e.g. size="4" on the new purchase suggestion form, and others. With this new change, these inputs lose their initial enforced "smaller" size. I think this should be iterated and made more streamlined and use a .input-small class of the size. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #6 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 175773 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175773&action=edit Bug 36285: (QA follow-up): Fix regular select elements height -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #7 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 175774 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175774&action=edit Bug 36285: (QA follow-up): Apply new style only to form elements inside fieldset->li Styling was being applied where it shouldn't. This is to address Katrin's comment: * In the messaging preferences table, the pull down for "days in advance" is now too small to fit the number. Without the patch the width is ok. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #8 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 175775 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175775&action=edit Bug 36285: (QA follow-up): Use 30% as min-width, but if input has 'size' property, utilize that instead Addresing Katrin's comment: * Input field lengths appear longer in general - I quite like that in general. But wondering about fields with a set max-length like the copyright year in this form. It's still not the same length as the other input fields with the patch applied, but also not 'year-sized' anymore. Similar for zipcode in administration/libraries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #9 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 175776 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175776&action=edit Bug 36285: Clean-up: Remove WET code from Preservation/Main.vue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Sandbox CC| |andrew.auld@ptfs-europe.com | |, | |paul.derscheid@lmscloud.de, | |pedro.amorim@ptfs-europe.co | |m, tomascohen@gmail.com Patch complexity|--- |Trivial patch --- Comment #10 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi all, I'm revisiting this. I really need to improve the style of the ILL forms on Staff UI, as customers complain the input fields are often too small. Personally I agree. "Why not utilize the already improved form styling from ERM? And have all inputs in Koha use that for consistency", this was my original thinking. At the time it looked like the scope was too big (it may very well still be the case) but I've given this another go at attempting to apply this uniform style to all Koha forms for better UI consistency across modules (and of course improvement to the ILL form also, but not limited to). This obviously needs extensive testing so any help here is very much appreciated! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #11 from Jonathan Druart <jonathan.druart@gmail.com> --- I like the idea, however you are correct saying there is still lot of work. 1. add/edit library: https://snipboard.io/WEfPty.jpg That's a lot of different sizes! 2. Same for patrons: https://snipboard.io/nisNJH.jpg 3. Also note the lack of padding for the selected option in dropdown lists: https://snipboard.io/zkAV9Y.jpg I think we should remove the "size" parameter for all the inputs, so there are all aligned identically. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #12 from Paul Derscheid <paul.derscheid@lmscloud.de> --- I especially agree with that last bit:
I think we should remove the "size" parameter for all the inputs, so there are all aligned identically.
Normally this should be dictated by what the parent element wants, so `width: 100%` by default. Testing this is a bit of work, so maybe a consideration for a community sprint (#3)? Not sure whether we really need 3 weeks for that, though. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #13 from Owen Leonard <oleonard@myacpl.org> --- I'm concerned about the border color: "Text input: Where a text-input has an indicator such as a complete border (#767676), that indicator must meet 3:1 contrast ratio." https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#user-inte... I think in general we've gotten ourselves into trouble by trying to control form borders and backgrounds. Browsers have different default behaviors, and they also have different behaviors when you try to change those defaults. If you change the input background in Firefox, the borders reset to a weird default. If you change the input border-radius in Chrome, the border colors change. If you change select background in Chrome the border radius changes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> --- (In reply to Jonathan Druart from comment #11)
I like the idea, however you are correct saying there is still lot of work.
1. add/edit library: https://snipboard.io/WEfPty.jpg That's a lot of different sizes!
2. Same for patrons: https://snipboard.io/nisNJH.jpg
3. Also note the lack of padding for the selected option in dropdown lists: https://snipboard.io/zkAV9Y.jpg
I think we should remove the "size" parameter for all the inputs, so there are all aligned identically.
The size part was explicitly added at Katrins request... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #15 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I have been following this discussion a bit, but I am not sure I get the full picture yet. Is the suggestion to make all the input fields the same length? I am not sure if there are some guidelines to follow here. Personally I like that the field is shorter if I am only allowed to add a year (like publication year on suggestions form in OPAC), that only allows 4 characters. Similar for fields that store dates. But as we use flatpickr we could maybe limit the length for those another way. Having an idea about best practice might be helpful. Martin is probably right, that I asked for it... but can you give me some context? I am not sure where and what for I did it :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #16 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Katrin Fischer from comment #15)
Martin is probably right, that I asked for it... but can you give me some context? I am not sure where and what for I did it :)
This one I guess: (In reply to Katrin Fischer from comment #4)
* Input field lengths appear longer in general - I quite like that in general. But wondering about fields with a set max-length like the copyright year in this form. It's still not the same length as the other input fields with the patch applied, but also not 'year-sized' anymore. Similar for zipcode in administration/libraries.
-- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #17 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #16)
(In reply to Katrin Fischer from comment #15)
Martin is probably right, that I asked for it... but can you give me some context? I am not sure where and what for I did it :)
This one I guess:
(In reply to Katrin Fischer from comment #4)
* Input field lengths appear longer in general - I quite like that in general. But wondering about fields with a set max-length like the copyright year in this form. It's still not the same length as the other input fields with the patch applied, but also not 'year-sized' anymore. Similar for zipcode in administration/libraries.
Ah ok, that matches with what I wrote about the dates and the year on suggestions. If there are some general guidelines to follow, I'd be happy to. For the dates I also like that it means the X for deleting a date is "closer" but I am not sure if that counts for usability... which should be the ultimate goal. Do the WCAG or similar say anything useful about forms? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 --- Comment #18 from Paul Derscheid <paul.derscheid@lmscloud.de> --- A compromise would maybe be to "type" the input fields with a data attribute or just make it dependent on the standard type attribute and use that for a custom length for certain fields. Then we'd have the best of both worlds, uniform fields and a custom length where it makes sense (and consistent). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36285 Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Hackfest -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org