I love it! Does it scale nicely to small screens?
Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 [email protected] ----- Original Message ----- From: "Kathy Lussier" <[email protected]> To: [email protected] Sent: Wednesday, July 22, 2015 1:43:07 PM Subject: Re: [OPEN-ILS-GENERAL] Web Client Design - Fixed Page Elements? Hi all, I just wanted to report back that I submitted something in LP with some code attached to make the main navigation menu a fixed element. The LP bug is available at https://bugs.launchpad.net/evergreen/+bug/1474455. A small screencast showing the new behavior for the navigation menu is available at https://drive.google.com/file/d/0B74gDMUDwDXqWWFLbDhLV3p3bzg/view?usp=sharing Kathy On 07/10/2015 03:14 PM, Dan Wells wrote: > > Hello all, > > This came up in Kathy’s recent thread asking about the patron editor, > and rather than hijack that thread, I’d like to broaden the > conversation a little, because the same usability issues will affect > many areas of the staff client. > > To cut straight to the point, I strongly believe that using fixed > position for large portions of the staff client interface will have a > major positive effect on usability. This has been applied and proven > in desktop applications for decades, and is now being rediscovered > within the browser environment as web “pages” become applications. > There is plenty of evidence out there to support this stance, but here > is a quick read which highlights the point well: > http://www.smashingmagazine.com/2012/09/11/sticky-menus-are-quicker-to-navigate/ > > If we consider the mockups from our design internship a few months > back, in the screenshot Kathy referenced, the entire top area (and, in > this case, the right sidebar) would ideally be fixed position. The > only scrolling area should be the actual form. For any who attended > my talk on design at the conference, this is exactly the concern of > rule of thumb #3: “Scroll the data, not the interface”, with “data” > broadly including all information and workspaces which are not “the > program”. (Here is Kathy’s screenshot link again for reference: > http://media.tumblr.com/69beec7802a938b889bdfa80c7e0d54b/tumblr_inline_nkn0okinXl1t572gy.png > > ) > > The main complaint driven at fixed screen elements is that they take > up too much space. They do take up space, obviously, but with the > amount of use these elements get on a moment by moment basis, the > space is well worth taking. In cases where more workspace is truly of > benefit, we are better off using fixed position with a “hide” option > (auto or manual) than we would be with using scroll, as we can retain > the clear benefits of persistent availability and predictability. > (Expert users might also choose to do without some toolbars and rely > on keyboard shortcuts, but that sort of use will never be feasible for > many staff client users and scenarios.) > > As the Smashing Magazine article points out, the easiest way to > understand the situation is to simply imagine other software working > with fully-scrolling interfaces. In this imaginary scenario, when you > are using a word processor, a spreadsheet application, or even a > browser itself, all of your menus, toolbars, tabs, etc., would simply > scroll off the screen as soon as you tried to scroll down to see > additional content. It’s likely that some ancient desktop software > did exactly that, but if they did, they are now extinct, and not > without good reason. > > Another valid concern sometimes raised is the effect a rich, fixed > interface might have on a small screen appliance, like a phone. This > topic should be addressed, but I believe it is best kept separate from > the problems at hand, which are already large enough. My personal > stance would be that a full, first-class staff client interface on a > small screen device is not a realistic concern for a community of our > size, needs, and capabilities. Our bar for using the full client on > phones should be “not impossible”, and then we can re-dedicate a > portion of our energy to creating limited, purpose-built interfaces > for functions of known value on small devices (e.g. inventory > scanning), and which are also likely to best include some fixed top > and/or bottom elements. > > I also want to emphasize that none if this is meant to disparage the > work which has been done so far. It is much harder to make something > out of nothing than to take something and make it better. I also > acknowledge that, while I have spent large amounts of time studying > the web client, I have found zero time to contribute to the actual web > client code. That said, if we can help establish consensus around > where we want to end up, I know I would feel more comfortable jumping > in, and I suspect others might as well. > > Sincerely, > > Dan > > Daniel Wells > > Library Programmer/Analyst > > Hekman Library, Calvin College > > 616.526.7133 > -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 [email protected] Twitter: http://www.twitter.com/kmlussier
