What Would an English IDE Look Like?


In yesterday's post I floated the idea of an English IDE for technical writing. IDEs are code editors with powerful tools for sculpting and changing a codebase, and I'm curious if any of their lessons extend to documentation and technical writing.

So in this post I'd like to riff on what it would even mean to have an IDE for English and what such a tool might look like.

Example 1: Scrivener

As a starting point, let's consider Scrivener, the gorgeous writing tool for professional authors. Here are some of the power features that stand out to me:

  • A project sidebar — Scrivener focuses on a main document but shows all of its related documents, including notes, scraps, and associated research, in nested folders on the left side.

  • A compile step — Scrivener treats a project as a list of small documents that we then compile into a final result. During compilation, we can apply project-wide settings and exclude whatever pages we like from from the final result.

  • Refactoring — Scrivener doesn't call it this, but you can rearrange documents and folders to reorder the project's content flow.

  • Side-by-side view — This is for working on multiple documents at a time.

  • Snapshots — For saving different drafts over time. This is analogous to a Git commit history.

  • Multi-format export — Text, PDF, Word, ePub, Markdown, LaTeX, ...

  • Metadata — This includes tags, meta-notes, comments, and other important information about a document.

  • Templates for projects with a particular structure.

Example 2: Ulysses

The Ulysses app is similar, but whereas Scrivener seems more suited for books and traditional publishing, Ulysses seems more suited for web publishing and a more technical audience. Three of its power features stand out to me:

  • Bulit-in proofreading — The app suggests grammar and usage changes to ensure that text flows smoothly.

  • Markdown-based writing — Ulysses doesn't have a standard visual editor. Instead, it uses an extended Markdown dialect called Markdown XL. It seems that this markup supports some degree of customization as well.

  • Flexible themes that leave the document semantics intact but display the text in whatever style you like. Again, there's a code analogy: I don't care how the code is displayed, just that it's displayed in the way I like it. (Let me choose a typeface and color palette I like! I know my eyes better than you do!)

Example 3: Dropbox Paper

Where Scrivener and Ulysses focus on solo authorship, Dropbox Paper at least nominally positions itself as a knowledge base first. I love using it, particularly for these features:

  • Fast and responsive design — All else equal, fast and pleasant things are more enjoyable and get used more often. I think this is criminally underrated.

  • Rich embedded widgets — Because plain text isn't always enough.

  • Inflexible formatting — This is analogous to using a standard coding style in a large project. Text formatting is a nerd snipe.

  • Comment threads on any part of the document — I like Dropbox Paper's implementation of this, but I do wish that the sidebar were wider and with larger text.

IDE daydreaming

My dream IDE would incorporate all of the features above and add the following:

  • Integration with a knowledge base — This can happen in various forms: a smart glossary, bidirectional links, ...

  • Fast and powerful corpus search — This is self-explanatory.

  • Ownership and staleness tracking — Documentation will tend to lag behind the facts on the ground. We should acknowledge this fact and flag when documentation might be stale or abandoned.

  • Engagement tracking — Not in a creepy way! Just enough that writers can learn how many people are reading and using their content.

  • Speech to text — It's not as reliable, but it's fast and easy.

Notion or Dropbox Paper are the closest options I can think of to what I have in mind, even though they both fall short of my ideal. But I'm encouraged by what I've found, and hopeful for what comes next.

For further reading