Change text of search scopes to match new Himmelfarb style

[maxstarkenburg]

As discussed with Joscelyn, the search scopes are planning on being updated on Primo to match the style that Himmelfarb is using, so now:

• "Catalog + Articles" will become "Articles + GW & Consortium Catalog"
• "Catalog" will become "GW & Consortium Catalog"
• no order changes (that was a miscommunication)

This should be just a text change (no URL differences), but:

• since it increases the size of the text, CSS adjustments may be needed for fit issues
• make sure the text is changed in all places in code that it's referenced
• potential issues w/ HTML's encoding of ampersand

[rdelaloy]

What is the expected time frame for this to be ready for the live site?

[maxstarkenburg]

I made the basic change on gwdev-maxs already (sorry) to just see if things wouldn't blow up

• I'd like another 1.5 hours to look at style adjustments (Aretha Franklin text is cut off)
• .1 hours to commit to branch and make pull request
• 2 hours to clean up test (it's still pink and who knows what else from last regression test)
• 2.5 hours feature testing in different browsers
• 1.5 hours when to fix whatever style changes break the version of IE in the 8-year-old iPad
• .1 hours to commit fix to branch and again (pull request should grab the new change)
• 4 hours regression testing
• 6 hours regression test again when Drupal releases security update Sunday
• .1 hours to merge pull request into master
• .1 hours deploy to prod
• .5 hours spot test prod
• Do we need to budget extra time to change things like text references and screenshots in the How Do I pages, or is that not our responsibility?

So I'm guessing 18.4 man hours (6 of which are hypothetical surprise) + unknown howdoi (etc.) content changes + whatever buffer

[maxstarkenburg]

The text is quite a bit longer, and it was looking odd to me that sometimes the new scope text was longer than the typeable area of the search box, so I made some adjustments. At wide desktop sizes, the entire white search box is longer.

Before: After:

At kind of smallish medium widths (think vertical iPad or maybe split-screen desktop), the scope text hides down to just the triangle at wider screens than it did before.

Before: After:

At phone kind of sizes, if you tapped the triangle to show the scopes, they were no longer fitting on the screen entirely, and options I tried that involved the text wrapping were quite confusing, so I adjusted the placement and bumped down the text size.

Before: After:

Barring objections to the above changes, I think the code part of this ticket should be complete and ready for testing.

[rdelaloy]

I'm fine with the desktop/ipad style changes, but is there any way to make the search box a little more visible on the mobile version? I'm worried it will seem confusing to users to have that completely disappear. I don't think this will fly, but what if we kept the text size, but changed "consortium" to "WRLC" on mobile? Would that free up enough space to be able to click on the search box with it open?

[maxstarkenburg]

Here it is with the change of word and size kept same. This is 320px wide, which I believe is the smallest iPhone resolution (2, 3, 4, 5, and SE).

This only shows up when clicking on the triangle, of course, so most of the time, people would presumably see this when they start entering text (well, actually, likely cut off somewhat by their onscreen keyboard):

While a seeming alternative might be to have the dropdown show below the search box, as seen here:

I made a prior assumption that the list would show up on top of the current scope selection, so I don't currently have a way, for example, of having the list disappear again if you click the triangle again, and don't know yet whether certain assumptions (i.e. hovering outside the list makes it go away) might need to be reconsidered or adjusted.

[maxstarkenburg]

I asked @qbaron, who preferred keeping "Consortium" and also liked the list showing below the input box instead of on top of it, and wondered if we shouldn't just have a triangle at all widths. When I tried that, I noticed an unfortunate side-effect (the diagonal mouse-movement problem):

This would only affect mouse users, not tappers of touch screens (since tap only mimics the start of a mouse movement). Granted, there should be ways around it by delaying the hiding of the list when mousing outside of the triangle, or maybe only hiding the list after a click elsewhere on the page, but it's more futzing and more to test.

For quickest rollout I'd still recommend going triangle-only at <940px-wide screens (as in the 2nd set of screenshots in a comment above) since these are mostly tap screens anyway (over the last year, desktop users at <940px-wide have only been 0.06% of users, according to our analytics), and we can still position the list below the triangle for narrow-screen users (as in the last screenshot of the previous comment) (toggling the list to hidden again after 2nd triangle click was less JS trouble than I thought).

[rdelaloy]

Since we've already blown past the date we committed to have this done thanks to the 602 plague, lets go triangle-only at <940px and position the list below for narrowest phones.

[maxstarkenburg]

Deployed just now.