[OPEN-ILS-GENERAL] Web Client Design - Fixed Page Elements?

[Kathy Lussier]

Hi Terran,

The menu stays fixed at the top of the screen in mobile view, but, 
otherwise, I didn't change the current way that the menu responds on a 
smaller screen.

https://drive.google.com/file/d/0B74gDMUDwDXqVDhXaXhxQUd0c2c/view?usp=drivesdk

Kathy

On 07/22/2015 01:47 PM, McCanna, Terran wrote:
> 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
> tmccanna at georgialibraries.org
>
>
> ----- Original Message -----
> From: "Kathy Lussier" <klussier at masslnc.org>
> To: open-ils-general at list.georgialibraries.org
> 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
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier