Function Follows Form?
It's been a while since the inaugural installment of this newsletter! Extrapolating from all the available data points, it appears these will be sent out every 3 months or so.
First, a couple quick updates:
Metamuse podcast: I was recently a guest on the Metamuse podcast (one of my favorites to listen to!). We had a wide-ranging conversation about Bring Your Own Client, data interoperability on the web, making software that invites customization, and more. If you're interested, you can listen here.
It was my first time being on a podcast and I enjoyed the medium a lot. As a listener I had always seen podcasts as just "a recorded conversation," but being on the other side made me realize how much preparation and editing can go into producing something that sounds that way. Improvisational jazz seems like a good analogy—there's a delightful spontaneity to the conversational format, but great results are far from automatic.
Summer research: I've been spending my summer (remotely) at Ink & Switch, the research lab where I worked on Cambria last summer. This time around I'm working on rich text editing, together with Slim and a few other collaborators. We have some ideas about how collaborative rich text editors (like Google Docs) could better support the way people actually want to work together, and how CRDTs like Automerge could help enable those use cases. Not much to share widely yet, but get in touch if you have thoughts on that topic!
Function follows form?
So here's a question I've been thinking about lately: What defines a piece of software?
Like, if someone asked you "What is PowerPoint?" What would you say to them?
One way to answer is by describing the kinds of tasks the software helps you perform. You could say, "PowerPoint helps you make slide shows for presentations."
Another way to answer would be to describe more literally the capabilities the software provides. You could say, "It gives you a series of landscape boxes that you can put text and shapes into."
These are both reasonable descriptions, but they lead to very different ways of thinking about the tool. In the task-focused mindset, you sort of trust a designer to do a good job empathizing with your specific use case. You think to yourself, "I'm making a slideshow, this software is built for making slideshows, I hope it will have the features I need."
In the capability-focused mindset, you're constructing your own mapping from features to goals. You need to make a poster for an event, or make some UI mockups maybe, and you think to yourself, "Huh, I guess I already know how to use PowerPoint, and it will let me draw shapes and output PDFs and everything I need to perform this task."
Joel Spolsky, who worked on Excel for a while, notes that many people actually treat Office software in the second way:
The great horizontal killer applications are actually just fancy data structures.
Spreadsheets are not just tools for doing “what-if” analysis. They provide a specific data structure: a table. Most Excel users never enter a formula. They use Excel when they need a table. The gridlines are the most important feature of Excel, not recalc.
Word processors are not just tools for writing books, reports, and letters. They provide a specific data structure: lines of text which automatically wrap and split into pages.
PowerPoint is not just a tool for making boring meetings. It provides a specific data structure: an array of full-screen images.
This pattern of "software as data structure" pops up in other places. In realtime collaborative software like Google Docs and Figma, people often find ways to take advantage of the shared "space" metaphor beyond the explicit purpose of the tool—it's common to write "hey I'm editing this section" into the body of a Google Doc. Some tools like Notion and Airtable go further and explicitly present themselves as "horizontal"--more a material with endless potential than a tool for a particular use case.
To me, this pattern gestures towards using computers as a flexible medium rather than a narrowly focused tool. I'm obviously not saying PowerPoint is the culmination of the vision of personal computing, but I am saying, it's neat that people find ways to use software in new ways, and I wonder: how can we encourage more of this kind of thing?
The mapping problem
An important sub-problem is: how can we support people in mapping tool capabilities to end goals? That's a critical step in unleashing the power of horizontal tools: you need to be able to find an appropriate general toolkit, and feel confident that it'll get the job done, even if your use case isn't listed on the marketing page.
For example, would you use PowerPoint to make a poster? A website mockup? An animated figure for an explorable explanation? See, you're doing mappings in your head there, thinking about what PowerPoint is capable of and what you'll need for that particular task.
By the way, this process isn't necessarily easy! It's arguably a big part of what salespeople, designers, and product managers do—think through the needs of a problem, and find ways to solve the problem with a given toolkit. But I also think this is a skill that anyone can become competent at with a bit of practice.
One simple but effective pattern here is "templates": seeing concrete examples of what other people have done. This helps to get inspired and roughly understand the possibilities. Platforms like Notion and Airtable clearly put a ton of effort into templates for this reason. The problem is, templates are just points in a space; if your use case isn't that close to existing templates, you might not get a satisfying answer.
Another approach is just directly interrogating what the tool can do. It's not obvious how to do this, though—how do you concisely describe what a system can do, in a way that's abstract enough to apply to many scenarios? Part of the challenge here is that you need to know the right questions to ask. Someone with experience building software might ask questions like "Does Airtable support many-to-many relationships" or "Can I store more than 100,000 rows of data", but recognizing these "requirements" is an art of its own.
One approach I find promising here is the work my advisor Daniel Jackson has been doing for a while on describing "concepts" in software designs. (Here's an essay he wrote about this a while ago; there's a book coming soon with much more depth.) The rough idea is to identify the independent key ideas underpinning a piece of software, and to clearly describe both their purpose and how they behave. Maybe it would be neat if all applications came with an inventory of their key concepts, to help people understand how to repurpose them.
Ultimately in our messy world you can't answer perfectly upfront whether a tool will be good for a particular job, so it helps a lot to have some flexibility both in the tool and the requirements. For example, last year I worked on a project helping local governments in California organize meal deliveries during Covid. We deployed a solution extremely rapidly with Airtable and it worked out pretty nicely. There were two key points of flexibility: 1) Airtable has a Javascript scripting layer that we could use to bolt on advanced features; 2) our client was flexible enough that they could somewhat mold their requirements to the tool. (This second part is crucial—if you've ever tried to replace an existing system, you've probably heard the dreaded "but can it do X super specific tiny little feature that Y system did?" requests...)
Embracing structural design
The thing is, "How would you describe PowerPoint?" isn't just a question for a user observing a finished product. It's also a question for software designers. In your design process, do you choose to emphasize use cases, or structural form?
My favorite take on this question comes from Andrea DiSessa's excellent book, Changing Minds. (I talk about this story way too often, but it's just that good!) If you can zoom in on this image, it's worth just reading this whole two pages:
To summarize, DiSessa describes a "nightmare bicycle" where the gears are labeled not with numbers, but with icons describing the best situation for each gear: smooth uphill, smooth downhill, gravel, crossing railroad tracks....
This designer did a good job following the rule "make form follow function" by empathizing with the user and thinking about specific use cases first. Rather than label gears with cryptic numbers, they put friendly names on the gears that normal people can understand.
And yet... as anyone who's ridden a bike can see, something is deeply wrong with this design. How do you find the right gear for a situation not listed, like going downhill in gravel? How do you quickly find any of the gears, for that matter, since they seem to be listed in a some kind of random order? "There is no sense of systematicity or completeness in the mechanism."
I think DiSessa's story perfectly illustrates the dangers of excessively applying a certain design philosophy. Yes, it's good to think about specific problems that real people have; agile incremental development can work well; premature abstraction can be a trap. But taken too far, this design process infantilizes the user, assuming they have zero capacity to understand the structure of a system and map it to a unique situation. People are smart! They can learn to use bicycle gears, they can learn many things!
If all we do is check off individual user stories one by one, it seems like we too often end up with a nightmare bicycle: chock full of specific uses, but deprived of any coherent structure. We should aim for structure that people can grasp and reuse. Computers as medium, not appliance.
Reading these days
- Orality and Literacy by Walter Ong: It seems obvious that literate cultures think differently than oral cultures, but I'm shocked by how deep the differences go.
- This Is How They Tell Me the World Ends, by Nicole Perlroth: Thrilling and terrifying tales of modern cyberwarfare. Didn't realize how much things had escalated over the past couple decades.
- Exhalation by Ted Chiang: the best kind of thought-provoking sci-fi.