Cambrian Blocks: The Emergence & Evolution of Block-based Editors

The block is our hot new interface pattern. The way swipeable cards were all the rage in 2014. You have almost certainly seen and used these blocks. They come in an array of familiar types; ranging from simple formats like headers and blockquotes, to complex interactive widgets like tables and embeds.

These blocks don't look drastically different to the interface elements you use on the web every day. Except normal, everyday users can create, edit, and publish them to the web without touching any HTML, CSS, or JS. They are a syntax-free, user-friendly way to create dynamic, complex, multimedia documents, websites, and even apps on the web.

The places where we create these blocks them have been christened block-based editors. They typically take the form of a document or canvas where the user can select blocks from a pre-defined set and arrange them on a page. Through simple click and drag interactions, they're able to compose fairly sophisticated layouts.

These blocks don't seem remarkable at this point. We've become accustomed to interfaces that allow us to whip together complex, multimedia documents in a few clicks. They've quickly become a mundane backdrop on the modern web; so quotidian that we've failed to recognise that they're pushing forward a long sought-after dream: the belief that everyday people should be able to create and publish dynamic, sophisticated, multimedia content to the web, without extensive training or technical knowledge.

This dream goes by a few names: end-user programming, the read-write web.

[ These ordinary blocks are helping shift power from developers to end-users. They are a huge force in enabling end-user programming. One that how flown under the radar. They've enabled the democratisation of publishing rich, multimedia docusment to the web in a way that has been entirely unappreciated and unacknowledged. We are underrating blocks. We should be pointing at them and loudly acknolwedging how important they are to shifting power away from the technical elite. Then ask how we can keep pushing in this direction. ]

We're now in the middle of a Cambrian explosion of these editors. Blocks are a core concept in almost every modern document editor and no-code website builder. At last count I found 30 block-editors in active development, and I've certainly missed some. Two more will get seed funding while you're reading this.

There's three main software categories where these block-based editors are especially popular and widespread:

In addition to those mentioned above there's also , , , , , , , , , , , , , the list goes on.

We're at the stage where Notion – one of the pioneers of the block-based interface – have plastered giant advertisements all over the London tube. One of many signs that blocks are no longer a niche interface pattern that a few startups are experimenting with. They've gone mainstream.

Given this popular burst, it's a fine time to ask some clarifying questions:

• What exactly is a “block”?
• Why are blocks such a popular and widely used interface pattern?
• What common standards and best practices are we congregating around for how blocks work?
• What historical threads led us to block interfaces?
• What new possibilities do blocks enable for both developers and end-users?

We'll attempt to answer all these questions in this piece. We'll start with a quick tour through the popular interface patterns being used in these editors. We'll explore what historical interface traditions and infrastructure made our block-filled present possible. We'll then ask what block-based editors allows us to do that classical text editors and straight programming syntax can't.

At the moment we don't have a strict definition of what counts as a block-based editor, but our current ones all follow an impressively consistent set of interface patterns:

It's a mindset shift from a text-first environment to a block-first environment.

In classic text documents the primary semantic unit is a single character or sentence. The document has no understanding of a set of sentences adding up to a larger semantic unit like a list, callout box, or code block. While you can sometimes add special elements to text documents like images or tables, they're treated as exceptions.

In block-editors, we don't treat text any differently to an image or table – it's just another block. Blocks are the primary unit of composition, not pages, paragraphs, or individual lines of text.

You click on the block type you want and it appears inline. You can then add content to the block, or continue adding blocks below.

This interaction pattern allows you to very quickly browse and select blocks without moving your hands off the keyboard. It helps keep you in the flow of writing like a traditional text editor would. Only with a far greater range of mediums and formatting options available at your fingertips.

Editors that are based around a canvas rather than a document often opt to display blocks in a persistent sidebar. This gives users a way select a block outside of a text input, and has the benefit of a larger browing area.

Checklist blocks let you type in text, tap the checkbox to items as done, assign people to tasks, and add due dates.

Image blocks let you upload files, embed images via URL, or search through popular creative commons libraries like Unsplash.

Table blocks let you arrange data in spreadsheets where you can name columns, add extra rows, and sort and filter values.

Each editor has their own set of block types they offer. While there’s no universally agreed upon list, there’s a set of basics that appear almost everywhere: text, header, checklist, bullet list, numbered list, image, video, callout, table, blockquote, embed, code block, divider, and file upload.

Beyond those essentials, its open game. Some editors distinguish themselves by offering a wider array of blocks with advanced functionality. These become competitive advantages in a domains where every app is a block-based editor. If you want to draw mermaid diagrams in a block you'll have to use . If you want a collaborative voting block you'll want to pick . If you want a block that behaves like a spaced repetition flashcard you'll want .

There seems to be no ceiling to the complexity level we're willing to wrap up into a single block. Some could be standalone apps in their own right. Kanban boards, image galleries, live coding environments, and fully decked-out spreadsheets that function as relational databases can all be encapsulated into a “block”. This extends to embeds which allow users to stick the whole of Google Maps, Figma, or Airtable into a document.

[image]

You can also click and hold a block, then drag-and-drop it into another place on the page. This makes it quick to restructure a document without faffing about with precise text selection.

[image]

You are directly touching and manipluating the thing you want to change, rather than typing instructions describing the thing you want to change into a text editor or command line.

This might not sound any different to how you interact with anything else on your computer. And it's not. Direct manipulation one of the hallmarks of modern graphical user interfaces. Ever since developed the principles of direct manipulation in the 1980's:

• Continuous representation of objects on the screen
• Using physical actions to perform tasks; clicking, dragging, and gestures
• Having continuous feedback about the system status
• Being able to make reversible, incremental actions

Blocks are a perfect example of how direct manipulation can drastically improve usability. Direct manipulation brings the principles of physical interaction to the digital interface and help make block-based interfaces intuitive for people to use.

The content a block holds and the way it displays that data isn't firmly tied together. This means if you decide you want a different block, you can easily swap it out. The content adapts to fit its new format. Data and display aren't tied to one another in block land. You can flexibly play with multiple ways to show the same data.

We could take this data set about Monty Python's filmography and display it as a table, a set of cards, a kanban board with statuses, or a timeline chart plotting data points.

These examples are made in but most advanced block-editors allow you to do this.

Checklists can become blockquotes. Headers can become collapsible toggles. Tables can become kanban boards.

[Swapping block types in Notion]

This requires more robust data structures and complexity on the backend, but it makes it possible to relate blocks to one another through links, references, and programmatic logic.

Notion's database blocks are a classic example of this. You're able to add related data through "rollups" and "functions" – these let you query data in other database blocks.

[ Notion rollups feature ]

Roam Research become known for their powerful referencing and backlinking features within blocks. They pioneered the idea of "embed blocks" where a single block could be embedded in multiple locations and synchronously edited from each instance. Soon after, Notion added "synced blocks" which follow the same principle.

[ Embedded blocks in roam ]

Block-editors like Glide and Fibery takes shared data a step further and allow you to construct data relationships outside of blocks, then reference them inside blocks. This separates the ontology layer from the display layer.

We've now seen the general shape and interface patterns of blocks, but what precisely defines a block?

We all love a good definitional debate, and I am not one to rob us of this opportunity. I offered a concise definition above: “A block is a rectangular section of your document that looks and acts a certain way, depending on its type."

I think it's pretty good summary of the situation, but one that leaks in a hundred ways. According to this, the navigation bar, dropdown menus, and obnoxious chat widget that won't stop audibly alerting you to a message from a bot could all be mistaken for blocks.

Let's try this defintion again, this time wearing our technological pedant hat:

Here's a visual version to help drive that definition home

What Blocks are Not

To reduce any confusion, let's also make clear what blocks are not. Within the context of this essay, blocks do not refer to:

• Components in the sense. Blocks and CBS are certainly compatible concepts, but the former is an interface design pattern and the latter an approach to software engineering that goes well beyond user-editable interfaces.
• A specific technical implementation. They are not the same as React components, Web Components, or the-next-hot-JS-framework components. They are a conceptual idea about how we present editable content to end-users of the web. One that could be implemented in any number of languages or frameworks.
• An entry on a blockchain ledger, or anything to do with Web3 blockchain hype. Please take that party elsewhere.

[cartoon sketch of a block as a higher interface concept, possibly implemented in WC/React/etc, but not concerned with implementation. And nothing to do with the blockchain]

The blocks I am talking about here are an interface pattern. How that pattern is implemented is beyond the scope of this article and my limited knowledge as a pseudo-developer. I'm interested in blocks from a user and interface designer perspective, rather than a web infrastructure perspective.

If I asked you to guess when blocks and block-based editors first appeared, I'd expect the audience to split into two camps with very different time scales.

In casual surveys with friends I found most people first became aware of block-based editors via . A smaller contingent with a longer history in software development cited projects like Microsoft's system and Apple's project:

To gauge the level of historical awareness around block-editors with a larger audience, I ran a quick Twitter poll. I don't have hard stats on the demographics of my twitter followers, but I'd summarise the group as well-informed programmers (primarily web developers), tools for thought enthusiasts, and interface designers. In that order.

Let's first acknowledge the fundamental flaws in my poll; it offers my predicted answers by default, and requires people go to the effort of replying if they have an alternate view.

The question itself was also duplicitous. Trying to pinpoint a single “invention moment” by one person or project in history is a fool's errand. Especially in the field of interface design where every new creation is a bric-a-brac recompilation of existing conventions and standards.

But we all make compromises to run reductive, ad-hoc twitter polls.

There were plenty of write-in replies that included , Douglas Engelbart's , , and the visual programming language. I agree that all of these projects played a role in the development of block interfaces. Many of them described or implemented software patterns that could easily be interpreted as block-like. We'll take a closer look at these in a minute.

Out of 185 people, over 50% knew about the OLE and OpenDoc projects from the 90's. A solid 30% still thought Notion was the first. This isn't too surprising, given that it's easily the most visible and widely used to date. Its predecessors are not immediately obvious, and do a poor job of self-promotion.

This is compounded by the fact the web development and design industry is reasonably oblivious to historical precedent. This isn't out of laziness or ambivalence. We're not an industry with well-established intellectual centres, academic legacies, or official degrees yet. None of us were required to take Web History 101 before FTP-ing up our weird Flash sites. We're left to scavenge community histories from the , wayback machine, and scattered Twitter threads from indsutry veterans.

With that in mind, let's forge ahead to try and make sense of this historical trajectory. I've split the evolution of blocks into three distinct ages:

Each of these time frames saw a surge in projects that explored the qualities that led to block interfaces. Many of the early efforts addressed pragmatic issues like ecosystem integration, UX usability, and hardware capacity.

The First Age of Blocks – Xanadu and NLS

1965-1968

The history of any modern interface pattern has to start in California in the late 1960s with the work of Ted Nelson, Douglas Engelbart, and Xerox PARC. The interface waters we currently swim in — graphical screens, click-and-point interactions, hyperlinks, and direct manipulation — all lead back to this same river.

To lightly set the scene, in the 1960s “computers” were giant, hulking, room-sized machines that only large, wealthy corporations and governments owned to run complex statistical and scientific calculations. The idea an individual person might own a one of these multi-million dollar computer was ludicrous. What could they possibly need it for?

It took a few rogue thinkers (and a few good drugs) to look at these industrial-size calculators and see something else entirely; the potential for personal devices that could augment the way people think, communicate, and create.

was one of the first to realise this. He wasn't a programmer, but a writer, film maker, and sociologist. He saw the early graphical interfaces engineers were hooking up to computers and imagined ways they might help him write screenplays and edit films.

Throughout the early 1960s he wrote a series of papers proposing a hypothetical system for managing text and editing documents on computers. The most relevant for us is a paper published by the ACM in 1965 called : A File Structure for the Complex, the Changing, and the Indeterminate. Here he coined the term hypertext, and laid out a structure for file management on machines that would influence the way we structure information for many decades.

The proposed ELF (evolutionary file structure) was made up of a "simple and generalizable building-block structure, user-oriented and wholly general purpose" that could be "shaped into various forms, changed from one arrangement to another in accordance with the user's changing need."

That system involved documents made up of 'parts', which could be any data type, and could be freely moved around a document. Being able to insert a part into multiple documents, link parts to one another, and easily rearrange parts within a document were all essential to the concept.

Nelson's subsequent work on

Working in the same realm as Nelson was .

In 1968 Engelbart gave showcasing the NLS (oNLine System). It featured a graphical interface, hyperlinks, point and click interactions, and live video conferencing via the internet all at once. Features that had never been seen before in computing.

In terms of block-like interactions, the NLS used flexible parts of a document that could be rearranged. This helped set the precedent for flexible data structures and dynamic documents.

These projects are all spiritual predecesors in this story. They aren't exactly like the blocks of today, but the interfaces patterns they established moved us closer to thinking in blocks.

The Second Age of Blocks – Hypercard, Microsoft OLE, and Open Doc

1987-1997

By the late 1980s, the personal computing revolution was in full swing. Boxy white DELL's graced every modern office desk. Families could afford their own Macintosh and a floppy of Oregon Trail.

The first meaningful block project in this period was Hypercard. Developed in 1987 by Bill Atkinson, Hypercard was designed to help non-programmers build their own multimedia apps. In Bill's own words, it's "a software erector set that lets non-programmers put together interactive information"

The concept was simple: users had a stack of cards they could put anything onto – text, pictures, videos, links, buttons, animations, and sound effects. Just like modern blocks, it relied on simple drag-and-drop functionality to make this process intuitive for users.

The detail that makes Hypercard truly remarkable is that each element on a card was programmable – you could open up an editing window and customise its behaviour using Hypertalk, a simplified progreamming language specially designed for Hypercard.

The beauty of Hypercard was that it has low floors and high ceilings, meaning it was simple enough for children to learn to use. But also powerful enough to support complex business applications. People built CRMs, encyclopaedias, and accounting tools in it.

The next two projects of this era were rivals racing to develop a brand new type of software: "compound documents". A

allow developers to write small component-level applications that would fit together as a unified document.

Microsoft was the first to begin working on infrastructure that would allow small components from one application to be used inside another.

This became a standard known as (OLE)

Microsoft developed a system that allowed users to select an “object” created in one Microsoft application and embed it in another. This Object Linking and Embedding (OLE) technology meant you could select a set of cells in Microsoft Excel, copy it, and then paste it into a Microsoft Word document. 'Embedding' the Excel object into Word.

Microsoft's OLE was the first implementation that made block documents possible. Despite this big pragmatic leap, they let their imaginations stop short. OLE didn't seem to spur any dreams beyond copying and pasting bits of Microsoft applications into one another.

Apple stepped up with a vision that aimed to compete with OLE, but took the idea to its full potential. was a programme that flipped the concept of how applications worked on its head. It proposed a compound document made up of multiple small applications, things it called “parts” – similar to our modern day blocks, but more ambitious.

"create small, reusable components, responsible for a specific task, such as text editing, bitmap editing, or browsing an FTP server. OpenDoc provides a framework in which these components can run together, and a document format for storing the data created by each component."

"Instead of requiring developers to write huge applications that had to do many things (for instance, any credible word processor needs not just editing features but spell checking, tables, embeddable photos, etc.) the [[OpenDoc] concept was that developers could just write the one piece they were best at, then let end-users mix and match all of the little pieces of functionality together as they wished"

the first OpenDoc-based product release was Apple's CyberDog web browser in May 1996. It died along with Hypercard in 1997

Despite the enthusiasm for the idea, it came too soon. At the time the physical limitations of the hardware couldn’t keep up with their ambitions. OpenDoc required 4-8 MB of RAM while most Apple computers only shipped with 2.

The idea died as attention and funding shifted from proprietary platform apps to the open web. These technologies were built in a time before the web; they were designed to work within a contained desktop environment. When the web rose in popularity, they weren't able to adapt. Microsoft created ActiveX which tried to bring OLE Object Linking and Embedding to the web but was wildly insecure. It would execute almost any .exe file you downloaded from the internet.

If we're just going off the promotional videos, OpenDoc is the clear winner in this popularity contest:

There's still a strong contingent of OpenDoc enthusiasts around. Lamenting its death, analysing what went wrong, and waiting for the idea to re-emerge.

Outside of specific projects like OpenDoc and OLE, the early 1990's was a moment when this dream of giving end-users access to the power and flexibilty that developers enjoy began to take shape.

• Angelika Leeb's MIT master's thesis: A flexible object architecture for component software (1996)

The Third Age of Blocks – Gutenberg, Notion, and the Cambrian Explosion

2016-present

Starting in 2016 we entered the third age of the block.

2016 was a significantly blocky year for two reasons. First, a small company called Notion released version 1.0 of their team wiki application. This first release introduced many of the interface patterns we now think of canonical for block-based editors. Second, a startup called released a plug-in for Wordpress that would end up changing the entire platform.

These are two useful landmarks to pay attention to, but it would be insincere to say blocks weren't already brewing on the web before this point.

From the start of “Web 2.0” in the mid-2000s block-like objects began to appear on our newly invented web apps – websites that allowed users to dynamically interact with the page without refreshing or reloading it.

Tumblr is worth mentioning here.

Tumblr was at the height of its popularity. The web was interactive and Web 2.0 was in full swing. More and more people needed accessible tools to publish content to the web.

Wordpress

Wordpress started work on Gutenberg in 2017(?) and released its first version in 2018(?).

Notion

Notion released version 2.0 in 2018. In this context, despite being the most visible and widely used block-editor to date, Notion was quite late to the game. It's undeniable Notion has been the most influential platform championing and pushing the boundaries of block editing in recent years.

Notion's first release in 2018 kicked things into high gear here. While Wordpress Gutenberg has been out for X years, it served a small use case; writing blog posts. Notion reframed the block-based editor as an everyday tool – a place to write collaborative documents for your team, or even just yourself. It turned it into an editor you live in, rather than a publishing tool for a specific purpose.

The Cambrian Explosion

It is exceptionally ironic that when Micrososoft announced their new project "Microsoft Loop” in X, it was lambasted across Twitter as a “shameless Notion clone."

These editors are sometimes belittled as “Notion clones", although Notion was not the first or last platform to implement the conceptual model of documents composed of blocks. Nevertheless, it became a touchstone reference point – a software category in its own right. Like Uber for X, we now have Notion, but with Y feature.

As with every shiny new interface pattern, we should question it. Even if the benefits of blocks seem obvious on the surface, it's worth asking what ways of working blocks have made possible. And what ways of working they've made harder or entirely impossible.

block-based editors are changing the way people create documents, websites, and apps on the web

Documents Before Blocks

Before these atomic, interactive blocks started appearing, our documents were predominately made up of simple text. A linear string of characters, spaces, and new lines breaks were the basic units of any digital document.

String enough of these lines together, and you have a document.

Simple text didn't stay simple for long. Starting in the 1980's, we added on rich text editing – text marked up with formatting like bold, italics, ~~strikethroughs~~, underlines, highlights and the like. Souped up text editors dave us even more formatting options like making the
font size huge and orange

These presentational annotations certainly add semantic meaning – big, orange, 3D text is clearly important.

But the formatting options available to us in classic rich text editing only manipulate the visual style of a set of characters. They rarely add meaningful semantic or functional structure to the document that the computer can understand.

Blocks, on the other hand, combine visual formatting with semantic structure. A Header block is significant both visually and as a type the computer understands.

In the case of documents in wikis and notes, we simply couldn't have created docs as complex with our previous tools.

Web Publishing & Blogging Before Blocks

Before they came along, creating a website or blog post of the same level of complexity avaliable in block-based editors would have required writing HTML, CSS, and JS by hand.

It is unsurprising the standard list of block types maps fairly tightly to the in HTML; <h1>, <img>, <ul>, <blockquote>, etc. The web was originally designed as a medium to author and share academic documents, and these basic primitives are still serving us well.

We might be tempted to think blocks are just a way to reuse pre-made snippets of HTML with a GUI stuck on top. This could be true for very basic blocks that simply format text. But many blocks offered by these editors included advanced functionality like uploading files, running calculations, external data integrations, state management, dynamic views, and the ability to filter, sort, and search for data.

We're so used to having access to this type of advanced formatting and functionality on the web we barely think twice about it.

But before these block-editors showed up you would need to know a non-trivial amount of HTML, CSS, and JavaScript if you wanted to add something this complex to a document on the web.

Figuring out how to stick some text in a <p> tag is one thing, but building a dynamic table with sorting and filtering is way beyond the programming capabilities of most of us. Blocks provide a user-friendly interface for creating rich, complex web components that previously only developers has access to. They shift power – even if only slightly – from developers to end users.

Even document editors that aren't officially webpage creators end up inadvertendly playing the role. Notion is designed as a wiki for teams, but so many people have reappropriated it as a platform for building personal websites, whole side industries have emerged to support it.

What Do Blocks Give Us That Linear Text Can't?

On the surface level, a page of linear text and a page of blocks seem identical. But structurally and functionally they are entirely different beasts.

[description of how block documents are different to rich text editors]

• Stylistic edits vs structural edits
• Granular character level editing vs block-level editing
• Documents as basic unit of linking, reference, and comments vs block as basic unit
• Flexibility of drag and drop rearrangement; importance of rapid rearrangement
• Swapping block types without changing the content; able to easily view the same data multiple ways
• Interactive and reactive documents; dynamic data on a page you can see in multiple ways, transform, and edit.

All of these presentational annotations expand what we're able to express and communicate through the medium of digital documents. But they're mostly surface level. Stylistic annotations change the visual display of our information, without applying any structural changes to the data. When we make text big and orange, the programme does not encode that as “this text is important” or “this text is a headline.” It has no semantic structure.

Formatting at the character level gives us an enormous amount of granular control – enough to hang ourselves with.

Classical documents might format at the character level, but they organise at the document level. The document is the entity you reference when you link to your work or reference it by name.

A block can be dragged and dropped into a new position on the page. It can be swapped for another type of block without changing its content. It can be copied and pasted into a different document without losing its content and structure.

[annotated diagram of swapping blocks and dragging and dropping blocks]

Blocks open up a world of flexibility and interactive power within a scoped area. They're easier to move around – a key quality for anyone working with ideas who needs to arrange and rearrange information in relationships to find the right groupings and sequences – which is to say, all of us doing knowledge work.

Blocks as Emergent, User-Driven Design Primitives

Blocks are about handing power over to end-users. I've touched on the topic of end-user programming in this piece already.

The long-tail problem of user interface design. We try to serve the most populous, visible, and loud users. There simply aren't enough developer resources to craft use cases for everyone.

Kamey Klimes calls this Designing for Emergence – when we take it as a given that users understand their own problems far better than we do, and should be given tools to design their own solutions. As opposed to designers and developers forcing their opinionated solution onto users.

This spirit of user-drvien design run back all the way back to the Smalltalk and HyperCard projects.

Block-based editors realise the dream of component documents that faltered in the 1990's. Many of the people who worked on the original OpenDoc project now point at the web as the realisation of their efforts. A multimedia document that can host multiple mini applications within a unified container.

The web has given us the shared medium to build on. Modular, composable blocks are the next major metaphor after the page.

Say what you've said. Poetic wrap up.

The story of blocks is the story of historical dreams taking shape. The visions of componund documents and end-user applications defined in the early 1990's are finally coming together on the web.