5 ms·

> The answer of course is some form of file tagging, so that 'scuba' can be a single distinct group that overlaps with both 'books' and 'vacation' and 'photos',

• darkpuma 8y ago
  > "But that is separate from what file paths are for" This is close to my core point. File paths and/or file hierarchies are not good for file organization. They have been pressed into this role for historic reasons and out of inertia. Papering over the problems of file hierarchies by implementing a good copy-paste system is not a good solution to the fundamental problem. It alleviates some problems, but not all. You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year ago? How will you find that file? Under the file hierarchy scheme, in order to retrieve an old file the user must remember the idiosyncrasies of the hierarchy they created ages ago, with many concepts invariably being split into gods know how many subdirectories, OR nearly all of their files sitting in a small handful of directories, unorganized, with little more than the file name to help retrieve the desired file. These are both poor states of affairs. They require the user to store too much extraneous state about the system in their head in order to have any chance of efficiently finding the files they're looking for. Modern systems have begun to improve on this state of affairs by implementing file searching capabilities that function more like internet search engines than traditional hierarchical directory explorers. In theory the user may be able to simply search "scuba" and the black box file search system may use a variety of methods for pulling up a list of files from numerous different subdirectories it believes to be scuba related. Perhaps it pulls in both /vacations/2017/scuba/neat-fish.jpg and /books/scuba/how-to-scuba.epub because both have the string "scuba" in their path. Or perhaps there is some exotic shit going on behind the scenes and an image classifier was previously used to determine the presence of scuba gear in /Pictures/1002389943-984983-198395.jpg This sort of file search engine is fundamentally an imperfect file tagging system. The tagging in this case is being done automatically in a variety of ways the user may or may not be aware of and understand, and may or may not be able to consciously influence and exploit. Let's take a step back for a moment and define the problem: In the mind of the user, there exists a many-to-many mapping between files and concepts. When a user is thinking of a particular file, they have in mind a set of traits about that file. (For example, the user might be thinking of "that picture I took of a strange fish while scuba diving on vacation." The concepts associated with that file might be picture, fish, scuba, vacation.) How do we get that mapping out of the user's head and into the computer, such that it can be used by the computer to retrieve the files a user desires when thinking about a particular set of concepts? That's not yet a question with a definite answer. Automatic tagging of files with concepts the user is anticipated to have should certainly play a role. Image classification is heavy, and therefore has privacy implications since that sort of thing is virtually always offloaded to some corporate server, but when it works well it's great. There are easy sources for automatic tags as well, such as extracting terms out of the file path, or extracting date ranges or even geolocation out of the file metadata. These are great, but typically prove insufficient on their own. Asking the user to manually tag their files with the concepts they associate each file with gets you a very high quality many-to-many mapping between files and concepts, but that is manually intensive. Notoriously so. One solution is to amortize it; during file creation ask the user to tag the file instead of naming the file. That's okay, but still not great. The user might be snapping 10 photos a second and not care to take the time to tag or even name each individual file. How do we meet the needs of that sort of user? A solution I've been exploring is the creation of statistical models that assist the user in manual tagging, to blur the line between automatic and manual tagging. Here is what I mean by that: suppose the user imports 500 new jpg images, with metadata suggesting they were all taken in within a half hour of each other. The user tags ONE of those pictures with "vacation". What is the probability that the remaining pictures in that set are also vacation pictures? Pretty high. (Of course that's a trivial example, the user could just as well import the images all at once in a directory called 'vacation', but this goes back to my earlier point of extracting the many-to-many mapping that exists in the user's head. 'vacation' is merely one tag. By constructing the right statistical models, we can support an arbitrary number of tags.
  • zrm 8y ago
    > You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year ago? How will you find that file? With searchable tags, or whatever other thing you can come up with which is better than trying to remember a file path. But that doesn't mean you should get rid of file paths, because they're each good for different things and there is no reason you can't have both. Here's another example. On a desktop you can open a static web page from a local .html file along with all the associated content. You'll have a directory containing an HTML file, maybe some associated .png, .gif, .webm or .js files and so on. A complicated one may have its own hierarchy because it's useful within the context of that document. Then that HTML file is going to have the names of the other files in it, including their relative paths if they're in subdirectories. The same thing can happen with InDesign documents or any other composite document like that. Now how does the user find that HTML file a year later? Using some kind of tags or search function. But the way the HTML file then finds its associated pictures/scripts/videos is using something like filesystem paths. The alternative would be to combine them together into some kind of tarball, which is what some things do (like PDF), but then that's worse -- how do you edit a photo which is embedded in a PDF? Your average image editor will either not support it or will be inclined to do something horrible like rasterize the whole PDF first.
    • darkpuma 8y ago
      As I've detailed here (https://news.ycombinator.com/item?id=19523901 https://news.ycombinator.com/item?id=19523901), the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction. At the least, interaction with it should be opt-in, not opt-out. You're touching on a broader subject than file organization though, and that is humanist software design. Your static web page example is a good example. That's not humanist software design, it's design that serves the computer. When you save a web page you get an html file and a directory next to it that contains the images, css, etc of that webpage. The user is now burdened with keeping that html file and resource directory next to each other for the rest of the lifespan of that [meta-]file. Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) This unburdens the user; they no longer have to worry about keeping those files next to each other when copying it, sending it to other people, etc. Epubs are humanist design (and not only for this reason, but I'll save that for another discussion.) Of course inside that epub is a hierarchy of files. And that's fine. A hierarchy of files serves the ebook reader well. While strict hierarchies are poor for user interaction, they're great for software. The details of a file format need not be humanist because the user is not meant to pick it apart. Of course there may be perfectly valid and common use-cases for the user to pick it apart, to pull images out of it for instance. Software that facilitates pulling data out of documents, into a format that is generally useful to the user, is humanist. Consider your common desktop web browser for instance. It allows the user to easily pull an image out of a webpage by right clicking on it and saving it, or perhaps dragging the image out of the browser onto their desktop, or similar modes of interaction. The user needn't save the entire webpage, then poke through a directory filled with numerous files looking for the image they wanted. (At least, not unless the website and browser are conspiring to behave in a manner that is hostile to the user, for example by blocking right clicking....) PDFs and PDF readers are shoddy in numerous ways of course, and strict hierarchical file management has done little to alleviate that.