Add autoplay control button

[thatbudakguy]

closes #286 branched from #283 since I didn't want to end up redoing work to reference layouts (and hence draft).

this implementation adds a small play/pause button to control autoplay with a "ring" indicator of how much time is left until the next slide/step. if you advance the slide manually or otherwise interact with the page, the autoplay should deactivate. eventually (after autoplayTimeout elapses without any interaction) it will turn back on again on its own.

note that if you want to test with shorter timer values, you also need to change the CSS that controls the "ring" animation: https://github.com/sul-dlss/wallscreens/blob/89daf9f6941ddc6b1c91e179b0f00a58be24aa7f/_scss/wallscreens/_buttons.scss#L202-L205

this could be made "smarter" (we could actually update the ring to match the interval) but i went with a "dumb" version for the first pass where the animation doesn't actually know about the timer, it just runs for a set amount of time. it seems to work OK.

[netlify[bot]]

✔️ Deploy Preview for sul-wallscreens ready!

🔨 Explore the source changes: 7863e38c76b3da687c9ecc49a7838add40f763de

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

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

[ggeisler]

Thanks for working on this @thatbudakguy, definitely looks like a great start on something that seems feasible and useful. I like the ring solution. To me it's a great compromise between being noticeable but still somewhat subtle and unobtrusive.

I know this is just a draft so not sure which aspects you've thought through and are intentional but here are some initial thoughts, assuming everything is intentional:

• The icon size for the play/pause button is out of scale with the next and previous icons, but I think those are the ones that are too small, and we still have some font updates to make, so not suggesting any change for this now, just noting we might want to tweak icon sizes at some point to make sure all three buttons feel more unified.

• On Chrome, the play/pause button looks weird and I don't see the progress ring (but this is possibly just something wrong with my Chrome; if you aren't using Chrome, see what you get):

• I think we should play by default. When the user selects Touch to begin, we transition to the first slide and the play/pause button should be in the play (showing the pause icon) state, with the countdown ring starting immediately. That immediately (hopefully) clues the user into the fact that it is going to auto-advance and they can stand back and wait. Plus they've already indicated they want to see the experience, by selecting the Touch to begin button.

• I think we're going to want a much shorter time interval for each slide. I'm not sure what that should be exactly, but as we work on finalizing this we might as well go with something much shorter and easier for testing, such as 15 seconds? (This is where things are going to get tricky, because something like 15 or 20 seconds seems roughly right for, say, Adobe and Apple, but that's uncomfortably long for a guided tour stop with a very short annotation. But the user can manually advance, so I guess that's the best we can do without getting in very complicated, experience instance- or slide-specific time intervals.)

• Not sure how consistent this is (I can test more when the time interval is shorter), but if I pause a slideshow slide, then restart it, the progress rings starts again but when it reaches zero it begins again without advancing the slide image/card.

[thatbudakguy]

ok @ggeisler thanks for the feedback — this is ready for another look.

• button shape was fixed for chrome
• autoplay now begins when you start the experience
• autoplay interval decreased to 15 seconds
• no-advance bug was hopefully fixed?

[ggeisler]

@thatbudakguy The autostart looks great and things work well when you just let autoplay to do its thing. Below are things I'm still concerned about, although some of them might be the behavior you intended. For those, just let me know if you did intend it to be like that and we can discuss whether we should stick to that behavior.

• The Play/Pause button looks great in Firefox, but it still doesn't seem round in Chrome or Safari. Below is from the Safari inspector, which seems to indicate button is 44x49?

You can see it isn't truly round by how the progress ring doesn't follow the edge as it approaches the bottom:

It's possible these issues are because I don't have Safari or Chrome device-mode setup correctly (I use Firefox most of the time). So if you and others don't see this issue, it's just me.

The items below are not browser-specific:

• If I select Pause, the progress ring disappears and the icon changes to Play. When I select Play to resume, it resumes from the beginning. Is this intentional? I guess my expectation is that when I select Pause, the ring progress would stop, but still be visible, and when I then select Play, it would resume where it left off.

• If I select Previous or Next before the current slide advances by itself, it navigates to the next slide as expected, but autoplay is now off. Is that intentional? I suppose an argument could be made either way, but I was assuming the most common use case for selecting Next is you're ready to move on before autoplay advances, rather than because you don't want autoplay at all. But currently the user would have to select Next, then select Play, before autoplay resumes normally. Seems like an unnecessary extra step?

[thatbudakguy]

thanks again for reviewing!

