I built a prototype of a 2D canvas you can put all of your work on: real terminals, running apps and browsers side by side instead of a row of tabs. We, at FlutterFlow, got so obsessed with using it that we built a full product out of it, Campus. It's free and available for macOS now. Next comes the story of how we got here …

The age of context switching

Just a few years ago, development was organized in a pretty straightforward way. Plan the work in more or less detail, then work on those features for the next week or two, rinse and repeat. With the advent of agentic coding, that has completely changed. Planning or discussing certain types of work has itself become slower than just letting the agent do the work.

This is causing a massive shift in how I and tons of people I know work. Instead of focusing on a single task for a prolonged period of time, parallel work is the new norm.

My attention, then vs. now. Guess which week is more tiring.

None of us would want to go back, but it came at a steep cost: context switching.

One consensus among me and my group of friends is that software engineering has become more tiring. Quite ironic, as we’re essentially doing less of the actual work. I think context switching plays a big part in that.

Why I put agents into Minecraft

For the past year or so I’ve been obsessed with exploring different ways of putting “work” into better context. I strongly believe the future of work is moving towards a more holistic way of working. I hope the future is better than switching between Jira, Slack, VSC and GitHub.

One of my earlier experiments was putting agents into Minecraft. Why Minecraft, you might ask? And you might be forgiven for doubting the holy grail of IDEs that is Minecraft. But I actually think Minecraft is a pretty interesting way of prototyping ideas in 3D. It’s well known, has a very good modding community and, most importantly, has all the basics already implemented for you. No need to re-invent any 3D, networking or general interactions.

Wow, Opus 4.6, times really have advanced soooo quickly.

I didn’t take this too far, but the idea of having your work in a “physical” space while also maintaining some kind of human connection in this increasingly isolated world was intriguing to me.

Fast forward a couple of months and I start a new job at FlutterFlow. Having done my fair share of experiments around interesting concepts of future work, I threw together a new prototype of work in 3D, this time in Three.js so others wouldn’t have to buy Minecraft to try it.

This was interesting! I actually spent a full afternoon working within this environment and it was … dizzy? I found that I was getting dizzy after some time. Flying and looking around in 3D, especially with all of the context switching, was extra confusing for my brain. I showed this prototype to a few colleagues, and Abel (one of our founders) was intrigued, but noted that this would be more interesting in 2D.

The next day I whipped up another prototype, this time using Flutter and in 2D. And it caught on. Within a couple of days we had something that actually worked for us.

Our messy early collaborative workspace

Project “work_canvas”

Work Canvas, later Campus, wasn’t something we planned or wanted to do at that point, but that initial prototype I shared across our team spread like wildfire. We found ourselves preferring to work in this very early prototype of a 2D spatial work canvas over the tab-switching workflow we had before.

Here’s a tour of what it grew into:

In short, Campus is a collaborative infinite canvas that you can actually work on. It supports a bunch of different tile types out of the box (terminals, web browsers, assets, etc.) and we’re currently working on an extensive plugin system. The overall goal is to build a sandbox made for work.

One idea that stuck around in my head ever since the Minecraft prototype was multiplayer. My most cherished memories playing Minecraft when I was younger were of playing with friends. It just feels right being able to create a space, personalize it and share it with your friends.

Getting back to context switches: the philosophy of Campus is having everything in context. Basically, it’s putting related things close to each other, grouping by what you’re working on instead of by what kind of thing it is. It’s the same instinct as structuring code by feature rather than dumping every model in one folder and every controller in another. This means you have the agent that is creating the work, the artifact (such as the compiled and running app) and any additional resources (tickets, issues, inspiration) in close proximity. Context switching can’t be eliminated entirely, but picking a piece of work back up stopped feeling like a chore. I’m not going to pretend I measured any of this. We just like working this way, and none of us have wanted to go back.

But isn’t this just Miro?

Fair question, and it’s the first one I get. Infinite canvases aren’t new. Miro, FigJam and Obsidian Canvas have been around for years and they’re good at what they do.

The difference is what a tile actually is. On a whiteboard, a tile is a picture of something: a screenshot, a sticky note, a link pointing at the real thing somewhere else. In Campus the tile is the real thing. That terminal on the canvas is a terminal running on my machine, in my repo, with my agent working in it. The app next to it is the actual build, actually running. You don’t paste your work into Campus, you put your work in Campus.

Tiling window managers get that part right too. What they don’t give you is a space bigger than your monitor, one you can zoom out of, move around in and actually remember.

Spatial memory

My workspaces in Campus can be quite messy.

But interestingly, it’s not messy for me.

