The Death of External Storage: Where's Google?

Do you have any evidence that that's the approach they plan to take here, or is this just a lazy accusation backed by nothing but cynicism?

That said, once I tried copying/moving files around, I was sold on the 2-column layout. I recently got a new phone, which meant moving my custom ringtones and notification sounds to their correct locations. With Google Drive I downloaded them, then using X-Plore I moved them to the ~/Notifications and ~/Ringtones folders. That was fairly easy to do - you find the destination in the right hand column, then swipe back to the left column, select the files for moving, then choose copy/move.

It's kind of like the column mode in Finder on OS X, which I really wish I had on Windows 10.

One angle is it prevents apps from scanning your local storage for files and stealing them.

Another angle is that it blurs the line between cloud and local so that storing data on cloud services gets treated the same as local data. If you happen to own said cloud storage services (cough Google cough) then that direction aligns with your corporate interests.

I think you can manage files even without rooting. I plugged a phone (XZ1C, Android 9) into USB now, the computer offered to open the phone's storage, 2-3 clicks later and I see the photos that are stored on the phone.

Regardless of whether you think it's good or bad design, at least it's consistent IMO.

The sales figures disagree.

The other thing that killed them, as many have noted, was the lack of apps. That's because they were too late mainly; they were a me-too after iPhone and Android had already established their dominance. What app developer wants to spend a lot of time and resources developing a 3rd version of their app for a new platform that no one is using yet?

Somehow we're not discussing prohibiting filesystem access for personal computers? Why is this an issue for smartphones, a.k.a. a pocket-sized personal computer?

I remember wondering at the time: do windows and mac not do enough to help users organize their files, or are the cute little My Documents and Pictures folders that obscure the underlying filesystem already too much?

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.

That hierarchies can be expressed by tags is easy to demonstrate. Simply tag each file with all of it's parent directories up to root. Implementing hierarchies in terms of tags is not as computationally efficient, so you wouldn't actually write a filesystem in that way. The point is to create a new interface for humans, not for software. When a human has a dataset that is genuinely best organized as a hierarchy, they can express that hierarchy in terms of tags.

Of course traditional file hierarchies implemented in the traditional way, not in terms of tags, must still exist for some purposes. Source code, which requires a deterministic and efficient way to refer to specific other files, is one example. (However the user could still benefit greatly from augmenting the source code tree with tags.)

What I'm suggesting is not that hierarchical file systems be removed from operating systems, but rather that they be removed from nearly all user interaction with computers. The "Save as" dialog should not be exposing the hierarchical file system, at least not by default. Ditto the "Open" dialog. Hierarchical file managers like Finder, Explorer, Dolphin, Nautilus, etc should all be revised to be foremost file tagging systems designed to aid the user in managing and querying their tags. The "Desktop" should not be a directory on the filesystem, but rather a tag (or even a complex dynamic query.)

You don't put every single physical item you have relating to scuba into one big bucket because in the physical world, putting something into one bucket precludes it from being placed into another bucket. When you are organizing things you have to anticipate your most likely queries in advanced. So maybe you have one shelf for science fiction, and another for marine wildlife, and another for all your programming language books. For a while, this works well enough. One book can't go on two shelves, but with few enough books that's not a deal breaker.

However, when your personal library grows large enough, this system rapidly becomes impractical. At this point, the librarian resorts to creating a card catalogue, categorizing books by author, subject, etc. Books which have numerous topics have numerous cards in the card catalogue.

Since this is the 21st century, card catalogues are now digitized. The digitization of card catalogues saves space, but more importantly it facilitates more powerful queries. You can grab two different stacks of cards, relating to two separate topics, and instantly find the intersection between them. That is, the list of books which appear in both stacks. This greatly reduces the number of cards you must look through to find a book that you're quite certain is in both of the stacks. For instance each stack might have a thousand cards, but the intersection of those two stacks might only be 50 cards. That's 50 cards you have to search through to find your book, instead of a thousand.

A file tagging system is a digital card catalogue for your files. And as librarian of your library, you can decide which subjects warrant their own tags and which don't. What you don't have to do is decide ahead of time what sort of queries you want to facilitate. And it's no longer important to keep your collection of books and photographs separated. If you want a book, you intersect whatever you're looking for with the card stack of all books. If you want a photograph, you intersect it with the card stack of all photographs. If you have a book of photographs, it could even be in both, should you want it to be.

A communication-only device that can take photos and browse the web is very useful, but I think it will lose market to a proper computer every time.

Also, in the case of public computers, the risk of keyloggers means you cannot trust the computer even if you boot your own OS.

For applications there is lots of work to make it really nice. Putting mobile apps on "desktop" can be done, while user interface will be a bit strange. But that's a thing which needs time. Microsoft tried that by pushing mobile on desktop, but they didn't have the mobile story. Apple has notable Userbase on both.