Hacker News new | past | comments | ask | show | jobs | submit login
Spotify - Chrome Web Store (chrome.google.com)
34 points by jacobwg on April 13, 2013 | hide | past | favorite | 50 comments



Isn't this just a bookmark for http://play.spotify.com/ ?


I has always bothered me that Google is branding a bookmark with an icon as an "app". Current app counts: Apple app store ~= 800K, Google Play ~= 900K, Chrome apps = number of URLs on the internet.


There is a bunch of functionality that you can do with Chrome apps, such as desktray alerts, background music streaming, etc. Most of the "apps" in the store do not do this and are mostly just links to sites, but there are plenty of things you can do with Chrome as an app that go beyond regular browser capabilities.


Those are features of Chrome and not really an "app". It is not new for web developers to target specific features of a web browser. I have not qualms about calling Chrome apps that can be ran offline apps. Perhaps I am looking at this from the wrong perspective. For Chrome OS, a link that is acting like an app that you can "Alt+Tab" to would play better into the idea of an app than another tab in your Chrome browser. Almost every "app" on the chrome store I have interacted with has been an app-like icon that is a link to a URL that functions identically in Firefox or other browsers.


I think earbitscom is talking about the protected APIs in Chrome. There are APIs that regular web sites get and there are APIs that extensions/packaged apps get (like local file storage). Chrome Web Store is still a weird concept for me, but especially so when most of the 'apps' are, as you mention, fancy bookmarks.


Some Chrome apps aren't just a few specific browser features though, they're literally full packages that you download that have the ability to go through your files, run native code, access to bluetooth, USB, the ability to embed a WebView (like with Android), access to everything extensions can do and more.

Even some of the "bookmarks" add extra functionality to a site that wouldn't have been able to be granted otherwise, like unlimited storage, access to the clipboard and the ability to run in the background.


It would be very useful if the bookmark ones were a separate category, just like there's a distinction between extensions and apps.


What exactly should they do, disallow all apps that don't use a chrome.* API?


I like the suggestion that lucian1900 made.


Yeah, I think the point is that it's finally web based.


You need to visit a different link to enable it-

https://apps.facebook.com/get-spotify/?fb_source=notificatio...

Once you do that, then play.spotify.com will work. I believe it's still in beta and some weird bugs showed up for me about a week ago, but it's still sufficient.


Yes, but then most of those Chrome web apps are!

Extensions however add extra functionalities other than a web page! I never understood all those fancy names and screenshots for the Chrome Web Apps when in the end they are just bookmarks with a big pretty icon!


Note that it is still US only though, if you are based in a different country it will just forward you to the Spotify homepage.

On a different note, does anybody know why they started with native clients instead of one web client? I can think of some advantages of native clients (P2P streaming as the have it, better OS integration etc.) but when compared to the big disadvantage of having to maintain two codebases (Win + OS X) and deliver updates to both I would expect it to require more resources for them than one web client for all.


> ... but when compared to the big disadvantage of having to maintain two codebases ...

It's about your users, not your developers. Of course it costs more to provide a better product, which was the original reasoning behind providing native desktop applications.

What they're doing now has more to do with politics and skillsets amongst traditionally web-focused engineering management and teams, than it does with actually creating a great product. Spotify has a ridiculously hard time hiring outside their management's core competency of web-focused development, including both for mobile and desktop. That has more to do with their management than the job market, though.

As an aside, I can't say I understand why web developers find it so impossible to migrate to mobile/desktop. Time and time again we work with organizations who have built a large server-side web-focused team and somehow simply cannot manage to support the mobile/desktop. What kinds of engineers are they hiring that they can't learn a new platform?


What kinds of engineers are they hiring that they can't learn a new platform?

Speaking as a web developer, I can tell you that I am perfectly able to transition to making desktop apps, I just have no incentive to. There are fewer and fewer desktop apps out there, so it's not a great use of my time to learn those skills.

Back to the Spotify player, the web client makes far more sense than a desktop one to me. All the music is stored in the cloud, so why do I have to download a desktop client on every machine I use to access it? It seems horribly backward to me.


> Speaking as a web developer, I can tell you that I am perfectly able to transition to making desktop apps, I just have no incentive to. There are fewer and fewer desktop apps out there, so it's not a great use of my time to learn those skills.

Funny that you speak of it as a dead market, when A) The skill cross-over between desktop and mobile is direct, B) There's a huge amount of unfulfilled demand for mobile developers, and C) There's an enormously underserved desktop market (see also: Spotify, Netflix, HBO Go).

> Back to the Spotify player, the web client makes far more sense than a desktop one to me. All the music is stored in the cloud, so why do I have to download a desktop client on every machine I use to access it? It seems horribly backward to me.

