The recent fad of the metaverse is all about digitizing the physical world and moving our shared experiences (even more so) onto the internet.

I wonder what an opposite approach might look like—one where, instead of making the physical digital, we instead attempt to bring the online world into our physical spaces (and no, I don’t remotely mean AR or VR).

The first thing that comes to mind for me is Berg’s now-defunct Little Printer project from back in 2012 or so. Little Printer was a web-connected thermal printer that lived in your home and allowed you to receive print-outs of digital publications, your daily agenda, messages from friends, etc.

Little Printer was an attempt at bridging the physical and digital, essentially creating a social network manifested as a physical object in the home and consumed via paper and ink.

Personal websites are the digital homesteads for many. Those sites live somewhere on a web server, quietly humming away in a warehouse meant to keep them online and secure. For each of us those servers represent empty rooms waiting to be decorated with our thoughts, feelings, interests, and personalities. We then invite strangers from all over the world to step inside and have a look.

Like the Little Printer, I wish that my web server could exist in my home as a physical object that could be touched, observed, and interacted with.

Hosting a web server yourself is surprisingly difficult today given the advances we’ve made in consumer technology over the last few decades. Hosting content on someone else’s server has become as simple as dragging and dropping a folder onto your web browser. There are countless business that will happily rent out online space to for very cheap (or even free, with the hopes that eventually you’ll upgrade and give them money).

We’re all tenants of a digital shopping mall, sharing space controlled by corporate entities who may not share our values or interests.

When someone visits my website, I wish it could feel more like inviting them into my home. What if my website lived in my home with me?

Imagine if having a web server in the home was as common as any other appliance such as a refridgerator. You might look over and see your friend (or a welcome stranger!) browsing your website. You could see what they’re browsing—look at photos with them, listen to a song together, whatever—and start a conversation about any of it.

I’m certainly not the only one who has imagined this. A while ago I stumbled upon a project by a student named Jeeyoon Hyun called “Personal Pet Pages” which is a small, personal web server with a fiendly screen displaying what’s going on inside the server.

Ever since we’ve decided that servers are something heavy, enigmatic, gigantic black boxes belonging to corporations - not individuals - we have slowly lost agency towards our own small space on the Internet. But actually, servers are just computers. Just as your favorite cassette player or portable game console, they are something that you can possess and understand and enjoy.

Personal Pet Pages, ITP Thesis Archives 2022

Jeeyoon’s idea combines turns a web server into a sort of virtual pet, one that you can move around and interact with.

Matt Webb has also considered the idea:

It is boundary-violating, to have a website in the corner of your bedroom. Websites are meant to be in the cloud. Eternal, somehow, transcendent, like the voice of code floating down from the sky. But no, there it is. It is real! I can kick it! Argumentum ad lapidem.

I wish my web server were in the corner of my room

Those fixated with the idea of the metaverse might are interested in bringing real-world objects into the cloud. I wonder instead how we might try to bring objects from the cloud into the real world and into our homes. How would we design webpages differently if our materials included the servers that they’re hosted on?

I remember the first time I saw a Mac in person. I was in middle school, but on the campus of the nearby college because my dad had a gig as a stand-in drummer for a local band.

While hanging out backstage—something I often had the privilege of doing from a young age as the son of a drummer—I saw a girl, sitting on the ground, typing away on a brand new MacBook Air.

The Air had just been introduced to the world, and I remember rewatching the announcement video online. Steve Jobs talked about the computer at Macworld only to reveal that it had been on stage with him the entire time inside a manilla envelope. He opened it and pulled out the thinnest computer in the world. I had no idea a computer could even look like that.

After my dad’s show I immediately pointed out the girl and her computer, and I remember him sharing my excitement so much that he asked the girl if we could look at it a bit closer. She was kind and happy to show it off and even let me hold it. From then on, I was hooked. I knew that’s the computer I’d own one day, and sure enough I’d get my first Mac, a MacBook Air, a few years later in high school.

And now Apple has introduced a MacBook Air thinner than the original iPhone. I wonder what middle school me, who coveted but did not own an iPhone at the time, would think about that.

