One of the original design goals of the iPhone was to try and do away with the whole concept of “files”. Each app was supposed to have its own special way of storing its data, and if that data needed to be made available to another app – for example, if you wanted to attach it to an email – the user would be expected to “share” the document with the email app.
That’s a very different proposition to the PC, where we expect to store data in discrete files within folders. So, we might write a document in Word, save it as a file within a folder, go over to our email app, and open up that folder and select the file to attach it. Apple looks at the world as apps first, files second – the PC look at the world as files first, software second.
The metaphor we use for the PC dates back 50 years to the original work done at Xerox PARC in the early 1970s where the engineers there decided to take the concepts of the desktop, filing cabinet, folders, and files, and present those as abstract concepts within their computer software. Very early computer interfaces would show drives pictographically as either entire filing cabinets or drawers within those cabinets. Fast forward to 2020 and we’re so used to storing data electronically that physical filing cabinets, folders, and even printouts and hardcopies seem archaic.
(Mind you, I’m writing this in Microsoft Word and at the top of the screen is a rendering of a 3.5” disk used for a save icon – floppy disk drives haven’t been a standard feature of PCs for over 15 years.)
Over time, we’ve learned to use network drives to store our organisation’s documents – first by using a file server within the office, and more commonly now to use some sort of cloud-based file system. When businesses transfer their files from local file servers over to the cloud, they tend to “lift and shift” the whole lot, rather than thinking about adjusting the paradigm as part of that work. It’s helpful to move the data over to the cloud – because it lets anyone work anywhere – but we’re doing ourselves a disservice to just limit that operation to “putting the files somewhere else”.
An important shift that is often not recognised with regards to storing files in the cloud is that it allows for people external to the organisation to be given (controlled) access to those files as well. Most organisations end up with a set of files that can be regarded as a sprawling mess of data, spanning hundreds of thousands of files over tens of thousands of files, all of which needs to be backed up, navigated, and – in the case of GDPR – carefully pruned in line with data retention policies and legislation. What we see now is an appetite for creating “project spaces” that are created for a certain, discrete activities, where people internal to and external to the organisation can be invited in to collaborate. These projects can be for things like setting budgets, putting together a new marketing campaign, investigating an operational issue, planning to acquire a competitor – anything and everything the business may do as discrete chunks of work.
All of those projects have files, but they also have other “artefacts” that can be lumped together around that activity. In the old world, how this might work is that you create a shared folder on a drive, and then use email to talk about the project, and also use email to send documents to project team members. If the team member was external, you might send them the whole file – if they were internal, hopefully you just sent them a link, but oftentimes attachments would get sent around via email here as well.