We’ve been trained to make paper

TL;DR: If the internet is the primary medium by which content is consumed, shouldn’t that be the primary medium for which content is prepared?
3 minute read

We’ve been trained wrong. We’ve been trained that content creation starts by firing up a desktop word processor — a piece of software, mind you, that still does its best to generate a digital representation of a physical piece of paper — margins, page breaks, and all. Yet this quintessential workplace-place training simply fails to remain relevant in a world where we carry a computer in our pockets at all times. Our training now tells us to create content for the least-likely way it’s consumed: on paper. We’re stuck in an anachronistic workflow.

It’s not uncommon for example, for a team to need to write or edit a document together. Take the typical collaborative publishing process, which generally goes something like this:

  1. Draft content in Microsoft Word
  2. Save to shared folder or email around for comments and changes
  3. Manually (and opaquely) reconcile changes one-by-one
  4. Repeat steps 2–3 until satisfied with the document
  5. Convert to web-friendly format
  6. Publish

See what we did there? We’re still writing content for print, and then only once we’re completely done, begin to prepare it for web. That’s broken. That’s like building an entire car, and then at the last minute, deciding it should actually, in fact, be a plane. If the internet is the primary medium by which content is consumed, shouldn’t that be the primary medium for which content is written?

Using the wrong tools

Microsoft Word was designed with one purpose in mind: to make paper. Think about it. Its essential elements arose in the early ’80s. There are print-centric buttons like left and right align front and center, but newfangled internet things like hyperlinks or rich media are buried deep inside these labyrinthian sub-menus. Sure, it’s industry standard, but it’s an industry-standard workflow that arose before the age of the web (and hasn’t really changed since).

Yet the majority of the documents we create today rarely, if ever, embody physical space. They don’t care about the things Microsoft Word cares about — margin width, page breaks, or other properties that assume four sharp corners — and more importantly, they don’t handle mobile responsiveness, machine-readability, or other web-specific features.

Merely a snapshot

And then there’s the problem of collaborating. I can’t count the number of times I’ve been e-mailed a document entitled foo-document_2012_10_15_clean_fixed_revised_final2 or told that it’s “on the share drive” or asked “are you out yet?”. Without expensive software, that document’s just a snapshot in time. There’s no context. What updates does this version have that weren’t in the last? Wait is this even the most recent version? Who made the last three revisions? What happened with that change I submitted - did you accept it? Why not? Can we discuss? Can two people edit it at the same time? Not to mention — I have a crazy idea — can I go off and experiment in a parallel version?

Geeks solved this problem a long time ago. It’s called version control. We built it in the ’70s. We start with content, you edit it, I edit it, and we get better content. It’s really that simple, and better yet, it’s free. It handles curating the master copy, keeps track of every change (down to the character mind you), and even provides a transparent forum to discuss those changes in the context in which they occur. Take a look for yourself.

Jailbreaking content

So why doesn’t everyone use this “version control”? Because we’re trained wrong. We’ve got to break free of these proprietary, print-only formats. We’ve got to stop shuttling changes back-and-forth via email or with obscure filenames. We’ve got to un-program ourselves for an age of print.

And here’s why: .doc files are like tiny micro-jails for our content. Proprietary document formats tend to commingle the text we provide with the commands the software needs to recreate it, and it stores all this in a complicated and inaccessible binary format. That’s what makes it proprietary. We put text in — one of the most basic things computers understand — and we get this big mess back that can only be opened by that software. Imagine if the most common way to get water was to buy a can of Coke and run in through a Brita filter. It doesn’t need to be so complicated.

Break the habit

Let’s just concentrate on what matters: the content. When you separate design from content, things get a lot cleaner and a lot easier to work with. From now on, instead of clicking the little blue “W” out of habit, ask “does this really need to be a piece of paper?” If not, all of a sudden you can now use the best collaboration tools that human kind has made to date, rather than publishing tools that were made for a bygone generation.

And it’s not that hard. You can just click “edit” below (as an example), or the next project that comes across your plate, give Git a try:

  1. Learn Markdown - it takes 30 seconds. Honestly.
  2. Sign up for a GitHub account - it’s free!
  3. Install GitHub Desktop and Mou
  4. Create a repository and go to work

Granted some of the tools can be a bit rough around the edges at times, they are getting better, and like lots of other open-source technologies before it, as we move from paper-first to a web-only distribution, the time is ripe for a more evolved, text-centric, distributed workflow to become mainstream. Stop making paper, start collaborating.

Originally published October 19, 2012 | View revision history

If you enjoyed this post, you might also enjoy:

benbalter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit