[OPEN-ILS-GENERAL] Interface Ideas Mockup

[Dan Wells]

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.

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.

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.

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.

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?

Thank you all again for your consideration.  I look forward to any discussion about the positives and negatives of these concepts.

Sincerely,
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Action_Bar_Mockup.png
Type: image/png
Size: 73681 bytes
Desc: Action_Bar_Mockup.png
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140605/20131cdf/attachment-0001.png>