With individual track files living inside each album directory.
At the time, I was running Linux on my home PC and spent a lot of time navigating file structures in a shell. Having my music organized hierarchically was useful there, and I spent a bit of effort maintaining the system, even going so far as to write a shell script that would automate the creation of file structures for unclassified files.
Today, my habits have held over even while technology has changed. I still think of my media collection in terms of files (so old fashioned, I know) , and I keep iTunes in the "column browser" view. It works, but it's antiquated; were I more modern, I'd stream media exclusively and would search a cloud library for tags (created through folksonomy), not browse by static, predetermined layers of organization. When I was running Linux that wasn't an option, and my hierarchical organization was my easiest and most effective way of sorting songs. Now, that advantage is slipping away in the music industry, as social and cloud-based streaming services become more and more intelligent about how they thing about the qualities of a song or artist.
In other facets of my life, hierarchical organization gets closer and closer to obsolescence. When managing 3D assembly models, I find it tricky to establish naming sequences that will make sense across projects and phases of development. I tend towards part names that begin with two letters and end with four numbers. In a given filename, I follow the part name with a short verbal description. The end result looks like this:
"BK1008 Rack End.ipt"
Here, the file extension is .ipt, which is the Autodesk Inventor extension for part files. This particular part is one I designed for custom bike racks, and the prefix "BK" refers to bikes. The part lives in a directory called "BK Bike Parts", along with a bunch of other - related and unrelated - parts. Parts are categorized in directories according to the purpose they're originally designed for, but they're often repurposed or discarded. Their part numbers are just placeholders, and the descriptive titles I give them are often mostly meaningless. Often times, one designs a part with a particular form in mind and names it accordingly. Over time, that form changes, and in the end the name is nothing but a vestige. It's a kind of a Theseus' Paradox, and one that conventional naming schemes - or mine, anyway - don't account for well.
I'm happy to say that I have no idea what my files naming sequences will look like in five years. Jordan Brandt, Technology Futurist at Autodesk, predicts the death of files in a way that strikes me as totally prescient here. I'm not totally clear on the implications, but he describes a world in which part metadata is stored at attribute tags, much like Facebook photo tagging. Such a system would, I presume, at least initially require the user to set up searchable tags in order to enable reliable part retrieval. Eventually I'd hope that attributes could be generated predictively, much like Facebook scans photos for faces and auto-suggests likely matches for who to tag.
At this point, my file naming conventions would become irrelevant. Brandt puts it very well - I *never* need to look in a particular folder, or for a particular filename, when I want to find a photo on Facebook. It's tagged with all the relevant data, and with adequate search tools it'll never be hard to find. Eventually I expect the same to be the case for the little gadgets I'm designing: their identities becomes more and more tied to their actual attributes, rather than some arbitrary and cumbersome naming sequence.
