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

[Bill Erickson]

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.
>

Agreed.


>
>
> 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.
>

Agreed this is unclear.  More below...


> Also, why link on barcode?  What is the analog in, say, a list of serial
> items attached to a unit?
>

Hmm, why not link on barcode?  We should link on serial items, too, if a
URL exists which uniquely represents the item.  I'd like to see every
occurrence of objects like copies, records, users, etc, .etc. which have a
dedicated page of some sort presented as links so staff can easily
ctrl-click to pull that information up in a new tab a la Wikipedia.


>
>
> 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.
>
>
>
Indeed, I didn't do a great job of explaining what types of link I was
mainly referring to in my post.  Here's a small brain dump to add some
context.

4 general categories of link come to mind:

1. Links with href values which refer to pages within the same application.
 The <a> tags will have no target, which tells Angular the links should be
activated as push-state URL swaps (no server page load).  A typical example
would be tab navigation links, whose behavior I think is pretty obvious,
but I could also imagine bare-text links, which are non-obvious, referring
to in-app resources as well.

Such links should be designed to function when loaded directly from the
server, but also benefit from being able to maintain state (via Angluar
services) when navigating within the application.

2. Links with href values which refer to pages within the staff client as a
whole, but to a different sub-application.  These <a> tags have a
target="_self" value, which tells Angular to load them from the server and
not as a push-state URL swap.

As developers, we should make every attempt to ensure that these two types
of links are indistinguishable, i.e. navigating directly to
/eg/staf/patron/123/bills should work even when accessed from an external
site, where no existing state is available.

However, because #1-style links can maintain state, there will invariably
be differences.  For example, we cache patron search results which remain
cached until the user navigates away from the egPatron Angular application.
 (Note, we could perform user searches via URL params, which would allow us
to avoid caching, but that approach won't be reasonable for every type of
state maintenance).  In this case, there is a noticeable difference between
clicking on another tab in the patron UI and clicking on the barcode link
in the grid, which takes the user out of the egPatron app and into the
egItemStatus app.  Once in the egItemStatus app, clicking the back button
will return the user to the egPatron app, but the previously cached search
results will be gone.

3. Links which perform some action within the current page but do not
affect the URL.  These have an empty href value and are driven by onclick
(ng-click, etc.) handlers.  These links perform nonsense actions when
ctrll-clicked, etc., since empty URLs default to the global base path,
which takes the user to the home splash page.

We have previously discussed indicating links of type #3 by always making
them appear as buttons instead of bare text links.  This is done in many
cases, but not all, as you've pointed out, Dan.  However, the column
sorting links, for example, would probably look... odd as buttons.  Maybe
they should be a different color, different font, etc.?

[Column headers get even more interesting when we consider that some
columns will support server-side sorting and some won't, so they may need
an additional layer of differentiation].

4.  Links to external sites.  These will be rare and I think it's
reasonable to open them in a new tab by default.

Assuming that #3-type links can't always be rendered as buttons, do we need
4 different ways of indicating link behavior when the behavior is not
obvious?  (BTW, i consider the behavior of navbar links, tab links, column
headers, and generally any standard, repeated navigation or UI control link
to be obvious, but there may be some room for debate there.  Button's fall
into this group as well if we all agree that buttons mean do-not-navigate).


How shall we differentiate?  Styling is an obvious choice.  We could
alternatively (or also) append small glyphicon (
http://getbootstrap.com/components/#glyphicons) to each text link as a way
to indicate link behavior.  For example, see the barcode links in the grid
at https://bill-dev2.esilibrary.com/eg/staff/circ/patron/7/items_out  (I
think the use of the "Random" glyphicon is somehow apropos ;)  The
squiggles in this example say, "ctrl-click this link if you want to retain
your work in progress, otherwise click as usual".

Thanks for all your thoughts and input, Dan.  Making the behavior obvious
will be a huge usability win.

-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/20140522/9e7454ad/attachment-0001.htm>