I received the new M2 MacBook Air (in Midnight) a few months ago and I’ve been smitten with it. It is a cool, dark slab of silent compute, and it feels dense and book-ish in the most satisfying way.

The battery life deserves its own mention, and feels like a leap ahead for personal computers in its own right.

In all honesty I thought the time had come when a computer could not longer really excite me in the way that original MacBook Air did. But, this new one takes me right back there. It reminds me how lucky we all are to carry around devices that can conjure up all sorts of magic. And it takes me back to my beginnings in software when people wrote about the design of new iOS and Mac apps like they were art critics.

My life and friends and relationships and career are all in there, wound up with the electrons.

In setting up and using this new computer for the first time, however, I’ve realized how much devices today are like shells. The real computers, the ones that store our data and perform tasks on our behalf, are behemoths sitting in data centers. Setting up a new computer today is mostly a task of signing into various web applications to access your data, not transferring data onto the machine itself.

Our computers have become internet computers. And that might mean that the physical devices we own will trend towards nothingness—their goal is no longer to impress or inspire, but to be so small and light as to fall away entirely.

There’s something about that which makes me feel a bit melancholy. It feels like the days of computing devices being objects with personality and conviviality are fading. The computer is no longer a centerpiece, it’s an accessory, a thin client for some other machine or machines which are hidden away from us.

Since I was a kid the space program has been an object of my fascination, and even as an adult I’ve been captured by the heroics of NASA and other organizations launching probes and telescopes into the far reaches of space.

But something has never sat quite right with me about the recently renewed interest in human space travel, especially from CEOs of private companies like Musk and Bezos.

I think it’s always been a combination of two things:

1. There are so many problems here on Earth, many of which could be solved with the resources being invested into sending humans to another world.
2. Colonizing another planet is… still colonization.

I’d really never given it too much thought until this week when Maciej Cegłowski made his blogging return for the first time since 2020:

Wherever you stand on the matter, whether you’re a Musk fanboy, an unaligned Mars obsessive, or just biplanetary/curious, I invite you to come imagine with me what it would take, and what it would really mean, for people to go put their footprints in the Martian sand.

Idle Words: Why Not Mars

Maciej does a great job explaining just how bad and nonsensical of an idea it is to send humans to Mars.

As much as I love media about humans traveling to the red planet (The Martian and For All Mankind come to mind), perhaps it’s best that fantasy lives on solely as part of our imagination for now.

The Browser Company of New York is building a web browser called Arc, and they recently shared a preview of a new feature called “Boosts”.

Boosts are a reinvention of browser extensions—a built-in way to boost the web by writing your own code (HTML, JavaScript, and CSS) that can run on any website or specific ones that you assign. Check out this example of applying custom styles to GitHub:

Look at that! The webpage on the right is the canvas, and the code on the left is the medium. They’ve even built in visual editing tools such as a color picker.

Webpages have always been destinations, but this invites them to be starting points—blank canvases, even. Your browser now invites you to extend and reimagine the web in whatever way you see fit.

It has always been possible to run user scripts and styles via browser extensions, but the developer experience of creating an extension has never been particularly beginner friendly. I’ve personally never seen extension development integrated so seamlessly and directly into the browser. Arc even implies that working with the web might be just as important as browsing it—in Arc’s interface, the Boost editor sits at the same level as the page you’re browsing, not in some nested panel that feels secondary to the experience.

Under the hood, Boosts are just a folder of HTML, JS, and CSS files. You can zip them up and send them to a friend, if you’d like. One can imagine a way to easily share boosts on the web in some sort of marketplace built right into Arc. There could be entire forums dedicated to sharing boosts around like Winamp skins for websites.

Boosts empowers even non technical users to create with the web rather than simply consuming it. The possibilities are exciting, and it’s refreshing that they’re being explored by a startup in 2022 at all.

I’m interested in software that works for us, our creativity, and our attention. The web is a powerful building material with a variety of textures, and it’s time we had tools that let all of us take advantage of such an incredible resource.

From The Browser Company’s email to Arc beta members about Boosts:

So, what happens to the internet when changing the internet is this easy?

I can’t wait to find out.

