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

Wed Jul 22 15:07:02 EDT 2015

+1, like it. 

Lynn Floyd 
 <mailto:lfloyd at andersonlibrary.org> lfloyd at andersonlibrary.org 
Anderson County Library 
864-260-4500 x181 
 <http://www.andersonlibrary.org/> http://www.andersonlibrary.org 

From: Open-ils-general
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Kathy Lussier
Sent: Wednesday, July 22, 2015 1:43 PM
To: open-ils-general at list.georgialibraries.org
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=sharin
g

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-navig
ate/

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_nkn0o
kinXl1t572gy.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/3fcce78e/attachment.html>