On online collaboration and our obligations as makers of software

My reading corner at home. An old comfy chair. Bookcases. Books stacked
My reading corner.

This post is the final entry of three in a series where I go over what I learned from the user research I’ve been doing for Colophon Cards. The first was about markdown. The second was about the various different kinds of notetaking.

It all began with blogging

As I’ve mentioned earlier in this series, I’ve been blogging for almost two decades. What I didn’t mention was that I was a true believer in ‘Blogging’.

—So, you believed in having a personal website, what of it?

No, you see, at the time blogging was supposed to be so much more than that. I truly believed that it heralded the future of collaboration, communications, publishing, and intellectual discourse. I believed that the future of social media was an interconnected web of personal blogs. I believed that the future of intellectual discourse was in cross-blog debates on lofty topics.

I believed the hype. I was quite wrong.

Blogs didn’t quite die. You could even say that they won as they have become a cornerstone of the web’s infrastructure:

Blog tech underpins almost everything you see online.

So, while blogs didn’t quite have the profound effect on society, publishing, and media that I expected them to have, their influence is respectable and far-reaching.

I am biased in favour of blogs, though. They had a major influence on my intellectual development, to the point where I still to this day revisit old blog post favourites for fresh inspiration.

One such major influence, one that probably changed my entire outlook on both writing and software development, was Kathy Sierra and her blog Creating Passionate Users. Her writing sent me down a path of studying the learning process, skills development, expertise, mastery, and why they matter to software development and UI design.

And Kathy Sierra’s social media story—that began with a group of self-styled ‘mean kids’ revelling in mean jokes and ended with literal nazis calling for mass murder—is the reason why I fell out of love with weblogs and began to distrust the tech industry’s approach to social media and online collaboration.

Getting back to notetaking, or the one where I piss off the punditry (again)

I reject the ‘external brain’ hypothesis for notetaking.

Or, more specifically, I think it’s a counterproductive metaphor for notetaking.

The hypothesis is straightforward: a complex notetaking system, built in the form of a structured web, acts as an extension of your brain and makes you smarter.

The theory is sometimes stated; sometimes merely implied. But it’s the trend among those making notetaking apps or selling courses on notetaking to talk as if structured, interlinked notetaking will raise your IQ, help you think more clearly, and prompt a wellspring of new ideas. Your collection of notes, dutifully linked and tagged, woven into an impenetrable fabric of collections and context, are therefore serious work and the promise is that all of that effort will be rewarded with intelligence, memory, and genius. The notetaking system is complex and tough to use because it’s supposed to expand the cognitive space that we use to structure our thoughts and generate ideas.

The problem is that even if our observations about these notetaking systems are correct, we don’t know if we have the arrow of causality pointing in the right direction.

Maybe that German academic was a genius and he definitely used a complex notetaking system. But was he a genius because he had a complex and involved notetaking system? Or did a complex and involved system work for him because he was a genius?

Is it the notetaking system that’s helping you think more clearly? Or is it the act of writing that forces you to clarify your thoughts?

Is it the complex interlinked web of notes that helps you get new ideas? Or is it all the reading you’re doing to fill that notetaking app bucket?

Is all of this notetaking work making you smarter? Or is it just indirectly forcing you into deliberate, goalless practice?

If the external brain hypothesis is correct, then complexity is essential. You can’t have a neurological extension of the brain without neurological complexity. The involved structures and regimented processes exist to tap into specific structures in our brain. There might be variations but all should have a baseline complexity that can’t be abstracted away because, hey, the brain is complex.

That’s the theory, at least.

However, if my suspicions are correct, then the primary benefit from notetaking comes from regular, deliberate practice. It doesn’t matter if you’re sketching, journaling, collaging, jotting down bullet points, recording a daily video, or just writing. It doesn’t matter if you’re filing it all away with a detailed ontology into a structured database or if you’re dumping it all into a box. It’s the habitual practice—in a way that fits your skill, personality, and practices—that matters.

