(In reply to Solene D from comment #25)
> Created attachment 136847 [details] [review] [review]
> Bug 30952: update request

There have been incorrect merge conflict fixed in this patch.

At least:
* badBibs has been removed by bug 30742
* Removal of "PROCESS patron_search_js" looks wrong.

Please see comment 27. I think some merge conflicts haven't been resolved correctly.

> Bug 30952: css generation
This looks like the compiles CSS from SCSS, you should not attach a patch for that, it is compiled by testers :
https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_interface

Do we have a link to presentation ?
Screen shots ?

(In reply to Fridolin Somers from comment #79)
> > Bug 30952: css generation
> This looks like the compiles CSS from SCSS, you should not attach a patch
> for that, it is compiled by testers :
> https://wiki.koha-community.org/wiki/
> Working_with_SCSS_in_the_OPAC_and_staff_interface

I used to attach the result of SCSS compilation as a separate patch, to ease testing (especially on sandboxes). It's not something we do anymore ?

Anyway, we are still working on the patches (to fix bad conflict resolutions that happened during rebase). Fixed patches should be attached later this day, please be patient :)

There is now a simple option to build the CSS from the sandbox manager so the compiled CSS patch isn't required.

Personally, I was OK either way, so long as the compilation patch was distinct (as it's almost always a rebase issue, and is easier to just skip and rebuild when it's on it's own).

Looking forward to playing with this.. I assume, given rebases are challenging, we're wanting to get testing done pretty quick... Adding myself to CC

Can we also have a list of the changes we are expecting from these patches?

Created attachment 137408 [details]
screenshot of the new interface : the main menu

Created attachment 137409 [details]
screenshot of the new interface : return page

Created attachment 137410 [details]
screenshot of the new interface : patron details

Created attachment 137411 [details]
screenshot of the new interface : patron details

This new interface includes  modifications of the main colors, the buttons, the menus, the searchbar... (cf screenshots)

Any feedback will be helpfull. :)

We decided to remove the css from the patch, you'll have to generate it to test the interface.

1. Lot of French in the patches:
* "onclick="clique(this)""
* <p class="plusdessous" id="filters"> 
Plus dessous?!
* <ul id="taille">
* id="lientype", french, "link type"

2. Not descriptive:
* id="button_1", button_2, button_3, button_4

3. Lot of commented code.

4. This seems wrong:
+    function toggle(elem){style="width: calc(301px);"

5. identical JS code copy/pasted all around:
functions focusInput, toggle, clique, fold, taille, etc.

6. There is a lot of unnecessary indentation changes, that will lead to unnecessary conflicts...

On the home page, HTML from the IntranetmainUserblock system preference gets pushed under the news area (id="area-news") in the new interface.  It should be under the menu items.

"Patrons requesting updates" used to be in a div called id="area-pending" and it used to fall under the menu items.  Now it's under the news area in an id="area-news" div.

This same problem applies to Suggestions pending and Quote of the day.  They should all be under the menu items.  

My library make extensive use of the news area to share links to outside resources and putting these things underneath the news area makes the alerts, quote of the day and IntranetmainUserblock means that users may have to scroll 40 feet down the page in order to access relevant information and alerts.

Code mirror text in system preferences like IntranetUserJS is centered?

That's just crazy.

The "area-news" id is repeated several times on the home page for news, quote of the day, and alerts.

(In reply to George Williams (NEKLS) from comment #98)
> Code mirror text in system preferences like IntranetUserJS is centered?
> 
> That's just crazy.

Agreed. I feel the same way about centered text in the search results. It makes it harder to distinguish items and visually track certain characteristics that would always be in the same place in left justified text.

Let's keep the comments constructive please.

I'm sure there will be lots of follow-ups and fixes but let's remember lots of work has already happened and is good.  Now it's time for us to all help polish and fix inevitable issues that may have crept in. ﷐[U+1F642]﷑

On that front, I wonder if it might be helpful to have a shared branch to work on together for the final submission?  Perhaps a merge-request flow for fixes managed by Solene (with a little help from Julian or someone else)

There are coders here happy to help guide this through.

Thanks for the feedback!

Obviously the centered text in system preferences is a mistake and will be fixed ;)

Issues raised by comment 97 will be fixed too

Jonathan, we are aware of the problems you mention. Solène is working on it
(note that (5) is already fixed by attachment 137415 [details] [review])

Martin, I think a shared branch is an interesting idea, but maybe for later when things are more stable (lots of rewrites/indentation fixes/... at the moment)

Also, we'll probably set up a public instance so that people can test it easily.

Hi!  Is https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=137408 the latest update of the Main Menu?  It seems odd that "Lists" is now on a line with "Advanced Search" and "Item Search," since Lists is very much tied to one's login--it takes one to one's own lists & the lists one has access to.

I like Reports being moved to a column with Tools and Administration.  But the "About Koha" logo seems out of place here--should it be next to the Koha logo at the center bottom of the screen?

I know this is probably only a dream at this point, but it would be great for the user to be able to click/tap-and-drag these buttons to a custom layout based on their login, and to hide less often used ones.  I'd have my top buttons be Cataloging, Authorities, Advanced Search, and Item Search, with my second row of buttons being Serials, Reports, Tools, Administration, and I'd hide the Acquisitions button (and access the module via the pull-down menus at the top).

There's a lovely typo in the pull-down menus at the top, "Catalogage."  Although I do adore the idea that this makes cataloging seem more en-gaging, it should probably match the button that says "Cataloging."  And while I'm at it, can we please standardize Catalog vs. Catalogue, and Cataloging vs. Cataloguing?  Can we just put the "u" in or leave it out everywhere?  I'd say put it in, and drag we USians into the spelling of the international community!  (Next let's work on making us metric.:) )