There is this concept of a “memory palace”. It’s essentially an imaginary 3D space that you build up in your head, and you associate different ideas and things with an actual location in that space.

In the screenshot above, I can tell you right away which tile and terminal is working on what, just by their position and size. Compare that to a tabbed experience, where I was always lost and had to click my way around to understand who is working on what.

I'm one of those people with too many browser tabs open (whenever it becomes too messy I just create another group and shove all the old tabs in there …)

Campus with colleagues and friends

What I find even more fascinating about this process of creating a virtual space is doing it with others. Having a deeply rooted shared understanding of the space should make collaboration more seamless, in theory. Campus is built on the premise that everything in Campus can be shared with others.

Campus has a pretty interesting networking architecture. Everything is (opt-in) multiplayer: every tile you see and every interaction you take can be shared across people. Traditionally you would have one server which does the work, and peers just see the output of that work and send commands. Here, the work happens on each user’s personal computer. Streaming data is opt-in (work is local first, sharing with colleagues is an explicit action).

Media, such as wallpapers and binary data, is another aspect. We identify each asset by hash, and stuff on the canvas references those hashes. If a peer is missing an asset, it requests it from the asset owner, still routed through the fanout server rather than peer to peer, so nobody in the room ends up connecting straight to anybody else. Once the asset is cached, it doesn’t need to be re-downloaded when re-joining. This works pretty well for small teams and light asset usage, but obviously doesn’t scale that well with many people in a room (you don’t want to DDoS yourself by having hundreds of people requesting assets!).

One core philosophy though: we don’t want a central managed server being a bottleneck, whether for scaling, development complexity or security. One thing I would like to get to soon is letting users configure a custom NAS or similar which can act as a host for assets.

While the current implementation is not truly peer-to-peer (there is a very thin fanout server in the middle), the architecture itself is peer-to-peer. The initial “server” we deployed just kept running through soooo many client versions before we had a reason to touch it again!

Additionally, I was recently looking into Iroh for making this a truly p2p experience. That’s going to be a separate blog post if we do end up shipping it!

There is a shared space on the canvas. It’s opt-in, and people can gather there and bring their work along if they feel like it.

One feature I didn’t expect to catch on was local chat.

At any point in time you can just start typing a message (prefixed with /) and it appears next to your cursor. When you’re in a room with peers, others see those messages as they are being typed. Once you’re done, the message fades away after a bit.

On paper this sounds like a bad chat experience. Others can see all your typing mistakes; messages disappear, so if somebody is afk or doesn’t read it in time it’s gone; and you have to hold your cursor still if you want anybody to have a chance to actually read it.

Despite all of these shortcomings, we noticed that exactly these properties lead to so many more “micro interactions”. The kind of chat you’d have in front of the water cooler. These messages were typically low pressure, sometimes fun and filled with gifs, sometimes just situational about some shared work happening in the background.

Sometimes it’s not about the technically best implementation or system. Sometimes it can just be about what’s most human. Do we expect critical business decisions to be made in a disappearing chat? No. Are we definitely keeping this feature because it facilitates something that’s hard in a remote team? Absolutely!

What’s next

Campus is free and you can try it at campus.flutterflow.io. The core is going to stay free. It’s the only way a tool you’re supposed to live in all day actually works.

There are a bunch of interesting bigger features being worked on for Campus right now, each of which deserves its own post once it’s ready. Just to name a few initiatives:

Extensions

One of the reasons I think Campus captivated us so much was working on Campus itself and having it shared with the team within minutes. Especially now, with agents, customization and making things work for you and your team have gotten so much cheaper and more fun. I’m working on a bigger extension system right now which is going to be WASM-based and essentially able to do anything to Campus that we would be able to do (while remaining secure, fast and reliable). This will definitely deserve its own blog post when ready!

Mobile

We have an early alpha of the Campus mobile app in TestFlight right now. It features the same canvas view as desktop for orientation, but has specialized UI for each tile kind to optimize for the mobile display. The iPad version is where I see this becoming incredibly useful: working remotely with just an iPad while having all the tools available on a Mac.

Web

Campus is built with Flutter, and Flutter runs anywhere, so the web is a natural next step!

3D

Brandon DeRosier has been doing some incredible work on adding advanced 3D capabilities to Flutter. While this definitely falls more into the fun category, a true sandbox experience needs to provide these capabilities.

We’re a remote-first company, and whenever we meet up we love playing board games as a team, something which is completely lost when we’re remote. My personal hope is that we might bring some of that culture back through Campus (Seven Wonders 👀).

Campus is free and available for macOS at campus.flutterflow.io. If there is anything you’re missing or something breaks, you can submit feedback right from within Campus, or reach out to me on X.