[OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback requests

[Dan Wells]

Hello Bill,

Thanks for the update.  I have some thoughts about both of your questions, but will focus on the link issue for now.

I’m not quite sure how to answer because I feel like we’re not asking the right question.  Rather than ask how links should behave, we might instead ask, what should be a link?  And also perhaps the inverse; in our interface, what should a link be?

As an experiment, I tried to look very critically at a familiar and popular interface: Gmail.  In the parts I would consider to be the everyday interface, you’d be hard-pressed to identify anything as a link.  In fact, the only things I could find which actually are links are the main sidebar options (Inbox, Starred, etc.), and even those don’t present themselves as links.

On the other hand (and recognizing the current code is a work in progress), consider our use of links in the patron search.  We have links both for column sorting, and also a link on the row numbers.  Neither of these currently do anything useful when right-clicking and opening in a new tab.  The row number links could, I imagine, but the column header links make little sense in that context.

The simplest argument, then, is that those shouldn’t be links, but that gets to the heart of what I am trying to say.  We are taking something which is fundamentally a website concept (a link between pages) and applying it to an application, and we need to very careful that we don’t misapply a web-centric mindset to any areas where that thinking isn’t appropriate.

Back to Gmail, in my experience, every link *within* an email opens in a new tab.  This prevents you from losing your Gmail context.  I think this is a very sensible behavior, and would even say it is the correct behavior for external links.  In my opinion, we should do the same, at least by default.

My sense, though, is that you were not really asking about external links which might exist in our content, but rather “internal” links (which I will define as a link to a new context in the staff client).  These are trickier.  To help our thinking, I wish to posit that on any given screen, we have both a context and a state.  The URL always captures the context, and sometimes some aspects of the state, but we cannot expect it to always capture every aspect of the current state.  Because of this fact, every time you switch contexts, you risk losing some state.  Therefore, we should be very careful to offer any interface element, link or otherwise, which switches context without a clear indication to the user of that intention.

To help illustrate the idea, I don’t feel the linked barcode in the “Items Out” table passes this test.  It isn’t clear that that link is going to change my current context.  It might not matter much in the patron context, since there isn’t much state to lose, but that won’t always be the case in every context.  Also, why link on barcode?  What is the analog in, say, a list of serial items attached to a unit?

Instead of thinking of things as “links” and then trying to make one rule for a bunch of disparate things, I’d propose that we should have distinctive interface elements for which we can then define usage appropriate behaviors.  Doing so would create a tremendous opportunity for improving the overall usability of the staff client as a whole.

I could say more, but I’ve said a lot already.  I’d love to hear reactions to what I’ve said so far (which I know is very uneven given the time and space limitations).  Am I way off-base?  Or is this the beginning of something we can work with?

Thanks,
Dan

P.S.  Bill, I think you are doing an outstanding job, and we couldn’t even have this conversation without all the work you have done to pave the way.  Please don’t take anything above as being critical of the hundreds of decisions you’ve had to make to get to where we are today.  Again, thank you!


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133

From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Bill Erickson
Sent: Monday, May 19, 2014 5:01 PM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback requests

http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_notes#section20140519

I have feedback requests for patron horizontal vs. vertical display and link (<a>) behavior.

Thanks,

-b

--
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: berick at esilibrary.com<mailto: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/20140521/b815ac0c/attachment-0001.htm>