Recently, as we work on completing our proof-of-concept version of Shareup, we’ve often been talking about different ways we can best help people work together through our software. I’ve never taken the time to write down how I think about collaborative software, so in this post I’ll attempt to. These concepts are how Adam, Anthony, and I are approaching building our new product and drive a lot of our conversations about how it will work.

Over the past couple decades, while working on different distributed software and systems, I’ve been able to refine my thoughts about how to categorize and talk about collaborating through software. Also, I enjoy reading about software history and the many HCI research papers one can find about collaboration, like: AR video conferencing, Telehealth, and related topics.

Xerox PARC, from way back when, are responsible for so many different technologies: Ethernet, “video links” and distributed software (called “ethernet software” at the time) to help people work with “digital paper.” This concept of digital paper really resonates with me most in my experience building software and has impacted how I think about designing a space for collaboration.

Digital paper

I like to always start thinking about a piece of software or a system as a group of people sitting around a table with a sheet of paper and some markers. Everyone can clearly see each other, can easily see when someone is writing or drawing, and it’s not possible to make a mark that cannot be seen by everyone else. Also, everything is spatially arranged: when I make a mark to the left of yours, you also see that it’s to the left of the mark you previously made.

Miro, Figma (and now FigJam), Google Docs, and Craft pages are examples of “digital paper.” (I also sometimes call them “digital whiteboards.”) They work like a magic, digitally replicated piece of paper that everyone can see and write on together. Everything is spatially arranged, we can see each other’s “fingers” (cursors), and all changes are immediately visible to everyone.

Digital whiteboards are the easiest collaborative software to talk about because they are both extremely immediate and give everyone 100% visibility. I cannot insert a circle into a Figma doc that you cannot see. The rules or “physics” of the software can be talked through very quickly and everyone “gets it.”

I recently read a Microsoft Research paper titled “Three’s Company: Understanding Communication Channels in Three-way Distributed Collaboration” where each participant could see “shadow images” of the other participants arms and hands as they would attempt to work together to accomplish a task like moving a block. Everyone also had audio and video feeds from the others. It seemed like everyone got it and the “additional arms” didn’t seem to bother anyone:

Despite the fact that we regularly saw three, and occasionally saw six arm shadows (two per person) in the task space, users did not seem to be distracted by this additional clutter.

(I also found the feedback from participants that the video feed was only really useful when preparing for a task, but not during it, super interesting.)

I also really liked another paper by Bill Buxton titled “Telepresence: Integrating Shared Task and Person Spaces” which has a great part which says (emphasis mine):

… the interaction breaks out of being like watching TV, into a direct engagement of the participants. They meet each other, not the system.

What about email?

Email can also be considered a “digital paper” product, however its immutability and the slow cycle of feedback make it less useful for a lot of tasks. Now, people love email. It’s the most successful distributed technology ever created.

The rules are understandable: I write something in a place that only I can see, then I hit “send” which will transfer a copy over to another person’s inbox (where I cannot see) for them to read sometime in the future. I can’t “unsend” an email and I can’t modify an email after it’s been sent.

For tasks which don’t need immediacy or really resemble letter writing, then email is the right choice. Personally, email doesn’t interest me much as something to work on. I wish the email protocols could be updated to allow for easy end-to-end encryption, auto-rejection of unknown senders, etc to make it more private and less overwhelming – but I also really get why it’s hard to change something so old and so successful.

What about chat?

Chat software can be a little fuzzy to pin down. While it might seem like a Slack channel is both fully immediate and fully visible, it turns out there are things one can do that are not shared and Slack tries to make this clear by labelling those messages “Only visible to you”.

By making it less clear if everything is fully shared, it adds stress for users who feel uneasy about trying something because “what if everyone sees me make a mistake” or “what if I send this to the wrong place.” (The old IRC software also had ways for “the system” to message you that were only visible to you, so this is not a problem unique to Slack.)

Using Apple’s Messages can also be confusing: if I delete a message, then does it delete it for the other person? (No, it doesn’t.)

