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 <d...@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: d...@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.