"Selections pending approval" at the bottom of the left column would be ignored at my library, and would get pushed down by staff client news.  It's something that needs paying attention to--it's a, "Hey!  You!  You need to take care of this!" item, so although I like it over in the column, I'd put it at the top in an alert color, or prefaced with the login name to catch the eye of the user, e.g., for me, "Hello, Heather!  Suggestions pending approval..."

I don't have any comments yet on other areas--I don't really use the Basic Bib Editor, but am eager to see what the Advanced Editor and/or Authorities might look like.

Lovely work!!  So exciting!

As far as accessibility goes, I don't like putting the search input (#header_search) in the header and I don't like removing the text labels for the different types searches and replacing them only with icons.

I have staff that are older and their vision isn't great and relying solely on icons to select the function of the search input is going to be difficult for them.

I'd either like to see a return to the text tabs underneath the search input or, at the very least, making the hint text that appears when you hover over the icons much, much larger.

The bottom line is that I have staff with vision issues that are going to need a bigger search input.  The one in the current iteration of this interface is too small and difficult to read.

I agree with George in comment 94.  I am a visually impaired person who finds this search input display very difficult to read. The input box is not big enough for me to comfortably use it and the icons are too small to distinguish from each other without zooming in.

I prefer the text labels underneath the input (maybe because that is what I'm used to) If the icons could be made much larger and include plenty of space between them that would help a great deal.

Including the input box in the #header_search makes it less prominent to me. I would prefer it to have its own dedicated area of the screen.  Additionally, our library uses the extra white space in the #header_search to add additional links which have streamlined our operations.  Placing the input box here would make us lose that ability.

We have an extremely busy Information Desk at out library so staff being able to clearly see the screen and quickly navigate around while a lot of patrons are waiting for assistance is of prime importance to us.

Think this needs another rebase.. I had a go but there are a lot of template changes going on here so it's non-trivial to get right.

(In reply to Martin Renvoize from comment #106)
> Think this needs another rebase.. I had a go but there are a lot of template
> changes going on here so it's non-trivial to get right.

It's coming soon. Solène has been working on fixes and also on reducing the number of template changes to ease rebase. We'll try to submit an up-to-date patch today.

There are a few other errors highlighted by the QA tool, so please run that provide a follow-up.

Agreeing with the comments of George & Barbara on accessibility & design of the header (comments 104, 105).

Search bar, icon sizes, et al. as presently configured would present *many* issues to staff.

A couple other notes on issues in the current sandbox that are no doubt being worked on:

Patrons page (members-home.pl): layout issues

Lists page (shelves.pl): Template process failed: file error - parse error

Cab Vinton/ Plaistow PL

How hard would it be to implement a expand/collapse feature to display a minimal/full header? I think it would fit everybody's needs.

(In reply to Jonathan Druart from comment #115)
> How hard would it be to implement a expand/collapse feature to display a
> minimal/full header? I think it would fit everybody's needs.

If the logic of not having text labels on the buttons is to make the interface responsive, perhaps the labels could appear on desktops but switch to icons only on smaller screen sizes?

(In reply to Benjamin Daeuber from comment #116)
> (In reply to Jonathan Druart from comment #115)
> > How hard would it be to implement a expand/collapse feature to display a
> > minimal/full header? I think it would fit everybody's needs.
> 
> If the logic of not having text labels on the buttons is to make the
> interface responsive, perhaps the labels could appear on desktops but switch
> to icons only on smaller screen sizes?

I like both ideas. 

Maybe it would work better if the select options would be below or above the search form again. 

Another thought here: there is not much room currently for additional links added by IntranetNav. A longer register name or library name would also take up more space - if we leave a bit more space, we could fit these better too.

Addressing accessibility concerns presented by others, I have to second this. If categories on the home page are no longer neatly grouped, navigation and orientation will take longer and I anticipate my staff having difficulty with this. In present format, eyes do tend to drift across the page.

I have done a bit of cleanup in the patch and split it in more logical patches. I tried to remove all template changes that were not necessary. Hopefully it will be easier to review.

There are some changes too (non-exhaustive list):
- The search bar in the header has been "fixed". It's still the same with the same accessibility issues mentioned earlier, but at least it should be displayed correctly on all pages, even when the search form have more than one input. There was some JS code used to fix sizes and positioning, it's gone. All positioning is done in CSS only now
- The main page regained its old appearance (only colors are different).
- The circulation home page went back to old boring links (still WIP)
- There was some "UIKit" icons added in the previous patch, but only two of those were used, and those two have an equivalent icon in FontAwesome (arrow-right and sliders). I decided to remove all UIKit icons from the patch and use FontAwesome instead.
- QA tests are green :)

There is still work to do, but you can already have a look at it on the sandbox: https://staff-bug30952.sandboxes.biblibre.eu (user/password as usual)

I also set up a github repository here: https://github.com/jajm/koha-staff-interface-redesign
I think it can be useful to organize feedbacks/decisions:
  - If you see something that need to be fixed you can open an issue https://github.com/jajm/koha-staff-interface-redesign/issues/new
  - If you want to discuss something, you can create a new discussion https://github.com/jajm/koha-staff-interface-redesign/discussions/new

The search bar is always returning to "Check Out". If I do a catalog search, the bar will return to "Check out" and I need to manually return it to "Search Catalog" each time. Also, I think the entry in that bar should persist even as you switch contexts (so if I type something in and realize it's on Check out, I should be able to switch to Search and not retype).

The floating search header bar has a transparent background, meaning that as items scroll underneath it, you can no longer read the bar properly.

Moved my comments to the github issues board.

I've taken a different approach regarding the next step with this work. I think we should be working with a set of templates with as few changes as possible as we adjust the CSS. I think reducing template changes is going to make testing easier. Some template change reversions can be replaced with CSS changes. Others can wait until we have more consensus about the design in general.

https://gitlab.com/koha-dev/koha-dev/-/commits/wip-bug-30952-staff-redesign

Owen, I took one of your patches for removing for undoing changes to the breadcrumb, but I didn't take the last patch like I said I would do. I believe it tries to fix things that are already fixed, and for the home icon I changed the CSS to use the FontAwesome icon instead (looks better than the inline SVG IMO)

Sandbox recreated will all patches: https://staff-bug30952.sandboxes.biblibre.eu

(In reply to Julian Maurice from comment #145)
> Sandbox recreated will all patches:
> https://staff-bug30952.sandboxes.biblibre.eu

I've posted the link into the discussion on the mailing list - thanks a lot for setting this up!

A couple of alternative ideas for the search header:

https://imgur.com/a/HRwtZQH

I like those alternatives much better, especially having the search input box separated from the header. Having text as opposed to icons is important to our busy information desk staff. This makes sense to me both stylistically and functionally.

I like "Horizontal search header form with forms inline with each button" alternative. Good work.

Thanks Michal. That's the one I prefer too. At first I was concerned about it being confusing for users accustomed to the static tabs (always in the same place no matter which form is selected) but now I think it might be useful to have the visual clue of the position of the form to help the user orient themselves.

(In reply to Michal Denar from comment #149)
> I like "Horizontal search header form with forms inline with each button"
> alternative. Good work.

Same for me.

This change is quite complex, we may want to separate it on another bug report so that this one may go faster.

(In reply to Fridolin Somers from comment #151)
> (In reply to Michal Denar from comment #149)
> > I like "Horizontal search header form with forms inline with each button"
> > alternative. Good work.
> 
> Same for me.
> 
> This change is quite complex, we may want to separate it on another bug
> report so that this one may go faster.

Not sure if this is ready to be pushed with our without the changes to search bar, but not sure if we should rush things. The search bar is probably the most important bit to get right.

I like the second option better too.  Would love to see a mock-up that includes IntranetAddMastheadLibraryPulldown and IntranetCatalogSearchPulldown.

Hello all,
There are around 12 issues that have been risen on https://github.com/jajm/koha-staff-interface-redesign/issues
Most are bugs, Julian will take care of them in the next 2 weeks.

Regarding the search bar, I'm very reluctant to change things :
- it has been discussed in web meetings before the development. Changing things now is a little bit unfair
- maintaining the branch is a pain : every patch with something in a template requires a rebase. Thus, the earlier the whole thing is pushed, the better it is. It will also let us time to find any unseen bug.
- we can always discuss & adjust the search bar after the main merge

At the end, my proposal would be:
- Julian Fixes bugs
- we merge the patch as soon as possible, with the goal to have it for 22.11.
- we open a separate bug for the search bar. Maybe comments from libraries using the proposed version will also help us find the best possible solution. I'm planning to continue BibLibre effort in order to modernize the staff interface.

PS in case you missed the information: Solene is no more with us (back to school)

(In reply to Paul Poulain from comment #154)
> Hello all,
> There are around 12 issues that have been risen on
> https://github.com/jajm/koha-staff-interface-redesign/issues
> Most are bugs, Julian will take care of them in the next 2 weeks.
> 
> Regarding the search bar, I'm very reluctant to change things :
> - it has been discussed in web meetings before the development. Changing
> things now is a little bit unfair
> - maintaining the branch is a pain : every patch with something in a
> template requires a rebase. Thus, the earlier the whole thing is pushed, the
> better it is. It will also let us time to find any unseen bug.
> - we can always discuss & adjust the search bar after the main merge
> 
> At the end, my proposal would be:
> - Julian Fixes bugs
> - we merge the patch as soon as possible, with the goal to have it for 22.11.
> - we open a separate bug for the search bar. Maybe comments from libraries
> using the proposed version will also help us find the best possible
> solution. I'm planning to continue BibLibre effort in order to modernize the
> staff interface.
> 
> PS in case you missed the information: Solene is no more with us (back to
> school)

It feels to me that it is getting too late in the 22.11 cycle to push this and still have time to work out any unseen bugs. Would it not be more prudent to have this ready for a very early push to 23.05? That way we would have ample time to work out those bugs?

(In reply to Lucas Gass from comment #155)
> Would it not be more
> prudent to have this ready for a very early push to 23.05? That way we would
> have ample time to work out those bugs?

Agreed. 

Also, the search bar is arguably the single most important interface piece in all of Koha. It's interacted with hundreds of times a day here so getting it right is an absolute must, in my opinion.

It will be the decision of the Release Manager.

Maybe I'm optimistic, but I prefer to keep in mind the 22.11 goal, knowing it's optimistic, and not say "well, we've 6 more months", and let the topic fall in a pit.

All github issues were addressed in the last patches, at least partially *
All patches are rebased on master and the sandbox was rebuilt: https://staff-bug30952.sandboxes.biblibre.eu/cgi-bin/koha/mainpage.pl

Please test and give feedback.

About the search bar, Owen, where is the code ? :) I'd like to test it.
Personally I prefer the "static tabs" alternative. It's weird to see the text input move from left to right. Also some buttons are always on one side of the input, while other buttons can be on either side, depending on which form is selected. It's a little bit confusing.

* there are still contrast issues - see https://github.com/jajm/koha-staff-interface-redesign/issues/10 - which requires more work

(In reply to Julian Maurice from comment #185)
> About the search bar, Owen, where is the code ?

https://gitlab.com/koha-dev/koha-dev/-/tree/bug-30952-search-redesign

I just rebased it on your latest patches.

Was it agreed upon to not use the tab design from the original work?

What we have now: https://snipboard.io/A9SOz7.jpg

What it would look like with the original style: https://snipboard.io/2FJSnl.jpg

(In reply to Owen Leonard from comment #187)
> Was it agreed upon to not use the tab design from the original work?
> 
> What we have now: https://snipboard.io/A9SOz7.jpg
> 
> What it would look like with the original style:
> https://snipboard.io/2FJSnl.jpg

+1000 for the "now" version !

As a middle ground for the search bar changes stuff as it appears to be the most contentious part..  I re-read the comments on the Mock-ups and Myka's comments seems really relevant.

> Can having the persistent search at the top throughout the site continue to be an option (toggle on/off) in admin settings?

We could fairly easily get the best of both worlds as an interim option.. with a system preference that either embeds the search stuff in the top header OR uses Owens separate bar as the alternate option... Thoughts?

(In reply to Paul Poulain from comment #188)
> (In reply to Owen Leonard from comment #187)
> > Was it agreed upon to not use the tab design from the original work?
> > 
> > What we have now: https://snipboard.io/A9SOz7.jpg
> > 
> > What it would look like with the original style:
> > https://snipboard.io/2FJSnl.jpg
> 
> +1000 for the "now" version !

I raised a github issue for this.. I think there's more to it than just the tab based nav.. the card layout isn't as the mock-ups suggested either and I think that lack of cards causes some of the difficulties Jonathan D and I raised regarding the right aligned toolbar buttons and lack of toolbar background making the buttons lose natural focus.

https://github.com/jajm/koha-staff-interface-redesign/issues/17 and https://github.com/jajm/koha-staff-interface-redesign/issues/8

PTFS-E have a group of us scheduled to go through the new UI this Friday (9th September).. hopefully, it'll yield lots of good feedback and help drive this through.

(In reply to Benjamin Daeuber from comment #156)
> (In reply to Lucas Gass from comment #155)
> > Would it not be more
> > prudent to have this ready for a very early push to 23.05? That way we would
> > have ample time to work out those bugs?
> 
> Agreed. 
> 
> Also, the search bar is arguably the single most important interface piece
> in all of Koha. It's interacted with hundreds of times a day here so getting
> it right is an absolute must, in my opinion.

I think we can not release without this being fixed. There was a lot of feedback on exactly this piece from librarians on the mock-ups. We can not just ignore that.

I'd also like some tests done with different languages including non-latin ones.

The last patches contain a few bugfixes related to https://github.com/jajm/koha-staff-interface-redesign/issues/17 and the move of the search bar. It looks like this now : https://snipboard.io/ioTBnV.jpg
This is close to what Owen did, but with all the tabs on the left, and I kept the icons

Which one do you prefer:
- All tabs on the left ?
- All tabs on the right ?
- Form in between tabs ?

With or without icons ?

@julian : am I wrong or the sandbox has not been updated with the last patch ?
https://staff-bug30952.sandboxes.biblibre.eu/
(however: I like the screenshot, more than the search inside the menu: more clear and less risk of overwriting something with too many information on the menu line)

(In reply to Paul Poulain from comment #198)
> @julian : am I wrong or the sandbox has not been updated with the last patch
> ?
> https://staff-bug30952.sandboxes.biblibre.eu/

I'm surprised it still exists because it is not listed on the sandboxes page... (so we cannot delete it :/)
I'm not sure what's happening with the sandboxes but I decided to not use them anymore as they tend to break after some (short) time.
So you're right, the sandbox is not up to date.

If you want an up-to-date version you have to create a new sandbox.

I summarized the search bar options in a poll on github: https://github.com/jajm/koha-staff-interface-redesign/discussions/34
Please vote :)

> If you want an up-to-date version you have to create a new sandbox.

Are we supposed to use the patches here or the git branch? If the git branch: how can I set this up on the sandbox? I failed spectacularly last time I tried the use the branch options in the sandbox form.

I update both at the same time, so you can use the method you prefer (or in that case, the one that works ;))