Recently I decided to familiarise myself with Deezer, because I feel the service could start making some big moves this year and that therefore it would be good to have some insight as to the platform, the user interface, what’s possible etc etc.
Something that really caught my eye when using their web client though was the way in which many of the Deezer “apps” were basically just external websites that were using the Deezer API to provide their audio. This led me on a train of thought around both Deezer and Spotify apps, where I concluded that in many respects what we have here is a massive case of Emperor’s New Clothes. A chat with Syd Lawrence on Twitter basically confirmed that, too – which you read on Storify here.
Let’s start with the basics. Spotify’s desktop client is basically a jazzed up Chromium browser, as I understand it. The Spotify apps that run within it are, to all intents and purposes, websites. They’re code being pulled from elsewhere and run within the Spotify desktop client. Similarly, Deezer’s apps run in a similar manner – though often not even within the Deezer web client.
That being the case, one has to ask the question: why are the people behind these apps not broadening them out to run on the web, connecting in with all available services? Take the Earache Metalizer Spotify app, for example. I’d wager that with probably an extra 20% of time spent on it, that could have been adapted to also run within Earache’s website, pointing people to the streaming service of choice, be that Spotify, Deezer, Rdio or potentially something else.
This isn’t – and shouldn’t be – an “either/or” scenario. I would assume you could have the same app available in Spotify, Deezer *and* on your website if you so desired – and why not? It provides convenience to your users, after all. So why aren’t people doing this?
Continue reading “Spotify & Deezer’s apps: The Emperor’s New Clothes?”