Sharing, saving, and Star Trek

I have a confession. I love watching Star Trek, and almost everything about it: the humanoid aliens, the amount of dialogue that fits into a space battle, the reverse-analogy (take an analogy – find a needle in a haystack, for example – and precede it with technical mumbo jumbo, then mention the analogy to explain it all). I love the treklore.

The other day I was watching an interesting opening sequence on Voyager. It was an unusually long take of a crewman taking an iPad with orders on it down to somebody else in the bowels of the ship. It was pretty funny, because a ship like Voyager would obviously be networked, and there's no need to send an order on foot. The iPad hand off is standard treklore: giving us an intro into the scene, giving actor extras a little bit of work, without giving a thought as to how people would actually work.

We have our own version of this, right here in reality. It's the way we hand off files to our colleagues when where done.  This is easier to see when compared saving your progress on a computer. It's clear that sharing is a pain while saving is a robust, mature process.

Saving is so important, you barely have to do it anymore

Not only do applications crash less (and recover when they do), saving is no longer necessary. When working in Adobe Lightroom, I have complete history of all my edits to any given photo, and the freedom to undo all the way to the beginning.

I often use Google Docs to write a draft of any non-sensitive document. The interface has a save button, but most of the time is grey and inactive. The application saves my progress automatically.

The saving task is taking its rightful place in the experience of working on a computer. It happens all the time, and it happens in the background.

Sharing closer to pulling teeth than collaboration

Most deliverable production resembles a tennis match. After arriving at a particular milestone, one publishes the results in a communication/publishing channel - email or Content Management Systems - and says: "the ball is in their court". Eventually the ball will be served back, hopefully without too much spin.

There are many pitfalls, such as: forgetting to sign up to keep track of a file, loosing important notifications in a flood of pointless ones, or making an important edit after publishing a version.

Most of the current workflows feel like a more complicated version of the mantra: "save always, save often". It works if you're disciplined, but it's not a real-world solution.

I have seen a glimpse of the future

I was building an html prototype with my colleagues, and we had set up a Google spreadsheet to put notes, let others know if a wireframe had changed, what template to use on a particular page, etc. We were all diligent updating it on the fly, because things where changing rather quickly and we didn't want to interrupt each other with every time they did. In the final stages the small edits became secondary to staying in sync. It was a great moment for me, because we could share our thoughts and work together in real time, without too much technology in the way.

Conclusion

In certain applications the process of keeping track of work is a separate one from doing the work. You have to stop what you're doing and prompt the machine with Control+S (or Command+S). This process is rightfully being viewed as pointless and redundant, with modern applications storing progress automatically and allowing more user freedom to backtrack. I hope for the same thing will happen to publishing and sharing, that it blends into the collaborative working space.

There will always be a place for a create-then-publish workflow. I just want a future where a TV show with dialogue such as: "can you email me that file?", or "the notification must have gone to my spam" is as funny as spaceship without a network.