SerialBox, Part 2: autoplay, mobile platform UX, and UI respect

SerialBox is live! A web app for listening to playlists consisting of audio stored in Google Drive, ideal for sound creators looking to listen to unpublished work in “set and forget” serial playlist form (and maybe try out some artist names for the material). This initial proof of concept is extremely simple: HTML, CSS, vanilla JavaScript.

While the Google client made bootstrapping this a breeze, I did run into a platform-level issue: mobile platforms do not allow autoplay on load, and can sometimes flat out ignore subsequent autoplays within an initialized user context. This is annoying if you don’t know what’s going on, but it makes sense once you do.

For one, mobile platforms are designed for maximum power efficiency, making it programmatically difficult to force the monopolization of processing time. In addition, allowing autoplay without user interaction is a can of worms in terms of UX: who wants to have to frantically search for a way to turn off some kind of autoplayed audio while browsing on their phone? And what if it’s really annoying audio? We have enough popups to deal with, right?

It boils down to platform experience, which depends on an as-seamless-as-possible user experience, which depends on as-seamless-as-possible processing speeds and memory management. Audio files, relative to text files, are enormous, so allowing a web app to essentially hijack a user’s processor is simply bad UX, thus bad product.

Obviating the autoplay on load issue is simple: I made the player not autoplay on load by design (autoplay=false), so the user has to press play to start the first track. Once they do, the processor has a user-initialized context, which then is effectively permitted to autoplay one track after another. I did, however, observe while testing that automatic track changes weren’t always taking (next track is queued up, but no audio starts playing).

At first I thought this might be a major issue, but I noticed my phone was in “power save mode” with around 10% battery life. As of typing this, I’ve been listening on my phone, at 75-80% power, for almost an hour and the track changes have been seamless. I need to try again when the battery is back down under 20% and power save is on to confirm, but I think the power save mode cuts in on the autoplay chain somehow/someway. Check back for an update!

Depending on how these issues impact initial usage, and how well initial mitigations play out, the next big step will be to port SerialBox to React in order to add features like a backend with persistence layer, aiming to ultimately release a native mobile app. Ahead of that, I’ll be adding some validation and exception handling to make the app as is a little more user friendly and robust.

This being the latest HTML/CSS/JS web app of several I’ve built, I also want to give kudos to UI frameworks like React and Angular, both of which I’ve used and find amazingly valuable. Pure JavaScript makes DOM manipulation a breeze – it’s what it was invented for, after all – but such manipulation (state management, both of data and view) is full of rote repetition and automation-friendly patterns.

It’s important to understand the necessity that birthed an invention, both to inform your usage of the tool, but also to inform you of the milieu/zeitgeist out of which this tool emerged, and from which new tools, new optimizations to our interactions with the world, will arise.