• the button sizing issue was actually caused by our new fonts, I think: they slightly increased the height of the other buttons, and the autoplay button tried to adjust to match. I've recalculated the height fix for Chrome/Safari (some ugly math, but whatever, it seems to work).
• pause/play resetting the autoplay interval is intentional, and it would unfortunately take a lot of work (i think) to change it. the reason is that the browser doesn't actually track how much time has elapsed on the timer, so it can't be queried on demand in order to re-start a timer with only that amount of time remaining. not quite a true "play"/"pause", but hopefully this isn't a big UX faux pas.
• next/previous resetting the autoplay was also intentional, but fortunately that one's easy to change, and i see the logic about why you might not always want to stop autoplay when doing it (especially if the user has just manually started autoplay). i've removed that behavior, so now autoplay continues until it's paused.

[ggeisler]

@thatbudakguy Yeah the font changes messing things up makes sense (sorry!). The button now looks good on Chrome, but in Safari not so much, though again, maybe my device emulation is not set up correctly (I'm using Responsive Design mode and Chrome on Windows as the browser to emulate):

Sure, we can live with resetting the autoplay interval if it's not simple to fix. We'll see if anyone cares or notices.

I'm glad you could fix the next/previous not stopping autoplay, but now there appears to be a related issue. If autoplay is on (progress ring is moving) and I use either button, the slide navigates as expected but the progress doesn't restart at 0, it starts where the previous slide left off. In other words, if I select Next from slide 1 at 10 seconds in, when we get to slide 2 the progress ring is already at ~11 seconds.

[thatbudakguy]

@ggeisler i tested in safari (my version is Version 15.1 (16612.2.9.1.30, 16612)) and wasn't able to duplicate that strange offset. it looks like safari actually respects aspect-ratio (unlike Chrome), so everything is displaying normally for me. i'm also not even sure the utility of telling Safari on a Mac to emulate Chrome on Windows, so maybe we should shelve this until we know whether the wallscreen itself actually displays this bug.

i added some logic to restart the autoplay advance timer when you click next/prev. it's a little weird (i guess there has to be a sufficient delay of 1ms in order to restart the animation) but it seems to work.

[ggeisler]

@thatbudakguy Yeah, I'm sure it was just my Safari setup being weird. And now that I think about it, we don't really care about Safari (or Firefox, for that matter), in the immediate timeframe, anyway, since our only known target is Chrome on Windows.

I still see some odd/inconsistent behavior when I navigate using Previous/Next (sometimes the timer restarts, but other times it keeps going from where it was on the previous slide), but I'm not confident that what I'm seeing is accurate (I've only been using the Netlify version of this PR). Given we worked out the ideal behavior we're shooting for, I'm happy to someone else to do a technical review and merge this. And then the whole team can maybe verify it is working as expected (and we can see how it looks at Hohbach on Monday).

[thatbudakguy]

ok, autoplay should now pause when the "more info" modal is opened. I didn't add corresponding logic to restart autoplay when the modal is closed, because if the user had opened the modal with autoplay turned off, closing it would still start autoplay even if they didn't want to use it. @ggeisler let me know if this makes sense to you.

[ggeisler]

I didn't add corresponding logic to restart autoplay when the modal is closed, because if the user had opened the modal with autoplay turned off, closing it would still start autoplay even if they didn't want to use it.

@thatbudakguy Sure, seems reasonable, but can you confirm what happens in these scenarios:

1. User may or may not have autoplay turned off, but opens the More Info modal. Then the user walks away, with the modal window still open. No other users are around. Does the wallscreen remain in this state (displaying the modal) until another user comes along? Or do we still have a timer somewhere that detects when there's been no screen interaction for some_time_interval and then closes the modal and goes into attract mode?
2. User paused autoplay, opens the modal, reads it, closes it, and walks away. Do we still finish the current experience and go into autoplay?

What I'm getting at is do we still have the more global no visitor interaction for some time interval detection going on so we can't get into a scenario where there are no users but the wallscreen is stuck in a particular state?

I guess I've just gotten confused over whether this new autoplay/pause button has affected our previous strategy of going into attractor mode after no visitor interaction for some time interval.

[thatbudakguy]

both great questions! fortunately the system for entering attract mode is separate from the one for autoplay, so we shouldn't be able to get into a "stuck" state:

1. the more info modal always tracks how long it's been open without an interaction, and eventually closes itself. at that point, the experience will be tracking how long it's been without any interaction, and eventually resume autoplaying.
2. same thing here; autoplay will resume on its own after 15 minutes if there's been no interaction of any kind.

to clarify — what i think of as "attract mode" is the situation where we're switching between the experience type index pages. we will always eventually get there, because:

• autoplay will turn itself back on if there's no interaction for 15 minutes
• we will autoplay all the way to the end of the experience
• after the end, we return to the starting slide briefly,
• finally, we go to the experience type index page, and then attract mode takes over

[ggeisler]

@thatbudakguy Okay, great. That all sounds fine then. (I do wonder if we should shorten the interval before going into attract mode -- 15 minutes seems kind of long to be showing some arbitrary state with no one around -- but that's a separate thing we could discuss and maybe change later.)

So I have no objection/would be happy if someone wants to finalize the technical review of this and merge.