
# We Name Files Because We Have To

You have received a document, which you need to sign. You download it, and it is creatively named agreement_2023.pdf. You don't change this name, because you don’t have to.

Now you open it in your program of choice, insert your signature and save-as. You create a different file (because you signed it), and name it agreement_2023_signed.pdf.

Now, imagine that it is the following day, and you need to email this agreement to someone. Let's also imagine that the stakes are quite high (monetary, social, etc.), and that you only have one opportunity to do this correctly.

Do you upload the attachment and hit send? Or do you open it first, make sure it is the one with the signature, and then upload.

Nine times out of ten when I am sending a file, even if I have just created it, I will open it anyways, to make sure it is the right one. Is this a deep-seated mistrust of operating systems? Perhaps. For the context of this post, however, I prefer to think of it as "I know the right document when I see it.


## Example One: Pictures

Select your favorite picture from a recent outing or trip, in your phone’s gallery. What is its filename? Is it, dinner_with_jake_and_jess_october_2023.JPG? Or is it IMG_1231.JPG. Moreover, when you search for “Jake” or “Jess”, does that photo still show up? We take thousands of photos. To go through and name them all would be an outrageous chore. 

Diving into the past, if you were to develop a reel of film, you would get in return a pouch full of photos. Or, really digging, perhaps you got some _slides_ (a link for those unfamiliar). Photos are, generally, the thing that they are. That is, they don’t need a “filename”. At most, they warrant a date and a description. “Summer at the cottage, ‘23”. _This is not a filename_. 

And so, we see with photo and gallery applications that pictures and video are simply given an arbitrary title behind the scenes. You _can_ name them, if you want, but it will not make any difference to the application. 


## Example Two: Sheets

I have pulled this example from my favorite writing tool, Ulysses. Examine the screenshot of the application below. Each of the sheets are un-named, you can move them around, and even group them! The key feature here is the _preview_ that shows you the first line or six of the document. 

This may strike some Microsoft Office users as familiar. In Word, we don’t need to name each individual page that we add. In PowerPoint, we don’t need to name each slide. In the same way, in the overview panel (image) we can see the _preview_ of the slide. We don’t need a list of names to navigate!


## Example Three: Google Drive

When you are editing a document on Google Drive, you can at any point change the filename. You can change the file location. This _feels_ different from the file system on your computer. Changing a filename while the document is _open_? Moving a file while the document is open, and the _links to it still work?_ That’s because powering Google Drive is _not_ a file system like the one on your computer. Files are stored in some kind of arbitrary storage medium. You are manipulating values like “where it is” and “what it’s called” _without really affecting its actual location_. 


# The “New Folder (3)” Problem

Did you know that in windows you can change the default new folder name with a registry entry? I would never indulge doing this to someone’s computer as an april fools prank. 

Right now, without cleaning up first, how many “untitled folder 2” are there on your computer. Too many? _I have the same issue_. I believe this stems from a fundamental disconnect about how we create folders. 


## What Do I Call This?

I believe this prompt has resulted in more lost-good-ideas than should reasonably be attributed to a single concept. 

When an artist sits down at a blank canvas, do they inscribe the title, first? When a photographer composes a shot, do they first write down the caption in a notebook? No and no! So why, then, when using a digital system, are we asked to create a filename before we have created _the thing itself_. 

When I sit down to use a program, I have an intent to make something. Humans are fickle, and developers have spent countless hours minimizing the friction-to-start for any given app or program. I think, though, that in many cases it is an unforced error to make the user title their work, prior to starting it. 

There has been progress in this space, Google allows you to get right into a document, call it what you want and change it at will. This is good, but it could be better. 

Why name documents at all? File names are a technical holdover from a time when computers required a unique file descriptor for any given file. This is no longer a constraint. One might object, asking “what about search?” To that, I challenge, when was the last time you searched for something on your computer and actually found it?

We have _so many files_ that name-based-search is useless. We are also so bad at _naming_ files that name-based-search is useless. Semantic or content search is/was the hot-new-thing in searching your files. Why? Because we don’t need filenames. 

If I have two copies of a file, I care which is newer, or perhaps that one is signed, the other the original. Both of these could be in the filename, or, they could be contained in readily accessible metadata. 


## We Don’t Make Folders, We Organize Files

This may seem like two sides of the same coin, but there is an important distinction. Making folders is the act of labeling something that _will_ contain something, now or in the future. Organizing files is the action of taking a collection of _things_ and putting them in a shared location. 

I make this distinction because this is how we end up with “untitled folder 4” or “miscellaneous”. We have items that we need to group together, we _know_ they belong together. But titles are slippery, was it a project? Or was it just a one-off?

Like files, folders don’t _really_ need names. They are the sum of their contents. Maybe you scribble something on the front, maybe you _do_ print off labels for some. But not all, and it’s not a requirement. 


# File Management on Mobile Devices

For proof of the dire state of file management, I would look no further than trying to manage files on a touchscreen device of any kind. Many of the problems are the same, but some new ones are introduced. Due to these limitations, mobile design has trended away from files. 


## Silos

Data for applications is often saved either inside the app folder (and useless outside of it), or stored in a database of some kind, either on the device or cloud synchronized. The data is only exposed through limited scope _as the developer sees fit_. 


## Limited Input

