I’d like to offer very well-deserved congratulations to the team at Spain-based Zuinq Studio, who produced Podcast for Glass, and I highly encourage all of you reading this to do the same. I’ve used the service extensively since it went live earlier last week, and the people that built it are to be commended for putting it together and getting it listed in the MyGlass directory.

Media apps are rarely trivial projects to take up, podcast clients especially. And providing features common to that idiosyncratic space such as feed subscription and management, proper playback, content archival, and listing metadata in a browser session really takes some creative thought and technical chops.

How does it work?

Podcast for Glass is built by using a clever combination of the Mirror API and web-based app configuration, which makes the app a web service endpoint with the front-end elements being static cards that can be pinned to the left of the home card for persistence and immediate access. Usage is extremely simple: you navigate to PodcastForGlass.com, authorize your Google profile to use the application, then choose from the vetted content or add a custom feed URL. The available episodes for each feed are displayed, any of which you can easily send to Glass, which inserts a new card into your timeline for that episode with simple menu items for Play and Pin. Keeping with the simplicity model, the files themselves aren’t pushed to your device, but streamed from their source servers.

Multiple podcasts sent to Glass live within the same card bundle, which is a neat expression of the idea of managing an entire collection and moving saved content around in a single step.

The Mirror API and media

However, there are a few notable drawbacks to basing this service on the Mirror API, being dependent on the web stack. Playing the content requires its containing card to remain active in the Glass display and to maintain focus within the timeline, which means no navigating to any other cards, which means the display needs to stay on for the duration of playback, which means a major drain on the battery. And with most podcasts being mid- to long-form radio programming, we’re not just talking about a 3.5-minute verse/chorus/verse song – these are full shows, sometimes in excess of an hour or more.

There’s also the case of unregistering for podcasts once they’ve been sent to Glass. There’s not an easy way to delist episodes, so you’ve got to unpin items and let Google’s self-managed sync cycle remove cards — a timeline currently displays a user’s most recent 200 items, and any pinned cards are purged automatically after seven days. You just have to let stuff expire naturally.

Lastly — and this one’s a biggie — any incoming calls interrupt a current stream and effectively shut it down, forcing you to start over from scratch. This isn’t due to any fault on the part of the developer; it’s the behavior of the system when using the Mirror API. Anecdotally, engineers at Pandora told me they wrestled with similar issues due to Glass’s telephony integration in early prototypes of their Glassware.

Key takeaways

To Podcast for Glass’s credit, the application doesn’t display cover art or any sort of graphics during playback, so the screen is basically blank. This rather nondescript all-black interface probably saves a little on the amount of discharge the battery has to endure while the projection unit stays illuminated, as opposed to rendering eye candy merely for the sake of having something on the screen.

And the use of the Glass media player does have merit in that this is one of the first instances of Glassware supporting playback of MP3s or other audio content by streaming the file from a remote location. This is significant in positive ways, as the Mirror API supports media attachments for a wide range of image or video formats, but not audio. This takeaway is a win and shouldn’t be overlooked by the development community.

What do other projects use?

Comparatively, another outstanding Glassware application, ViewTube for Glass, uses live cards published with the Glass Development Kit to support playback of video content from YouTube. Live cards are also used by Pandora and Boston NPR station WBUR’s Glassware as streaming stages. Live cards are native UI elements connected to Android background services that offer more granular control for the developer, and differ in distinct ways from Mirror API-based static cards, which add to a Glassware’s usability:

1. an active session will continue to stream its content even when Glass goes to sleep due to idle use
2. the user can continue to swipe through and interact with rest of their timeline without disrupting the media being played
3. any inbound phone calls pause the playing stream and resume its playback position when the call is terminated or ignored
4. when you want to halt running content from playing, the Stop command kills the underlying Android service in one shot

Cliff’s Notes version: you can do something else mid-stream, and terminate the service fully when you’re done.

Michael Mahemoff, the creator of the multiplatform podcasting client Player.FM, and a veteran of the time-shifted content delivery community, talked about launching a fully-featured web-based podcatcher as far back as 2004. He’s recently overseen development of neat features with his platform to Android Wear, using smartwatches as remote controls for the app running on handheld devices. I interviewed him in a Hangout about some of the challenges shortly after he launched his service. It’s worth checking out.

Golf clap time

Don’t get me wrong, I’m not sniping on Podcast for Glass. Not at all. I think it’s fantastic, and a great example of how to apply the notion of an integrated media service to wearable technology. It applies the Mirror API according to Google’s recommended best practices. It’s quick, lightweight, functional, and doesn’t impose drivespace consumption demands on my device. It makes for a fantastic case study in wearable design, specifically for the particularities of Glass. At the same time they released Podcast for Glass, Zuinq Studio churned out PDF for Glass, making them one of the few publishers with more than one approved Glassware service in MyGlass.

But the nature of podcast clients and what’s expected of them by consumers does introduce some interesting challenges in how to best present the content and let the user manage what can be lengthy usage sessions with respect to their attention span and impacts on Glass resources. Perhaps a future release might employ a hybrid solution, wherein elements of the Mirror API’s static timeline items could be combined with the GDK’s live cards to create a more robust, flexible environment for handling media (probably not so much for an immersion).

(This isn’t an uncommon evolution, by the way. A few projects I know of, including the original Genie Glassware, were originally born of the Mirror API, then had plans to be re-architected using the GDK.)

I’m a big fan of Podcast for Glass, still in its infancy, and can’t wait to see where the team behind it goes with it, what the roadmap for this service entails, and how it inspires other Glassware developers for their own projects. It’s inspired me with ideas for my own wearable work. There’s a big opportunity here and we can all learn a lot from using it.

Thanks to Andreas Calvo and Lucas Baran for their contributions to this report.

The post Podcast for Glass & the Tough Task of Building Web-based Wearable Media Apps appeared first on Glass Almanac.