If I’m right, then you can get the results of a complex notetaking system with a lot less work. Or, to be more specific, with a lot less wasted work—it should all go into the writing (or sketching, recording, etc.).

The key is that the object of notetaking is never to take notes. It’s to do a better job:

Notetaking should always be less work than the actual work you’re doing. When the notetaking process takes over, something has gone seriously wrong.

How blogs influenced my thinking on the subject

Kathy Sierra’s work has a single recurring idea from the very beginning of her first blog, Creating Passionate Users to her amazing 2015 book Badass: Making Users Awesome: the job of the tools we make is to set the user on a path of mastery. The tool shouldn’t get in the way of them improving their skills. It shouldn’t overload the UI with distractions. It should enable experimentation and practice. It should be designed in such a way as to enable and foster mastery.

That requires us to understand what mastery and skills development is, how it comes from deliberate goalless practice, exposure to examples of work that exhibit the skills the user aspires to, from having a tight feedback loop that lets the end user be aware of how they are working when they need to, from increasing the resolution of the work when applicable. And the generally accepted key to mastery (or skill-specific expertise, if you want to be nitpicky), is twofold: deliberate practice and perceptual knowledge.

In Kathy Sierra’s words, from her book Badass, first on practice:

Practicing harder and longer can potentially make us even worse than if we did less practicing.

Building deep expertise takes work, but of a very specific type that’s often the opposite of what people do when practicing.

Practice does not make perfect

On perceptual knowledge:

The second attribute of those who became experts is this: they were exposed to high quantity, high quality examples of expertise. (page 128)

After enough exposure with feedback, your brain began detecting patterns and underlying structures, without your conscious awareness. With more exposure, your brain fine-tuned its perception and eventually figured out what really mattered. Your brain was making finer distinctions and sorting signal from noise even if you couldn’t explain how. (page 133)

These two ideas, deliberate practice and exposure to high-quality examples, should be the forces that drive the design and structure of most apps. That includes Colophon Cards.

The research so far

As I wrote in my last entry, I began my research into writing and notetaking well before I began the Colophon Cards project itself. I came to the project with a set of ideas. I’d based them on my research of existing studies and writing about expertise, mastery, creative work, and knowledge work. (And I reviewed a ton of forum threads on notetaking.)

The purpose of the survey and the interviews was to see if I could validate or invalidate some of my guesses before I advance to the implementation stage proper. Better now than after I’ve implemented something.

Finally, writing these entries where I analyse and outline the observations from the interviews while explaining where they stand relative to my other research, helped me consolidate my ideas into a cohesive theory of how a subset of the notetaking field works.

The research I’ve done isn’t enough to lend my theories scientific legitimacy (for that I’d need way more money) but it’s enough to give me confidence in going forward.

My hunches:

There are many kinds of notes, but these are the kinds of notes I’m hoping to support. The app should help those in creative or knowledge work become better at their jobs.

Most of these kinds of jobs involve other people.

Couple that with the need for the high-quality examples required for mastery and the key to a great personal notetaking app is then, paradoxically, other people.

Other people (the various types of collaboration)

It can be jarring to listen to people describe the many ways they work with other people. Especially if you’re only used to the limited takes on collaboration that are the norm in the software industry.

Tech today favours only two approaches to collaborative work:

  1. Multiplayer spaces that are shared in real time (or close to real time).
  2. A library where everybody sees and contributes to the same shared space.

Both are essentially the same idea: a space with realtime synchronisation and presence signalling; and a space without.

Examples of the former include Google Docs, Slack, Figma, and Zoom. Their design makes you aware of everybody else in the space, and their actions affect your perception of that space in real time (or close to real time).

Examples of the latter include Wikipedia, various kinds of knowledge bases, Dropbox and Google Drive, and version control systems. They are all about making it easy for a group of people to work simultaneously in a space but without realtime awareness of each others actions.

The makers of both kinds of apps often invest a lot of engineering hours into making sure that multiple people can work on the same document or file at the same time without causing conflicts or losing data.

