At risk of sounding like every other ‘it was better in the olden days’ fogie out there (see also “I was born in the wrong generation!!1!1) - what the hell has happened to the internet? The internet today is distant in implementation to what Tim Berners-Lee envisaged when he designed HTML and HTTP. It is optimised to bring content to the masses with little permanence and accessibility via the open means inherently built into the protocols that underpin the internet. Instead, experience designers want you to use the content management tools they design that are engineered to trap you longer on their platform, and has the nasty side effect of making your saved content nigh impossible to reach via any other means.
Dynamic websites, that is, websites which have some from of document manipulation via programmatic means, most typically JavaScript, are in violation of the basic principle that a URI should target a particular document. By ‘document’, I don’t mean a page in general, I mean a discrete block of content on any topic - the content itself. In many cases, URIs now direct you to the start of a journey, or an interface you can use to access content. But accessing this content isn’t then reflected in that URI. It may be at /favourites instead. This article from the World Wide Web Consortium discusses the topic and provides good insight as to what the original plan was.
Files are scary
This problem is also visible in application design, particularly on mobile. In the 1990s, if I wanted to make an application for any Windows 9x computer, one would use operating system specific GUI toolkits like the .NET framework or Carbon. Applications would have OS specific flavours that integrated natively with the underlying operating systems, and utilize commonly expected functions available to them from the operating system. One ubiquitous example of this is the ability to read and write files to the filesystem, which users have visibility of through their OS’s filesystem browser. Since the late 2000s however, web applications have become increasingly dominant, and if they run on your desktop, they’re probably an Electron app. Web applications have increasingly been using self-contained file management locked within the application you are using. You can often export your creations to some kind of open format, but at the expense of some level of detail in what you export, as some levels of information will be ‘proprietary’, and thus unable to be exported. This locks you in to their platform.
Mobile program design is particularly interesting because it exhibits application design trends that were common in the 1990s desktop operating system market. Most mobile apps are made using native OS toolkits, just like they were in the 1990s. However, they are adopting the way of obscuring files within applications. To an extent, they’ve been forced to do this on mobile as file managers were mostly non-existent on mobile for some time. Apple was, and still is, fiercely against file management on iOS devices. And to be honest, they have a reason. Because test, after test, has proved that files are hard. People have difficulties finding them, organising them, knowing where they are, etc. And now we have the new problem that children under the age of 15 or so at the time of writing may never have used a computer with a traditional file manager. The whole concept of a hierarchical filesystem is foreign to them. So the UX designers simply want to be rid of the whole idea - why is an open filesystem useful anyway?
Because vendor lock-in wasn’t always endemic to application design. Once, we understood that open files in an open filesystem were the ideal system. The benefits are many: Any program can access any file. We can track all our files for a project together regardless of application. We can keep the content separate from the applications for efficient backups. But unfortunately this isn’t easy for people, so whether malicious or not, UX designers are rapidly increasing vendor lock in by taking the easier route - associating files directly with the applications by simply building the files into the application.
From the perspective of someone who needs to design products for customers needs, this is the right thing to do - as people understand it more. But I think it harms openness and freedoms of the way we manage our information with technology. It’s a tough problem to think about solving.
Perhaps one way to solve it, would be to introduce tagged filesystems into operating systems. This post from Project Nayuki goes into extensive detail on this topic, and is certainly worth the read to understand more if you are interested. This would allow us to keep our open filesystems, but make it easier for people to naturally understand and use them. I look forward to seeing if we get any traction on tagged filesystems in general use operating systems in the future.