New Tool Paradoxes
One of the paradoxes of technological change is that as new tools are introduced, people often remain tethered to their existing tools and practices.
It’s a paradox because new technologies can be significantly beneficial, yet we are loath to incorporate them into our daily routines.
As people, we don’t tolerate losses too well. If we lose a technology we’ve come to rely on, even to replace it with a better version, that can feel like a big source of pain.
It’s also common that most tools we encounter have a marginal benefit. The benefits can be slim because of steep learning curves or the acute pain of using them. Sometimes, we’re able to recognize better outcomes through experimentation, through a long-term view, or how broader use might benefit a more diverse set of stakeholders. That helps make those initial forays with a new technology feel more worthwhile.
We live with deep mixtures of old and new technologies in everyday life. Each has varying degrees of complexity and sophistication, and this creates a lot of conflict, especially when we try to sort out and normalize new working practices.
What might be some of the mechanisms for resolving avoidable conflicts and redirecting our attention, work, and habits towards more productive and personally satisfying exchanges?
Are there technologies that can serve as proxies for working out the inconsistencies of social interactions, our values, and new working principles in order to help make a better fit between technology and everyday life?
Collaborative Authorship
Collaborative authorship and revision of documents is one of those areas where working practices can converge, can conflict, and are ripe as a proxy for sorting out new solutions for change.
Consider how complicated it is to collaborate as a group on a document. There are different ways of crafting statements, varied word choices, structure, formatting, and design. If we add the many ways that we share, trade, exchange, comment, validate, and track these changes, it quickly become surprisingly complicated. Furthermore, as the size of a collaborative group grows, intra-group communication, sharing, and version conflict intensifies.
Despite all of these complications, we still retain many of the vestiges of paper trails, office files, and document authoring tools that we used a decade ago. With the exception real-time editing (e.g. http://etherpad.com/ and its google docs offspring), we haven’t yet embraced tools that 1) serve the goal of minimizing version conflicts in distributed authorship environments, 2) make generic organizational structures an explicit variable in collaborative processes, 3) allow us to capture the meta-information around our work and creative processes to provide us with a richer perspective on our work, and 4) coordinate the different tasks that go into creating the document and make it a durable and mobile carrier of meaning.
Each of these four areas is a pain point for people who collaborate and share documents in their everyday lives. Collaboratively produced documents represent a tremendous amount of transactional effort to work through, and this frequently amplifies emotional conflicts that arise from reconciling different cultural and organizational values, working styles, and different technical skills. We like to stick with what we know, because we know it works at least reasonably well. But often times, a new tool can be better simply because it reduces the pain or wasted effort we normally experience.
What would happen if the coordination techniques of collaborative coding used by programmers were applied to other disciplines and organizing styles? What if the core value of conflict resolution between computer scripts could be applied to humanities manuscripts, power point decks, maps, and grant proposals?
Collaborative Coding
One outcome of the open source software movement is the embrace of distributed, collaborative methods for maintaining and developing programming scripts. Programmers need tools for collaborating remotely, and because open source projects aren’t always run from a centralized authority, collaborators need ways to resolve different forms of conflict. And because computers and other machines run logical processes, they have a low tolerance for script errors and other conflicts. Programmers need version control to identify new errors, fix old ones, and track their progress. By archiving and saving each iteration of a script instead of writing over it, incremental process are made by different members of a team working collaboratively on different parts of the script. This distributes the ability to contribute at a much finer resolution–from the whole document level to the individual letter, word, or phrase.
Computer-readable scripts are not very different from any other form of written document. This means that the same tools for distributed and collaborative authorship can be used for areas other than computer science–from the humanities to graphic design.
¿Do you want to keep reading about it? Click here.
Gabriel Harp
THE INSTITUTE FOR THE FUTURE
Comments on this publication