Other approaches that used to have favour in tech but are now out of fashion, despite their evident popularity among end users:

Most discussions of how to make collaborative software focus on one or more of these approaches.

This is like describing a chair in terms of the hammers, saws, and screwdrivers used to make it. Great when talking to other carpenters who want to make another exactly like it. Not so great when you want to find out whether the chair works for sitting.

We need to have a clear idea of what people are trying to accomplish with collaboration. Knowing the tools we can provide them with as UX designers is not enough.

A non-exhaustive list of the primary goals of most collaborative office work:

Consensus-building

The point of most meetings, brainstorming sessions, and workplace discussions isn’t to generate ideas, make decisions, or understand the situation. The point is to build consensus. The ideas or decisions are the most straightforward part of the process. Without consensus, they are all meaningless.

Constructive examples from the interviews include:

For consensus-building, you need everybody to have an overview of what everybody has said, who has participated, and what the overall argument has been.

Any time you have a group of people together where everybody is aware of everybody else’s presence and status, you tend to automatically end up with a group consensus, even if that wasn’t what you wanted. We are a social species, and we are really good at adjusting our own opinions to match that of the crowd.

The Bandwagon Effect (and the equal and opposite anti-Bandwagon Effect) is what drives most online social interactions. It’s what tore blogs apart; what makes Twitter a hellsite; and what turned Facebook into the propaganda machine it is today.

It also tends to lead to bad outcomes in collaborative work.

Consensus-building is an essential part of work collaboration but it can’t be the only part. The dominance of consensus-building online collaboration tools directly leads to worse decisions.

Here’s Kathy Sierra again talking about how this phenomenon is described in the book The Wisdom of Crowds (which, paradoxically, talks a lot about how crowds are dumb):

And that’s all great and intuitive… until you get to humans. Humans, he said, demonstrate the opposite principle: more interactions equals dumber behavior. When we come together and interact as a group seeking consensus, we lose sophistication and intelligence. Ants get smarter while we get dumber.

And.

At its simplest form, it means that if you take a bunch of people and ask them (as individuals) to answer a question, the average of each of those individual answers will likely be better than if the group works together to come up with a single answer.

Feedback and review

Another common scenario is to get feedback or a review of an idea, proposal, or piece of work. You have a thing. You would like to improve said thing. So, you ask a bunch of people what they think, giving more weight to those with relevant expertise. It’s a time-tested strategy.

The pitfall here is that if the participants are aware of each other’s contributions, they will almost always automatically switch to consensus-building instead of providing their honest feedback. Worst case scenario: the bandwagon effect gathers steam and drives you toward a crap decision.

These kinds of disasters are a routine occurrence today. You see them in corporations, small and large, in movie studios, at publishing houses, and in governments. A product or project is released and all of a sudden you have a bunch of people in your inbox pointing out glaring, obvious, and fatal flaws that everybody involved had missed.

To get the best feedback possible from the participants, you need to avoid the mechanisms of consensus-building. You need to ensure that everybody’s responses are kept separate and only visible to those responsible for integrating all of the feedback, something that’s surprisingly difficult to accomplish in modern collaborative software.

The interviewees all had examples where they needed to get feedback from a specific person on something they did. But only those who were specifically writing or teaching as a part of their job did feedback in a structured way. Most of the examples of feedback or reviews that came up in the interviews were more accurately examples of consensus building as described above as they all involved:

That’s just the consensus trap all over again. Which is fine, if that’s what you actually wanted, but counterproductive if needed that feedback.

Knowledge sharing

This is the one everybody loves to try to solve because it’s a problem that everybody seems to have. The reasoning is straightforward and compelling:

Stuff that should be informing the decisions and strategies of the company. Some of it sits unread in a knowledge base or a wiki. Some of it lies in the drives of individual employees who don’t have a way to share it productively.

So much knowledge not being applied!

