From the lab

Prototyp Sound Service

A sound service that enables us to play sounds, create text-to-speech messages or play music at all our offices simultaneously through our Sonos speakers. Powered by a Slackbot.

Tech used

  • Sonos web API
  • Slack API
  • Ruby on Rails

Press to view video

Background and problem

Prototyp week was special this year since it was the first time we all met since the start of the pandemic; so we’ve waited over two years for this! You could tell that we’ve all missed each other when looking at how many of the ideas generated by the teams focused on interacting with colleagues, mainly between our different offices.

Our take on making our offices more connected was to create some sort of common sound service. Since we have Sonos speakers in all offices, we realized that the Sonos web API made it possible for us to play sounds on all speakers in all offices at the same time. We therefore decided to create a solution for a common sound service, the ‘Prototyp Sound Service’.

Idea and solution

Our idea was to be able to play sounds, create text-to-speech messages or play music that all offices could listen to simultaneously through our Sonos speakers. We wanted it to be easy to use for everybody, so the Slack app seemed like a good tool. We also wanted the service to help remind us of recurring meetings; like our Daily stand-up, weekly Demo, or Dev Coffee.

Implementation and results

To achieve this goal, we created a code project to connect the Sonos API, the Slack API, and the AWS database in the RedwoodJS framework. After some researching and trying out some different things, we realized that the built-in authentication support in Redwood was great for single-page applications but not as mature when doing more server-based authentication. So we decided to create a new project with Ruby on Rails instead. We could then use the Sonos API to fetch our households of speakers for the different offices via our auth token.

Using the Slack API we implemented a Prototyp Sound Service bot, that would enable us to choose which of (or all) the offices that should be affected by a play request, as well as what type of sound should be used. We wanted to be able to create messages via text-to-speech, as well as to choose from already existing sound effects. The latter could be divided into sound effects that we store in our database, or by pasting an mp3 file that is then just used once. We also made it possible to upload new sound effects to a back-office interface.

We also created a simple landing page with some information on how to use this service. There we also included instructions to direct the user to the back-office interface.

Insights and reflections

Authentication is always complicated. To create the feature to be able to authenticate via Sonos drove some early decisions, but after proof-of-concepting it more, it didn’t work anyway. It would have been better to use the shortcut/hack from the start instead of 2 days into the project. We also learned that Slack apps can do a lot, and that it’s possible to display fairly complicated multi-step forms using Slack apps. Using the Sonos API to connect devices, where the API itself is not the main feature, we found was tougher to use.

A suggestion to further develop the Sound Service would be to set up auto generated messages, such as company/office-wide Slack reminders and greetings, to sound when the office opens up or closes.