[manigandham]

Since HN likes technical analogies: why do you use a RDBMS instead of flat files?

People don't care about how the files are stored, and they shouldn't need to. We've seen this in everything from music catalogs to file sharing to productivity software. We want content organized logically with metadata, tags, folders, lists and search that's completely removed from the physical location. Let the computers do what they're good at while the software lets you consume it the way you want.

[wwweston]

> 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.

[manigandham]

The separation between logical and physical data is a very old concept used to enhance UX everywhere and has been the general trend for decades.

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.

[wwweston]

> The separation between logical and physical data is a very old concept used to enhance UX everywhere and has been the general trend for decades.

I mean, yes. Files as we're speaking of them are in fact this very thing themselves. But:

> Most people are not concerned about files

Do you know how you know that? Is it based off of observation, or is it a story you like to tell yourself?

Like I said, I'm not pulling this out of my nose, I'm basing this off of real life observations including non-technical users. It isn't everyone who wants files in every case, but it is waaay more than a tiny minority. It's a little complicated given that you've got at least two curves you're dealing with (user experience and very roughly speaking intelligence), but if you imagine a bell curve and draw a line about a half standard deviation down from the median, roughly everyone north of that will likely care about files or file-related behavior at some point.

> they want music.

Ask yourself this: do you see "Copy Song Link" with Spotify tracks? What exactly do you think Activities are doing all over iOS?

These are ways of directing/handling files.

> If you do want to handle the raw files then there's nothing stopping you

Except sometimes in applications written/designed by people who think "they want music" means "Most people are not concerned about files."

[octorian]

> We want content organized in a logical manner with tags, folders, lists and search that's completely removed from the physical location.

The problem is that there's a lot of room for interpretation as to what is the best way to actually translate media metadata into an organizational scheme. Furthermore, the most appropriate interpretation is DIFFERENT depending on the type and/or genre of the music.

Most metadata-oriented media players tend to pick one scheme, apply it across the board, and completely screw up somewhere along the way. For whatever kind of music the developers had in mind, it'll work okay. For anything else, it's borderline unusable as you constantly struggle to find/browse what you're looking for.

[manigandham]

The whole point is you can structure it however you want because of the separation between logical and physical representation. Some players are better and more flexible than others but that separation is still a requirement to offer any kind of rich interface beyond just files on a disk.