My last post “The Future Needs Files” clearly touched a nerve. The comments covered concerns well beyond what I intended. This amazing energy shows how fundamental and impassioned we are when it comes to “storing my data”.

However, I made a mistake by titling my post “The Future needs FILES” as several assumed I meant some archaic POSIX style approach. Exactly the opposite! I’m a UX designer so the goal was to focus on the user metaphor of “Documents” and how it unlocks more powerful use cases in the future.

But even “Document” has a bit too much baggage. Not so much “office docs” as potentially much smaller “blobs of my personal stuff”. These blobs have one core critical difference: they must be stored outside of any app that created it. I probably should have called the original post “Documents are Dope” but that didn’t quite have the right gravitas…

While I wanted to focus on how to organize my personal “blobs of stuff” within my devices, the Twitter conversations went quite broad, expanding the discussion to cover 3 broad types of “my stuff”:

My Device Data
This is the more classic blobs of stuff that I directly create that we’ve used for over a decade. But instead of locking these blobs within walled app gardens, release them to be freely available. Not only to other apps (to encourage cross editing) but to the inevitable productivity tools unleashed by machine learning. If my data is locked away inside of apps, these new tools can’t access these blobs. If there is anything we’ve learned from the history of technology is that competition and access are powerful multipliers. If we want there to be an explosion of business value, creativity, and innovation, we need to separate our data from the constrictive ownership of single applications. It’s really that simple.
My Cloud Data
Another related category of blobs of stuff people were concerned with were cloud based apps such as Figma. Much like mobile, these blobs are locked away within an app jail. If we can get the model right for device data, my hope is that we can extend this same model to the cloud. But let’s be clear, it’s a completely different tech stack so a simple ‘just do the same here’ feels naïve. My goal is to get the mobile/desktop model working first with the strong hope that once settled, it improves our discussion of how to eventually handle the cloud.
My Behavioral Data
There were also comments related to my personal data well outside of a ‘document” such as ownership of social media posts, my web browsing history, and the collection of personal data done by ad tracking companies. This is clearly important but feels like a much bigger topic and quite removed from my issues around productivity and working on my direct creative output.

Walk before we run

These three categories of personal data cover an enormous space. I’m not here to boil the ocean, attempting solve all of these issues. Let’s start simply and create a solid user model to build upon.

I want to walk before I run. By creating a better model for mobile, the plan is to create a clear user understanding of what is “mine” and how this is seen, stored, shared, and acted upon. The long term goal is to build on this model and layer abstractions that extend it for cloud data as well. I’ll take some baby steps in this direction in this post but it clearly needs more discussion.

OK, now let’s take a look at how I propose we “fix mobile”. We should have all of the APIs and tools in place. Nothing needs to be radically changed technically (at least I don’t think so, this may be a bit over confident…). There are six steps listed below, starting quite modestly and building as we go.

Step 1: Save standalone documents into their app folder

From my previous post, I praised the UX simplification that the iPhone created, by listing a small number of objects in a list within the app. This is a much simpler UX, grouping the data and the app together. There is nothing inherently wrong with this. The problem is that a simplistic implementation effectively hides the data within the app so other apps can’t see or act on it easily.

Surprisingly, my inspiration to fix this came from the Windows 10 Voice Recorder app!

This has exactly the same simplified UX as iOS, sharing that single scrolling list of ‘blobs’ within the app, but with a small but critical twist: every blob listed in the app is also visible in the file system:

This is the best of both worlds: a simplified UX for novices and full access to the documents for those that need it. So if I want to dump ALL of my voice recordings into an audio conversion utility that cleans them the audio, compresses them better and extracts all of the text from the conversations, that is entirely possible, with no impact on the main app at all. In fact, after these audio files are modified, they still open and play normally in that original app.

Note that many mobile apps already store their blobs of data as files visible in it’s app folder. This is certainly not a big, crazy step. I’m just saying this should be the norm for all apps.

Step 2: Use a common document format where possible

We see how helpful common formats is for images, audio and video files nearly every day. This not only allows other apps to open and modify them, but it also allows the OS to provide better preview capabilities when using the system file picker.

In my previous post, some were quick to point out that yes, having my data separate in an open document format is powerful, but then snarkily dismissing the premise by denouncing no app dev would ever do that. Sneaky logic but missing the point. The critical step isn’t 100% compliance on open formats but rather getting the document, in any format, outside the app and visible. This unlocks many use cases independent of the document format. And, as we have also seen throughout computer history, enables others to create document converters to step in when reluctant companies won’t. @tabatkins says it quite well here:

"Files" as arbitrary binary blobs have long enabled hostile interoperability – that is, you can take your files elsewhere and use them with something else, without the creating app's permission. Limiting to more structured types feels like it would limit this in practice.
— Minimalist Wall Clocks (@tabatkins) September 1, 2021

