Web based staff client needs tab details on the tab label

[Blake GH]

Some of our libraries used the tab titles for navigation. Now with the web based staff client, it looks like we lost some of the details on the "title" of the tab.

AKA:
"Patron xxxxx" vs. "Evergreen Staff Patron"
"Bib Record xxxx" vs "Evergreen Staff Catalog"

We would like to get that functionality back in the web based staff client.

[Blake GH (bmagic)]

Screen shot

[Kathy Lussier (klussier)]

This is related to another bug I was planning to submit regarding the tabs. It may be best to add it to another bug, but I'll post it here for now in case it can be handled in the same branch.

Without a client toolbar, staff will likely use the bookmarks bar to provide quick access to their most-used interfaces. All of the titles in the web client begin with Evergreen, e.g. Evergreen Staff Catalog, Evergreen Staff Check In, Evergreen Staff Z39.50. It will make it difficult to distinguish one toolbar button from another.

Years ago, I saw a usability recommendation to provide the more specific page info first in a title and then add the name or the organization or, in this case, the name of the application you are running. For example, we could use titles like:

Catalog - Evergreen Staff
Check In - Evergreen Staff
Z39.50 - Evergreen Staff

I've also noticed that there are some places where the title isn't matching the interface the person is using. For example, the Create MARC record screen has a title of Evergreen Staff Catalog. All of the acq interfaces have a title of Evergreen staff acquisitions, rather than the specific interface that was retrieved. Usability will be improved if these titles could be as specific as possible. In the case of the original bug description, the patron or bib id is the specific information people will want to see.

[Bill Erickson (berick)]

Sharing a proof of concept implementation for feedback.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1656036-webstaff-tab-titles

1. Adds a new service for setting the page titles dynamically.
2. When no dynamic title is set, it falls back to the static per-template page titles

If this seems reasonable, I'll flesh it out more. Arguably, the intermediate egPageTitle service is overkill. We could modify $rootScope directly or hang a function directly off egCore to do it.

[Jason Boyer (jboyer)]

I'll make a strong recommendation that the variable data always be first, so if there are many tabs and they start to shrink the user isn't left with /Patro...\/Patro...\/etc.\ for tab titles. I also like the idea of just hanging it off of egCore since there's potential for every page to have some useful identifying information. Another idea might be to accept the title in 2 pieces, the variable data that specifically identifies this page (Smith, Joe) and the context (Checkout / Bills / etc.) that way the variable data could be truncated if it's too long and you can ensure that the context is still visible. (Assuming a max tab length of something like 20-30 chars, etc.) Giving titles like "Smith, Joe - Checkout" I assume there's no point in putting "Evergreen" in all of them when it's on the page itself and it doesn't add any clarity when it's in literally every page title.

I can try to throw together a PoC of that if that description wasn't clear enough to entice anyone to just run with it, heh.

[Bill Erickson (berick)]

Updated branch pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1656036-webstaff-tab-titles

From the commit:

==
Support page/tab titles applied by page controllers. This makes it possible for titles to change as the script-driven UI changes.

Includes implementations for applying dynamic titles to the patron UI and bib details pages, consistent with the XUL client.

Apply a title dynamically within a controller like so:

$scope.$root.pageTitle = egCore.strings.MY_TITLE_STRING;
==

Following Kathy's suggestion, this also moves the dynamic portion of the title to the front of the string. This affects all titles, even those applied statically within the template.

The patch does not include dynamic titles universally (Create MARC, Acquisitions, etc.). Full coverage will be a big task. I propose we open new bug(s) for these so we can get what we have now into the codebase sooner than later.

[Bill Erickson (berick)]

Didn't see your comment until after I had pushed my branch, Jason.

What your describing can all be done w/ my most recent implementation, minus the truncation bit. To support that, as noted, we'd need to link a new service into egCore to do the truncation dance and egStrings.$replace dance prior to linking to $rootScope. Or, we could teach egStrings to truncate dynamic content for us.

Some concerns about truncation:

To support dynamic content truncation, I believe we'd have to make a requirement that each page title string have at most 1 dynamic component. For example, truncating the dynamic components of "Patron: $lastname, $firstname $middlename" would not produce the desired results.

Another concern is that the dynamic component can change position in the string depending on the locale. Truncating a dynamic component that sits between static text could create the impression that no truncation has occurred, which could be misleading. E.g. a shortened record ID just looks like a different ID.

[Jason Boyer (jboyer)]

I didn't think about i18n until I saw your second branch. My assumption when mentioning variable vs static was that there would only be 1 static entry at the end rather than on either end. That said, IF there's a way to do what I'm thinking it would definitely have to be part of egCore and have a signature something like (static_text, format, ...) and do the string formatting itself. If the formatting could be done in this function then truncation is still possible, though I don't know if this is worth the trouble (though I do like having a function on Core to call vs twiddling $root.pageTitle directly...)

[Bill Erickson (berick)]

I think we can have it all! I'm modifying my latest branch to support hierarchical titles, with a dynamic portion (e.g. patron name) and a static context (e.g. Checkout). The dynamic part will come first, be $replace-able (internally) and support truncation across the entire (dynamic) string.

[Bill Erickson (berick)]

Updated code pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1656036-webstaff-tab-titles

Supports the dynamic and static components. Dynamic components are interpolate'able and will truncate when paired with a static component and exceed a configurable length (currently 12).

For example:

egCore.strings.setPageTitle(
   egCore.strings.PAGE_TITLE_PATRON_NAME,
   egCore.strings['PAGE_TITLE_PATRON_' + tab.toUpperCase()],
   { lname : patronSvc.current.family_name(),
       fname : patronSvc.current.first_given_name(),
       mname : patronSvc.current.second_given_name()
   }
);

[Jason Boyer (jboyer)]

You got chocolate in my peanut butter!

Sweet.

[Bill Erickson (berick)]

To test:

1. Navigate to Patron Search in the browser client and confirm the tab title shows "Patron Search"
2. Perform a search and load a patron.
3. Once on the Check Out tab, confirm the tab show "$Last, $First $Middle - Check Out"
4. Navigate to other Patron UI tabs and confirm the browser tab title changes to match.

=

1. Perform a catalog search
2. Select a bib record
3. Confirm the tab title changes as the selected bib record changes.

[Jason Boyer (jboyer)]

So far, I can't get bib records to show anything in the title but the default.
When looking patrons up by barcode number it works as expected but if you start with Patron Search and then double click a patron to open their account it stays on the default "Evergreen Staff Patron" even when clicking through the tabs. Maybe there's something odd about the routes when you take that path?

Aside from the snafus above it's pretty much exactly what I had in mind. I'm still working on a different bug today but if you have time and want me to test anything else I'll make it a priority.

[Bill Erickson (berick)]

I rebuilt and ran through all of the above work flows successfully. Apart from the usual kill-cache-everywhere-always, I'm not sure what to suggest. Adding console logs in and around the new code would helpful to see what's firing (or not).

[Jason Boyer (jboyer)]

I'm sprinkling console.log()s all over trying to see what's what.

[Jason Boyer (jboyer)]

I'm not sure where the holdup lie but after blowing away every cache I could find, yes, it works as advertised.

Signoff here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1656036-webstaff-tab-titles-signoff

Thanks, Bill!

[Kathy Lussier (klussier)]

Thank you Bill and Jason! It looks good to me too. I resolved a conflict and merged the code to master and 3.0. The merge conflicts were a lot more extensive for 2.12, so I decided not to backport that far.

I'll update the targets as soon as I add a 3.0.2 milestone launchpad.