Digital files have served us well, having helped bring us the digital age. But now that we’re older and wiser, do we still need them? And should they be allowed in our content programs? In this post I propose that the digital file—with its inherent limitations—may now be more burden than boon.
It all starts with metaphors
Metaphor is a constant force in the history of innovation, and is a powerful thing. Not only can it trigger innovation (Where else can this technology be applied?), but it profoundly influences the design process (Where has this problem been solved already?).
Metaphors serve as gateway concepts that enable us to leave the old world for the new without suffering too much cognitive dissonance. When something is too foreign for our brains to comprehend, metaphors anchor the unknown to that which is already known, allowing us to focus on classifying the novelty in a way that is generally consistent with our world view.
“Is this something that I can eat, or is it something that will try to eat me?”
It’s the concept behind the design technique skeuomorphism, which attempts to make software look and feel like its real-world counterparts so that it feels more natural. You may have used e-readers with “page curl” effects or digital watches that have hands. Or, if you’ve made electronic music, used virtual instruments with chrome-plated rotary knobs and wood grain.
These are all applied metaphors. They have a purpose, a time, and a place. But as the unfamiliar becomes mundane and their comforting quality becomes unnecessary, they also have a shelf life.
The rise of physical office metaphors
Electronic computing is by all measures a revolutionary concept, so it isn’t surprising that as computers were sold and marketed to a wider audience, that this process leveraged lots of metaphors, especially physical office metaphors, including the desktop, mail, folders, trash cans/recycle bins, and of course the ubiquitous document, otherwise known as the file.
In the physical world, files are quite useful. They represent a clearly-scoped, unambiguous container for content and information. They can be opened any number of times, duplicated, stored, marked-up, moved-around, organized, shared with others, and if necessary, destroyed.
These are all things that we’d like to do with content in the electronic world too. And since digital files can be processed far faster and at greater volumes than what is possible in the physical world, what’s not to love, right?
The dark side of metaphors
In Edsger Dijkstra’s paper, “On the Cruelty of Really Teaching Computer Science,” he discusses the problem of applying metaphors from the physical world to concepts in computer science:
“…though we may glorify it with the name ‘common sense’, our past experience is no longer relevant, the analogies become too shallow, and the metaphors become more misleading than illuminating.”
He argues that analogies not only project characteristics upon the “radical novelty” that aren’t true, but they can deny the thing its true potential.
Looking at the world through Dijkstra’s lens, it is easy to find examples of metaphors that have broken down, imposed unnecessary limitations in the space they’re supposed to empower, or have turned the tables by requiring the user be in service to it.
Look no further than your smartphone—which opted-out of many of the office metaphors previously taken for granted. Would your phone be more useful if it had a virtual desktop and trash can? Would it save you time if you could put virtual pieces of paper into virtual stacks and organize them into virtual folders?
Files’ strengths become their weaknesses
Digital files, as an applied metaphor used to manage information, impose unnecessary limits on information management. In the context of new information technologies, those characteristics which were strengths in the physical world become weaknesses in the digital world.
The “clearly scoped unambiguous container” problem
The information that lives in a file is static in a world where the demand for information is dynamic.
If I have a report, for example, and I want additional information that isn’t in the report, a new report needs to be generated. And since the file is a snapshot of the data, by the time it makes it to my eyes it’s already old news.
By comparison, systems that forgo the file container and use more database-like techniques can serve us by creating on-demand renderings of the real-time data based on whatever criteria we’re interested in.
The portability problem
In a world where systems can talk to each other directly, the flexible portability of files invites trouble. If data must go on a road-trip—riding in a file—it risks being subject to corruption, obsolescence, hijacking, and getting lost along the way.
If it’s a human who is playing host to the file, he must make a home for it so that he can find it later (which is also known as the “thing that needs to be physically put away into a folder” problem).
In the context of sophisticated search algorithms which can find and retrieve information regardless of where it lives, this requirement to organize files—inherited from the metaphor of the physical files—has become an example of “the tail wagging the dog.”
In certain business-to-business traditions, localization included, files have been used as an interchange format as way to exchange information between otherwise independent systems or independent steps within a process.
But from the standpoint of overall process efficiency, using files in this way represents several classes of muda (waste, inefficiency), including entire steps dedicated to:
- changing the file format
- running quality control to make sure something didn’t break when the file format was changed
- hand-offs and hand-backs, version control, file-splitting, etc.
The non-value-add costs add up quickly.
Alternatives to the file
In the world of building globalization solutions, the practice of processing content through files has been universal. And measurably costly. But things are changing.
When designing solutions today, if there is a file in the mix, we’re asking, “Is this necessary? How much will it cost to create and manage this file?”
Instead of bringing the content to the process (in the form of files), we’re looking at ways to bring the process to the content using web services, browser extensions, and other techniques that don’t force the content to go on long, expensive, and unnecessary road trips.
And this seems to be a trend.
The XLIFF-OMOS project is an attempt to make the XLIFF format (which aims to standardize the way localizable data is handled by localization systems) useful in a world without files.
“A top priority [of the project is to] unleash XLIFF 2, make it usable outside XML pipelines, and ready it for real time cloud services”
XLIFF-OMOS, you’ve got my attention!
What do you think? Are files a boon or a burden for your program? Something else entirely?
Let’s start a conversation!