Running a full fledged browser, with the resulting poor application UX, for a lightweight task as music streaming, seems horribly backwards to me.

All I want when music is streaming is a miniplayer, not a web browser. It should work with the play/pause/skip buttons on my keyboard/headphones, support airplay streaming, be able to integrate with my music library, and otherwise fit in nicely to my desktop/mobile experience.

If I worked for Spotify, Hulu, Netflix, or HBO (Go) (which I wouldn't, because they're myopically web-focused), I'd be beating the war drums to provide better, more engaging user experiences via native applications for not just mobile, but desktop too.

Unfortunately, it winds up being a catch 22. They build technological monocultures (web-focused), can't hire for alternative platforms, contract out the mobile development, and then the web developers use their political positioning to try to turn everything into a bad shell around a web rendering view. The users lose.


Perhaps a better way to look at it is this- when I have a great job doing web development and see job listings all over the place for other rewarding web roles, where is my incentive to do desktop development- even if it's close to the (much more booming) mobile app space? The web is in no danger of dying or getting less popular any time too soon.

Running a full fledged browser, with the resulting poor application UX, for a lightweight task as music streaming, seems horribly backwards to me.

But that isn't why I'm running it. I have a web browser open every minute I'm using my computer, so it's already there. The browser is a multitasking application itself, so using it for music streaming fits in great. I haven't used the Spotify web player, but Rdio has been web-based from the start, and has been great.


> Perhaps a better way to look at it is this- when I have a great job doing web development and see job listings all over the place for other rewarding web roles, where is my incentive to do desktop development- even if it's close to the (much more booming) mobile app space? The web is in no danger of dying or getting less popular any time too soon.

Because it would provide a better product for your users, which is the whole point.

It also shouldn't be hard to do. A senior engineer that can't easily jump on new technology stacks is not a senior engineer.

> But that isn't why I'm running it. I have a web browser open every minute I'm using my computer, so it's already there. The browser is a multitasking application itself, so using it for music streaming fits in great. I haven't used the Spotify web player, but Rdio has been web-based from the start, and has been great.

An arbitrarily resizable browser window/tab that looks like every other browser window on my desktop, which can't share state between multiple windows, and can't interact with my desktop in any meaningful way, doesn't use native components, goes wonky if I reload, and goes away if I have to restart my browser.

That doesn't make sense. This makes sense: http://www.pandabarapp.com/


I like how you're talking about good user experiences and then use that as an example.

Furthermore, that wouldn't as easily transfer to Windows since taskbar notification icons are routinely hidden.


> I like how you're talking about good user experiences and then use that as an example.

What's your point?

> Furthermore, that wouldn't as easily transfer to Windows since taskbar notification icons are routinely hidden.

Mac OS X isn't Windows. Part of writing native applications is working with established platform conventions and user expectations, not trying to rubber stamp the same thing everywhere.


> What's your point?

It's ugly. It doesn't look nice in the slightest. It doesn't scream to me "Boy, this looks like an awesome user experience. I better try it out!"

> Mac OS X isn't Windows. Part of writing native applications is working with established platform conventions and user expectations, not trying to rubber stamp the same thing everywhere.

Then there is no good user experience for Windows. There goes your UX angle.


> It's ugly. It doesn't look nice in the slightest. It doesn't scream to me "Boy, this looks like an awesome user experience. I better try it out!"

Why is it ugly? What, specifically is wrong with the UX?


The UI is non-standard:

- The buttons aren't styled like Cocoa buttons

- The gradient is non-standard

- Why is there so much lime green?

- Why is there a lime green border?

- The images don't look like they scale well, they look blurry and not very well defined, even in the screenshots

It's supposed to be a Mac app but it doesn't use any of the guidelines published by Apple on conformity in the UI. That makes for a horrible user experience, especially when your app is made for the platform which embraces uniformity across its apps. It is not using any UI elements which the user is accustomed to, instead opting for custom-styled everything.


These are all aesthetic complaints, not UX complaints. The UX is standard.

Now, I actually happen to agree that it's not the prettiest app. But it is a very usable app, in ways that a web browser music player is not.

I also get the impression that you're just being willfully contrary and not particularly genuine.


Besides the P2P, I think that with the native client they went after iTunes at that time. Their first versions of the client (not sure if current ones), scanned your hard drive to organize your music library, allowed you to purchase individual songs and also to sync your iPod. Now iTunes is not their main competitor, but Rdio and Pandora are, that's why I think the strategy shift.

Having a native client was the feature that caught my attention and made me try Spotify in the first place. I was tired of implementations that used to hang my web browser or consumed lot of memory. But that was back in the time. Their latest Mac OS client is very memory hungry, almost every time on my top 3 of applications consuming the most memory.


