Quip is a document editor defined by collaboration. It enables a dramatically better co-authoring experience than static Word documents. (Most of what I’m writing here about Quip also applies to Google Docs.)

Collaboration in Quip is driven by two features:

  1. Live editing of the same document by multiple users. This works fine; it’s basically table stakes for a modern web app, I guess.

  2. Social comments, where users can be tagged in the context of specific text, receive notifications when tagged, and mark comments as resolved.

Social comments are important and help make Quip sticky: you are constantly pulled back into it by people tagging you against documents. But if you’re working on any document of significant size, comments quickly become a mess. All comments on the document are shown in a single chronological sidebar. It’s hard to find which comments are assigned to you; it’s also hard to find comments you tagged someone else in, to see if they’ve followed up; and multiple comments in a single thread are disconnected from each other. Your workflow becomes a nightmare of scrolling, reading, and making edits. The problems multiply if you’re working across several documents, or if people are still actively commenting while you’re trying to catch up.

These issues stem from Quip treating the document as the fundamental unit of the interface. In a world of paper, or a desktop document editor, this is obviously necessary. But in a web app, it’s not: documents in a web app are divisible. Each paragraph with a comment could be broken out of its original document and unified into an inbox of, say, “paragraphs that need action”. Editing the paragraph in the inbox view would also edit it in place in the original document – it’s just a reference to the same text. So rather than jumping between documents and scrolling to find commented paragraphs, the user could smoothly work through an inbox of actions, resolving each comment as she goes.

The lack of a feature like this – in either Quip or Google Docs – probably just reflects prioritisation. It’s kind of a power user feature, and they’re better served by building things like Salesforce data integration to drive broad use by sales teams. But I think it might also reflect a kind of implicit skeuomorphism. (Skeuomorphism is the tendency to retain design cues that are no longer necessary when moving from one design medium to another, like the faux leather binding and torn-off yellow pages in the early iOS Notes app.) We’ve spent so much time thinking about documents as indivisible units - whether on paper, or as desktop files - that it might not be obvious that we could reinvent them by breaking them down and recombining them.

What other ways might we improve the user experience by letting go of this old notion, and thinking about documents more granularly? A few ideas:

A few other product reflections on Quip:

  1. The default ‘news feed’ is very noisy because it shows all updates from all documents that I can theoretically access – even if I’ve never interacted with them. (You can disable this on a per-folder basis, but that is unrealistically painstaking to carry out across lots of folders.) I think a feed of ‘updates to documents I’ve opened’ would be much better.

  2. ‘Chat rooms’ seem like a vestigial feature (and a quasi-expression of Zawinski’s law – I wonder if anyone uses them, or if they could just be deleted from the product. Maybe organisations without an alternative like Slack or Teams.

  3. Although I use Quip a lot more than Confluence, I appreciate Confluence’s ability to nest pages under a parent page, and have the parent page show an automatically-generated set of links to the child pages. This makes maintaining and navigating a set of related pages quite simple. Quip’s folder structure takes a bunch of manual work. I guess they expect most people to rely on search but search is only useful if you know what you’re looking for.

    Search is harder for users than you think

  4. In contrast to Slack, I haven’t noticed much impact from Quip introducing their app platform. I wonder how successful they view this as being; I’m not sure if there are lots of apps in use in some other organisations.

  5. The work on live data integrations, in the wake of the Salesforce acquisition, is interesting and perhaps a good example of them starting to reimagine documents as being more dynamic and changeable, and driving more towards solving the actual workflow. Consider this point from Benedict Evans: “Then, in our own time, every week, thousands of VPs in hundreds of companies pull data out of internal systems into Excel, make charts, paste them into Powerpoint, write bullets and email the PPT to a dozen stakeholders. But actually, their job isn’t to make Powerpoint - that’s just a tool. Their job is to do something, not make slides, and that PPT should really be a live SaaS dashboard.” Quip might not be jumping all the way to the SaaS dashboard, but live-updating data inside the document is an OK start.