web client: usability with some menus at bottom of screen

[Kathy Lussier]

This is a follow-up to some comments made in bug 1695062 and bug 1464767. We have some dropdown menus in the web client, which, when activated, drop below the bottom of the screen, creating usability issues with use of those menus. Examples include,

* Menus to select user stat cats at the bottom of the patron registration screen.

* The holdings view of a bib record, when no holdings display on the screen (see screencast at https://drive.google.com/file/d/0B74gDMUDwDXqTmhRYzc4b04wZDg/view

* The Z39.50 actions menu.

Space needs to be created at the bottom of those pages or some other mechanism needs to be used so that the menus display in their entirety when they are in use.

Overall, even when there isn't a menu at the bottom of the screen, I often feel like more padding at the bottom of the screen would be beneficial.

[Kathy Lussier (klussier)]

See also related bug 1669120

[Kathy Lussier (klussier)]

Jason Boyer said he had added 2 inches of padding in base.tt2. This much space at the bottom has been sufficient in my test cases to display the entire menu, but my test stat cat menus are fairly small. Also, 2 inches looks like a lot of space in interfaces where it really isn't needed.

I found that adding a style for the body tag for 50px of padding at the bottom of the page provided good breathing room at the bottom of the page without appearing to be too much white space. However, it didn't help with our menu situation.

Adding a dropup class to the Actions menu in the Z39.50 interface might be a good idea since this menu is located towards the bottom of the page. I think this would work for the reports action menu and maybe even the record holdings view action menu (I'm on the fence with this one). It would be nice if there was a way for the menus to either dropup or dropdown depending on the screen space available.

The menus for the stat cats are different, and I haven't figured out yet how I could get those to drop up.

[Kathy Lussier (klussier)]

I don't know if my approach is 'correct', but it seems to work. I have a working branch at

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1706415-improve-bottom-of-page-menu-usability

The branch does the following:
1. Adds the dropup class to the action menus on the Z39.50 page and report templates editor so that the options appear above the menu rather than below. The same class was also added to the stat cat menus at the bottom of the patron registration screen.

2. Adds some space at the bottom of the page on all web client screens. With the dropup class, this additional space isn't required for the menus to display properly. However, without the padding, the interfaces feel a little more crowded.

This branch does not address another issue I discovered with the right-click context menu falling below the screen when used on the bottom row of a grid.

If anyone wants to look at it, I have loaded the branch on https://mlnc1.noblenet.org/eg/staff/home. You can log in with admin / evergreen123.

I have added some user stat cats to that server so that you can see the patron registration fix without too much work. For the Z39.50 screen, you can best see the issue if you do an ISBN search that only retrieves on result in the bottom grid.

For comparison, the MassLNC demo server at https://mlnc2.noblenet.org/eg/staff/home shows current behavior.

[Mike Rylander (mrylander)]

I was looking around and it seems someone has managed to find a good solution for this.
 Coming from https://github.com/angular-ui/bootstrap/issues/1317 there's a plunker at http://plnkr.co/edit/wzrfiP0vsvgkg3McUvh0?p=preview that seems to do what we want dynamically. Should we consider going this way?

[Mike Rylander (mrylander)]

There's also the answer here https://stackoverflow.com/questions/41446122/make-dropdown-menu-go-upwards-if-it-is-at-the-bottom-of-the-browser-window-auto that may be useful, especially on grid-generated dropdowns and context menus.

[Kathy Lussier (klussier)]

Oh, yes! I would definitely prefer to go in the direction of something that handles this issue dynamically.

[Kathy Lussier (klussier)]

Adding a note that regardless of what we do with the dropdown menus, I still would like to add the additional padding at the bottom of the page to give us some breathing room. Maybe I'll pull that commit out from the rest of the branch and submit it in a separate LP bug.

[Bill Erickson (berick)]

The pop-up menus work for me. There is one issue with the body padding, though. It creates a permanent scroll bar in the patron interfaces (checkout, items out, etc.), likely because of the fixed-height stuff we added to implement the fixed tabs in the patron UIs.

It's more of an annoyance than a functional issue, but thought it worth mentioning.

[Terran McCanna (tmccanna)]

Just adding a note that we're seeing this problem on the patron edit screen if there are survey questions with drop downs as well.

[Bill Erickson (berick)]

Re: my scroll bar comment, it's not actually permanent. It's there because the patron summary extends almost to the bottom of the page and the padding pushes it barely past the end of the page. If I change the padding to 45px or hide the side bar or change the browser dimensions or add a visible blocking penalty, I can make it appear and disappear. So, really, it's doing what you'd expect given the content in the page.

[Kathy Lussier (klussier)]

I took another look at this code to see if we might want to consider the dropup menus as a temporary measure while we work on getting the dynamic menus in. However, upon testing, I noticed the dropup menus for patron stat cats made no sense for sites that use surveys, since the surveys display below stat cats. IOW, menus that drop up or down dynamically depending on where they land on the page really does seem to be the way to go. I'm going to create a new bug for the additional padding so that we can get the padding in sooner rather than later.

[Janet Schrader (jschrader)]

It doesn't look like anyone has touched this in a year. This problem came up on a survey we did about moving entirely to the web client. I'd like to revive this and see if anything can be done about the dynamic menus.

We are on release 3.2.8 and have some catalogers still using xul because of the drop-down menu being below the screen. For a city library cataloging for branches, in holdings view, right clicking to edit items or add items to a branch the there's not only scrolling down the menu but scrolling down the page to get to Action menu choices at the bottom of the list.

[Courtney Brown (courtney.brown)]

Since upgrading to EG 3.7, Cataloging Staff have reported running into similar issues when displaying the actions dropdown menu to edit items in the holdings view of the bib record. Whether using the dropdown Icon at the top right of the grid list display or by right clicking the selected item(s) directly from the grid list to apply the needed edits, the menu closes as staff attempt to scroll down the drop down menu to select actions toward the bottom of the menu.

[Jennifer Pringle (jpringle-u)]

In 3.9 if you have a horizontal scroll bar it blocks the last option on the actions menu in Holdings View (Transfer Items to Marked Destination). If you can expand your screen until the horizontal scroll bar disappears you can then see the final option but that won't be an options for everyone.