You get into a routine of iterating on improvements, adding new features, and gradually scaling things up. You gradually expand that cycle of people. You try to generate some traction and build interest around your idea, validating it at a very small scale (friends, family, "Show HN", etc). You build something you can show other people. Here's how these things usually go: first, you start small. It feels like the cli was included as a sort of testing tool to check the underlying libs and code, and not as a usable version of the app itself - but it's still very early in development so the GUI might be the same. I can't do -h to find out what I can do with it, I can only call it with a spotify URL and get it to play and exit once it's done. Sure, psst has a CLI, but I only get panics. Sadly, these UI frameworks don't, or can't. The OS vendors spend a lot of time to make them usable and consistent. Because if they were, if they used native controls, the accessibility would be there. I'd almost go as far as to not call these UI's native. It doesn't guarantee accessibility, but the likelyhood is so, so, so much higher than any modern cross-platform UI framework. YouTube Music and Deezer had much better UI's from the get go.Īt this point, I'm almost happy to see an Electron app. I remember being very frustrated with the old UI's to the point where I chose another service just because it was more accessible, even if it didn't have a desktop app. Landmarks, clear labels, headings, and even aria-trickery to automatically announce things using my screen reader. The new Spotify UI released a few months ago is the most accessible Spotify has ever been. I just tried the GUI version of this client and was not surprised to find out that I could not use it.
Spotify web player without flash for free#
Something that Chromium apps do give you however, for free for the most part, is accessibility. Seems the larger the organization the more likely they are to build new Web rendered Desktop Apps and we have to rely on unauthorized Indie efforts like this for fast, responsive native UIs.
It's unfortunate the skill and desire of building fast native UIs are being lost to Electron and CEF wrappers. I wish they maintained 2 desktop clients, and left their native client alone to just be an audio player and push all their new social features to their new flagship CEF app. I expect it fell to the pressures of a growing startup adding 100s of developers (without the skill of their original CTO/devs) where a native UI couldn't be updated and re-iterated as fast as a Web App. I was disappointed to see their native client eventually be abandoned and succumb to become yet another Chromium wrapper. Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. Their traffic looked like it was initially seeded from their own (or CDN) servers (for best latency) and then overtime we would see some P2P traffic on the wire. It looked as though they had built their own custom UI renderer and optimized TCP protocol which sent back its metadata in XML. We we’re very surprised we couldn’t find any evidence of an established UI toolkit. We were building a Music Startup at the time, so we investigated how it worked. Everything was latency-free and instantaneous. I remember being perplexed at how I could search and skip to any part of a song quicker than iTunes could looking at a local library. What's funny about having to rely on unauthorized clones to provide a fast native UX was that Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.įew Apps ever had that wow factor the first time I used it, it was so much lighter and more responsive than anything else of the day.
0 kommentar(er)
