Sunday Letter - let's leave the typewriter behind.

(this one is a bit long, but then I'll be on break until late August)

Documents have changed a great deal in the past 30 years, right? We had typewritten letters, which were slow and formal, then we had desktop word processing, which was faster and more fun (remember outline fonts?), and then we had web docs and things got collaborative and even more informal. We've even had emojis in texts being used as documents.?

But through all of these changes, a document hasn't really changed. It's less formal, but it's no smarter. It's still a fixed object, some linear text that you read through. Maybe you create it non-linearly in a collaborative mode but you are still creating a linear, mostly static artifact. A few companies have tried to do more graph-like structures but they're still more or less static and passive, and accordingly, hard to use. And even though each of the changes above was a response to a technical platform change, we've never really seen a document form that felt fully native and comfortable on mobile devices.?

I blame the Romans. Actually, no, I really blame the typewriter. But there's a story that the reason our train tracks are spaced the way they are can be traced all the way back to the dimensions of Roman chariots (this is likely not true, but it's a colorful image). In a similar way, I suspect that we are still, essentially, making documents that are designed to be built by a typewriter (or maybe a printing press). We've never let go of that constraint, so our documents are fixed, linear, dead. They'd be recognizable by an office worker in the late 19th?century.?

What's the point of a document??Not to have an artifact (usually) but to communicate or inform. In a business context, it's to get to a business action or outcome. With the exception of archiving (which is usually just about being able to perform?one of those actions at some point in the future), we very rarely care about the artifact itself. We care about the content, the understanding, the action, but the actual document...not really.*

Until very recently, we didn't really have any capability to build anything else, so that made some sense. But we are beginning to have that ability now with AI systems. We can be more conversational, and we are seeing more content be created that way. But so far, we are still stuck in the "typewriter" pattern - we have lots of authoring helpers and copilots that can help generate or clean up your content, but it's still just static, fixed content.?

One experiment I've been?working?on with a small team is a chatbot that has longer memory than just the token window (using a vector DB). One thing it's very useful for is as a brainstorming/writing partner. If you tell it what you want to write a paper about, it will happily interrogate you for as long as you let it to get the details and "understand" what you want. The record of that conversation is itself both a very compelling form of document, but more importantly, the conversation (and memory, which can be reused) has built an educated "bot" that you can talk to about the content of the document.?The bot (or document, depending on what you want to call it), has understanding, and can converse with you in complex ways about that understanding.?

It's a "live", "smart" document - and you could never build it with a typewriter.?

But why stop there? Now that there is "presence" and "understanding" in the document, and we have assumed it can be fluid, why not be able to ask the bot/doc to generate the contents in a different form? Or for different use? Maybe you're very visual. Maybe you're a lawyer and you need it to contrast with prior practice. Maybe you have a similar task to perform but with different content (like a quarterly report). And while this is a nice thing to be able to do with natural language, why stop even there? Why not have these fluid objects be discoverable and modifiable by code, or by other copilots or agents, stitched into larger and more fluid experiences??

In fact, that's starting to sound a lot like an application, isn't it?

We might ask the same questions we've been asking about documents, but about applications. Why are they static (for the most part)? Why can't I interrogate them or ask them to reconfigure themselves to suit my needs (other than very clunky preferences dialogs). Why don't they "understand themselves" at a deeper level? Why can't I collaborate, not with another person, but with the document or application? Fixed, hard-coded application UX is anachronistic too - we haven't had good enough AI to be able to converse with an application, so programmers have had to "play AI" and build out these fixed flows. It's time to rethink applications for this new paradigm too.?

When we built GDocs, we introduced two things: easy collaboration, and zero-install. They were a bit related - both served to strip away some of the overhead of creating and managing a document and guaranteed that the content you needed would be where you needed it, always. We made some tradeoffs and bargains with the user, too - we removed some of the features that weren't being used much, in exchange for a much cleaner, faster, and more convenient experience. That might happen here too.?

"Live/Fluid" and "Smart" are the equivalent for the next generation of applications and documents. Just like an app or doc that is disconnected from the internet or awkward to use online seems anachronistic at best and even broken in some cases (would you use a totally offline database or expense reporting system?), applications and documents that can't be interacted with in rich ways, that don't understand their content or purpose and can't adapt to user instruction, are very shortly going to seem the same.?

If you can't talk to it and have it do what you want, whatever it is, it will seem less convenient. Convenience always wins.?

When there is a platform/paradigm shift, the first instinct is always to imitate the last pattern, just in the new world. That's fine, and it's a way to get started. But the real breakthroughs come from embracing the native affordances of the new platform. What most companies are doing now with automated content creation is the first kind of reaction - it's reasonable but it's not taking full advantage yet. This is also like the early internet - most efforts were imitations of something in the real world, like small shopfronts that were highly curated, or complex "wall of text" news sites. It took a while to understand what was valuable in the new world - distribution, aggregation of demand instead of supply, speed, abundance.?

What is described above will have some challenges and problems to overcome. If you are reacting to this and thinking "that's dumb!" or "that will never work!", that makes me happy - that's a good sign that it's touching a nerve and has the potential to be disruptive. All the good ideas look like that at first.?

We don't care about the artifact; we care about the outcome. We care about smart things that we can talk to, that make our lives more convenient, not well-polished static displays of pixel art.?

Let's leave the typewriter behind.

*(As a fun aside, the Computer History museum in Mtn View asked me if they could "curate" the first GDoc, which I have in my account. But "have" and "document" is kind of slippery in this context - the contents have been copied through three backend and two frontend architectures that I know of. It's the "document of Theseus - is it really the "first GDoc"? Not really - it's the contents of the first one, but I can make it's equivalent with a quick copy/paste. I doubt any metadata other than my ownership has survived).?