`, 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 `` 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.
+
+
+## Conclusion and summary
+
+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.
+
+
+
+Read next
+
+The follow-up to this post is [[Block to the Future]] – a short essay exploring how I think block-based editors will evolve over the next 5-10 years
+
+
+
+
+
+
+
+
+
+
+
+
+
+
From baf9dfcb57755475c306bc6312d00565cd0f60cd Mon Sep 17 00:00:00 2001
From: Maggie Appleton <5599295+MaggieAppleton@users.noreply.github.com>
Date: Tue, 23 Aug 2022 13:15:30 +0100
Subject: [PATCH 2/2] edits
---
posts/.drafts/block-party.mdx | 12 +++++-----
posts/essays/cambrian-blocks.mdx | 40 ++++++++++++++------------------
2 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/posts/.drafts/block-party.mdx b/posts/.drafts/block-party.mdx
index a0cd72ae..5facacac 100644
--- a/posts/.drafts/block-party.mdx
+++ b/posts/.drafts/block-party.mdx
@@ -120,7 +120,7 @@ aria-labelledby="titleID"
width="128"
height="128"
stroke="#04A5BB"
- stroke-width="2"
+ strokeWidth="2"
/>