We designed and coded a prototype of a “democratic” Google Docs: rather than giving your document collaborators one of the two extremes — “comment only access” or “full edit access” — our tool enables you to let your collaborators propose changes, and if they receive the majority of votes, those changes take effect.
A demo video below walks through the functionality. You can also demo it live at dem-doc.web.app.
You’re probably thinking: “That’s an interesting and novel interaction design, but does anyone actually want it?” And our answer is: probably not in this exact packaging, but possibly in another. Allow us to explain:
In 2019 we were accepted into a competitive “tech policy” program called the Aspen Tech Policy Hub, a teaching ground and incubator for novel applications of technology to policy-making. During the program, we grew fascinated by the concept of building a “GitHub for Law”. So, for our fellowship project, we decided to prototype what we believed would be a core module of this system: a service to handle conflict resolution around the actual text of policy documents. Our presumption was that “users” of this service would primarily be other software, via an API.
[Warning: Policy Nerd Rabbit Hole] — Our vision was that, in a “delegatable direct democracy” (aka “liquid democracy”), programmatic delegates could act on behalf of (and with the weight of) their constituents in order to “git commit” policy wording into law. This would be done in an environment of many other such programs. In this scenario, we imagined conflict resolution being determined by the number of constituents each delegate represented (essentially by weighted voting). We decided to engineer an interactive user prototype of this module to demonstrate proof of concept, to explore value and viability among policy fellows.
We used this prototype engineering opportunity to build our first full-scale React.js application with a Google Firebase backend. We considered sentences in a document to be the most atomic unit and structured our database accordingly. We programmed each sentence to contain a reference to the sentence before and after it (essentially granting the functionality of a doubly-linked list, while retaining individual indexing). This allowed for efficient sentence insertion, modification, and deletion.
We made the application look a lot like Google Docs, with more of a physical-desktop-layout (rather than list-layout) view of your created documents. We desired the editing process of text to be done via direct manipulation (how most all word processors function), but due to time constraints, we enabled sentence adding and editing via an overlay. Voting on the sentences takes place in the same overlay. This was the simple way to handle both sentence editing and voting in a single interface, but it would not be the choice for a production application.
Stack:
- Prototype
- Google Docs API
- Voting System
- Interaction Design
- Tech Policy
- React.js
- Firebase