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 <[email protected]> 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: [email protected] > [mailto:[email protected]] 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: [email protected] > > | 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: [email protected] | web: http://www.esilibrary.com
