Add build timestamp; Use Sass color vars.

[corylown]

Adds a build timestamp to the lower left corner. I think it's small enough and low enough contrast so it's not noticeable but still readable. We'll want to check how it works on the actual wallscreen.

Closes #223

[netlify[bot]]

✔️ Deploy Preview for sul-wallscreens ready!

🔨 Explore the source changes: d791a50b4f1207c60c4cb0e86b0abbc867b0d05d

🔍 Inspect the deploy log: https://app.netlify.com/sites/sul-wallscreens/deploys/61951e645f82f50007f1e3b2

😎 Browse the preview: https://deploy-preview-226--sul-wallscreens.netlify.app

[ggeisler]

I like the color variable replacement part of this. But the build timestamp part makes me uneasy (and maybe these should be in two separate PRs?).

It seems reasonable that our team would want an easy way to find out the details of the current screen build, but with this solution, if it's noticeable enough for us to read then it's also noticeable enough for wallscreen visitors to read (though I understand it is very low contrast so you have to know where to look and that visitors are not going to know where to look).

I'd personally like to see a solution where there is nothing visible to visitors but we know how to invoke when we need it. For example, perhaps an invisible button in the lower-left area of the More Info modal, that when selected, replaces the More Info modal with another modal displaying the build details. (And maybe it doesn't even have to be invisible? Just very unobtrusive and out-of-the-way, so it doesn't distract from the main purpose of the modal.)

This build details modal could be a regular modal with easy to read text and a regular close button; since we don't expect visitors to trigger it, we don't have to do anything special with the modal itself, and if a visitor does accidentally select the invisible button to trigger it, it will be clear how to clear the modal and get back to the wallscreen experiences. (To be even more safe, the build modal could also automatically disappear after 5 seconds or something, since we'll not need it up for very long to get what we want from it.)

I know this is a more complicated solution, and there might be better ideas, but I'd prefer a solution where we're not actually displaying something on the screen at all times that is only relevant to us.

[corylown]

I'm open to other solutions, although the current approach is appealing because it's very simple. My other thought was to create an invisible button/touchpoint on the lower left corner that would make the timestamp visible temporarily.

[ggeisler]

The current solution might be simple to implement, but I'm not sure it is as simple to use as it might seem. DLSS is physically located in a different building from where the wallscreens reside. So if, when the wallscreens are in normal operation next year, there is some sort of issue, that might be noticed by Green Library staff. And they might report it to us, and because we might not have anyone on the team on campus, or not available to walk over to Green, we might want to ask the staff member to tell us the build details. And that staff member might have older eyes that can't read the low-contrast text as well as you can.

And putting an invisible button in the main interaction area would make it more likely to be accidentally triggered by a visitor. That's why I suggested the modal; it's easy enough for us to get to when we want it, but it's not something that is going to be visible to visitors a large majority of the time, therefore very unlikely to be accidentally triggered.

[camillevilla]

I think this is pretty close to what I had imagined, @corylown. When I filed this ticket, I had some invisible text + this gesture in mind: 🤔 After #201 I need to verify whether Chrome lets users do this in kiosk mode.

@ggeisler I agree that we'll likely need something more transparent for post-launch operations. At this point in the process, I'm just looking for a quick debug statement so that I don't waste our visits at Hohbach Hall. I also agree that placing it outside of the main interaction area would be practical.

Do you think we could merge this and iterate on the solution? A modal within a modal could cause some unintended JS side effects that I'd like to put through some careful code review and QA.

[ggeisler]

@camillevilla Sure I'm fine with whatever for an immediate-term solution. My concern is about when the wallscreen is available to the public. So I have no problem with someone merging this, but if we do I hope we can agree to replace it with a solution that has a reduced potential effect on the end-user experience.

(Also, I wasn't suggesting a modal within a modal. I was suggesting the Build button would close the current modal and trigger a new one. But that was just an example of creating a more polished solution off the top of my head. We could think of another way -- though I still feel like the modal is a good place to hide away access to this feature, long-term.)

[corylown]

I think we should merge this with the understanding that it's for the development phase. I'll create a new issue to capture developing something acceptable for production use.