Except that’s not how we work as human beings. If you haven’t read it, experienced it, and contextualised it, then it isn’t knowledge to you. Knowledge is a quality that people possess, not documents, and the only way to transfer it from one place to another is for people at both ends to apply themselves and make it their own.

In terms of preserving and transmitting knowledge, most of the systems being used are working about as well as they ever can, and even if you could improve upon them, it’s highly unlikely that anybody would pay you for that improvement as it’s a pizza crust problem, to use a phrase coined by Amy Hoy.

Using the term “knowledge” for knowledge sharing and knowledge bases is misleading. It’s the term of art, but it’s also wrong enough to lead you to make poor decisions. We should be talking about documentation and references. In other words: a library. At scale, when you’re dealing with a large collection of documents and papers, you’re probably big enough to hire somebody (or a team of somebodies) with an information science degree (or degrees).

If you’re big enough to have a library where everything gets lost all the time but still too small to hire people who have the relevant expertise to solve the problem, you’re kind of screwed. Search only works up to a point.

Thankfully, if keep your scope limited (small organisation or single department) there’s this neat thing that digital files can do that saves the day: digital files can be in multiple places at the same time.

The issue with large shared document libraries at most companies is:

  1. They generally don’t have an organising principle beyond the personal tastes of the employee who volunteered to organise the Google Drive.
  2. If they do have an organising principle, it isn’t understood by most of those who use it, which leads them to move things around and leave items in the wrong place.
  3. Almost every time somebody puts a document in a place that makes sense to them, it’s lost to everybody else.

Information science people know how to solve these problems and others that come up, but what if you don’t have one of those hanging around?

The simplest solution, one that works surprisingly often, is for everybody to maintain their organisation for the document library.

To use the shelf analogy: if you have a large enough shared bookshelf and you move a book to a place that makes sense to you, then that book is immediately lost to those who knew where it was in the old place.

If you, on the other hand, have a bookshelf for each employee and unlimited copies of all of the books, then each person can organise their version of the library in a way that they understand and can navigate easily.

If you ever wondered why every office has at least one person who emails themselves everything—files, PDFs, pictures, whatever—now you know.

This approach has obvious limitations. It’s crap at helping you find stuff that came up before you started work in the organisation and it doesn’t scale to a large organisation.

A bookmarking service that supports collaborative tagging (folksonomies) can often fill in that gap.

Doesn’t always work. Even when it doesn’t, it’s probably still going to be better than the black hole of data that passes as your shared Google Drive or Dropbox.

Almost everybody I interviewed described knowledge sharing as an ideal they aspired to but none of them practised it.

Parallel work

Finally, we get to the other kind of collaboration that modern software is good at (the first being consensus-building, which apps and the web excel at, to a fault).

Namely, working people down to the bone—I mean, helping people work in parallel.

With Google Docs, you can get a group of writers to work in parallel on whichever part of the document you want. With Git, a group of developers can be working on separate problems in the same codebase without issue. With Figma, you can have all of your designers working on your design library at the same time and the app will handle it without a hiccup.

This can be great and this can be awful. The great part is obvious: sometimes you can sic a bunch of people at a problem and they’ll tear it apart. But also sometimes a problem can only be solved by a single person with expertise and others would only get in their way.

The risk with these tools is that they are also frequently inadvertent consensus engines. Because tools like Google Docs and Figma show the work in a single shared space and make you aware of the actions and presence of others working in said space they end up having the same drive towards consensus as you get in UIs specifically designed to help a group come to a consensus.

Amazing division of labour; mediocre outcomes.

In Kathy Sierra’s words:

I’m not dissing teams–our books are all collaborative efforts, and far better because of it. And we consider ourselves to be on a team that includes our publisher O’Reilly. It’s not teams that are the problem, it’s the rabid insistence on teamwork. Group think. Committee decisions.

