diff --git a/components/mdx/ListNumber.js b/components/mdx/ListNumber.js index 8d4e5a9b..d06d062b 100644 --- a/components/mdx/ListNumber.js +++ b/components/mdx/ListNumber.js @@ -100,7 +100,7 @@ export default function ListNumber({ number, title, children }) { return ( -

{title}

+

{title}

{children}
); @@ -108,4 +108,5 @@ export default function ListNumber({ number, title, children }) { const ListContainer = styled.div` display: inline-block; + margin-top: 1.5rem; `; diff --git a/components/unique/blocks/BlockAges.js b/components/unique/blocks/BlockAges.js index 775f45f9..79117648 100644 --- a/components/unique/blocks/BlockAges.js +++ b/components/unique/blocks/BlockAges.js @@ -5,45 +5,27 @@ const BlockAges = (props) => { - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + - + 1965 @@ -51,21 +33,21 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#04A5BB" fontFamily="Lato" - fontSize="14" + fontSize="16" xmlSpace="preserve" > - - 1990 + + 1987 - + 2016 @@ -73,10 +55,10 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#04A5BB" fontFamily="Lato" - fontSize="14" + fontSize="16" xmlSpace="preserve" > - + NOW @@ -84,10 +66,10 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#04A5BB" fontFamily="Lato" - fontSize="14" + fontSize="16" xmlSpace="preserve" > - + 1997 @@ -95,10 +77,10 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#04A5BB" fontFamily="Lato" - fontSize="14" + fontSize="16" xmlSpace="preserve" > - + 1968 @@ -106,10 +88,10 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#4A4A46" fontFamily="Lato" - fontSize="16" + fontSize="18" xmlSpace="preserve" > - + The first age @@ -117,10 +99,10 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#4A4A46" fontFamily="Lato" - fontSize="16" + fontSize="18" xmlSpace="preserve" > - + The second age @@ -128,10 +110,10 @@ const BlockAges = (props) => { style={{ whiteSpace: "pre" }} fill="#4A4A46" fontFamily="Lato" - fontSize="16" + fontSize="18" xmlSpace="preserve" > - + The third age diff --git a/components/unique/blocks/Blocktimeline.js b/components/unique/blocks/Blocktimeline.js index a282cd76..d9409d3c 100644 --- a/components/unique/blocks/Blocktimeline.js +++ b/components/unique/blocks/Blocktimeline.js @@ -1,161 +1,177 @@ const Blocktimeline = () => { return ( - - - - - - - - - - - - - - - Microsoft OLE and/or - - - OpenDoc invented it - - - - - - - - - Notion invented it - - - - + + + - - Microsoft OLE - - - - - 1990 + + Microsoft OLE and/or - - - - DATED TO FIRST PUBLIC RELEASE - - - - - 1996 - - - - - OpenDoc - - - - - 2016 - - - - - NOW + + OpenDoc invented it + + + + - - Notion + + Notion invented it - - + + + + + + + Microsoft OLE + + + + + 1990 + + + + + DATED TO FIRST PUBLIC RELEASE + + + + + 1996 + + + + + OpenDoc + + + + + 2016 + + + + + NOW + + + + + Notion + + + + + + + + + + + + ); }; diff --git a/components/unique/blocks/DemoBlock2.js b/components/unique/blocks/DemoBlock2.js index 379bf31d..e719f8ac 100644 --- a/components/unique/blocks/DemoBlock2.js +++ b/components/unique/blocks/DemoBlock2.js @@ -1,6 +1,6 @@ import React from "react"; -const DemoBlocks2 = (props) => { +const DemoBlock2 = (props) => { return ( { viewBox="0 0 449 526" xmlns="http://www.w3.org/2000/svg" > - - - - - - + + + + + + - + @@ -47,7 +47,7 @@ const DemoBlocks2 = (props) => { width="428" fill="white" rx="4" - x="16.6367" + x="16.6362" y="357" style={{filter:"url(#shadow)"}} /> @@ -55,36 +55,24 @@ const DemoBlocks2 = (props) => { height="162" width="427" rx="3.5" - stroke="#ECE6E6" - x="17.1367" + stroke="#E1EAF0" + x="17.1362" y="357.5" /> - - - - + { ); }; -export default DemoBlocks2; +export default DemoBlock2; diff --git a/components/unique/blocks/TextvBlocks.js b/components/unique/blocks/TextvBlocks.js index a3908802..31b20812 100644 --- a/components/unique/blocks/TextvBlocks.js +++ b/components/unique/blocks/TextvBlocks.js @@ -5,117 +5,171 @@ const TextvBlocks = (props) => { - + + + + + + + + - + - - - - - + - + - + 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" /> @@ -168,7 +168,7 @@ In classic documents where text is the default format, you can sometimes add spe width="128" height="128" stroke="#04A5BB" - stroke-width="2" + strokeWidth="2" /> + +People who have already read my [[Cambrian Blocks]] piece and are open to some playful speculation on the role of blocks in future interfaces. + + + + + +I used to work at HASH, a company building infrastructure for block-based editors. This essay and all the research associated with it is my own personal work and opinion, and no one else at the company was involved in its creation. It has no ulterior motive, other than to share my predictions on the block-based landscape. Feel free to take it all with a grain of salt anyway. + + + + + + +We're here to chuck around some irresponsibly speculative ideas on how the block landscape might evolve in the coming years. + +In [[Cambrian Blocks]] we worked through our blocky past and present +Which brings us to the part everyone clamours for. _But what is the future?_ What is the point of reciting history, if not to try and find patterns that point to what happens next? Let's march forwards with our rear-view mirror in hand. + +I've outlined a set of 'bets' I would make about how block interfaces will develop over the next 5 years. + + + + + + +As blocks become a more standardised interface approach, we should expect to see a wider diversity of block types. + +Current React developers have access to 60,000+ components. Users of block systems have access to an average of 30 blocks. + +We should be creating and supporting niche blocks – recipe cards, flight maps, [at least 6 more suggestions in here] + +I should point out here I'm advocating for a proliferation of _block types_ but not a proliferation of block interfaces and standards. + +### Standardisation of block editors + +Like all good software designers, the people creating these new editors are following [Jakob's Law](https://www.nngroup.com/videos/jakobs-law-internet-ux/) of internet user experience; people spend 99% of their time on websites _other than yours_. You'll make their lives far easier if you use design patterns they're already familiar with. While many will grumble the similarities between block-editors speaks to a lack of “innovation”, “Innovate” | ˈɪnəveɪt | verb. To flagrantly disregard previous historical work and established conventions that have survived the test of time. Results may vary. the industry converging around a set of standards is a net gain for both users and creators. + + + + + +This was the original dream of OpenDoc. The people who build block-editors don't necessarily have to be the same people who build blocks. + +This is currently manifesting as plugin marketplaces. Coda's maker marketplace is one of the recent signs we're moving in this direction. Roam's plugin marketplace. Figma's plugin marketplace. + +We've already been moving swiftly in this direction in the larger context of front-end web development. Modular components built by a wide variety of other engineers is the name of the game. We all rely upon open collective efforts like MUI, Chakra, Radix, Reach UI, etc. + +The same will happen with blocks, which are a simply a very specific type of component – one designed for authoring documents on the web. + +[ diagram ] + + + + + +Blocks connected to ontologicals structures. + +- Notion's 'databases' +- Palantir +- Fibery +- Anytype + + + + + +Blocks that specifically focus on giving end-users the kind of power programmers have. Setting state. Defining functions and calling them at the click of a button. Defining hover states. + +[Needs a better name] + +The biggest hope I have for blocks is as an entry point into front-end development for people who can't currently code. + +Button blocks on Coda and Retool are big indicators of this. + + + + + +I might as well have called this one 'blocks for digital gardening' + +Blocks designed for garden-esque structures on the web: reply blocks, academic citation blocks, questions, books, + +As an advocate of [[Digital Gardening]], this one comes from my own biases + +Enabling users to write rich content to the independent, open web. Web 2.0 enabled users to write to the web... within limitations. They can only write to “platforms” - FB, twitter. The platform owners control and own the content. + +Because blocks are inependent chunks of content, they could have their own addressable URLs. This would allow a block to be 'passed around' a community. Not unlike the way we pass around tweets + +The [Quotebacks]() tool that X and Y built is a good premonition of how this could work. A section of a length blogpost can be pulled out and referenced, while maintaing a consistent link back to the source. + +I touched on the possibilities of this kinds of persistent backlinking in [[Transclusion and Transcopyright Dreams]] + + + + + +Standing up a whole website has moved far beyond the capacities of most people. Sandboxed environments like Observable and Jupyter notebook give people the ability to write code and execute it without also needing to learn the command line, Webpack, DNS redirects, etc. etc. + +The web was born as a text-first medium. Tim Berners Lee designed it to mimic text documents. Specifically, long, linear research documents shared among scientists and academics as pieces of paper. Ever since then we've been negotiating its paper-like qualities. + +The text-first, document-based model comes with a lot of design implications. It presumes the document or page is the basic unit of the web. We store our metadata at the level of the page, usually in the `` tag. We link at the page level, rather than at the word, paragraph, or section level. This has improved slightly with #header-level links, but the vast majority of links are still to entire pages, not granular lines or sections within a page. + +Being able to link to specific blocks or sets of blocks. Tied up with the dream of [[Transclusions]]. Lalallal + + + + +Lalalallala \ No newline at end of file diff --git a/posts/essays/cambrian-blocks.mdx b/posts/essays/cambrian-blocks.mdx new file mode 100644 index 00000000..25cb39c2 --- /dev/null +++ b/posts/essays/cambrian-blocks.mdx @@ -0,0 +1,917 @@ +--- +title: "Cambrian Blocks: The Emergence & Evolution of Block-based Editors" +description: "The rise of interactive, user-editable blocks as the basic unit of documents on the web" +aliases: ['Cambrian Blocks'] +updated: "2022-08-15" +startDate: "2022-08-15" +type: "essay" +cover: "/images/covers/databases-cover@2x.png" +topics: ["Design", "The Web"] +featured: true +toc: true +growthStage: "seedling" +--- + + + +People who design and build websites, apps, and interfaces. Likely ones related to the fields of “tools for thought”, knowledge management, and collaborative work. + + + + + +I used to work at [HASH](https://hash.ai), a company building infrastructure for block-based editors. This essay and all the research associated with it is my own personal work and opinion, and no one else at the company was involved in its creation. It has no ulterior motive, other than to share my research and reflections on the block-based landscape. Feel free to take it all with a grain of salt anyway. +
+Also, this essay has nothing to do with the blockchain or the Web3 movement and will not be available for purchase as an NFT. It's not that kind of block. + +
+ + + + + +Over the last five years, our digital documents, canvases, emails, and pages have taken on a strange shape. They have become noticeably _blocky_. + + + +The **block** is our hot new interface patternTake “new” lightly here. The concept of blocks is an exceptionally old idea in software design, but we will cover that ground later.. 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. At a lower level these blocks are of course built with core web technologies, but at the level of the user interface people don't need to touch code. 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. ] + + +## The Block-based Landscape + +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: + + + +Document editors, team wikis, and personal note-taking systems were the first category to get on board with blocks. The most popular examples here include [Notion](https://www.notion.so/), [Coda](https://coda.io/), and [Roam Research](https://roamresearch.com/) + + + + + +Platforms that help people create blog posts, emails, and simple webpages through drag-and-drop interfaces rely upon blocks. These include [Wordpress Gutenberg](https://wordpress.org/gutenberg/), [Squarespace](https://www.squarespace.com/), [Mailchimp](https://mailchimp.com/en-gb/features/dynamic-content/) and [Webflow](https://webflow.com/) + + + + + +Platforms that give small teams and companies the flexibilty to create their own dynamic views of data and perform basic actions are also heavy block-users. Newer apps like [Retool](https://retool.com/), [Glide](https://www.glideapps.com/), and [ClickUp](https://clickup.com/) fit into this space. + + + +In addition to those mentioned above there's also [Craft](https://www.craft.do/), [Clover](https://cloverapp.co/), [Microsoft Loop](https://www.microsoft.com/en-us/microsoft-loop?ms.url=microsoftcommicrosoft-loop), [Kosmik](https://www.kosmik.app/), [Roam Research](https://roamresearch.com/), [Logseq](https://logseq.com/), [Fermat](https://fermat.ws), [Remnote](https://www.remnote.com/), [Thunknotes](https://www.thunknotes.com/), [Clarity](https://www.clarity.so/), [Muse](https://museapp.com/), [Reflect](https://reflect.app/), [Athens](https://www.athensresearch.org/), 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. + +## The Established Patterns of Blocks + +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: + +
+ +Pattern #1 + + + + + +

Blocks are first-class citizens

+ +Blocks are the primary objects users interact with in these editors. Documents made with blocks look suspiciously similar to traditional documents, but +are built around a different conceptual model. Rather than treating documents as +strings and paragraphs of styled text, these editors treat them as a stack of types +blocks: + +
+ + + + + + + +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. + + +
+ + + Pattern #2 + + + + + +

1-click block creation

+ +All block-based editors allow you to quickly add a block to a document or canvas within 1-2 clicks or keystrokes. Most do this by having users type a hotkey – usually the slash `/` key Or rarely @ if an app is feeling particularly spicy and innovative. Sometimes you can also click a floating + icon nearby.. This triggers a “block picker” menu that offers users a set of block choices: + +
+ + + + + + + + + + + + + +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. + + + +
+ + + Pattern #3 + + + + + +

Each block has a unique, pre-formatted type

+ +Every block has a “type” – a specific format that determines what kind of content it will accept (some text, a set of numbers, an image, etc.), how it displays that data, and how the user can interact with it. + +When you create a new block, the default interface elements and input fields usually make it clear what kind of content you can enter. + +
+ +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 [Notion](https://notion.com/). If you want a collaborative voting block you'll want to pick [Coda](https://coda.io/). If you want a block that behaves like a spaced repetition flashcard you'll want [Remnote](https://www.remnote.com/). + + + +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. + + +
+ + + Pattern #4 + + + + + +

Direct manipulation of blocks

+ +If you want to create, edit, or move a block, you do it via [direct manipulation](https://www.nngroup.com/articles/direct-manipulation/). Meaning you move your cursor over the block and click on any parts you want to edit. + +
+ +[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 [Ben Schneiderman](https://en.wikipedia.org/wiki/Ben_Shneiderman) 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. + + +
+ + + Pattern #5 + + + + + +

Seperation of data and formatting

+ +Each block displays a specific set of data. This might be a string of text like "A shrubbery is the innocuous demand made by the knights who say _Ni!_ in the 1975 film _Monty Python and the Holy Grail_". Or it could be a PNG photograph of John Cleese. Or a set dates cataloguing when each Monty Python film was released. + +
+ +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 [Coda](https://coda.io) but most advanced block-editors allow you to do this. + +Checklists can become blockquotes. Headers can become collapsible toggles. Tables can become kanban boards. There are of course sensible limitations to this. Most applications won't let you turn an image into a code block or a video block. + +[Swapping block types in Notion] + + +
+ + + Pattern #6 + + + + + +

Individually addressable and linkable

+ +Each block can be directly linked to. The same way you can link to a webpage. It has a unique URL you can send somone to. + +Internally within these tools you can usually directly reference another block anywhere else in the system. + +[ Searching for other blocks in Notion, Roam, and ] + +
+ +
+ + + Pattern #6 + + + + + +

Shared data between blocks

+ +The content we put into a block isn't necessarily constrained to just that block. In some of the more advanced block-editors, blocks can query and reference data held in other blocks. + +
+ +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.This principle has a much longer history which I covered in both [[A Short History of Bi-directional Links]] and [[Transclusion and Transcopyright]] dreams + +[ 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. + + + +--- + +## What _exactly_ is a block? + +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: This is a good faith best effort, which I'm certainly open to revising if and when more intelligent and experienced people point out its flaws on Twitter. At least be polite when you do :) + + + +Definition: block| blɒk |Noun + +A block is the basic semantic unit of a block-based interface. It is a self-contained set of data, with a specific type, that can a user can easily add to a document or canvas. Blocks can be flexibly composed, arranged, and interlinked with other blocks on the page. +Each block... + +- is connected to a specific set of data +- has a unique type that determines how it displays that data. This type can be changed without affecting the data it displays. +- allows _end-users_ to input, edit, and delete data within the block + + + +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 [component-based software](https://en.wikipedia.org/wiki/Component-based_software_engineering) 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. There is plenty to be said about the technical challenges of how we could/should build interoperable blocks built on solid web standards, but I'll leave that to someone else. Perhaps you? + +--- + +## A History of Blocks + +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 [Notion](https://www.notion.so/). A smaller contingent with a longer history in software development cited projects like Microsoft's [OLE](https://en.wikipedia.org/wiki/Object_Linking_and_Embedding) system and Apple's [OpenDoc](https://en.wikipedia.org/wiki/OpenDoc) 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 [Hypercard](https://en.wikipedia.org/wiki/HyperCard), Douglas Engelbart's [NLS System](), [Ted Nelson](https://en.wikipedia.org/wiki/Ted_Nelson), and the [Pygmalion](http://acypher.com/wwid/Chapters/01Pygmalion.html) 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 [C2 wiki](https://wiki.c2.com/), 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. + +[Ted Nelson](https://en.wikipedia.org/wiki/Ted_Nelson) 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 [**Complex Information Processing**](https://dl.acm.org/doi/10.1145/800197.806036): **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." Nelson 1965, Complex Information Processing, p.84-89 + +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 [[Project Xanadu]] built on these initial ideas and continued to pursue systems for “serious electronic literature.” It's clear his central concept of linked, rearrangeable blocks of multimedia content lives on in our modern block-based editors. + +Working in the same realm as Nelson was [Douglas Engelbart](https://en.wikipedia.org/wiki/Douglas_Engelbart). + +In 1968 Engelbart gave [the mother of all demos](https://www.youtube.com/watch?v=M5PgQS3ZBWA&list=PLCGFadV4FqU3flMPLg36d8RFQW65bWsnP&index=1) 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. + +