If you read any of my writing you know that Robin Sloan is one of my favorite internet thinkers. He’s just published a spec for a new web protocol he’s designed called Spring ‘83.

I’d encourage you to read the spec yourself and check out the demo client. Just look at it:

It’s just so wonderfully web-ish.

Robin frames this work around imagining alternative “ways of relating” across the internet. So many of our current ways of relating online (social media, RSS, email) do a create job of syndicating and delivering content, but they sacrifice the presentation of the content and in doing so lose a key piece of what makes the web so great: creativity, expression, and freedom.

Robin touches on this in his newsletter announcing Spring ‘83:

For my part, I believe presentation is fused to content; I believe presentation is a form of content; so RSS cannot be the end of the story.

Specifying Spring '83

I hadn’t thought about this much before, but subconsciously I’ve always been aware of it on some level because when I read RSS I much prefer to jump out to a person’s website rather than reading in the client. It feels more personal and imparts the voice of the author. Reading on the source website feels like stepping into someone’s home for a chat, whereas reading in an RSS client feels more… clinical.

It makes me dream of an RSS reader that could emulate the styles of the websites it’s syndicating. I’m reminded of a protocol-like idea from Kicks Condor called “whostyles” which is “a way of styling syndicated hypertext from other writers.”

Whostyles calls on website owners to make a chunk of CSS available at a well-known URL that others can embed into their sites to match the style of the original. If everyone implemented a whostyle for their site, an RSS client could use it to personalize the display of feed entries.

Spring ‘83 feels like it’s getting at these ideas, and it’s doing so by embracing HTML/CSS as a creative tool and a medium unto themselves.

A few things came across my desk this week that inspired hope about the future of the web and hypermedia as a medium.

No matter whether you consider yourself technical or not, it has never been easier to be creative with web technologies. Even the pain of setting up a local development environment has been abstracted away by code-in-the browser apps.

Why, then, have we not seen more people using the web as you might expect a layperson use a spreadsheet to assist with a myriad of tasks? The web goes far beyond just letting us organize and process information, it also lets us architect our own little palaces in the ether. It leaves space not just for data and numbers, but for our imaginations and interests.

Cristóbal Sciutto published an essay this past week about using the browser and the filesystem to visualize local media, and why others might want to build their own media environments. He calls these folk interfaces:

I think of these as folk interfaces, akin to the jigs one makes in wood-working. Divorced from grandiose ambitions of building comprehensive systems, it leads the programmer to directly engage with data. I hope this mode can paint the picture of software, not as a teleological instrument careening towards automation and ease, but as a medium for intimacy with the matter of our time (images, audio, video), yielding a sense of agency with what, to most, feels like an indelible substrate.

Folk (Browser) Interfaces

The spreadsheet might lend us the wonders of automation, but the web has romance. It lets us connect with what Cristóbal calls the “matter of our time” in a way that is much more human.

We’ve put the web in the hands of nearly everyone in society, but we’ve spent a depressingly small amount of time helping folks use the web as a building material.

If we want to empower the average web user to harness the power of the tools at their fingertips, it makes sense that we would start teaching the basic skills needed at a young age.

On that note, someone started an interesting thread on Hacker News this past week: Is there a site popular with Gen Z where users can write HTML and CSS?

In the 90’s, a number of teenagers made Geocities sites, which awakened their interest in web development and taught them some basics of HTML, CSS and JavaScript. Many of these teens went on to become web developers. […] Later still, many teenagers learned these skills customizing their Tumblr.

Ah, this had me reminiscing of many late hours spent hacking in the Tumblr theme editor.

There is some interesting discussion in the thread about how approachable mature technologies can even be to the uninitiated:

It’s probably disappointing to see the path so many of us took closing up behind us, but to some extent is a normal process for a maturing profession. There aren’t really accessible DIY paths to auto mechanic, aviator, architect, or lawyer either, though there once were.

I think that this is one of the great challenges we face as the web matures. If we don’t maintain accessible DIY paths as a point of order, we’ll lose the spirit of what has made the texture of the web that we know today.

Building the web is better compared not to auto mechanics and architects, but to painters and artists. You don’t need to make painting your profession to enjoy it as a method of self expression, and the same holds true of the web and any other creative medium.

