Dave Young writes within the context of Localhost: RWX, a symposium and worksession at Edinburgh Sculpture Workshop from 29-31 October 2015. For more information about RWX, visit the Localhost website. RWX is funded by Creative Scotland, with support from New Media Scotland, Furtherfield, and Edinburgh Sculpture Workshop.
As smart devices shape the near future of personal computing, we – as users – are experiencing a shift in the way digital data is represented and accessed. For the last five years, Apple, Google and the other tech giants have desperately attempted to position themselves as market innovators and patent holders in the next generation of consumer tech. Over this period, we have seen more companies dropping desktop PC production in favour of novel gadgets such as smart phones, tablets, watches, fitness bands – and even contact lenses, glasses, and so on. A noticeable side-effect of this shift is that the ‘traditional’ filesystem interface, familiar to us as a visually traversable hierarchical structure of files and folders, is replaced by an app-centric interface. With its primary objective of being more user-friendly, this kind of interface limits as much as possible the tedious and touchscreen-hostile tasks of file management and directory navigation. It’s certainly worth reviewing how data should be represented in the modern Operating System – “tradition” is not enough reason to purposefully stick to an old system of files/folders, created by Xerox for their Alto/Star OS in the 1970s. That said, any radical change in the interface design of the filesystem needs to be critiqued, as it is acts as the mediator between us, our data, and our tools.
It’s worth emphasising that the aforementioned Xerox system is also a metaphor – it does not necessarily offer us a truer insight into the raw data on our devices than an app would. In the case of wanting to open a .txt file, whether we do this by selecting files via OSX’s Finder/Windows Explorer/one of the myriad File Managers in the world of Linux, or by opening an app on a “smart OS” such as iOS/Windows Phone/Android, we still achieve the same end goal: while the rudiments of the interface might change from one system to another, the .txt file is still utimately accessed and displayed to the screen. But between the traditional Xerox system and newer mobile interfaces, there is an interesting divergence. In the former instance, we navigate to the information, the precise location of the particular file /within/the/hierarchy/of/directories, then choose to open it with a tool of our selection. In the latter case, we select the tool, which then prescribes what information can be accessed with it. This simple inversion of intent does fundamentally alter our experience of the filesystem, but what’s at stake when we prioritise the choice of tool over the choice of file?
In the case of the former interface, we are provided with a visual map of our data. We can see where something is stored, how it relates to the other data we have saved, and also its related metadata. We are presented with an open scope, an indexical view of the files stored in our device’s memory. By default, we have the option of surveying data saved to our hard drive, and we can choose to ‘explore’ this should we so desire.
In the case of the typical smart OS interface, where the selection of a tool is prioritised over the selection of a given file, our vision of the filesystem is closed down by a “helpful” framework that only displays data that can be opened with a particular app. The messages app allows you to read your messages, the note-taking app allows you to speedily write notes, yet ne’er the twain shall meet – unless through a closed black-box framework, often labelled as ‘share’, which again guides you to an app that mediates your selection of file. As if peering through a keyhole, the user sees their filesystem in discreet parts and at particular moments, mediated by a given app’s functionality and filetype preferences.
It must also be said that, increasingly, much in-app data is often not even locally hosted on the device. It occupys no discernible, indexed space on its hard disk – at least no space that is visible and open to the user. Instead, it sits in a dynamic, transient “app cache”, where information is stored temporarily, to be frequently written, updated, and wiped without the user’s explicit knowledge or conscious intervention.
But this problem has a simple solution: why not just download a file manager from an app store?! It is of course an easy task to download a third-party file manager, but why was the filesystem manager done away with in the first place? Default configurations are rarely inert gestures. The omission of a stock file manager should be understood as a deliberate design decision intended to influence or shape the way we engage with the device. Is its omission, for instance, a desire to shake up what is seen as an antiquated interface? Is it a victim of contemporary design obsession about UI friction and clutter?
Searching for a file in a directory tree and not being able to find it can be seen as an example of friction. It is a moment where the ‘user’ becomes aware that they are ‘using’, activated by frustration or self-reflexive concentration and the necessity to make decisions, to search, to solve a problem. Finding the lost file is a terribly banale puzzle, but one that at least self-conciously engages the user. The app interface, which always tries to guess what you want to do next under its chief design objective of smooth simplicity, aims to remove friction. The smart OS is not free from friction though: when it guesses wrong, a manual solution can be more complex to rectify than the traditional filesystem interface, and perhaps at this point, the user realises they may not be as free to ‘use’ their technology as they expect.
Recently, we can see how some features of the smart OS are invading the desktop Windows, Mac and (to a lesser extent) Linux Operating Systems. Ubuntu, the most popular desktop Linux OS, raised controversy when its new Unity interface was unveiled in 2012, with a noticeably touch-friendly design aesthetic featuring large app tiles and fancy but pointless UI features. Was this part of the wider trend as demonstrated by Apple and Windows, where an ecosystem of multiple devices share smart and responsive interfaces, homogenous no matter the screen size, format, or method of interaction? Since then, Canonical (the parent company that develops Ubuntu) have attempted to venture into the smartphone market, working on both software and hardware, with an OS that neatly ties into the Ubuntu desktop experience. This approach to smart OS design is not simply a matter of convenience for the user, but good business sense too, especially as it becomes increasingly common for a technically adept individual to have a computer at home, a tablet in their bag, a phone in their pocket and a smartwatch on their wrist. Interface and brand go hand in hand: a suite of devices that play nicely together, share files conveniently over fancy wireless protocols, and look good when sitting side-by-side on a coffee table further encourages brand loyalty.
Despite its somewhat unforgiving text-based interface, it is the Terminal that perhaps offers the least mediation of all filesystem interfaces. Commands are taken as commands, presumed to be intentional and subsequently applied, whatever the consequences. When developed according to the UNIX philosophy of “do one thing and do it well”, command-line tools have the ability to “pipe” a standard output to an input of another tool – that is, each tool can share its output with the input of the next tool. Tools and files are thus recombinant, and in their purest form, are not hidden from one another. A basic example, featuring an ASCII cow:
ls -a #lists all files in the current directory.
. .. My_Computer.gif .shhh_super-secret.file
ls -a | cowsay #the standard output of 'ls -a' is piped into the standard input of cowsay. Hence, an ASCII cow lists out files for us.
_____
< . .. My_Computer.gif .shhh_super-secret.file>
-----
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
Or for example, the ‘cat’ command dumps the contents of any file into the terminal. It does not really matter what you try to ‘cat’ – it could be an image, or whatever is in the RAM of your computer – if you have Read permission it will duly carry out your command.
cat My_Computer.gif #prints file contents to standard output
GIF87a+#)#� ######�##�#�##�����#�#���#�����������������������,####+#)###�0�I��8�ͻ�`(��X�h���T#p,�GR#m#�8��@#��[#�7b�#h:�Ndϴ##���U�d##P+��~u#�v9,{ ��`.#��o#Zbg'�bM{ }#mxjp#��"?�ak�xG+~S�K#��;KAA<'&��#'L"a����#����#���#?��0(���������##4�MŹ#�##��3�#����#�I�8�68��#z�����<���7���)��-l��ڼ�#� ����C##*�###;
sudo cat /dev/mem #prints the contents of a device's Random Access Memory to standard output
Yet, despite its direct and explicit interpretation of user input , we must return to the fact that the command line is a simulation – or more appropriately, an emulation – of a interface that mediates our relationship with the digital information stored on disk. Its commands recursively refer to lower-level frameworks and architectures, until it reaches the level of bits and electrical pulses.
Ultimately, when we discuss these issues about interface and access to information , we come to much greater issues surrounding the essence of memory and access to knowledge itself. As with any indexical system of information management (whether we speak of the archive, the library, the museum, or indeed the filesystem), there are inherent biases in the structures of representation that mediate and inform how we relate to the information contained within. There is a strong history of theorists (Jacques Derrida’s writing in Archive Fever being the obvious one) who attack the politics of the archive and our habits of designing biased frameworks for the storage of memory – certainly useful in these times, when we shift from one interface whose biases are familiar to another whose biases still somewhat elusive and in flux .
In the present though, it has become increasingly clear that the interface bias of the smart OS prioritises data-access and content-delivery, focusing on consumption rather than production. Maybe a filesystem manager is surplus to requirement for many, yet the ommission of such a perspective on our filesystem creates some issues for us as users. The phenomenon of ‘black-boxing’ – whereby complex activity is cloaked and opaque, incomprehensible and impenetrable to the user – becomes normalised. As a consequence, we can’t easily understand the behaviour of an app and the data it produces/accesses, we can’t explore what logs exist on our devices, and what personal data is potentially exposed to typical threats such as viruses, malware, hacks, and thieves. The perspective we have is simplified, and in this case, to simplify is to remove options, alternatives, and user-agency. The use-possibilities of our devices are parametrised, governed, and constrained by the overarching system of app-centricity, while opportunities for subversive intervention and creative misuse are reduced as we are obliged to act and respond within the increasingly powerful context of app store regimes.
Those orphaned config files, scripts, metadata, caches, loggers and logs: they will continue to reside in our most obscure, exotic directories, unseen, but saved.
—-
Also Read
* Turing Complete User – Olia Lialina
* Preface to FLOSS+Art – Aymeric Mansoux and Marloes de Valk
* McKenzie Wark – A Hacker Manifesto
* The Interface Effect – Alexander Galloway
Furtherfield content is published
