| > People don't care about how the files are stored, and they shouldn't need to. The second clause of this sentence is a pretty good software design value. The first part is overgeneralizing at best. Some people care very much about where in a folder/directory system their files are stores. I'm not just talking about HN audiences, I'm talking about actual people I've observed from personal acquaintances to real live user testing. Files are not some weird obscure technical point they're a dominant metaphor that's been used in computing workflows longer than more than half of HN has likely been adults. Lots of people know and care how they work. This is especially true for music files, where people have been ripping, transcoding, slicing/processing into derivative works, backing up, and yes sometimes sharing files for longer than iTunes has existed. They're not perfect for every application and user. An application-specific database with a different use profile might be good to have between the filesystem and a user. Users shouldn't have to care. But if we really mean "the software lets you consume it the way you want" then you don't really want it completely removed from filesystem location. You want to keep facilities that allow users to find underlying files and keep them easy enough to find. You want to accommodate use profiles where users may bring in files from outside your curated market, or even choose to intentionally organize files in a way that your application doesn't by default. |
Most people are not concerned about files, they want music. Tracks, playlists, artists, albums, etc. That's how they think and interact, and this abstraction provides that rich interface. That's why it's so seamless to switch from iTunes to Spotify where everything is streaming, because the basic primitives are not files.
If you do want to handle the raw files then there's nothing stopping you, but it's definitely a tiny minority.