[OPEN-ILS-GENERAL] Interface Ideas Mockup

[Bill Erickson]

On Thu, Jun 5, 2014 at 3:30 PM, Dan Wells <dbw2 at calvin.edu> wrote:

> Hello all,
>
> This email is a continuation of the thread from a few weeks ago discussing
> overall usability and flexible design for the web staff client.  I was
> encouraged by the thoughtful replies in that thread, and hope we can build
> some momentum.  That thread was focused on link behavior, but I want to
> broaden the conversation a little to better illustrate a few points.
>
> Attached is a mockup of a few interface ideas which I think we should
> consider going forward.  It isn't an endpoint, but I do believe it is a
> step in the direction we need to go.  I'll begin with a quick overview of
> the new elements, then a brief discussion of the principles they are
> working toward.
>
> First, there are two new interface features illustrated here.  In keeping
> with some other current interface environments, I am calling them "action
> bars".  More specifically, I am proposing that our list (i.e. table)
> interfaces consistently offer two action bars, which I have been calling
> the "List Action Bar" and the "Column Action Bar".  Though I am
> demonstrating with the "Items Out" list, our goal should be to develop and
> adopt conventions which are broadly useful across the majority of our
> interfaces.
>
> Beginning with the "List" (or "Table") bar (the new buttons above the main
> list, aligned right), we can notice a few things.  First, two actions are
> readily visible, and one is highlighted in blue ("Print Receipt").  Other
> actions would be accessible from the menu icon (aka "hamburger" icon) on
> the right side (making it a direct replacement for the "Actions..." menu).
>  For this "List" bar, the highlighted action signifies the "default" action
> of the list, which is the action which will happen when double-clicking a
> row.  Ideally the end-user will be able to configure which actions are
> always visible, and also which action is the default action for the list,
> but I expect we would rely on reasonable defaults to start.
>

I really like this.


>
> Moving on, directly below the title row of the list we have the "Column"
> bar.  This bar serves several purposes.  First, we again have a visible
> action label.  These labels express the result of clicking the links in
> their associated column, possibly including the default window behavior
> (e.g. the "arrow" icon for opening in a new tab).  They might also be used
> as buttons for direct access to secondary actions when selecting multiple
> rows.  Next to each column action is another "menu" icon for configuring
> the exposed action, giving the user additional actions appropriate to the
> object the column represents.
>

So, for example, one user might have the link go the Item Status page and
the action label of "View Item" and another user might have the link jump
to the Edit Item page with an action label of "Edit Item"?


>
> I think a setup like this would have great potential to meet a wide
> variety of workflow needs, but more importantly, I think it would improve
> upon our current design in one very significant way: visibility.  To
> illustrate, in the previous thread, I asked why we were linking on the
> barcode, and was asked in return "why not link on the barcode?"  The answer
> is that, without a label, the only ways to know what will happen when
> clicking on the barcode is either trial-and-error or inference.  The only
> label we have is "Barcode", so we must first infer that we are talking
> about copies (i.e. items).  Second, we must recall we are in the "Items
> Out" interface, not a cataloging or management interface, so we infer that
> this link will take us to an item status view, not an item editor.  In this
> particular case, it is very likely we will arrive at the correct
> assumption, so the design is not bad.  But can it be better?  And are there
> cases where the results are less inferable?  I believe the answer to both
> questions is yes.


> Visibility is a design principle we must always consider, and whenever
> possible, avoid believing that things will be "obvious."  Even in simple
> interfaces, inference always comes at a cost of both cognitive load and
> room for misinterpretation (sometimes small, sometimes large).  In the case
> of the barcode links, at the cost of a single row of space, we not only can
> know which object the barcode belongs to (the Copy), but also which action
> the link will take (View).  For no more additional cost in space, we can
> know the same facts about the Title column.  Ideally, this action bar could
> be configured to be collapsible when space is at a great premium, or the
> user simply doesn't need it anymore, but I don't think such an option is
> essential to the initial adoption of this concept.
>

Just to be clear, the column labels could be more descriptive.  It was
laziness (and an irrepressible urge to save space) on my part that lead to
a column label of "Barcode" instead of "Copy Barcode" (or "Item Barcode"..
I forget which one we're moving toward).  Similarly, the link behavior
could easily be represented within the column header label.  However, what
we can't easily represent in the column header is the link action, so
that's a big plus for the Column Action Bar.


>
> A second visibility improvement in this mockup can be found in the "List"
> bar.  Some common actions are displayed without any user intervention, and
> the highlight tells (and reminds) the user of the default "double-click"
> action for the list.  While the highlight concept itself is not inherently
> knowable and must be learned, once known, it can potentially be applied
> universally throughout the client.  Consequently, no list behavior will
> remain a mystery regardless of familiarity with any particular interface.
>

I like the space savings of moving the List nav/control bar to the bottom,
but that means users will have to scroll down to control the list when
their page size exceeds the vertical space of the monitor.  Is that
acceptable?


>
> There are still innumerable variations we might consider, such as
> different use of colors, configuration level, or even using the venerable
> downward-pointing triangle instead of the menu icon.  If anyone feels a
> particular additional detail is critical to consider at this point, please
> do bring it up.  Otherwise, what do we think of this proposal?  Is it
> flexible enough to be applied broadly to every interface?  If not, how can
> we improve it further?  Does it solve more problems than it causes?  And,
> perhaps the biggest question of all, is it worth the necessary effort?
>

I'm really liking these so far and the mockup helps a lot.  Thanks, Dan!

-b

-- 
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: berick at esilibrary.com
| web: http://esilibrary.com
| Equinox Software, Inc. / The Open Source Experts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140606/2c446ea3/attachment-0001.htm>