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

[Mike Rylander]

Dan,

Thanks for all of this.  Pushing everyone to think about the broader
context of user interaction types and expectations is /very/
important.

My thoughts on this basically boil down to a few simple rules of thumb
we could follow:

 *) if the interface component brings you to a screen that shows a
related but different object type, or expose actions whose focus is
something other than the currently displayed object -> use a link that
looks like a link (and is just a link, with all native click/modifier
combinations) ... Example: going from the patron items out list to the
item detail UI
 *) if the interface component shows more/less detail for the
displayed object, exposes actions whose focus is the displayed object,
saves or cancels data entry actions, or brings you from a list of
objects to a UI focused on an instance of the listed objects -> use a
button (or image) ... Example: going from the patron alert screen to
the patron edit screen.

Now, in-UI "tab" headings, like in the patron UI, are something in
between these two.  In that case, using a link that goes bold (instead
of underlined) on mouse-over -- or a similar visual cue -- makes sense
to me.

Obviously these don't cover everything, and my rules of thumb might be
wrong in may ways, but I offer them in the hopes of seeding a set of
guidelines as you suggest.

Thoughts, anyone?


On Wed, May 21, 2014 at 7:00 PM, Dan Wells <dbw2 at calvin.edu> wrote:
> 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
>
> | web: http://esilibrary.com
>
> | Equinox Software, Inc. / The Open Source Experts
>
>



-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com