I prefer software that is immediate: I would almost always rather use chat over email. But I also prefer software that is visible: I don’t like to be confused about who can see what.

Digital paper isn’t enough

Digital paper (or a digital whiteboard) is not enough. Arranging everything spatially can make it very difficult to find or remember where something was placed. As a canvas for a document grows it becomes harder and harder to keep up. Changes can happen over in an area one is not currently paying attention to. And searching for a note or comment from a month ago is almost impossible.

Both Miro and Figma continue to add features to try to help mitigate some of these issues (like following a person’s viewpoint) which is great. Google Docs can have the table of contents to the left which can help some as well.

The metaphor I use to talk about solving this issue is a digital card catalog.

Digital card catalog

When I design collaborative software, the metaphor I use the most is a digital card deck or digital card catalog, depending on the size and scope of the software.

If we each have a deck of playing cards, and we shuffle them in different ways, we know we still have the same “set of cards” despite the orders being different. I might have the ace of diamonds as my first card and you might have the queen of hearts, but we are not confused by that in any way. I can always search through and find any card you can. Also, if I decide to filter through and make a pile of only hearts, we understand that I am not filtering any cards in your deck.

For a “digital deck of cards” system: the card is like a little shared document. When we draw on the shared ace of clubs, we can all see the updated design immediately. I can also choose to put that card away in the deck and start working on another card. Then I won’t see your updates immediately because I’m on a different piece of digital paper. Everything inside the card is shared and everything outside is personal.

Sometimes we need a shared way to organize lots of cards which is what I call the “digital card catalog” system: not only is the card a shared digital document, the way the cards are organized is also shared. This is analogous to the card catalogs found in libraries.

Aside: a long time ago I learned from a few designers that if one wants inspiration for how to design information or software for people then always look at maps and libraries. They are ways to structure and organize lots of information, they are designed to be heavily used, and they try to work for a large number of people with as little required training as possible. Also, be aware that there are systemic biases inside libraries and the libarary science field that are important to know about and not replicate.

While a “deck of cards” is a nice and easy analogy, almost all types of software that I have helped design or helped build have become larger “card catalog” systems.

Wunderlist was one: each task was like a little shared document. Any change you make to task is visible to every member of the shared list. And the list itself is the “catalog.” We all see the same tasks in the list at all times.

One contentious argument we had was whether sorting a list alphabetically was a “shared action” or not. IMO, using the physical analogy to card catalogs, sorting or filtering is not a shared action. However, I lost this argument, and when someone sorted a list it actually sorted those tasks for everyone. I still feel this was a mistake and wish I could have done a better job making the case for personal-only sorting.

People prefer consistent rules or “physics.” When we are crafting the “universe” of a software product it’s important the physics and “gravity” are consistent and feel good. The rules of physical card catalog systems are already well documented and understood, so one can leverage that to help make our digital card catalog systems easier to use.

One can also look to libraries for how to “announce updates” since it is really impossible for a human to keep track of all the “new cards” in a busy catalog. There are “new releases” or “librarian picks” which try to help guide a person to relevant topics and places. There are many methods to search, filter, and arrange the cards to make it easier to find a specific one.

One could make “topic drawers” which include only the cards relevant to that topic. There is no reason why the same card cannot be present in more than one drawer if it were relevant to many topics. A card could helpfully indicate which other topic drawers it could be found in. This would make sense and be welcomed by library visitors.

Sometimes, in physical libraries, there are cards in the catalog which reference books over at other libraries: a union card catalog. Digitally, it’s possible to have a system to not just work with information inside your group or organization, but also with other groups and organizations which could be a huge win. 🙌

Quick summary

So that’s what I wanted to write about: when I design or build distributed software to help people work together, I almost always think about digital paper organized in a digital card catalog. I prefer software to be extremely immediate and it to be clear what is shared? and what is not.

I’m curious though, how do you think about collaborative distributed software? How do you think through the rules or physics of the system? Send me an email, I am very curious to hear what you think.