Skip to main content

Hello everyone! Thank you for coming through and participating in our first AMA on the Sonos Community. We know how difficult it can be to find the answer you were looking for scrolling through many replies, so in an effort to get you the answers quickly and without having to dig through pages of replies, we’ve put together this recap which should help you to find the answers you seek.

Answers are grouped by which team member responded.

 

Kate Answers: 

 

Will we see numbers re-added to the volume adjusters or is Sonos sticking with this UI decision?

Yes - volume numbers will be returning to this UI. We are continuing to refine our volume UI based on user feedback and will soon be providing an update to these controls.  Volume numbers should be visible now in the grouping menu.

 

Will My Library be added back to Global search?

Yes! We will be adding your local music library to search in the coming weeks.

 

Please describe what the thought processes was, going into the re-design. I understand the value of launching something new, but as a designer, I also understand that function always outweighs design.

The refreshed UI design is rooted in the needs that we’ve been hearing from our listeners for years. We heard from users that the information architecture of the S2 app felt like work, particularly in navigating between multiple tabs to get core jobs done. The intent of the new app home feed is to put the most useful content and controls immediately within thumb’s reach, offering quick access to the content that means most to users, and enabling them to drive what is prioritized in their personal home experience.

 

What data did you draw on to justify this new design? Was there any information architecture analysis done? Was there any investigation at all, like user interviews, analytics, usage data, etc? The marketing materials tout “no more tabs” as a selling point, but for me it’s one of the biggest UX regressions. The new home screen is worse than useless; it’s just a new barrier between me and the favorites screen, which is by far the most common place I’m trying to go in the app besides the now-playing screen.

We did go through multiple phases of assessing the current S2 structure, modified versions of it, and the tabless version that we have today. Our work has engaged existing and new Sonos users throughout, and we have pursued the path that felt the most useful and intuitive to the largest number of users overall. We understand that every user is an individual with unique needs and circumstances. My hope is that your specific needs can be addressed by personalizing your home screen so your Sonos Favorites module shows up front and center on your home screen. Doing so should make this the first thing you see when launching the app. A single tap should take you to the full view of that collection. 

 

I almost always use my Sonos devices in groups, and with the new app, handling of group volumes is worse. Not only does it not change in real-time like the former app, you end up with a UI pop-up on top of the volume slider I am using to adjust the volume. See the video below of before and after.

Will this be fixed in a future app update? 

I recognize that we have a ways to go to improve this tablet layout. Full stop. We will be continuing to improve this display and other UI improvements for tablets. No exact timing yet to share here, but the team shares your desire to make this and other layout improvements.

 

When the app was getting ready to be released, what were your personal feelings regarding the new app?
Did you anticipate that it would be so poorly received? 

I've personally been excited to bring the experience to our users, but also understand that anytime you are making a change to an interface that someone uses, you're going to be met with a breadth of reactions, and understandably some negative ones, simply due to the nature of change. We knew that some customers would be understandably upset by the delay in certain features, but are eager to continue to roll out updates to ensure these features are in place, and to address the feedback we are getting from our users. I'm thankful to have an app that is easier for the team to work with and publish updates to with far greater frequency than we've had in the past.

 

The UX of the new app is very laggy and unresponsive, frequently displaying error messages, please explain why it was released like this and what you are doing to resolve it.

Regarding responsiveness, I am sorry to hear you are having a bad experience. There are many factors that can contribute to this. We built the app to gather telemetry and data around these error states so we can continue to resolve issues for all users.

 

Tucker Answers:

 

What was the thought process behind releasing the app update in an obviously unfinished state, instead of waiting for critical issues to be resolved?

An app is never finished! 

It’s probably a good idea to give you some background. This is a new app - we started from an empty project file. As the project progressed, we stopped investing our time in the old app code. Over time we “cross-faded” our engineering attention into the new app. We need to make the new app be the app going forward so we stop splitting our attention.

We decided that now is the moment to bring you the new app. This is the beginning, and we will be continually iterating going forward. As I said - an app is never finished.

 

Please describe what the thought processes was, going into the re-design. I understand the value of launching something new, but as a designer, I also understand that function always outweighs design.

The refreshed UI design is rooted in the needs that we’ve been hearing from our listeners for years. We heard from users that the information architecture of the S2 app felt like work, particularly in navigating between multiple tabs to get core jobs done. The intent of the new app home feed is to put the most useful content and controls immediately within thumb’s reach, offering quick access to the content that means most to users, and enabling them to drive what is prioritized in their personal home experience.

 