Most truly remarkable ideas did not come from teamwork. Most truly brave decisions were not made through teamwork. The team’s role should be to act as a supportive environment for a collection of individuals. People with their own unique voice, ideas, thoughts, perspectives. A team should be there to encourage one another to pursue the wild ass ideas, not get in lock step to keep everything cheery and pleasant.

Everybody I interviewed had experience with parallel work, thanks to Google Docs. They all mentioned having worked on a document or a spreadsheet in parallel with others as a part of their job. The developers all used GitHub as well.

Putting it all together

—This sounds impossible! Might as well give up.

It would be impossible if you tried to solve all of the problems I’ve described with one app. Instead what the research helped me do is narrow down the focus of the app and validate or invalidate some of my assumptions.

As I described in the first entry in this series, heavy users in the notetaking scene are extraordinarily sensitive to lock-in and interoperability. While I’m hesitant to base the app on markdown—I think the format is a major roadblock for many on the path to master writing and notetaking—I need to make sure the app offers similar interop and compatibility guarantees as you get from a plain text format.

In the second entry I described the different kinds of notetaking people use. The research helped me decide that I wanted to focus on making a notetaking app for structured creative work, operating on the assumption that knowledge work has more in common with creative work than not. I also reviewed some of the different ways experienced writers commonly structure their notes and research, focusing on two that I called The Box and The Map.

And in this entry, I’ve been describing how practice and feedback are a vital part of helping people develop skills and expertise.

Through this work I’ve been finessing the concept of the app and cutting it down to four main spaces or views, each with a specific purpose, all connected through feedback loops.

  1. The Journal
  2. The Dot Grid
  3. The Reading Corner
  4. The Sharing Space

The Journal is your entry point. It ties everything together and prompts you to describe or contextualise the notes and bookmarks that you’ve added, edited, or deleted that day. As I described in my last entry, almost every book on writing or creative work strongly recommends a daily, goalless journal. It needs to be daily (or close to daily) because it’s practice. It needs to be goalless because it’s deliberate practice. You aren’t writing it to meet a deadline or finish a project. It’s there for you to empty your head, so to speak.

The Dot Grid is The Box. It’s the semi-structured space you use to collect your things.

Roy Peter Clark uses literal boxes, one for each project, and describes the process in his book Writing Tools in terms of saving string in a box:

To save string, I need a simple file box. I prefer the plastic ones that look like milk crates. I display the box in my office and put a label on it, say “The Plight of Boys.” As soon as I declare my interest in an important topic, a number of things happen. I notice more things about my topic. Then I have conversations about it with my friends and colleagues. They feed my interest. One by one, my box fills with items: an analysis of graduation rates of boys versus girls; a feature on whether video games help or hinder the development of boys; a story about decreasing participation by boys in high school sports. This is a big topic, so I take my time. Weeks and weeks pass, sometimes months and months, and one day I’ll look over at my box and hear it whisper, “It’s time.” I’m amazed at its fullness, and even more astonished at how much I’ve learned just by saving string. (p. 215)

The Reading Corner is where you read and review both the articles you’ve bookmarked and your own notes. It’s important when reviewing other people’s writing and your own that both happen in an identical environment. In theory, it should strengthen your perceptual knowledge to edit your writing in the same space as you read the (presumably) high-quality research that you’ve collected.

Finally, The Sharing Space is the same as The Reading Corner except it’s specifically for getting feedback from other people. You should be able to take a note or a draft and get independent feedback from each of your reviewers.

That’s the theory and the concept. This is what I hope Colophon Cards will be.

Our obligation as makers of software, as explained by the collapse of the blogosphere

In early 2007, a small group of popular bloggers started a site called Mean Kids, a tongue in cheek reference to some of the participants having previously been likened to “the mean kids in high school”. It claimed to be satire that poked fun at some of the people in the blogging world that annoyed them. That included Kathy Sierra (among others, it was a really mean-spirited effort).

The problem with the Bandwagon Effect and the anti-Bandwagon Effect online is that it leads to escalation. Everything keeps escalating unless you specifically take measures to prevent it, right at the beginning, which this group didn’t (out of ideological opposition to content moderation) until it was too late. The tech industry is filled with well-meaning enablers of abuse and 2007 wasn’t any different.

