How We Make Trello
March 13th, 2014 by Bobby Grace
Look around you. Is there something nearby that is firmly bolted to the ground? Okay good. Hold onto it. I’m about to pull back the curtains on everything you thought you knew about how Trello was made. The revelation could result in a rippling shockwave that knocks you off your seat and may have troubling, unpredictable consequences for the time-space continuum. Possibly.
To understand how Trello is made, you have to understand a little about how it works. When you go to trello.com in your browser, you are basically running an application–called a client–that talks to the Trello API. The API is a thing that goes to the Trello database and returns with the boards and cards you asked for. You tell the API, “Hello, I’m Bobby. If you don’t mind I would like to see my boards whenever it’s convenient” and in mere milliseconds the API responds with “{user: bobbygrace, boards: ['44321234432', '44321234433']}”. The client takes that and turns it into the beautiful, human-readable information you see on your screen.
You’ve probably downloaded our iOS, Android, Kindle, and/or Windows 8 apps, and are saying to yourself, “These are very well polished apps which I have rated or will rate favorably in their respective app stores. Are they just clients that talk to the Trello API?” Yes. They are just clients. There are clients everywhere. In fact, the Trello API is public and if you know how to speak Trello API, you can make a client, too.
The Trello API is well-written, has no bugs, and is totally rock solid. Or at least it doesn’t change very often. That means we can put out new clients all the time without having to update the API. In fact, we can have multiple versions of the website out at any given time.
“This is pretty interesting and I’m sure it will be relevant later in this post, but I thought this was about how you make Trello.” Okay, okay. I’ll explain our process first and then we’ll come back to this.
Using Trello for Trello
It should come as no surprise that we use Trello to make Trello. We have a board called “Trello Internal” which includes all the stuff related to the API and website that we’re currently working on. Our lists look something like this: “Doing”, “Waiting for test/review”, “Ready for merge”, then a bunch of lists for recent releases, “Incoming Bugs”.
So, let’s say a developer wants to fix a bug. That process goes like this:
- They pick a card from the “Incoming Bugs” list, assign themselves, and move it to the “Doing” list.
- They pound on their keyboards like wild primates until it appears to be fixed. (Maybe this is just me.)
- They create a new branch on their repository, like bobby/oops-no-crash, and push it to Kiln, a top-of-the-line distributed version control and code review system. (Disclaimer: we also make Kiln.) I’m not going to dig too much into how version control works, but basically a branch is a new version based off of a stable, established version that is in production. Everyone who knows how version control works is shrugging and grimacing right now.
- They put the name of the branch in the card description, like “fixed in bobby/oops-no-crash”, and move it to the “Waiting for test/review” list.
- Simultaneously, they get their changes reviewed by another developer in Kiln (which you should buy) and notify our intrepid tester Ali T. who checks out that branch and makes sure it’s really fixed.
- Once it gets four thumbs up, the card is moved to the ”Ready for merge” list.
- Doug Patti, our release manager, merges the changes into the official Build repo, makes the version with the change the new stable version, cuts a release, and pushes it into the wild. We often joke about how using the Kinect would make this step more exciting. Doug could just point in a different directions and say “Deploy! Deploy! Deploy!” Shamefully we haven’t made this a priority.
- The fix is out. Bottles of champagne are popped.
Now another developer can pull from the official Build repository, which includes the fix, and merge it into their working branch. Then their changes can go through the above process and everything is real smooth like a good, old-fashioned saxophone solo. We push out fixes many times a day.
I’m sure everything I have said so far sounds reasonable, but bug fixes are small potatoes, right? What about big, new, dangerous potato features that you might want to test out first? Something like the new card back?
How we make and test big, new, dangerous potato features.
Remember how the Build repository contains the stable, established version of Trello? Well actually, there are many stable, established versions of Trello and you might be running any one of them. What you see is not necessarily what everyone else sees. If the walls of reality just crumbled for you, I apologize. Why would we play you like that?
Well lets say we’ve decided to tackle a bigger problem in Trello. We dutifully researched, designed, and developed a whole new version of Trello and it’s completely code reviewed and tested, a long, carefully calculated process that I’ve squashed into one run-on sentence. This version is probably still a confusing, frustrating mess that is riddled with bugs. Why? Because the design is just an educated guess and it hasn’t been subject to eyes on the street. We don’t really know how it works in the real world (a concept which I have fundamentally shaken for you). We ship it to the team and find what really needs fixing, instead of subjecting everyone to not-quite-there version. So we put it out on the “Alpha” channel.
“THE WHA?”
There are three channels of the Trello website: “Stable”, “Beta”, and “Alpha”. When you go to trello.com, the server figures out which channel you are on and which version you should see. Everyone is on “Stable”, a handful of folks, maybe 20, have access to the “Beta” channel, and Trello team members and Fog Creekers are on “Alpha”. If you have access to more than one channel, you get a coveted channel switcher.
So while fixes are continuously being pushed out to the stable channel, our big potato versions like the new card back or the new boards page go out to alpha channel and are used by the team with real data. When it hits alpha, the gloves come off. Then there is heated debate. And anger. Glory. Joy. Frustration. Hope. And iteration. Lots of iteration. If only you saw some of the junk that hit the alpha channel… shoot.
Oh and if there are API changes associated with the new client, they are released separately and before the new client hits the alpha channel.
We iterate and refine until it’s ready for the beta channel. The beta version has a prominent “Give us feedback” button and disclaimer saying this is an early “explorer” versions of Trello and says “look out for these new things”. Then we get feedback, iterate, refine… When we’re almost happy, we slowly roll it out to a small, randomly-selected percentage of people on the stable channel. That usually starts at 1% goes up to 15% over a few days. Then we get plenty of feedback. We look for the big things that come up frequently, then iterate and iterate some more.
Now things are great and it goes out to 100% of stable. We draft up a blog post with the biggest, coolest new features, announce it, and then boom a bottle of champagne is popped. We are popping bottles of champagne constantly and if you ask me I think it should stop because it’s getting expensive and champagne gives me the worst hangovers.
Design and Research
I would like to elaborate on the design and research phase since I glossed over it earlier. We use a product planning board that has a list of problem-oriented cards. Cards are titled in the vein of “I can‘t find this feature” or “I want to do this thing but can’t”. These problems come from a few places:
- Common cases seen in support emails sent in via FogBugz, a world-class bug tracker. (Disclaimer: we also make FogBugz and we think you should buy it.)
- Frustrations of team members.
- One-on-one sessions with Trello users conducted by Ben, our customer happiness maker. I don’t know what Ben’s title is.
We use all this feedback as research. We also do numerous internal polls and hallway usability tests. We also look at anonymous usage tracking in Google Analytics to see what features people are actually using. In all, we hope to get a sense of how people are currently using Trello, how they might want something to work, what they aren’t using, and where their pain points are.
On the back of each card, we take this info into account and propose a few solutions. When we settle on a card that really needs fixin’, I’ll take the card, make a few pen and paper sketches based off the proposed solutions, and create a few low-fi mockups and workflows in Sketch. (Disclaimer: we do not make Sketch, but you should buy it.) I try and post workflows and screenshots to the associated Trello card throughout the process so I can get continuous feedback from the team. I know the design is going to change a lot so I don’t waste time with high-fidelity mockups. We can quickly iterate in code anyway. Here’s an example of the new card back mockup. It has notes to point out the important new things. This one is more high-fidelity than others because it covers some visual design aspects.
The next step before developing a prototype is establishing a project codename. This is very important and happens to be lots of fun. The new boards page was codenamed “Borderlands” because it concerned everything outside the main board view. The new card back was codenamed “Jelly Donut” because it was even tastier on the inside (of cards). When we added the ability to have multiple clients, we named it “Hydra” after the mythical multi-headed beast. We’re working on some new search stuff. It’s codenamed “Hayride” which I think is a reference to finding a needle in a haystack? The iOS team has project codenames, too. When they were working on scrolling performance, they codenamed it “Hobbit” after the major motion picture featuring a smooth, lifelike high frame rate. Codenames are important as a point of reference. It’s also what we name our branches. bobby/borderlands is much better than bobby/new-boards-page-starred-boards-other-stuff-too.
Now that it is all codenamed and prototyped up, we ship it off to alpha and start the iteration process. Rollout. Launch. Champagne. Saxophones.
I hope this was informative. Maybe there was something you can take home with you. Our release process and workflow has come a long way, mostly due to the work of Doug and the ability to have multiple clients in production. Maybe Doug will write something more technical about that. Also I should say that the iOS and Android teams have different workflows that are interesting in their own right but not covered here. Ian says the iOS build process is “cmd + B”, but I’m like, come on, you know that’s not what I’m talking about.
That’s all. Please yell at me on Twitter.