The new app left me without my carefully curated URL-based internet radio favorites. How is this supposed to be accomplished in the new app?

To add radio stations via a custom url, you will need to add the station in the Tune-In app first. Then you can add this station as a favorite from the Tune-In app in Sonos. I hope that helps!


Setting aside all the “why did you do this release like this”, can you tell us how you will ensure it wont happen in the future, and what the plan is to address customer input in a more coherent way

Our goal is to build the best products for you—to add sound to your lives. Along the way we may make mistakes. What we learned this past week is that we should have communicated more openly with you about changes that may impact you.

Going forward we plan to be more communicative to you all about changes that are coming.
 

We are also committed to acting on your feedback—and delivering you improvements—rapidly. Over the coming weeks and months we seek to fix the issues that you have surfaced and earn back your trust.


Diane Answers:

 

Sonos now claims that some of the most serious defects will be corrected in the 21 May release, but hopefully the panel can understand that there are a lot of blind people who can’t trust Sonos anymore. Given that Sonos got it so horribly wrong with this current release, why should we expect anything better in the next?

Will Sonos offer an apology to its blind users and accept that it got this wrong, and will Sonos commit to creating a Chief Accessibility Officer as a tangible commitment to ensuring this never happens again?

Thank you for your heartfelt feedback. 

 

We invested our user experience and engineering energy on supporting VoiceOver throughout this project. Unfortunately near the end, we took our eye off the ball and missed a couple of key bugs. Those bug fixes have been shipped in a release today.

 

That doesn’t mean we’re done. We have more that we want to do and will do to fine-tune the experience. This is the same kind of fine-tuning we are doing for the visual experience. In a visual UI that means adjusting the gutters between items on screen. In a spoken UI it means adding more hints about how to navigate. We look forward to tweaking those and making the experience get continually better.

I understand that we have to rebuild your trust. We will only be able to do that by improving the experience. Any words we say will be incomplete. I am sorry that we missed this.

 

Our next step involves building a hearty beta community of vision impaired users. Today we have 30 visually impaired users on the beta of the next version of the app. The next version already has several improvements beyond the bug fixes we shipped today.

 

I almost always use my Sonos devices in groups, and with the new app, handling of group volumes is worse. Not only does it not change in real-time like the former app, you end up with a UI pop-up on top of the volume slider I am using to adjust the volume. See the video below of before and after. Will this be fixed in a future app update? 

A key part of this new app was using the newer Sonos APIs, which means we did indeed rewrite the volume experience entirely.  Until this new update, our app was using an older set of technology based on UPnP and SOAP.

Thank you for sharing the videos. I will make sure the team sees these so that we can continue to iterate and improve in upcoming releases.

 

I noticed that the re-introduction of alarms actually required an update to Sonos devices as well as the app today. Does this mean that the new UI revamp was in fact much more than just a revamp to the UI? Are there currently bigger changes happening on the device side as well?

The app is definitely a revamp, but it’s not just the UI that changed! This new app is using new features on the speaker firmware and new cloud services as well. Let me share a bit more about what happened with alarm settings. 

On the morning of the app launch, we discovered a data corruption error around the new Alarms APIs. The corruption could cause alarms to go off in the wrong room at the wrong volume with the wrong content! In order to save your alarms, we made the difficult decision to remotely disable the alarm settings feature and then completely lock it out. It allowed us to make sure your alarms stayed as they were - but at the steep cost of taking away your ability to change them yourself.

The team rallied to make sure we could turn this feature back on safely - and today we are so delighted to say that we have re-enabled alarm settings. To get this feature, you must do a full system update. 

But that’s not how we expect to introduce features every time. We have built the new app to be able to update independently of the speaker firmware. As we go forward, you can expect us to bring out new features with smaller, less intrusive, updates.

 

What has been the general mood of the Sonos team/staff since the new app was released? Was the team surprised at the negative reception or was it expected?

Thanks for asking. We have all been deeply invested in this project for a long time. We are all Sonos owners. Many people on the team had Sonos in their homes before they joined the team. We all use the experience every day. 

Any time we change an experience or delay a feature, we know that some people will have negative sentiments. We also saw in our usability testing that people appreciated the new user interface, adaptability, and faster time to music. 

We have been reading your posts and seeing your feedback.

Once the release went live, the mood could be described as “energized.”  The activity on the team is high as people share what they’ve built for the next releases. We are excited that we can bring these continuous regular updates. It’s easier and faster now for us to share what we’ve built with you. That started with today’s release and will continue on May 21st with releases to follow.

 

