[OPEN-ILS-DEV] Features and defaults and navigation (was: [Bug 1261939] Re: Add per-library TPAC pages with schema.org structured data support)

[Dan Scott]

I've forwarded comments from Dan Wells on bug # 1261939 around merging a
new feature; and instead of responding in the bug (which is now closed),
I've put my thoughts below that. There's a mix of discussion around whether
new features should be "on" by default, as well as design how navigation in
the TPAC should work. I was going to respond in the bug, but thought that
it might make more sense to respond on open-ils-dev as the issues apply
pretty generally and a broader discussion is probably warranted.

---------- Forwarded message ----------
From: Dan Wells <dbw2 at calvin.edu>
Date: Tue, Jan 21, 2014 at 3:43 PM
Subject: [Bug 1261939] Re: Add per-library TPAC pages with
schema.orgstructured data support
To: dan at coffeecode.net


I have rebased this branch and pushed it into master.  Thanks, Dan!  I
opted not to squash any commits, as I find seeing the process to be of
value historically, and it all seemed understandably linear to me (with
no commits I'd consider "trivial").

Praises:
- I think exposing this library data in a public way is a very valuable
addition.
- Making it structured data gives it some added value beyond simple
exposure.

Concerns:
- The library "about" links added in 2.5 had the same behavior in both the
results list (show more details) and the details page.  This new feature
only affects the details page, and can therefore lead to some confusing
interface behavior.  It should be easy to add the same logic to the results
page, but it remains a TODO.
- This feature adds a large number of (frequently redundant) links to the
page.  In addition, I don't find it intuitive to predict what these links
will do before I click them for the first time.  I think a number of
installations (mine included) will either not need these links, or will
decide they detract more from the focus of the catalog than they add.
 Unless a feature is a "slam dunk", I am in favor of making it optional
(despite the drawbacks).

Questions:
- Should we consider making some display changes to help clarify the links?
 For instance, perhaps something as simple as a 'title' attribute which
says something like 'See library hours and contact information'?  Or what
about using small icons (with alt text) to identify either the external
links, the 'info' links, or both?  I think if we are consistent with
applying such conventions, we could get a lot of usability with minimal
disruption to the 'normal' flow of the catalog.

I pushed this branch since I felt that all of this could be addressed
(or not, as needed) in an ongoing way.  Thanks again, Dan!

=============================

Response:

Thanks Dan:

(Results page consistency is TODONE at 1271600)

I cannot prove whether this feature is going to be a "slam dunk".
(Hypothetically, Google / Yandex  / Bing could read all of the structured
data this make available from the agent-promise-object model linking copies
to records to libraries and surface richer results to users directly at
their level, given that they know where a user is physically located and
where the libraries & copies are... that would indeed be a slam dunk, and
this feature makes that actually possible, but I'm not going to place bets
on it.)

As far as I know "slam dunk" criteria has never been formally applied to
any previous changesets. Perhaps we should formalize how we make such
decisions and apply it consistently for _all_ new features, otherwise
conflict, hurt feelings, and wasted time may result.

Realistically, though, like most features, this is likely to be warmly
welcomed by some libraries and turned off by others. The power of the
default dictates whether libraries are likely to even be aware of the
feature; if the default is that it is off, then most libraries are unlikely
to ever become aware of the feature; even with excellent release notes, the
difference between "Oh, sounds neat" and "Oh, sounds neat; I'm going to go
into Library Settings and turn that on" is huge.

In addition, if it's made into YAOUS, then they get to deal with
configuration combinations of two different OUS dealing with one relatively
simple set of behaviour around library name links, and we get to figure out
how to test the various combinations thoroughly and figure out how we can
still supply structured data that provides a useful "seller" property for
the offers of copies independently of the choice of configurations... all
of which will complicate the template markup even further.

On redundancy in the copy tables: the existing copy tables already feature
plenty of potentially redundant information--the names of the libraries,
shelving locations, and copy availability. Any redesign seeking to reduce
redundancy should look at the broader context rather than just this
feature-specific narrow part of it.

While hover help via a title attribute or the like might help for desktop
browsers, the mobile browser situation is more complicated. I'll admit that
I shudder a bit at the thought of 90's-era "external link" / "more info"
icons and such for navigation; I think that would clutter up the display
even further. You're right, though, we do have a mix of mystery navigation
currently. Clicking one kind of link starts a brand new search for a single
author; clicking another kind of link narrows the current results down to
the intersection of one or more facets; clicking another kind of link
launches a browse search using the current keyword; clicking the title link
takes you to the record details. Some of this behaviour you're only going
to figure out by trying it, and even then you might be surprised because
it's not necessarily obvious that your existing search terms were used to
seed the browse or advanced search or whatever.

In the case of a linked library name, I guess one could form the erroneous
mental model (informed by experience with facets) that clicking the link
would limit your search to just copies available from that library. Perhaps
one could also form the impression that it would enable some copy-level
action. Are there other possible mixed mental models that you think having
a linked library name would lead to?

I suppose the saving grace (if any) for the per-library TPAC pages is that
the library pages don't launch a new search, so they render extremely
quickly and they look nothing like a search page. They are unequivocally
and very recognizably pages of information about the library that you just
clicked on, so the cost of an erroneous impression about the function of
the link is low; users can simply hit the back button to get back to their
search context if they decide that that's not what they're looking for, but
should be able to relatively easily build that into their mental model of
how the site works once they've hit a library link for the first time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140122/5429a18a/attachment-0001.htm>