These events were well documented at the time. This take, by Joseph Reagle, is as good as any.

The man who escalated the furthest was Andrew “Weev” Auernheimer who has since confessed several times to not only spreading lies about Kathy Sierra but also publishing her home address and social security number, encouraging people to send her ‘presents’ that showed what they thought of her.

And they did. Some of them were death threats.

So, Kathy stopped speaking publicly and stopped blogging. She retreated from the public web while Weev rose to stardom as a ‘hacktivist’. Many people in tech adored him for fighting against unfair laws that ‘stifled’ progress in the industry.

This is when I lost faith in blogs and online social media. This dynamic, repeated endlessly since then, is why distributed social media like the ‘blogosphere’ collapses; why Twitter is a hellsite; why Facebook is the place that turns Granddad into a nazi; why federated social media like Mastodon breaks apart into smaller isolated clusters.

The tech industry either doesn’t understand the harm being done by their idea of how social interactions work or it doesn’t care.

More than any other, this is the event that made me a sceptic of the promises of progress that the software industry is fond of making. It hammered home the obligation the rest of us have, those who do care, in making sure that the software and technology that we work on don’t enable the kinds of abuse and harm that keeps happening with mainstream social and collaborative media.

No app I make or work on should prioritise collaboration and work over the well-being of others. The obscurity or lack of popularity of my software or yours should not be the only thing that prevents it from being used for abuse.

Kathy Sierra returned to social media and the public web in 2013, joining Twitter as seriouspony and launching a website to promote her upcoming book.

For a while it seemed to be going well. The book, after all, is amazing. I highly recommend it. But then the crap kept coming. People kept repeating the lies Weev had told about her. He kept being heralded as a hacktivist and an important man in the fight against government overreach. Every time she tried to push back against the lies, she ended up being the one accused of being a troll.

The tech industry loves its abusive dudes.

So, she decided to stop. Only a few months after her return, she wrote a post explaining why, republished by Wired as Why the Trolls Will Always Win:

I don’t have the luxury of assuming “it’s just online. Not REAL. It’s not like these people would ever do anything in the real world.” And what you don’t hear much about is what most targeted women find the most frightening of all: the stalkerish energy, time, effort, focus on… YOU. The drive-by hate/threat comment, no matter how vile, is just that, a comment that took someone 2.5 seconds to think and execute. It might be annoying, offensive, maybe intimidating the first few times. But you get used to those, after all, it’s not like somebody put time and effort into it.

But Photoshopped images? Stories drawn from your own work? There’s a creepy and invasive horror knowing someone is pouring over your words, doing Google and Flickr image searches to find the perfect photo to manipulate. That someone is using their time and talent to write code even, about you. That’s not trolling, that’s obsession. That’s the point where you know it’s not really even about the Koolaid now…they’re obsessed with you.

This is a very long way from the favorite troll talking point “Oh boohoo someone was mean on the internet.”

Being online wasn’t worth the risk, so she left.

Since then Weev came out as a Nazi, got himself a swastika tattoo, and more than once has excused or advocated for mass murder while maintaining one of the more prominent online neo-nazi communities.

Despite this, I haven’t seen a single person who took his side over Kathy Sierra’s recant and apologise. Many instead doubled down, saying that in principle they were correct to defend a nazi’s freedom of speech.

At most, when you press them, you get a vague apology about how in nerd circles you have to have a tolerance for strange politics. Which is why it was apparently impossible for them to register what sort of person Weev was until it was too late.

It should worry you that these people, and others with similar priorities and similarly poor judgement, are still so influential in the tech industry.

And the rest of us need to try to be better.

The next steps for Colophon Cards

Next, it’s time to start implementing the prototype proper and start testing actual designs.

The Colophon Cards project is made possible by a grant from The Icelandic Centre for Research’s Technology Development Fund