So having common document formats is clearly valuable and apps that do it will absolutely empower users. However, if some apps don’t, there are ways to transition to it over time. It’s not a deal breaker.

Step 3: Sub-folders within each app folder

Once we have documents stored in each app folder, it’s a simple extension to include sub-folders. Here is an example of the iOS Notes app with sub-folders for “Home Renovation”:

This allows for many more blobs to be stored and organized. There is some extra app programming required as many apps don’t have any type of hierarchy in place, it’s just a flat list. However, the iOS Notes app shows this is already possible.

Step 4: Create a Commons for documents

This is really just the equivalent of a “Desktop” area: a place to store documents outside of the app folder. The biggest advantage to this is a common space where documents from different apps can be collected together, e.g. everything for ‘ZJ’s Wedding” can be in one place. This liberates my data to associate with related data from other apps. Apps creating opaque barriers around my data makes finding all of my ‘wedding stuff’ quite difficult. This too already is possible on both iOS and Android, but not in a clean, system endorsed way.

Step 5: Move this Commons area to the cloud

Once again, taking a pretty basic step here by making this “Commons” folder mirrored to the cloud is a simple and obvious way to share my documents easily with others. In fact, this is pretty old school, doing nothing more than what Dropbox or Google Drive does today.

However, this isn’t a full solution. For example, it doesn’t handle simultaneous editing. That’s clearly a more complex problem but it does handle a wide range of powerful sharing and versioning tasks with little effort(Dropbox does today automatically). It’s a good step in the right direction.

We could go even further and copy the entire application folder into the cloud. There is nothing technically stopping this from happening, it’s just potentially a large amount of data and would have to be done carefully to manage user expectations, battery drain, and data costs. Starting with the Commons provides a clear UX model that ‘special things happen here’ which is under clear user control. That doesn’t mean we can’t have an Setting panel that allows users to choose which apps to backup. I’m just pointing out that, again, we don’t assume too much and offer more as we understand things better.

Step 6: ML scanning in the Commons

Much like the Commons area could be used to unlock an obvious user model to backup into the cloud, the same applies to any ML programs. The Commons creates a space that users understand are visible to the ML processes we’d like to encourage. In addition, folders in the Commons are a powerful semantic clue as they provide a strong clue that the documents in that folder are related so references or linkages between them can be prioritized.

In Step 5 I called out the need to be careful and not back up the entire app folder, at least initially. The same applies to giving ML processes full access to the entire app folder. That’s likely tricky and raises a series of privacy and control issues. Again, walk before we run, let’s start with a user model that provides a clear doorway and as we learn more, consider what it would take to open this across all documents in the app folder.

So what do we have?

These are all fairly minor steps. What do we get? For starters, it’s EXACTLY the same UX as we have today so there is nearly zero impact on users existing flows. However, it adds the ability to:

Have all of my data blobs be seen outside the app
Enable users to group related data blobs together
Have all data blobs stored and shared to the cloud (with simple version control)
The ability for ML processes to run over this data

I can imagine a few saying “old news, you can already do most of this today” which is only true for a narrow range of apps and only using hacks. Just because you can hack something for a few apps doesn’t make it a unified part of the OS. The point here is to make this a universal approach done by all apps in a unified way that is supported by various system services. For example having a clear shared commons area that is cloud backed up is a combination that just isn’t easy to do right now.

I can’t stress enough that this is just an initial step. I’m trying to create a model that is modest yet coherent enough to layer on all of these features. Like any explorations, there are likely things I’m missing or ways for this model to improve. Baby steps. Twitter likely won’t be kind but I’m hoping this model is “Good enough” that we can critique it into shape.

But the next topics to tackle are clear:

More nuanced versioning
Multi-user editing
Commenting
Web support for the same Commons area

I argue that getting a clear UX metaphor that works for solo work with a simple bridge to cloud backup and sharing is like a good start. I’m not here to drop the mic and leave but instead to pass it to you and listen. What is next? How can be build on this? I’m looking forward to the conversation.

Closing point: DX vs UX

I can’t leave without addressing the most common discussion point to my last post: even if this approach was a good idea, it will be hard to get the devs to do this. Just because “it’s a good idea” doesn’t mean it will happen. I completely agree! But we aren’t going to progress if all we ever do is say “Devs will never do this.” I appreciate the problem of course but it’s effectively saying “give up, nothing will ever change.”

So while I appreciate the difficulty, we must at least ask “What does the future need?” I think what I’ve proposed here is technically modest, using existing APIs for the most part. If Android or iOS decided to do this and shifted their internal apps to do this, it would provide a powerful incentive for developers to follow suit. Is it a guarantee? Of course not, but I’m trying to show that a significantly better mobile experience, one that maintains the status quo yet still unlocks a wide range of new productivity models is not only possible but well within our grasp.

It seems worth considering.