webclient: patron summary should scroll separately from patron search results

[Kathy Lussier]

When scrolling through patron search results in the web client, the vertical patron summary scrolls at the same time, leading to the following possible steps when staff looks through a set of results:

Click on a patron name to see his/her info in the patron summary.
After realizing it's not the patron they are looking for, they scroll down the page to find another patron further down.
Click on the next patron, now scroll up to see the info listed at the top of the patron summary.
Scroll down again to go to the next patron in the list.

See screencast at:
https://drive.google.com/file/d/0B74gDMUDwDXqckFuTUc3ZlFZSDg/view

Ideally, the patron summary would scroll separately from the data that's on the right side of the screen.

[Bill Erickson (berick)]

I'm guessing we want the same behavior on every tab within the patron interface? In other words, the summary pane along the left and the navigation tabs along the top are always locked into place and only the content pane (search results, bills list, etc.) scrolls.

[Kathy Lussier (klussier)]

Yes, I think it makes sense to keep the behavior consistent and have the summary pane locked for all tabs.

[Terran McCanna (tmccanna)]

I agree with Kathy on the desired behavior.

[Jane Sandberg (sandbergja)]

I created a branch that allows the two sides of the screen to scroll separately. It is called user/sandbergja/lp1527756_separate_scrolling_in_patron_summary

Here's a link: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1527756_separate_scrolling_in_patron_summary

And here are the testing notes from the commit message:

1) Without this patch, do a patron search with a lot of results in a
browser window that is not very tall on a laptop or desktop computer.
2) Click on a search result.
3) Scroll down. Note that the patron summary on the left side of the
screen also scrolls down at the same time.
4) Apply this commit.
5) Repeat steps 1-3. Note that the patron summary has a separate
scrollbar and does not scroll along with the right side of the screen.
6) Confirm that the behavior you saw in step 5 is true across all of the
patron record tabs (e.g. Check Out, Items Out).

[Terran McCanna (tmccanna)]

This looks good in most situations, but I notice that when I enter a really, really long preferred name, it causes the summary section to widen and go behind the right-hand section. (If I narrow the entire browser window, it wraps nicely, but it doesn't wrap nicely when it's open wider.) Screenshot attached.

[Terran McCanna (tmccanna)]

Long alert messages that appear on the patron summary bar also cause weird overlapping / non-wrapping problems.

[Jane Sandberg (sandbergja)]

Thanks for the testing, Terran! I'll remove the pullrequest tag and take a look.

[Jane Sandberg (sandbergja)]

I did not have a chance to look at this further. I'm unassigning myself.

[Bill Erickson (berick)]

Looking ahead to when we Angularize this UI and potentially tweaking the existing code, I propose we take more of a gmail-style approach with the patron UI in general, where scrolling is limited to the variable data portion of the page. The navigation / patron summary parts sit along the left and top as before, and the scroll only affects the body of the page (search results, checkout grid, patron register UI, etc.). Using the gmail example, only the list of messages scroll, not the page as a whole.

Anything that needs to stick to the top (e.g. patron UI Save actions) can sit just above the scrolling div and they won't be affected by any scrolling.