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

Wed Jul 22 13:43:07 EDT 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20150722/c58d398f/attachment.html>