Can you confirm the reasoning behind the decision to “upgrade” S2 app rather than create a new S3 app with the new design and put S2 into maintenance mode as you did with S1 app?

Regarding the idea of a separate app, the problem with this approach is that the functionality between these apps would diverge over time, leaving a large group of users with an out of date and potentially not fully supported experience.

 

Are you able to explain why Sonos decided to make the app cloud-based, what are the advantages apart from extra latency making the app seem slow?

There are many advantages to using the cloud, but I’ll highlight one. With our new content services, we are able to provide a richer experience for discovering music to listen to. Our previous app was built on APIs that did not provide enough metadata to make that rich experience. 

 

It’s also important to note that the app is not exclusively cloud-based. We still interact with the speakers on the local network, similar to the old app. We will be continuing to fine tune when we use cloud or local APIs. And we are already working on performance enhancements across the stack.

 

Can you confirm the new app is built using Flutter rather than native apps to make a one-size-fits-all app?
What was the reasoning behind this? To save development costs?
I’m failing to see the advantage to the user, it’s slower to open and laggy, missing widgets, when installed on a large screen like a tablet it doesn't make good use of the extra screen real estate. 

The app is not exclusively built with Flutter, but does make use of Flutter for certain portions of the setup experience. We’ve actually been using Flutter for those experiences for many years, and ported that forward to the new app.

The majority of the app is in fact native. On iOS that means Swift, using SwiftUI. On Android that means Kotlin, using Jetpack Compose. These are the best in class layout engines offered on their respective platforms, and we’re excited to be able to use these modern technologies.

We are aware that there is work ahead for the tablet experience, and look forward to iterating on that as we go forward.

 

Do you factor in this loss of trust? Has this been costed? Was there a risk benefit analysis of releasing the app in such an unready state? Or did the the response to this app come as a surprise to you?

We did factor in a risk analysis about delaying some features along with the timing of the release. That risk-benefit analysis was carefully done across many decisions about what to prioritize.

One thing I would like to restate from an earlier reply - we never intended to ship without Alarm Settings.

On the morning of the app launch, we discovered a data corruption error around the new Alarms APIs. The corruption could cause alarms to go off in the wrong room at the wrong volume with the wrong content! In order to save your alarms, we made the difficult decision to remotely disable the alarm settings feature and then completely lock it out. It allowed us to make sure your alarms stayed as they were - but at the steep cost of taking away your ability to change them yourself.

The team rallied to make sure we could turn this feature back on safely - and today we are so delighted to say that we have re-enabled alarm settings. To get this feature, you must do a full system update. 

We will continue to evaluate the impact of new and returning features, and have committed to a timeline for the short term.

 

Please address the rationale behind the removal of sleep timers and alarms. You must have telemetry showing that these were very heavily used features of the app. And yet now they are gone.

We never intended to ship without Alarm Settings.

(I am copying this in since the threading is difficult to follow here)

On the morning of the app launch, we discovered a data corruption error around the new Alarms APIs. The corruption could cause alarms to go off in the wrong room at the wrong volume with the wrong content! In order to save your alarms, we made the difficult decision to remotely disable the alarm settings feature and then completely lock it out. It allowed us to make sure your alarms stayed as they were - but at the steep cost of taking away your ability to change them yourself.

The team rallied to make sure we could turn this feature back on safely. You can have Alarm Settings back right now!

  1. Update your app to:
    1. iOS: 80.00.08 - available now in the App Store
    2. Android: 80.00.05 - available now in the Play Store
  2. Update your firmware to 79.0-52294 - available now via the Sonos App:
    1. Tap the settings gear in the top right
    2. Select “Manage” next to your system name
    3. Select System Updates
    4. Select Check for Updates
  3. Launch the Sonos app twice in order to guarantee we fetch the latest feature flags:
    1. Start the Sonos app
    2. Force quit the app
    3. Start the Sonos app again

 

Wait, sorry, I screwed up. Swift native? That means there’s real hope of getting this right on iOS at least, and I’ll let Android users comment too. What parts are Swift and what parts are Flutter? This is crucial for accessibility.

The only portion of the experience that is in Flutter is what we call “wizards”. The cards that pop up from the bottom of the screen to either walk you through setting up your products or give you tips about how things work. With respect to accessibility, I can share that the wizards are reading the screen content on iOS. I just checked personally on today’s release.

Everything else is native UI. The home screen, search, browse, system view, now playing view, queue view, settings, etc.

One other piece of technology we use is a secure web view for areas that require authentication.

Overall, we think of this as one experience. We will not be satisfied until the entire experience is accessible.