They were leveraging p2p streaming to reduce their costs.


So the web version definitely doesn't do p2p? This would be good for work where there are usage agreements that specifically prohibit p2p


I don't see how they could do that with a regular site, given they would need to access the files on your computer, or cache an insane amount of music. But perhaps that's one of the things their Chrome app does that their regular web destination does not.


I'm in the UK and it is working for me so its definitely not US only.


Robin, the tutorial behind this link will enable it for you if you haven't got it yet: http://howto.cnet.com/8301-11310_39-57551372-285/enable-spot...


It's not US only. I've had access to it for a while now.


Their team came from Skype and Joost so they had more P2P/native client engineering talent.


The webplayer seems to take more memory in total and offer a still significantly worse UI than the desktop counterpart.

I'm not impressed yet, and I know that better web experiences can be delivered.

However, now that I see this webplayer and recognize a few similarities with the desktop player, I can see why many of the horrifically terrible changes to the native player happened recently.

They were getting rid of native rendering and replacing it with rendering a webpage. No wonder people were so pissed and no wonder so much functionality was dropped.

EDIT: Okay, I'm going to say this. Webapps: USE MY RIGHT CLICK. You are NOT A WEBPAGE, so don't use a webpage right click!

Right click a song in native app: Play, Queue, Add To->Lists, Radio, Copy 3 Kinds of Links, Share, Delete from Playlist.

Right click on a song in web app: Back, Forward, Reload (breaks playback lol...), Save, Print, View Page Source, Reload Frame...

I love my right click menus and not having them in a webapp is very frustrating. Oh wait, this is supposed to also work for touch so I will never get a real alt-menu again, will I?


> They were getting rid of native rendering and replacing it with rendering a webpage. No wonder people were so pissed and no wonder so much functionality was dropped.

I can confirm this, and have heard that this was politically driven by their web-focused engineering management and teams.

Netflix did the same thing, for the same reasons. People built up web fiefdoms and had the political clout to put their job security ahead of user experience.


> Note that it is still US only though

I don't know about this specific extension, but if what another commenter said is right (that it's just a bookmark for play.spotify.com), then I've been able to use that site from here in Southern Europe since I found out about it (not that it wasn't a hassle to find or get going in the first place though).

I don't know why it would start out being US-only, as the native application seems to have arrived relatively late in the US.

PS: The Spotify home page is god-awful these days: a splash page plus auto-play music, I thought we as a species were over that stage...

EDIT: the fact that I can use it might have to do with that I have Premium.


Am I the only one that actually prefers to use a desktop app for listening to music?

I mean, media keys integration, faster UI... The biggest selling point for Spotify to me was how _fast_ it would play songs...


Good to see another groundbreaking Spotify "innovation."

I remember Grooveshark getting into the chrome web store almost two years ago.


I definitely don't see Spotify parading around calling this a groundbreaking "innovation." It's convenient for people like me that use Spotify 24/7 and want the choice between web and desktop.


Seriously? Spotify and Grooveshark aren't even playing in the same league. Grooveshark's audio quality and music library are a wreck compared to Spotify's clean, consistent and reliable one. This is like people who decried the iPod and foresaw its doom because "Archos had the same thing available for 2 years." Not comparable.


I don't remember anyone calling it innovation. How about a nice feature addition to a service? After all, Spotify also has many other "innovations" Grooveshark doesn't: a clear legality, accurate track and artist catalogues, and paying all of their artists (even if it isn't much, it is certainly more than Grooveshark).


Finally! Web-based browser. It's actually pretty good. I like the interactions


play.spotify.com has been around for a while.


Why have Spotify decided to make a Chrome web app rather than just making a normal website, such as Grooveshark?


It is a normal website if you have access: http://play.spotify.com/


The 'web app' is really just a bookmark for: http://play.spotify.com/

Hopefully they add some other features like storing music locally, which might require more Chrome integration (I don't really know).


They could store music locally using the File System API and Encrypted Media Extensions (to make the labels happy), but seeing as no one has done this before it probably won't happen for a while.


Seems really dumb to not mention that a) you need to be signed up to the web player beta and b) although they mention Collections, the collections feature still isn't live, and in fact is just a poor choice of wording on the chromestore page.


It downloads and installs something, but then clicking on it just send me to the Spotify homepage.

Not the experience I was expecting, Spotify.


Maybe I'm missing something because I'm not in the US - what's so special about this?

It looks like merely a link to the Spotify website.


For those in the Spotify web app beta, this is a link to an entirely web-based version of Spotify. If you have a Spotify account, but don't yet have access to the web version, check out http://howto.cnet.com/8301-11310_39-57551372-285/enable-spot....




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: