Building the Windows Phone Client (MixRadio Blog)

Back at the end of 2013, I wrote a blog post entitled Building the New Windows Phone Client for the MixRadio Developers website. It gives some insight into the way we were working back then and how we approached what was a major change to the app.

Rafe Blandford from All About Windows Phone gave his take on the post in How Nokia Built the New MixRadio Windows Phone App.

Originally published 21 Nov 2013 on

Back in mid-August, our WP8 development team here in Bristol set-about building the new MixRadio WP8 client.

Our Product, Design and Architecture teams had laid the challenge out before us and our service teams had started to build the back-end functionality.
Armed with a proposition, a design prototype and a release deadline, we got to work.

Agile Development Process

We use the Scrum Agile development process, with typically two-week sprints and our Continuous Integration build set-up ensures we build working code all day every day.

We are a team of 8 along with a ScrumMaster (SM), Product Owner (PO), designers and an architect. Our PO had a well-defined set of features that he wanted to see in the final product, and a clear idea of what was the minimal proposition from that list that we could take to release.

The only levers you have for any project are cost, scope, time or quality. With a fixed release date, an established team and a refusal to compromise on quality, it is vital that the PO has some flexibility in their requirements and allows the team to challenge the scope of any work.

Building Blocks

Having gathered a ton of feedback for our previous release (Nokia MixRadio 3.11), we started out on some stability improvements. We also tackled some technical debt that would allow us to build the upcoming features.

For any long-term agile project, having engineers take ownership of technical debt is a must, as it is an overhead that is completely invisible to the wider business. Our technical debt board ranks items by risk and importance. We review it regularly and pick-off items that align with the features we need to deliver.

Other sprint 1 work included improving our localization process which eliminated any development overhead of making text or translation changes for the 30 different languages supported by MixRadio.

We took time to discuss our planned target architecture for some of the more challenging work still to come and talked to other teams that we share code with and aligned backlogs to maximise code reuse between projects.

This meant that there would be no new features delivered for the first sprint, but we had front-loaded some high-risk changes and knew we could now quickly deliver some key features.


Personalised Music Playback

Sprints 2 and 3 were focused on giving some payback to the business for giving us the space to get our house in order during the first sprint.

We tackled stories for redesigning the home panorama including a new ‘mini-player’ UserControl which represents the current playing track. We also delivered an online-only version of our new personalized radio experience – Play Me.

Our back-end service teams had started to build the dynamic playback API for Play Me that could modify a mix in real-time based on user feedback. Although this was in the early stages of development, the interface was clearly defined to allow us to integrate early and gradually iterate improvements to both the client and service independently.

Internal User Testing

Now that we had built something worth putting into the hands of real users, it was time to launch our internal testing programme. Not every engineering team is fortunate enough to work for a large company that has an army of enthusiastic staff on hand all armed with a range of your target devices! We are, and we’re also lucky enough to have an internal trials team with a website to manage the trial and the feedback.

No matter how many test cases you write, you can’t beat getting software into the hands of real users. This is a goldmine of information for us from getting a handle on edge-case defects to getting a feel for how users react to UI changes.


Giving Users More Control

Sprint 4 introduced thumbs up and down controls to allow users to react to what they hear. This allowed us to send data to our services to influence our dynamic mixes.

We built the offline functionality for Play Me and added more analytics data.

Feedback and Iterate Using Analytics

At times we took advantage of our trial user data to experiment with UI changes. We moved the position of buttons and analysed data to check what impact each change had on usage.

We’ve also adopted A/B testing, driven by our service teams to experiment with different feature implementations in trials.

This allows us to prove or disprove our hunches about which how users will react to the application with real user data.

Sharing Music Tastes

The next sprint involved integration work with our MixRadio website colleagues to allow users to share both their personalized mixes and other types of mixes (those based on selected artists or curated by our music experts) via NFC, social networks, email or SMS.

We also built a route into Play Me for users who haven’t used our app previously where we take them through selecting their favourite artists. Finally, we added the store and gigs search box to the home pano which takes you into a two-pivot results page when searching and provides another route for users to purchase tracks and albums from our store.

Developers using our MixRadio C# SDK can hook directly into the new search page using a MusicSearchTask just as they would have done with previous versions of the app:

MusicSearchTask task = new MusicSearchTask();
task.SearchTerms = "Muse";

New Branding and Finishing Touches

By now, there was a real feeling that the original vision had come together and we were ready to release. All of our high-risk changes were done and all that was left was our rebranding to MixRadio and some other UI modifications based on assets provided by our design team. We had delivered on-schedule and had exceeded the minimum proposed scope of features.

We hope you like the end result. Happy listening!!

Created with Nokia Camera


One thought on “Building the Windows Phone Client (MixRadio Blog)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s