Art class in middle school should have days focused on CSS.

Finally, an example of something being done to keep this kind of folklore alive for the generations to come. Figma and Google announced a partnership whereby students using Chromebooks will have free access to Figma.

Access is core to Figma’s mission. By partnering with the Chromebook team, we are able to use our web-based roots to deliver collaborative design software to more students and educators inside and outside of the classroom.

Figma education beta

This warms my heart in a way that is unusual considering Google is involved.

Figma is a powerful tool that, importantly, is made of the web. There’s quite a lot that a middle school Chase could have imagined up with an infinite, scriptable canvas like Figma.

When it comes to discovering the expressiveness of the web, Figma is a powerful gateway drug.

This week the team behind Stripe’s documentation launched Markdoc, the toolchain used internally to author and manage all of our docs. I’ve had the pleasure of working with this team and Markdoc internally at Stripe for some time, and I wanted to write a bit about why it’s such an exciting tool.

I have quite a bit of experience building content-heavy documentation sites for design systems, most of which have previously used MDX. MDX was a revolution due to the ease of use and familiarity of Markdown married with the power of being able to render arbitrary React components within your document. But in every MDX project I’ve worked on there have eventually been scaling and maintenance issues with closely marrying content/data and code.

Markdoc creates cleaner boundaries between your content and the code that powers and enriches it. If MDX is “docs as code” then Markdoc is “docs as data”. MDX gives authors the full power of JSX, whereas Markdoc requires maintainers to carefully consider the primitives that are exposed to authors, and how they are exposed. Markdoc includes tooling to validate that content has been authored correctly and according to spec, whereas MDX is a free-for-all.

Another benefit of Markdoc is that it doesn’t require abandoning Markdown to achieve customization. While I think some of this has been addressed in MDX v2, consider a case where you want to render a <ul> with a custom class name attached. In MDX, you need to bail out of Markdown and fall back to HTML or JSX:

# Some fancy list:

<ul class='fancy'>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

With Markdoc, you can attach an annotation to Markdown elements while still using Markdown syntax:

# Some fancy list:

- Item 1 {% .fancy %}
- Item 2
- Item 3

This is a lot easier to maintain and also retains the value of a Markdown powered authoring environment—Markdown is easy to use, even for non-technical contributors!

There are a lot of other reasons to love Markdoc that I won’t get into here. I am a big fan of the tool (as a user, not just because I work at Stripe) and I’m leveraging it to build the documentation site for Stripe’s design system. Congrats to the Docs team for creating such a robust tool and for making it available to the world as an open source project.

This week I finally received my Playdate from the folks over at Panic, and it’s just as delightful as everyone knew it would be. The Playdate account on Twitter recently tweeted:

That link at the end is not of the hypertext transfer variety—it’s a link to a resource via the Gopher protocol, which is an early predecessor of and not alternative to the web as we know it today. Gopher is used by a very small few today, but that’s not to say it’s not thriving. There are beautiful and rich communities running on Gopher.

If you don’t have a Gopher client handy, here’s a link to the document on the web. It’s a short reflection by Panic co-founder Steven Frank on the Playdate finally shipping after years of work, and I recommend you give it a read.

This stood out to me:

Maybe not every piece of new tech has to be the all-singing, all-dancing conqueror of all tech that came before. Maybe it wouldn’t hurt to slow down for a moment and re-explore some of the genuinely good ideas that fell to the wayside as we hurtled headlong into our current future. Maybe hardware whose primary appeal does not hinge on being the absolute cutting edge won’t become landfill quite as quickly. Maybe crushing every competitor needn’t be the goal of every business. Maybe, just maybe, it is good for alternatives to popular ideas to exist.

I immediately thought of the recent swerve in front-end development back towards the platform and web standards. Tools like Remix, Astro, Eleventy and Deno lean not just into the technologies of the web but also the underlying principles. Turns out there are lots of fantastic ideas that we largely forgot about while chasing after the latest and greatest.

To echo Steven, maybe code whose primary appeal does not hinge on being the absolute cutting edge won’t become obsolete quite as quickly. Sustainability is derived from a deep understanding materials, mediums, and their histories.

