Digital Bricolage & Web Foraging

When I reflect on the various lines of inquiry that light me up, there’s one consistent theme: digital bricolage. Bricolage is “the skill of using whatever is at hand and recombining them to create something new.”

This is truly a core guiding methodology to how I approach the web: as a composable, iterable, resilient thing. Something that invites creation, play and generative exploration.

CJ Eller found this lovely quote¹ -

While hierarchy and abstraction are valued by the structured programmers' "planner's" aesthetic, bricoleur programmers, like Levi-Strauss's bricoleur scientists, prefer negotiation and rearrangement of their materials. The bricoleur resembles the painter who stands back between brushstrokes, looks at the canvas, and only after this contemplation, decides what to do next. Bricoleurs use a mastery of associations and interactions. For planners, mistakes are missteps; bricoleurs use a navigation of midcourse corrections. For planners, a program is an instrument for premeditated control; bricoleurs have goals but set out to realize them in the spirit of a collaborative venture with the machine. For planners, getting a program to work is like "saying one's piece"; for bricoleurs, it is more like a conversation than a monologue.

This idea of digital bricolage pairs well with the idea of “web foraging” - a term I found in this great paper. When you ask programmers to code something they spend a lot of their time on the web:

“Good grief, I don’t even remember the syntax for forms!” Less than a minute later, this participant in our Web programming lab study had found an example of an HTML form online, successfully integrated it into her own code, adapted it for her needs, and moved onto a new task. As she continued to work, she frequently interleaved foraging for information on the Web, learning from that information, and authoring code.

Over the course of two hours, she used the Web 27 times, accounting for 28% of the total time she spent building her application. This participant’s behavior is illustrative of programmers’ increasing use of the Web as a problem-solving tool. How and why do people leverage online resources while programming?

I’m not a coder. Truly. But I can get my hands dirty and dabble - whether it’s bookmarklets, Chrome Extensions, Yahoo Pipes (rip), APIs or importxml() in Google Sheets.

As part of my consulting work this week I built a prototype for a client. It’s a bookmarklet - no database, no “website”. It’s so light as to be almost ephemeral. And yet. It’s like a little piece of extended cognition.

This bookmarklet is like x-ray vision. You fire it up on the client’s website and it opens up a bunch of analysis showing things that this client cares about on the page. It’s designed for anyone inside the organization to be able to look at a page in a new way. A kind of new way of seeing the same thing.

I’ve been coding bookmarklets for… at least 12 years now?

When I look back at my work with the web I’ve always been remixing, hacking and tinkering with the web. Trying to ask questions like what does the web feel like? How do you treat the web as a texture? What can you do with the web?

But formal coding - and running my own servers and infrastructure - has never interested me. I’ve always been more interested in a light touch experience. The web as light as gossamer. Digital bricolage and web foraging. These are little ideas that somehow underpin my entire professional career as as non-coder.

Geoffry Litt has a similar rallying cry for chrome extensions:

Most importantly, I’ll argue that making an extension is a fun and efficient way to create useful software, especially when you can only invest limited time and effort. Instead of starting from a blank slate, you can start by tailoring some piece of existing software to better serve your own needs, and then share your work with other people facing similar problems. No need to brainstorm weird startup ideas or hunt for markets—just find limitations in the software you already use, and patch them yourself.

Beyond these benefits for the developer, extensions can be awesome for end-users too. Instead of needing to switch to a different app, users can smoothly integrate new functionality into their existing experience. Extensions can also support niche use cases that would never be prioritized by the original developer.

As I catalog my projects and my interests - questing to understand what lights me up - I think that digital bricolage is a key component. Being able to

And as an indie consultant - there’s a kind of “new consultant’s toolkit” that enables this. Figma and Replit are my two faves, they enable a kind of “what if” work that’s shareable, easy to hack on and requires no formal skills or infrastructure. I think for others tools like Observable or Datasette might function in the same way.

Robin Sloan is a big fan of cloud functions:

I wrote about my experience with Google Cloud Functions back in the spring; for me, these represent the “perfection” of the AWS/GCP model. Their utility snuck up on me! At this point, I have about a dozen cloud functions running — or, I guess it’s more accurate to say, waiting to run. My little platoon of terra cotta warriors, dozing in their data centers until called upon.

I need to play around here. Cloudflare workers, cloud functions and Github Actions all feel like Google Appscript but better maybe?

–

Anyway. There’s no real point here. But isn’t the web amazing?