On larger devices, side-by-side is an available feature. However, it is not possible for smaller devices in a way that makes sense. Due to a difficulty establishing intent, it is also slower to perform drag-and-drop operations (either enter editing mode or long press-and-drag). Finally, mobile keyboards are less performant, leading people to want to use them less. 


# Designing A Solution


## Things Must Still _Feel_ Organized

The problem with simply giving everything random-seeming names is that you lose information. As covered above, the name is still sometimes important information. Imagine if all the titles were removed from the files in your download folder!

Rather, what we need to do is level the “name” field with the other information. 


## Metadata

This sounds scary, nerdy, and something that engineers should worry about, but humans have been using metadata since about when we learned to draw.

An artist’s signature on a painting? Metadata. A date on a book? Metadata. A note scribbled on the back of a photograph? Metadata.

Now, if we pre-determine the types of metadata that a file can have, and ask the user to fill all these in when they go to create it, we are actually making the problem worse. Several bits of metadata are and should continue to be added automatically. Last opened/accessed, date created, etc. 

However, we should allow users to add _arbitrary and unconstrained_ metadata to their files. While on the surface this sounds like an architectural nightmare, it allows individuals the ability to organize their files how _they_ want to, not how the engineer or designer thinks they should. This is simply opening up the current file properties to allow for user-input.

Isn’t this just “tags”? No, tags alone are not powerful enough. Tags have no inherent priority, differentiation, or nesting. All of these elements are important for managing files. What does solve this is _dynamic properties_. That is, the user can add an arbitrary property to any file. We should augment this system with smart suggestions, to minimize mistakes. 


## Examining Physical Approaches

My favourite feature about physical organization, past the analog nature of it, is that you are practically unlimited in your approach. (Of course, it lacks certain qualities like search…) 

Take, for example, the plain manilla folder. Ubiquitous workhorse of physical organization, and the inspiration for the vaunted windows folder icon. Immediately, several properties stand out. First, you don’t _need_ to title it. You probably should, but you aren’t forced to. Second, if you choose a title, then you can apply that in whatever manner you see fit. Print a tag, Scribble on the front, sticky note, all up to you. 

It is to our detriment that we have elected to take primarily the image graphic form of the folder, and not its creative naming and organizational parameters. On some operating systems (windows, for example), there is some sense of preview when the folder icon is large enough. However, this is hampered by a critical lack of thumbnail generation, as well as the miniature nature of icons making it hard to read. 

Because there is no real cost to making a folder, outside of the emotional cost of naming it, humans are predisposed to making _more_ of them than they need to. After all, it’s not like you need to buy more of them (not to give windows developers any ideas about monetization). 

Digital folders also lack secondary, tangible qualities that physical ones have. For example, frequently used folders will be worn, familiar. Folders with a large amount of contents will be thick. All of these give us information about what it contains, beyond just the name on the cover. 

An ideal digital folder system could use some of these cues, for example making commonly accessed folders a slightly different color (progressively), or by varying the digital size of some other indicator as a measure of how much is in them. 


## Going Beyond The Physical

We gain some additional capabilities in the digital world. First and foremost is _search_. We can perform powerful queries on all of our files. Second, is _linking_. More powerful than shortcuts, is the idea that a singular file can exist in multiple places. Finally, more powerful previews of media such as videos and audio. 


## Arguing For “Groups of Files” Over Folders

In some ways this can be viewed as semantic, but I believe it strikes at the core of the issue. My downloads folder is a mess. Things that are important are removed to the documents folder, and sorted. Everything else… Well until my harddrive fills up or I get in the mood to clean, it just sits there. Looking at it, there are things I would like to _keep together_. While it is relatively trivial to make a folder, these things might not warrant that resource. 

There is an important distinction here, because making a folder is an intentional act, and it requires naming it. Say you have a couple of related documents that you have downloaded. They aren’t important enough to move into your documents folder, but they aren’t unimportant enough to delete. You _do_ know they are related, and want them to be associated with one another. 

However, because they aren’t important enough to put in your documents folder, it doesn’t feel appropriate to make a folder _just for these files_. Plus, then you have to name it. 

Borrowing a simple concept for vector editors, you should be able to _group files_. Groups don’t need names, and they are just as easily _un_grouped. 

What does this give you? Well, for one you can move files around a lot easier because they stick together. Two, you get better search, because grouped files should show up together. This increases your chances of finding the “right” file for any given search. 

To take a metaphor from physical organization, think of it like a paper clip or staple. 

By keeping files together, but in a more flat folder hierarchy, we reduce the complexity of navigating through the file system. 


## Mobile Devices

This is a bold ask, however, I believe that mobile OS developers (Apple, Google) should enforce a system that encourages developers to expose their files outside of their apps. As we have seen with Google Suite, this does not mean the _actual files_ lie outside of the application, they can be merely url links. But by doing this, we would empower users on mobile platforms for organize their data in a way that is good for _them_. 

A user could keep references to a Photos album, an iCloud note, and a PDF all within a folder. If they wanted to add a hand-written document from Goodnotes, they could do that too. 

This is a fundamental inversion of the files-inside-apps architecture on mobile, but in many ways is simply a return to the user-centric file management. This avoids having to set up the same project folder structure inside each and every app, while being unsearchable and effectively unusable outside of individual app ecosystems. 

Latest Writing

2023-10-02 - Stop Naming Files