Playdate doesn’t compete with traditional handheld game consoles in the same way that Gopher no longer competes with the Web—by not playing the game at all. They are projects that understand their medium and are satisfied with exploring their own tiny little corner of it. They know that it’s more important to have 1,000 true fans than millions of unengaged users.

What are some of the genuinely good ideas we let fall to the wayside during our time working on the web that we could re-explore?

I started my career building iOS apps, and made my way back to the web out of excitement for tools that were emerging at the time around component-based design and development. I remember feeling that the idea of encapsulating markup, styles, and behavior was so obvious, and I couldn’t believe at the time that there was no method for that built directly into the platform. If you wanted to build components for the web you needed to setup a complex toolchain and build process, which is very intimidating for beginners.

In the years since, there’s been a lot of work done on the web platform to get us closer to a reality where you can design/build with components right out of the box. A great example of this was announced this week by the Lit team: an Eleventy plugin for statically rendering web components.

Me from 10 years ago trying to create a component-based website would have been overjoyed by the simplicity of this. I’m thankful for React et al. for changing the way we think about frontend development, but I’m even more thankful that future web developers will have a far more approachable (and lightweight) entry point to best practices.

Lately I’ve been thinking a lot about design systems documentation, and more importantly how we scale knowledge and best practices across a large team. Looking at most system documentation (including for the design systems I’ve built), you’ll see something that heavily resembles the documentation you might find for a standalone product or software library.

We’re used to writing and reading long, linear documents full of content structured from top-to-bottom. But I think that content is actually far more useful in small chunks that are individually addressable.

Design systems can offer products, and some of those may be software libraries, but a design system is not only a product or a library. Good systems are hyperobjects that capture decisions, language, patterns, history, and all of the things that make and have made your organization’s design what it is. They resemble knowledge graphs far more than products, and I’d like to see some of the emerging patterns around software for managing a knowledge graph applied to design systems.

What is a knowledge graph? The best formal definition I found was this one:

The knowledge graph represents a collection of interlinked descriptions of entities – objects, events or concepts. Knowledge graphs put data in context via linking and semantic metadata and this way provide a framework for data integration, unification, analytics and sharing.

The best way to think about how a knowledge graph can be represented in software form is to look at tools like Roam Research, Obsidian, and to some degree (with their new synced blocks feature) Notion. There are also individuals experimenting with these concepts, such as Andy Matuschak’s personal notes

These tools pull from a long history of ideas that can tie their origins to the creation of hypertext itself. But the original vision of hypertext is not really like the hypertext of today’s web. Pioneers like Ted Nelson imagined a hypertext where links aren’t only one way, and where information can be referenced and embedded across many contexts. (By the way, Devon Zuegel did a wonderful interview with Ted Nelson for Notion.)

Unfortunately, we didn’t get Mr. Nelson’s vision for hypertext with the web. Many of the reasons documentation on the web today is so limited is due to the limitations of the medium itself. Despite that, there are tools and sites popping up that give us a look at some of these ideas implemented on the web.

Knowledge graph systems that make specific ideas addressable unlock some interesting ideas that I think could be applied to documentation (not only, but especially, for design systems).

Transclusion

When content is stored in its minimum viable format and can be referenced uniquely, it becomes possible to “transclude” or embed the content directly in whatever context you’d like.

Imagine all of the pieces of a design system that could individually encoded:

• Styles
• Tokens
• Components
• Patterns
• Guidelines
• Frameworks
• Properties
• Content
• Icons
• Illustrations

Wherever these concepts are mentioned in our document, they could instead be transcluded. This means that future updates to that information are propagated through our documentation rather than documents slowly becoming out of sync with one another.

Not to mention that linking these concepts rather than simply re-iterating exposes the structure and relationships in our system to the end user—by seeing how things relate, they get better at navigating the system in the future.

I’ve tried to integrate some of these concepts into design system documentation before, and I’ve seen other systems experiment with it as well. When I was working on the Seeds design system, we built embeddable tags for some of the concepts in our system like design tokens, components, and even specific props on components. When the user hovers over the tokens, they can learn get more information about them inline without switching contexts:

