22 Nov 2014

The TagSystem — a Step Forward from the Filesystem

(Disclosure: I work for Google, but these are my personal opinions.)


For decades, we organised our data in folders on the filesystem. These folders are nested — you put folders within folders, and those in other folders, and so on, as deep as you need to organise your files.


Probably the first major advancement [1] over the 80s was Dropbox, freeing your files from the device they happen to reside on [2]. But a filesystem on the cloud is still a filesystem — you still organise your files in nested folders in Dropbox. So, if Dropbox is still a filesystem, what comes next? What would a step forward from the filesystem? How might we make the filesystem better?


I have a proposal, which I’ll call the “tagsystem”. Here’s the main idea: Imagine if the next version of your OS replaced folders with tags. Instead of putting files in folders, you’d apply tags to your files. And you can apply multiple tags to a file, unlike the filesystem, which forces each file to be placed in exactly one folder — no more, no less.


This is far more flexible than the filesystem, because the real world doesn’t neatly fall into exactly one non-overlapping category. Do I put my restricted stock documents in “Financial” or “Work-related”? Do I organise my photos by the place or by the year? There’s no one right answer, but the filesystem forces you to choose. The tagsystem is more flexible. It recognises that things don’t always fall neatly into a single category.


The tagsystem is still nested, like the filesystem is: you can apply a tag not just to a file, but to another tag. By doing that, all files tagged with the second tag automatically become tagged with the first tag. This is the equivalent of putting a folder inside another, which causes everything in the subfolder to also belong to the parent folder. Similarly, if you have a Tax tag and a Financial tag, and you tag Tax as being Financial, then all files tagged Tax implicitly become tagged Financial.


This holds for new files too: if, after you set up your organisation, you tag a new file Tax, then it’s again implicitly tagged Financial. This is again like the filesystem, where adding a file to a subfolder implicitly adds it to the parent folder.


So, the tagsystem is still nested, like the filesystem is [3].


But tags are more flexible, because a file can have multiple tags directly applied to it. This will hopefully mean that you will no longer need to have as deeply nested tags as you need with folders. For example, I organise my photos by year, and then by location, ending up with a file such as 2008/Singapore/DSC1234.jpeg. Here, the JPEG file is stored two levels deep. Whereas, if “2008” and “Singapore” become tags that are applied to the file, then the tags needn’t be nested — one tag doesn’t need to be a child of the other. Instead, they can be independent tags, and each file can be tagged with both 2008 and Singapore. We can depict this as {2008, Singapore}/DSC1234.jpeg. Here, the photo is only one level deep from the parent. So, I hope that allowing multidimensional grouping will lead to a shallower hierarchy.


And you won’t have to maintain parallel hierarchies. In this example, I actually visited Singapore in both 2008 and 2011. So both my 2008 and 2011 folders have a Singepore subfolder. This is an ugly hack, and will no longer be needed with tags. In fact, you’ll be able to see all your Singapore photos in one place, which you couldn’t in the filesystem world.


Further, the system can pull out information from standard formats like photos and music, and surface them as implicit tags. In this world, tags would be key-value pairs, with an optional key. For example, a music file will have tags of the form “Album: Dream Wide Awake” and “Artist: Omnimotion”. This information is just extracted from the file and presented visually (and at the API level) as tags. These are not actually stored with the file, as with a manually applied tag like “Favorite Music”. In the latter case, if the system didn’t explicitly store this tag, it would have no way of remembering which files you’ve tagged as “Favorite Music”. But the ID3 tags in MP3 files [4] already identify the album; there’s no need to store it again.


With implicit tags, you’ll no longer have to organise your Singapore photos by putting them in a folder or album named “Singapore”. Assuming the photos are geotagged, the computer should be able to figure it out, and not force you to spend time duplicating an organisation that already exists. In other words, it’s redundant to put your Singapore photos in a Singapore folder, because the photos themselves already say that they were taken in Singapore. Being forced to apply a redundant organisation wastes your time, and causes inconsistencies, such as accidentally putting your London photos in your Singapore folder.


Not only should not need a Singapore folder but you should also not need folders for Photos, Music, Documents, etc. These should be implicit tags. The computer knows what’s a picture and what’s music.


The system can also automatically tag files to identify the app you created the file with, the app you last edited the file with, and the app you last opened the file with. Another implicit tag may be the folder size.


The system can also inspect the header of the files and surface the file type as implicit tags. So, even if you had files that didn’t have an extension, they’d show up when you search for PDF files. If you double-click the file, it will open in an app that can handle them, rather than the OS putting up a dialog box saying, “Sorry, I don’t know what kind of file this is”. Applying a “.pdf” extension is redundant — the file already identifies itself as a PDF. Why should you have to tell the system that again?


File attributes can also be surfaced as tags — created date, last modified date, last opened date, file size, permissions, and so on. Extended attributes also become tags. In other words, one way to look at tags is that they are a more powerful version of extended attributes — so powerful that they replace folders.


Tags should be presented intelligently in the file manager. If there are too many of them, and some are nested within others, the nested tags needn’t be displayed in the UI. This is similar to how file managers display the contents of the folder you’re viewing but not of subfolders within that folder.


But if the hierarchy is shallow, with perhaps only one additional level of nesting, and only a few files, then the file manager can decide to cut through the hierarchy and show you sub-tags. This solves a problem with the filesystem, where if you have a half-dozen files in a folder, which fall into sub-groups, and you create sub-folders, you’ve now added another step of navigation to reach your actual files. Concretely, let’s say you went on a vacation and visited London, Birhimgham, San Francisco and Houston. It may seem more logical to group London and Birmingham as England, and San Francisco and Houston as US, but that adds another level of folders to navigate through. In the tagsystem world, the file manager can detect that this hierarchy is shallow — the “US” tag has only two sub-tags, and likewise for “England”, so it can show the contents of these tags directly in the top-level folder, perhaps below the parent tags and in a lighter font, so that you can bypass the hierarchy and directly go where you want.


