Bug 36285 - Staff UI form fieldset styling needs update
Summary: Staff UI form fieldset styling needs update
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords: Sandbox
Depends on:
Blocks:
 
Reported: 2024-03-08 15:09 UTC by Pedro Amorim
Modified: 2025-01-23 14:46 UTC (History)
10 users (show)

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


Attachments
Bug 36285: [PoC] Move ERM specific styling to all of koha Staff forms (3.22 KB, patch)
2024-03-08 15:12 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 36285: Preparation: Move ERM specific styling to all of koha Staff forms (3.22 KB, patch)
2024-12-19 15:27 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 36285: (QA follow-up): Fix regular select elements height (767 bytes, patch)
2024-12-19 15:27 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 36285: (QA follow-up): Apply new style only to form elements inside fieldset->li (2.49 KB, patch)
2024-12-19 15:27 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 36285: (QA follow-up): Use 30% as min-width, but if input has 'size' property, utilize that instead (1.45 KB, patch)
2024-12-19 15:27 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 36285: Clean-up: Remove WET code from Preservation/Main.vue (1.22 KB, patch)
2024-12-19 15:27 UTC, Pedro Amorim
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro Amorim 2024-03-08 15:09:54 UTC

    
Comment 1 Pedro Amorim 2024-03-08 15:12:37 UTC
Created attachment 162969 [details] [review]
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.
Comment 2 Pedro Amorim 2024-03-08 15:14:01 UTC
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.
Comment 3 Martin Renvoize (ashimema) 2024-03-08 16:37:52 UTC
I was looking at forms inside modals this afternoon and I'd love to see some consistency improvements there too ;)
Comment 4 Katrin Fischer 2024-03-09 12:09:25 UTC
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!
Comment 5 Pedro Amorim 2024-12-19 15:27:45 UTC
Created attachment 175772 [details] [review]
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.
Comment 6 Pedro Amorim 2024-12-19 15:27:47 UTC
Created attachment 175773 [details] [review]
Bug 36285: (QA follow-up): Fix regular select elements height
Comment 7 Pedro Amorim 2024-12-19 15:27:50 UTC
Created attachment 175774 [details] [review]
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.
Comment 8 Pedro Amorim 2024-12-19 15:27:52 UTC
Created attachment 175775 [details] [review]
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.
Comment 9 Pedro Amorim 2024-12-19 15:27:55 UTC
Created attachment 175776 [details] [review]
Bug 36285: Clean-up: Remove WET code from Preservation/Main.vue
Comment 10 Pedro Amorim 2024-12-19 15:35:58 UTC
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!
Comment 11 Jonathan Druart 2025-01-22 13:09:02 UTC
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.
Comment 12 Paul Derscheid 2025-01-22 13:16:07 UTC
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.
Comment 13 Owen Leonard 2025-01-22 15:39:32 UTC
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-interface-component-examples

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.
Comment 14 Martin Renvoize (ashimema) 2025-01-23 09:30:17 UTC
(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...
Comment 15 Katrin Fischer 2025-01-23 14:36:23 UTC
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 :)
Comment 16 Jonathan Druart 2025-01-23 14:42:49 UTC
(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.
Comment 17 Katrin Fischer 2025-01-23 14:45:44 UTC
(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?
Comment 18 Paul Derscheid 2025-01-23 14:46:50 UTC
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).