Whenever we updated one of these concepts in our system, we no longer needed to worry whether references throughout our docs would get updated as well. Other design systems have used this same idea. Here is a similar concept from Kiwi’s Orbit design system:

I think the idea could be taken even further, allowing not only simple values to be referenced but entire sections of content to be remixed and re-used throughout the knowledge graph.

Bidirectional links

Bidirectional links build on transclusion by making the original piece of content aware of where it is being referenced throughout the graph.

There are many ways in which bidirectional links would benefit a design system Consider a Button component, which imports and uses an Icon component. This dependency within the system resembles a link in a knowledge graph, and it should be bidirectional as well. If I view the documentation for Button, I want to see that it consumes Icon. And if I view the documentation for Icon, I want to see that it’s consumed by Button (and whatever other components).

Bidirectional links would allow us to visualize the relationship between entities in our system in unique ways. The most obvious example of this is showing the graph as a graph, which is a hallmark feature of Roam and Obsidian.

While this view is impressive, it may not be all that useful. I’d like to see something more like Andy Matuschak’s site applied to a design system:

Here, when you click on a new link it is layered onto the previous one. You can easily visualize the path you took to find a certain concept, and can view all of the related material that led you there side by side. The specific order is encoded in the URL as well, meaning you can uniquely share this path through the information with others.

Fragments

One of the most fascinating things to me as a kid about the periodic table of elements was that the way the table was organized told us about the existence of certain elements before they were ever discovered. We knew there should be something in the table at specific places, and we even knew certain properties of the elements that would eventually live there.

Design systems are similar—there are many concepts within our systems that do not exist, and yet we know that they’re there and that they will exist in the future.

Knowledge graph apps like Roam and Obsidian let you create a new object in your graph by simply naming it and linking to it. This creates what I’m calling a “fragment” here, an object in the system that is essentially undefined beyond its existence.

This is very similar to the concept of “red links” on Wikipedia, which represent linked-to pages that don’t yet exist. Here’s what the Wikipedia entry has to say about Wikipedia’s red links:

The creation of red links prevents new pages from being orphaned from the start. Good red links help Wikipedia—they encourage new contributors in useful directions, and remind us that Wikipedia is far from finished.

I believe that fragments and red links in design systems could be an effective tool for encouraging contribution: “Here’s a thing we know we need, it’s been identified but hasn’t been designed/developed yet. Want to help us add it?” Having a list of fragments at the very least gives you a good backlog of content to create for your system.

Queries

While this may be more of a application of knowledge graphs than a direct feature of them, it’s a powerful concept demonstrated by Roam Research’s query feature. In Roam, you can create queries for concepts in the graph using complex logical operators. The results are transcluded into the page where the query is performed.

This concept, if applied to documentation, would allow the user to query the knowledge graph that is our design system. For instance, a designer might want to query icons AND (onboarding OR first use) to see all of the icons in the system used within onboarding and first use experiences.

I’d love to see a future where, instead of browsing a documentation site to learn about a design system, we could ask questions of the system and receive answers and relevant resources immediately.

Shopify’s Polaris design system gets at this idea a bit by exposing a GraphQL API for their design system content including pages, design tokens, components, examples, and more. While their API is targeted towards creating documentation sites, Figma plugins, etc. it would be interesting to see this API exposed directly to users as an interface for the system.

Roam’s white paper gives a good description of the benefits of representing information as a knowledge graph:

Users can connect similar ideas in multiple overlapping hierarchies, remix them without overwriting the original context, and selectively share parts of the graph with others to collaborate on specific sub-questions.

Imagine documentation that allows your designers and developers to connect, remix, and share parts of your design system. Opening up that knowledge graph to contributions is a whole other world of possibilities on top of simply providing great documentation.

Design system docs take the form they do today because that’s what our current tooling is designed to produce. Creating a custom site with the features and authoring experience of something like Roam, Obsidian, or Notion is no small task, and simply using one of those tools directly will mean you’ll miss out on lots of other custom features that make good documentation great.

Still, there are surely ways we can take these ideas and be inspired by them when designing and building design system documentation in the future. If you have any thoughts on that or have seen any relevant examples, please let me know.