Another example of intelligently presenting tags would be: photos can have implicit tags identifying their location at various levels of granularity: Old Madras Road, Bangalore, Karnataka, India, Asia. If you’re looking at a collection of your photos from all over the world, the continent and country may be relevant to display, and states and cities would show up once you pick a country or continent.


One can also imagine a map view for your photos. In general, since files can have many tags, implicit or otherwise, the file manager should make intelligent and carefully balanced decisions as to what tags are useful to the user, and in what context, and surface them intelligently, to help the user quickly do what they want, but without information overload.


Implicit tags can also be defined as rules, such as “All my photos from New Zealand”. This essentially tells the system that of the many ways in which you could theoretically browse your photo collection, this particular way is useful or important to you. This is similar to Smart Folders in Finder, Smart Playlists in iTunes, and Smart Albums in iPhoto.


These are really nice because once you define the rules that constitute your tag, it will automatically be in sync. That is, if you were to define a Smart Album in iPhoto for New Zealand, all your photos from New Zealand will automatically appear there, and no others. If you import photos from your camera, the ones from New Zealand will automatically show up in the Smart Album. This is much better than creating a plain Album in iPhoto, or a folder in Finder, for your New Zealand photos, because now you’re taking on the job of keeping it updated. This is a nuisance. If you’ve never used these smart folders or albums, you may not appreciate this. But using them made me understand how much easier they are to deal with, because they are always correct and precise, and never need maintenance.


The tagsystem also supports smart tags — tags that are defined by a rule, in addition to tags that you manually apply to files. Of course, we also have implicit tags that are created by the system to surface information that’s already present in the file or its attributes or extended attributes.


So, in summary, imagine a future version of your OS that replaces folders with tags. Rather than putting files in folders, you apply tags to your files. And you can apply multiple tags to a file. In addition to manually applying a tag to a bunch of files, you can define a rule for a tag — the tag behaves as if it’s applied to all files that match the rule. In addition to manually defined tags, the system automatically surfaces information from files, like the place a photo was taken, or the album of a song, or the type of a file (even if it doesn’t have an extension) as implicit tags.


The file manager intelligently decides how many and what tags to show to help you navigate your files, letting you cut through hierarchies and to navigate your files along multiple dimensions, without suffering from information overload.


This is a more flexible way of organising your files than nested folders. And its power and expressiveness should result in shallower hierarchies that are easier to manage. In other words, not only is the tagsystem more flexible than the filesystem, it should also be easier to manage.



[1] One of these detours is apps that abstract away the filesystem, and free you from opening and closing files, instead substituting them with a library that shows all your data. Apple arguably started this trend, with iTunes and iPhoto, but now other apps have picked it up, like Lightroom. Apple calls these kind of apps “shoebox” apps. 


The examples above are all standalone apps, but there are also other shoebox apps like Simplenote or Evernote that sync to the cloud. In other words, if you have two PCs, their iTunes libraries are independent, but Simplenote shows you the same view of your data on any machine. Synced or not, shoebox apps abstract away the filesystem.


The second detour is, of course, web apps. These effectively create silos of your data — I have some of my data in Simplenote, some in Dropbox, some in Gmail, some in Google Drive, and so on. In the traditional PC world, we may use multiple apps, but we’d ultimately save all our data as files on the filesystem. With web apps, there are no files to manage — they are all stored on the servers of the company whose product you’re using, and you access them only through the UI. In that sense, they are no different from shoebox apps. In other words, Simplenote has both a Mac app and a web app, and they work almost identically.


The third detour was the iPad, which did away with the filesystem. People were eagerly waiting for Apple to develop a replacement, but they dropped the ball, leaving iOS with simple but rudimentary storage management.


[2] You can look at file servers on a LAN are a precursor to Dropbox, in companies or educational institutions. But they were limited — they’d work only as long as you were on the LAN, and they were slow even then.


[3] And it has to be, to manage complexity. If you couldn’t apply tags to other tags, and you had to apply them to each file, you’d go crazy trying to individually tag thousands of files. If I have a Chillout Music folder, and I put that within my Music folder, I no longer have to individually tag each of the thousand or so chillout songs in my library as being Music. My Dropbox has more than 6000 files — there’s no way I can tag each of them. By grouping them into folders, I can now treat the entire folder as one unit. This makes it less tedious to organise, and the simplification is what lets us manage thousand of files without running into our human limits on the complexity we can manage in our heads.


iA puts forward an insightful argument that humans just can’t deal with nesting. The argument goes that we can deal with putting files in folders, and maybe folders in shelves, and shelves in cupboards, but not folders in folders. Maybe nesting is hard for anyone who’s not a geek to comprehend, but otherwise you’d go crazy trying to organise thousands of files.


In that sense, nesting is no different from driving a car. Does it come naturally? Of course not. It’s hard and it’s scary. But learning a car, while complex in and of itself, simplifies our lives, by giving us mobility, rather than having to depend on public transport. Learning the tool itself is complex, but the tool simplifies our lives far more than the complexity of the tool itself. It’s an investment worth making. Nesting falls in the same category.


So, we need nesting of tags, being able to apply a tag to another tag, as much as need nesting of folders.


[4] Or their equivalent in AAC files.

No comments:

Post a Comment