Archive for the ‘Trello’ Category

Trello Server Team on NodeUp Podcast

November 12th, 2013 by Brett Kiefer

The Trello server team appears on this week’s NodeUp podcast, talking about the Trello tech stack in production.

Taco Headphones

 

How to Share Your Trello Board, But Not Your Secrets

March 7th, 2013 by Rich Armstrong

We really liked seeing this post on how WooThemes uses Trello. We love it when people show their Trello boards. However, the screenshot has the text on the cards blurred out individually. That seems like a huge hassle. There had to be a better way to share screenshots without giving away the particulars of their board.

So we poked around on the internet and found this technique for blurring text with CSS. (Neat!) We tailored it for Trello and created a bookmarklet that we call “Blur My Board”.

Check out the bookmarklet here!

Need an example? Here’s an unaltered screen shot of the Trello dev board:

unblurred

Click the “Blur My Board” bookmarklet and here’s what it looks like afterward:

blurred

Now snap a screenshot. Refresh the page and everything goes back to normal.

If only there were some aphorism we could use that would capture the concept that images convey more information than text. Oh well, we hope you enjoy the bookmarklet at least.

If you want to show us your board, get your bookmarklet here, and after you’ve blurred it, put it online somewhere and tweet us about it @trello!

Dogfooding Until It Hurts

February 26th, 2013 by Rich Armstrong

Dogfooding. Also called “eating your own dog food.” It’s pretty simple, right? If you work at Uber, maybe take an Uber car ride from time to time. If you work at Khan Academy, you’re probably pretty good at math by now.

In this video from 2009, Joel talks about dogfooding as being more than just using your own product. It’s about using your own product for everything you can imagine, even if that usage is a little uncomfortable.

We dogfood Trello, FogBugz, and Kiln in a ton of different ways.

We’re a software company, so we generate a lot of code. Kiln helps with that. But we even use it to hold things that aren’t “code” per se, such as backups of non-sensitive databases. We don’t have any real crazy use cases, like using code reviews to plan parties or the electric DAG to create subway maps, but that’s just because Kiln has only been around a few years.

FogBugz, on the other hand, we use for tons of off-label stuff. We use FogBugz’s crash reporting ability to read RSS and Twitter feeds and create cases when new items appear. We use its customer email capabilities to receive faxes. And we have a panoply of API scripts automating a bunch of different business processes.

Trello is a natural for dogfooding, of course, because it’s so flexible. We keep kitchen snack requests and lunch menus on boards. We keep track of who’s going to what conferences, and use it to plan their travel. Trello really shines in setting the agenda for and running our bi-weekly company all-hands meeting. Because Trello is so flexible, it invites a lot of different use cases. We’re still figuring out which ones really work, and it’s great to see a fast-growing user base figuring that out alongside us.

So, that’s all well and good, but if you really want to see “dogfooding until it hurts” in action, check out Beeminder, a tool for setting “goals with a sting.” You set up your goals, and if you stray from them, the service fines you an escalating amount of real money until you’re back on track. Beeminder is dogfooding heavily and publicly to keep their development goals on track. These folks are  literally giving away cold hard cash to users as a pre-commitment to do things like delivering user-visible enhancements or blog posts on a regular basis. Amazing. Even better, they have a Trello integration that’ll keep you moving those cards to the Done column regularly (or else).

 

Trello uses an icon font and so can you!

January 31st, 2013 by Bobby Grace

Inspired by Github’s Octicons and a desire to clean up our kludgy icon code, I set out to convert trello.com to use an icon font.

Previously, we used an image sprite method. We used a single 750×145 pixel image that contained 6 versions of each icon (two sizes and three states). We offset each icon with CSS background-image and background-position. We also loaded a sprite at double the resolution and served it to higher DPI devices via media queries.

The sprite image looked like this:

Spriting is a popular and battle-tested method. So why switch? Icon fonts are a new, modern way to implement icons. They have tons of benefits, such as…

  • They are scalable and resolution-independent. There’s no need to cut a huge 2x size image for Retina displays. Notice how fonts automatically look nice on a Retina display without any media queries or additional CSS? An icon font will, too. It also scales properly for different zoom levels on the desktop, unlike our sprite method.
  • Icon fonts are smaller. Way smaller. We compile our entire CSS into a single file, which includes the embedded sprite image. We cut down that file from 118kb gzipped to 70kb gzipped, with the font embedded. The CSS is also cleaner and much easier to use.
  • You can use regular old CSS to alter color, adjust size, and add effects like shadows and gradients and whatnot. You no longer need to cut another image for hover states or different sizes.
  • They’re easily extendable since you can use one of the thousands of open unicode code points. You don’t need to shuffle much CSS either.
  • You can do stuff like thiisssss.

I was convinced, so I set out to do the conversion. I found all kinds of interesting posts, but none of them put it all together, so I decided to create a guide. Here’s how to design and implement an icon font for your own site.

The Tools

  • Glyphs. Glyphs is a font editor for Mac. It’s the nicest app for editing vectors I’ve ever used. If you’re just creating icon fonts, you can probably just use Glyphs Mini, but those developers deserve every cent for this excellent software.
  • Adobe Illustrator. We created our icons in Illustrator, so copying into Glyphs was a breeze. You may get along just fine with only Glyphs if you’re starting anew.
  • FontSquirrel @font-face Generator. we’ll use Font Squirrel to convert our font file into various formats.

Importing Glyphs into Glyphs

You can copy and paste Illustrator paths directly into Glyphs. There are a few pitfalls you’ll want to avoid, though. Glyphs default x-height is 500 points which translates to 500px if you’ve got Glyphs set to the default grid spacing of 1 (“File” > “Font Info” > “Other Settings”). Make sure your Illustrator object is about as tall as your x height, otherwise it may be a little hard to scale when it gets into Glyphs. Also be sure to use a solid fill in Illustrator. Using a gradient fill creates some funky points and curves. Other than that, just copy your paths and paste.

More on importing from Illustrator on the Glyphs blog.

Naming Glyphs

Underneath the surface, every glyph in a font has a unique Unicode code point. For example the capital letter “A” is 0041 in Unicode. You could map your glyphs to everyday characters like “c” (0063) or “m” (006D) so that your icons will appear when you use those characters in HTML, but Unicode has something specifically for custom extensions like ours. It’s called the Private Use Area, or PUA. The PUA is the 6,400 unassigned code points (E000 through F8FF) that are meant to be used by third parties so they don’t conflict with the standard Unicode assignments. Our glyphs are like no other glyphs, so it makes sense to use this range.

As an example, Apple uses the PUA to show the the Apple logo character  (F8FF). Neat.

To assign code points in Glyphs, click the top field in the bottom left pane, then name your glyph starting with “uni” then the code point you want to use. “uniE000″ or “uniF010″, for example. You’ll know you did it correctly when see the Unicode field at the bottom of the view change. The glyph will also go into the “Private Use” section instead of “Other”. After the unicode point is set, you might be inclined to change the name to something more human readable like “search” or “info”. Resist this urge. Changing the name from the uniXXXX format might mess up the names on export.

More on glyph names on the Glyphs blog.

For more on Unicode, read “The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)” on Joel on Software.

Hinting Hints

Our sprite image looked nice and crisp because every pixel was predefined and rasterized. All browsers, for the most, render images in the same way. Fonts are different. The browser is converting paths, points, and lines to pixels. A lot can get lost in the translation. Your font will be subject to various font rendering engines, some which will finesse smooth curves and some of which will churn out jagged edges.

Hinting is the practice of adjusting your vector paths so that they line up nicely when rendered on a rasterized pixel grid. It’s what you do to make sure your icons look sharp and crisp. You’ll spend a lot of time hinting your font, and it will take a lot of testing, tweaking, and eyeballing. Here are some helpful guidelines for you to get started, though.

Trello uses two icon sizes, one at 12 pixels and one at 20 pixels. Sticking to a roughly 60 pixel grid means the output will look sharp when it’s rendered at either size. You’ll want to set the width of your glyphs to 1920, a nice, round multiple of 60 pixels. Notice how the height, width, and positioning are all multiples of 60 in the screenshot below?

We also set the units per em to 1920. The what per what? An em is a unit of measure that, basically, describes how wide it is. The units per em is a measure of how much information gets packed into a character. Higher units per em will deliver more precise fonts, but require more processing. Click here to read Microsoft’s guidelines on type hinting and production. To change the units per em in Glyphs, open “Font Info…” (the “i” button in the top right corner), select the “Font” subsection and set your “units per Em” to 1920.

Your smaller icons may need dedicated glyphs that are specially hinted to do them justice. That’s up to you. You can also use different sizes, of course. The math works out more elegantly with 16 and 32 pixel sizes, for example. Set your “units per Em” to “2048″ (or 2^11) if you go that route.

In the end, our font looked like this:

Now that you’ve decided on your sizes and hinted the heck out of your glyphs, your font is complete! Go to “File” > “Export” (or cmd-E), confirm, and you’ll have an OpenType (OTF) file waiting for you.

Converting into Multiple Formats

Browsers are picky, so we need lots of different formats to satisfy them all. Luckily there’s a tool out there that will convert OpenType files into all those formats for us. It’s called the FontSquirrel @font-face generator.

There are a few things you need to do here. First, add the font, then select the “Expert…” option below. (We are experts.) For formats, select TrueType, WOFF, EOT Compressed (if you need support for IE8 and below), and SVG. You can deselect everything in the “Fix Missing Glyphs” section. We won’t be using those.

By default, FontSquirrel won’t load glyphs in the Private Use Area. Since our font is entirely in that range, we want to make sure it’s included. To do so, select “Custom Subsetting…” in the Subsetting section. In “Unicode Ranges”, enter “E000-F8FF”. (That’s the PUA range, remember?) At this point, FontSquirrel will render a preview of all 6,400 characters in this range in the browser. This is kind of slow and you might assume your browser is broken, but it probably isn’t. Don’t be afraid. You’re an expert!

Did it work? Okay, good. You can also remove “-webfont” from the “Font Name Suffix”, unless you want your files to look like mycooliconfont-regular-webfont. You should reconsider the name My Cool Icon Font, too, actually. Next, set the “Em Square Value” to “1920″, or whatever you had your “units per Em” set to (see the Hinting Hints section above). Now click “Download Your Kit” and you’ll get a .zip file containing all the formats we need. This can also take a few seconds since FontSquirrel is basically performing a miracle for us.

Want to automate this conversion business? Check out fontforge. I can’t tell you if this actually works because I never tried, but I think it’s possible. Go figure it out.

Loading Your Font

Now that you’ve got your font in all the requisite formats, you’ll need to load them via CSS. We’ll use @font-face for that. If this sounds new or scary, it’s neither. @font-face has been around since IE4 and is supported in nearly every browser. Not all browsers support every font format, but we’ll get to that in a second. The code for loading fonts looks like this:

@font-face {
    font-family: 'Trellicons';
    src:
        url('/static/fonts/myfont-webfont.eot?#iefix') format('embedded-opentype') 
            /* This is a hack for Internet Explorer 8 and 
               below (oldIE), which can't handle multiple
               src declarations. See this Stack Overflow answer for more. 
               Also, you can delete this EOT line if you 
               don't need support for oldIE. */
        url('/static/fonts/trellicons-regular.woff') format('woff'),
        url('/static/fonts/trellicons-regular.ttf') format('truetype'),
        url('/static/fonts/trellicons-regular.svg#trelliconsregular') format('svg');
    font-weight: normal;
    font-style: normal;
}

Old Internet Explorer will load the embedded OpenType file (EOT) file, and most other browsers will use the WOFF file. WOFF, or Web Open Font Format, files are basically wrapped OpenType (OTF) and TrueType (TTF) files with the additional benefit of compression and extra metadata. The Android browser and older versions of iOS will use TTF, and SVG will cover any other cases.

A note about SVG. While my Mac was nicely rendering the WOFF font, I discovered Windows was not rendering so nicely. This was particularly true of Chrome on Windows, which uses its own font rendering engine. After reading this helpful Font Spring article I switched to SVG fonts, only to find that SVG fonts are not supported in Firefox or IE9+. So then I spent quite a bit of time hinting the font. Then I spent a lot more time hinting the font. It was a lot of work, but good hinting goes a long way. The icons look sharper across all browser and operating systems.

After all that, we ended up using WOFF for most browsers for a few couple reasons. First, the file was two and half times smaller than the SVG file (7kb compared to 18kb). Secondly, line height on SVG fonts behaves differently across browsers, which means the icons looked either too high or too low depending on the browser. We did end up using SVG for Chrome on Windows, since SVG fonts do not go through the default font rendering engine. They simply look the best. We load the font conditionally by adding CSS classes for the browser and operating system to the body element of the HTML via some JavaScript and User Agent sniffing. (Note: this is bad and you shouldn’t do it.) This also allows us to fix the line height fix conditionally. The code looks like this:

@font-face {
    font-family: 'Trellicons Regular SVG';
    src: url("/static/fonts/trellicons-regular.svg") format("svg");
    font-weight: normal;
    font-style: normal;
}
.windows.chrome .icon-lg,
.windows.chrome .icon-sm {
    font-family: "Trellicons Regular SVG";
}
.windows.chrome .icon-lg {
    line-height: 34px;
}
.windows.chrome .icon-sm {
    line-height: 20px;
}

For more on @font-face and loading fonts, check out Paul Irish’s “Bulletproof @font-face syntax” and Font Spring’s “The New Bulletproof @Font-Face Syntax”.

Building Reusable CSS

Now that we’ve got our font loaded, we need to write some more CSS in order to use it. First, we’ll set up our two different sizes.

.icon-lg, 
.icon-sm {
    color: #b3b3b3; 
    display: inline-block; 
    font-family: "Trellicons"; 
    -webkit-font-smoothing: antialiased; 
        /* For more detail on this property, see Tim Van Damme's blog post. */
    font-style: normal;
    font-weight: normal;
    line-height: 1;
}
.icon-sm {
    height: 18px;
    font-size: 12px;
    line-height: 18px;
    width: 18px;
}
.icon-lg {
    height: 30px;
    font-size: 20px;
    line-height: 30px;
    width: 30px;
}

Now we need to go through and map the Unicode characters to CSS classes. In our font, the icon for organization is known as “F000″, the icon for board is “F002″, etc. We don’t want to write Unicode in our template every time. (Actually, we would have to write the HTML entity for the Unicode code point. Computers are awesome.) Luckily there’s an easy way to insert Unicode content in an element using only CSS. We’ll use “content” and the pseudo class “:before”. Here’s what it looks like:

.icon-org:before {
    content: "\f000";
}
.icon-member:before {
    content: "\f001";
}
.icon-board:before {
    content: "\f002";
}

Look, ma! No background-position! Now we can do:

<span class="icon-sm icon-org"/>

and…

<span class="icon-lg icon-board"/>

Ta-da! Now all we need to do is convert the CSS and templates to the new… Oh… This is going to take a while…

There are a few different ways to implement the CSS/HTML. Another neat approach is to use data- attribute, a method outlined in John Hick’s 24 Ways post. This will save on markup and is more semantically correct. Also see Chris Coyier’s example here. The class based method worked best for us since it’s most similar to our codebase.

So there you have it. Every step of the process and all the reading, all in one place. Should you choose to go on this adventure, I wish you good luck! I’m glad we took the plunge. It’s a faster, more succinct, and more scalable implementation. If you have any questions, you can ask me on Twitter.

And, oh yeah, go sign up for Trello! It’s the easiest way to organize anything with anybody.

FogBugz and Trello Homebrew

September 6th, 2012 by Ben McCormack

When we launched Trello last year, we immediately heard from customers that they wanted Trello integration with FogBugz. It’s a reasonable request:

Fog Creek made FogBugz.

Fog Creek made Trello.

Fog Creek should make them play nicely together.

So over lunch, I asked one of the FogBugz developers, Why haven’t you made a Trello Plugin yet?” And he responded, “We would love to make a FogBugz plugin that integrates with Trello! What do you want to see?”

I drew a blank.

The solution wasn’t immediately obvious to me and I couldn’t think of a good design off the top of my head—certainly there is a good solution; it just wasn’t obvious to me what it should be. There are a billion different ways you might present FogBugz data in Trello. Plus, Trello is still maturing and (currently) lacks web hooks. Both of these things make integration with FogBugz a bit challenging at the moment.

There’s not a FogBugz-Trello integration plugin yet, but several customers expressed an interest, and I was sure I could help them out. We recently talked to a FogBugz customer who uses multiple Active statuses in their workflow and uses Milestones to break up sprints. Something like this:

FogBugz: All Cases in Sample Project Broken Down by Milestone

Given their workflow, their request seemed pretty reasonable. For a given project:

  • FogBugz Milestones as Trello Boards
  • FogBugz Active Statuses as Trello Lists
  • FogBugz Cases as Trello Cards, with a link back to the original case.

I decided to use the FogBugz XML API and the Trello API to see if we could make that view possible. Turns out it’s not that hard and this is what you get as a result:

Trello view of FogBugz Cases

Each card even has a little Kiwi icon that you can click to go right to the case in FogBugz (On Demand only). The script only updates one way (FogBugz => Trello), but I think it’s a nice visualization for this particular workflow. You can get the script here: Milestones to Trello.

Of course, you should modify the script to fit your needs. Would you prefer to see Projects as Boards with Milestones as Lists? Areas as Lists? Edit the script any way you like, and if you come up with something you want to share, send us an email and we’ll add it to our FogBugz recipes.

Do you have an idea for how FogBugz and Trello should play together? Let us know what’d you like to see by leaving an answer on our Trello Integration post.

Building trello.com for multiple devices

January 24th, 2012 by Bobby Grace

Trello at various sizes on multiple devicesWe built Trello from the ground up to work on just about any device. It’s not a simplified version with limited features, either. Trello responds to your device’s screen size and capabilities. It’s the same exact site and the same exact code; a consistent experience that looks, feels, and works the same everywhere.

But we also have an iPhone app. It’s pretty great if I may say so. If you are a Trello user with an iPhone, you should download it now. It’s free. Now that there is a great app, why would we still focus on a mobile web app? One reason is that focusing on mobile makes Trello better as a whole.

Everything we do for mobile translates back to a better desktop experience. This wasn’t the first reason we wanted to implement a responsive design, but it turned out to be the most important. Keeping mobile in mind focuses us on creating a fast and easy-to-use interface. Trello gets data super fast, but the page must also render quickly. That stops us from using complex interactions and some of the more whiz-bang CSS features. This translates back to rendering speed on your desktop, which isn’t likely to be an overclocked gaming rig with 32GB of RAM.

All the interface elements are mobile-friendly, which means they are also more desktop-friendly. Buttons and menus have big, friendly hit targets. Interactions are straight-forward. We don’t rely on hidden hover effects and if we’ve got a complex interaction, it will have a fallback for touch devices.

There are no redirects. Let’s say you’re on your phone and somebody links to trello.com from Twitter. You’re able to watch the video, read the pitch, sign up, and try it out. You are left with a good impression, no nonsense. No screaming “DOWNLOAD THE APP!” page, no switching out of whatever app your using, and you won’t be redirected five times and land on the m.trello.com homepage. You just get the information and it works.

Scaling, zooming, and resizing work seamlessly. Sometimes you want to use a small browser window on a desktop. Maybe you’ve got a side monitor with a Trello board and your mail app open while your text editor or photo editor are up on your main screen. The horizontal board view won’t work at smaller window sizes, but Trello will adapt to a view that does. If you need bigger or smaller text, you can zoom in (or out) as much as you need and Trello will use a view that works. Got a huge monitor and want to project your Trello board for all to see? Trello will work for that as well. Is it way far back in the office? Just zoom in and text will be readable.

We can deliver updates to all devices seamlessly. We have a single codebase and one place to deploy, which means updates are easy. We don’t have to retro-fit new features to a separate codebase, worry about new workflows or interactions, or think about how some URL is going to work. This lets us develop and ship features faster.

So how does it all work?

Here are some of the tools and tricks that made developing a responsive interface much easier.

Use a limited library of mobile-optimized, reusable components. Each component can be collapsed into a single column or otherwise adjusts for smaller screen sizes. The same layout elements used for the back of cards are used in the organization profile and a bunch of other pages. Our context menus (those small pop-ups used to do things like assign members and select labels) are narrow enough that they will fit on any screen. We have some one-offs like the landing page and the board, but they are few and far between. For the most part, we don’t have to ask how a new feature is going to work on mobile because any component we use will already be mobile-optimized.

Card menu on card detailThink twice about navigation. The card sidebar typically has navigation and buttons for voting, assigning, and the like. It collapses below the main column with a smaller window, which means you would have to scroll and scroll to get to that vote button you were looking for. We added a card menu to the header on the back of cards that lets you easily vote, add due dates, assign members, and everything else without wearing out your thumb.

Use a vector-based image editor like Illustrator to produce icons. We wanted to make sure icons looked sharp on devices with a higher pixel ratio like the the iPhone 4. We use a CSS sprite sheet that has every icon used on the site. We can easily export a higher resolution version using Illustrator, and serve it to capable devices using some simple CSS media queries. UPDATE: Trello.com now uses an icon font for icons! Icon fonts are faster, Retina-ready, and easier to work with. You can read about our experience converting trello.com to an icon font here.

Trello icon sprite sheet

That being said…

We’re developing for the browsers and devices of today and tomorrow. We don’t have spare development time, so we can’t spend any on browsers and devices that won’t be around in two to three years. Trello won’t work on the RAZR, for instance. It also doesn’t work on every ‘smart’ device. Internet Explorer 8 doesn’t have the technical capabilities to run Trello. The Windows Phone 7.0 browser is based off of IE8, so it won’t work either. But it will work on Android 2.3+, iOS 4.0+, Windows Phone 7.5 (Mango), and others. Are we neglecting would-be happy users? Perhaps. But we can provide more value to more people by shipping features faster and that’s better in the long run.

And we still love native apps! Apps provide things we can’t get out of the web: better speed, offline support, smooth animations, push notifications, and a native look and feel. Native apps will provide a better experience to a broader reach. We just don’t think the mobile web should be ignored because of them.

Designing for multiple devices has deeply influenced our design decisions and made for a better, faster, and easier-to-use product. There are plenty of improvements to be made, but we’re happy with the foundation we’ve set. Sign up now and check it out for yourself.

The Trello Tech Stack

January 19th, 2012 by Brett Kiefer

Trello started as an HTML mockup that Justin and Bobby, the Trello design team, put together in a week. I was floored by how cool it looked and felt. Since Daniel and I joined the project to prototype and build Trello, the challenge for the team has been to keep the snappy feeling of the initial mockups while creating a solid server and a maintainable client.

The Initial Trello Mockup

The Initial Trello Mockup

That led us toward a single-page app that would generate its UI on the client and accept data updates from a push channel. This is pretty far from any of the work we’ve done before at Fog Creek, so from a technical perspective Trello has been an adventure.

Initially, we were wondering how interesting and far-out the stack could be before management got nervous, but our concerns were addressed in an early meeting with Joel, when he said “Use things that are going to work great in two years.”

So we did. We have consistently opted for promising (and often troublesome) new technologies that would deliver an awesome experience over more mature alternatives. We’re about a year in, and it’s been a lot of fun.

CoffeeScript

Trello started out as a pure JavaScript project on both client and server, and stayed that way until May, when we experimentally ported a couple of files to CoffeeScript to see how we liked it. We loved it, and soon converted the rest of the code over and started coding CoffeeScript exclusively.

CoffeeScript is a language that compiles to readable JavaScript. It existed when we started Trello, but I was worried about the added complexity of having to debug compiled code rather than directly debug the source. When we tried, it, though, the conversion was so clean that mapping the target code to the source when debugging in Chrome required little mental effort, and the gains in code brevity and readability from CoffeeScript were obvious and compelling.

JavaScript is a really cool language. Well-written CoffeeScript smooths out and shortens JavaScript, while maintaining the same semantics, and does not introduce a substantial debugging indirection problem.

The Client

The Trello servers serve virtually no HTML. In fact, they don’t serve much client-side code at all. A Trello page is a thin (2k) shell that pulls down the Trello client-side app in the form of a single minified and compressed JS file (including our third-party libraries and our compiled CoffeeScript and Mustache templates) and a CSS file (compiled from our LESS source and including inlined images). All of that comes in under 250k, and we serve it from Amazon’s CloudFront CDN, so we get very low-latency loads in most locations. In reasonably high-bandwidth cases, we have the app up and running in the browser window in about half a second. After that, we have the benefit of caching, so subsequent visits to Trello can skip that part.

In parallel, we kick off an AJAX data load for the first page’s data content and try to establish a WebSocket connection to the server.

BACKBONE.JS

When the data request returns, Backbone.js gets busy. The idea with Backbone is that we render each Model that comes down from the server with a View, and then Backbone provides an easy way to:

  1. Watch for DOM events within the HTML generated by the View and tie those to methods on the corresponding Model, which re-syncs with the server
  2. Watch the model for changes, and re-render the model’s HTML block to reflect them

Neat! Using that general approach, we get a fairly regular, comprehensible, and maintainable client. We custom-built a client-side Model cache to handle updates and simplify client-side Model reuse.

PUSHSTATE

Now that we have the entire client app loaded in the browser window, we don’t want to waste any time with page transitions. We use HTML5 pushState for moving between pages; that way we can give proper and consistent links in the location bar, and just load data and hand off to the appropriate Backbone-based controller on transition.

MUSTACHE

We use Mustache, a logic-less templating language, to represent our models as HTML. While ‘harnessing the full power of [INSERT YOUR FAVORITE LANGUAGE HERE] in your templates’ sounds like a good idea, it seems that in practice it requires a lot of developer discipline to maintain comprehensible code. We’ve been very happy with the ‘less is more’ approach of Mustache, which allows us to re-use template code without encouraging us to mingle it with our client logic and make a mess of things.

Pushing and Polling

Realtime updates are not a new thing, but they’re an important part of making a collaborative tool, so we have spent some time on that layer of Trello.

SOCKET.IO AND WEBSOCKETS

Where we have browser support (recent Chrome, Firefox, and Safari), we make a WebSocket connection so that the server can push changes made by other people down to browsers listening on the appropriate channels. We use a modified version* of the Socket.io client and server libraries that allows us to keep many thousands of open WebSockets on each of our servers at very little cost in terms of CPU or memory usage. So when anything happens to a board you’re watching, that action is published to our server processes and propagated to your watching browser with very minimal latency, usually well under a second.

AJAX POLLING

It ain’t fancy, but it works.

Early Architecture Drawing

Early Architecture Drawing

When the client browser doesn’t support WebSockets (I’m lookin’ at you, Internet Explorer), we just make tiny AJAX requests for updates every couple of seconds while a user is active, and back off to polling every ten seconds when the user goes idle. Because our server setup allows us to serve HTTPS requests with very little overhead and keep TCP connections open, we can afford to provide a decent experience over plain polling when necessary.

We tried Comet, via the downlevel transports for Socket.io, and all of them were (at the time) shaky in one way or another. Also, Comet and WebSockets seemed to be a risky basis for a major feature of the app, and we wanted to be able to fall back on the most simple and well-established technologies if we hit a problem.

We hit a problem right after launch. Our WebSocket server implementation started behaving very strangely under the sudden and heavy real-world usage of launching at TechCrunch disrupt, and we were glad to be able to revert to plain polling and tune server performance by adjusting the active and idle polling intervals. It allowed us to degrade gracefully as we increased from 300 to 50,000 users in under a week. We’re back on WebSockets now, but having a working short-polling system still seems like a very prudent fallback.

The Server

  • node.js
  • HAProxy
  • Redis
  • MongoDB

NODE.JS

The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.

By the time we had finished the prototype, we were good and comfortable in Node and excited about its capabilities and performance, so we stuck with it and made our Pinocchio proto-Trello a real boy; we gave it:

Node is great, and getting better all of the time as its active developer community churns out new and useful libraries. The huge amount of continuation passing that you have to do is an issue at first, and it takes a couple of weeks to get used to it. We use a really excellent async library (and the increased code brevity of CoffeeScript) to keep our code under control. There are more sophisticated approaches that add features to JavaScript to automate continuations, but we’re more comfortable with just using an async library whose behavior we understand thoroughly.

 

HAPROXY

We use HAProxy to load balance between our webservers. It balances TCP between the machines round robin and leaves everything else to Node.js, leaving the connections open with a reasonably long time to live to support WebSockets and re-use of a TCP connection for AJAX polling.

REDIS

Trello uses Redis for ephemeral data that needs to be shared between server processes but not persisted to disk. Things like the activity level of a session or a temporary OpenID key are stored in Redis, and the application is built to recover gracefully if any of these (or all of them) are lost. We run with allkeys-lru enabled and about five times as much space as its actual working set needs, so Redis automatically discards data that hasn’t been accessed lately, and reconstructs it when necessary.

Our most interesting use of Redis is in our short-polling fallback for sending changes to Models down to browser clients. When an object is changed on the server, we send a JSON message down all of the appropriate WebSockets to notify those clients, and store the same message in a fixed-length list for the affected model, noting how many messages have been added to that list over all time. Then, when a client that is on AJAX polling pings the server to see if any changes have been made to an object since its last poll, we can get the entire server-side response down to a permissions check and a check of a single Redis value in most situations. Redis is so crazy-fast that it can handle thousands of these checks per second without making a substantial dent into a single CPU.

Redis is also our pub/sub server, and we use it to propagate object change messages from the server process making the initiating request to all of the other server processes. Once you have a Redis server in place, you start using it for all sorts of things.

MONGODB

MongoDB fills our more traditional database needs. We knew we wanted Trello to be blisteringly fast. One of the coolest and most performance-obsessed teams we know is our next-door neighbor and sister company StackExchange. Talking to their dev lead David at lunch one day, I learned that even though they use SQL Server for data storage, they actually primarily store a lot of their data in a denormalized format for performance, and normalize only when they need to.

Trello Today

In MongoDB, we give up relational DB features (e.g. arbitrary joins) for very fast writes, generally faster reads, and better denormalization support — we can store a card’s data in a single document in the database and still have the ability to query into (and index) subfields of the document. As we’ve grown quickly, having a database that can take a fair amount of abuse in terms of read and write capacity has been a very good thing. Also, MongoDB is really easy to replicate, back up, and restore (the Foursquare debacle notwithstanding).

Another neat side benefit of using a loose document store is how easy it is to run different versions of the Trello code against the same database without fooling around with DB schema migrations. This has a lot of benefits when we push a new version of Trello; there is seldom (if ever) a need to stop access to the app while we do a DB update or backfill.
This is also really cool for development: when you’re using hg (or git-) bisect and a relational test DB to search for the source of a bug, the additional step of up- or downgrading a test db (or creating a new one with the properties you need) can really slow things down.

So we like it?

We like our tech stack. As Joel observes, we’ve bled all over it, but I’ve never seen a team make an interesting app without tool- and component-related bloodshed, and not everyone can say that they really like what they’ve ended up with. As is true of most applications, no component or implementation detail is necessary to its nature; however, we think that this excellent set of open-source projects has sped up our development, left us with a solid and maintainable code base that we’re eager to move forward with, and made Trello a more responsive and beautiful app. Thanks to everyone who has contributed to them; it’s a great time to be a programmer.

Sound neat? Try Trello! It’s free.

Just can’t get enough tech stack talk? Here’s a Prezi I made for a recent talk on Trello.

* The Socket.io server currently has some problems with scaling up to more than 10K simultaneous client connections when using multiple processes and the Redis store, and the client has some issues that can cause it to open multiple connections to the same server, or not know that its connection has been severed. There are some issues with submitting our fixes (hacks!) back to the project – in many cases they only work with WebSockets (the only Socket.io transport we use). We are working to get those changes which are fit for general consumption ready to submit back to the project.

Let Them Have Cake … And Ice Cream Too!

November 17th, 2011 by Rock Hymas

Consider a cake shop owner in a small town in Siberia. He sells the best cake around. Whenever someone wants a treat after dinner they stroll down to the cake shop and get a nice big slice of cake. But along comes a new treat: ice cream. Our cake shop owner ridicules his neighbor for starting an ice cream stand, saying no one will buy it because it’s cold. This is Siberia, after all. But rather than running an oven all the time, she can just keep her ice cream outside in the freezing cold, so it sells for less. Suddenly a whole bunch of people who could never afford cake are stopping at the ice cream stand after both lunch and dinner. It’s cheap, it tastes good, and the teenagers are having contests to see how much they can eat before passing out from brain freeze. It seems the whole town is there, and some of the cake shop customers start getting ice cream just because they want to hang out with their friends at the ice cream stand. All of a sudden the neighbor is rolling in the dough and she wants to buy out the cake shop since they have a great location.

Now suppose the owner of the cake shop recognizes that lots of his customers will like the ice cream (even in Siberia) because it’s so much cheaper. So he sets up an ice cream stand and hires his neighbor to start selling it as fast as possible. He notices that some of his regular cake shop customers are going to the ice cream stand instead, because it’s cheaper. So cake sales are down a little. Rather than shutting down the ice cream stand though, he brings it into the cake shop, adds a special “cake” flavored ice cream, and becomes the town hero. Not only has he saved his business, but he’s also been able to meet the dessert needs of more of his fellow townspeople. Cake is selling even better than before, ice cream is selling even better than that, and the cake-fanatics and ice cream groupies all get to hang out together.

Clayton Christensen’s talk at this year’s Business of Software was all about how companies disrupt, and are disrupted by, other companies. In building a product, you (or those who came before you) made decisions that are really hard to change after the fact. That’s fine; those “stakes in the ground” are what made the product successful. But it also limits the viable lifetime of the product. At some point disruption happens.

Disruption =

Larger Market + Lower Price + Different Measure

 

Professor Christensen pointed out that disruption occurs when a company solves a given problem for a larger audience at a lower price point with a different measuring stick for comparing value. Companies that successfully avoid being disrupted are usually able to do so only by disrupting themselves. Few companies are able to pull that trick off, and it typically involves having a different team or business unit set up in order to avoid all the baggage that the last-generation products carry with them.

What does this have to do with Fog Creek? Well, I’ll admit that I was a little skeptical when Fog Creek launched Trello. My worries pretty much lined up with those outlined in this post from a FogBugz customer. Though it’s taken some time, I’m starting to see how important it is for Fog Creek to prepare for the disruption of its flagship product, FogBugz.  By doing so, we can make sure FogBugz will keep solving our customers problems and keep making us money.

Trello fits the model for disrupting Fogbugz. It solves the problem of planning the work on a project for a larger audience than just software companies, at a lower price point than a FogBugz or a Jira, with a different measuring stick: putting Trello and FogBugz next to each other on a feature comparison chart doesn’t make any sense.

Trello’s target market is much larger than that of FogBugz. Where FogBugz targeted software development teams with features like bug tracking, automated crash reporting, and evidence-based scheduling, Trello can provide value to any group of two or more people working together on something that can be broken down into steps. Even though any group of people could use FogBugz to do the same thing, using FogBugz doesn’t really make sense when you’re in HR doing hiring, or in law working through cases, or in a studio vetting country bands. Using Trello does.

Additionally, Trello has a lower price point: free. Everything currently offered by Trello is free, and will remain so going forward. Yes, there will probably be value-added features and services that Fog Creek will charge for at some point. Compared to free, though, FogBugz is expensive at $25 per user per month. When you just want something simple to plan your wedding, that doesn’t make any sense. But if you’re managing software projects for reasonably complex products, then FogBugz easily adds that much value, and our customers make that clear by coming back again and again.

Trello also has a different measuring stick. And that’s the real reason it will eventually overtake FogBugz, even for software projects. Or rather, it will take over some of the roles that FogBugz fills in a software development company. We already use it here at Fog Creek to manage our work at a coarse-grained level. It provides a potentially public view into product development, which is cool to see.

The real key, though, is that Trello, like FogBugz, is opinionated–but it has very different opinions. Rather than seeing work on a project as a large set of small items that need to be tracked individually, it sees project work as a small set of somewhat larger tasks that fit into a bigger whole, a workflow defined by the team. If FogBugz tried to create some kind of dashboard view of your bugs to compete with Trello, you’d be so overwhelmed by minutia that you’d give up and walk away. No one wants that kind of view when they’re dealing with hundreds or thousands of individuals cases. But Trello redefines the way we see our project work and that fundamentally changes the game.

Wait a sec! I’m on the FogBugz team. What am I saying?! Am I just making a Steve Yegge “TMI” mistake by posting this publicly? Am I talking myself out of a job?

 

TMI?

 

I don’t think so. And here’s why.

The same legacy that prevents it from winning in the larger Trello market gives it a competitive advantage in the market for software development teams. FogBugz will continue to make money, and it is still growing at a nice pace. It needs investment, but not the kind of investment that would attempt to turn it into Trello. Rather, the kind of investment that will take advantage of disrupting products like Trello while preserving it’s usefulness in the niche of software development teams.

And our customers, for the most part, aren’t going to jump ship for Trello anytime soon. Currently, Trello can replace only a very small part of what FogBugz provides. One customer pointed out that it cannot handle bulk editing, screenshot captures are painful, and categorization and search aren’t designed for the situation where you have lots of items. Additionally, FogBugz supports incoming and outgoing email, automated crash reports, and deep hierarchies of work. You can install it within your network and use it completely internally. It’s also got awesome source control integration with Kiln. These are all things that software development teams care about, often passionately. Trello, and other products like it, may eventually meet some of these needs, or integrate with other tools that do, but that will take time. Time that will allow FogBugz to further differentiate itself.

Besides, learning new ways of working is hard. Anecdote time! We spent some time over the last few months rethinking the UI for FogBugz. As the team lead, I made the call to focus on that, and did what I could to protect the team through the process. Unfortunately, when it was done, Joel pointed out that it wouldn’t fly with our customers. Why? Because we “moved the cheese” in too many ways. It would have required our customers to learn new ways of working, and human nature doesn’t like to do that. Though that does limit what we can do with FogBugz going forward, it also strengthens the ties that our current customers have with the product. They know where to click, which keyboard shortcuts to use, and they know what to expect. That helps them work faster, get in the flow, and keep the boss happy.

Finally, and related to the last point, FogBugz has an ecosystem of supporting technology around it. When our customers start using FogBugz and Kiln, they often integrate with a set of tools and technology. This is one reason it’s harder to innovate on those products, because our customers don’t just rely on not having to learn new ways of working, they also rely on their custom plugins not breaking, on their random Python scripts still working, and on third-party tools continuing to integrate well with FogBugz. Each of those is a barrier to entry – they make it harder for a competing product to win our customers away from us (yep, even if the competitor is made by us as well) because they also add value for the customer.

In short, for almost all of FogBugz existing customers, and most of the larger market of customers using a competing bug tracker, using Trello instead is not the right business decision. And within that market FogBugz can make sure that business decision doesn’t change by doing the right kinds of investment. Investment that will keep FogBugz relevant and growing into the future is core-competency investment, not more features or chasing faster competitors in a race decided by a radically different “finish line”.

And there are tons of things we can do in the core of FogBugz: reduce the complexity of the product both for our users and for our developers; make it faster; phase out old features that aren’t being used by anyone; fix the backlog of bugs; improve our up-time; integrate with Trello and other apps. That last point is probably the most salient. As Trello grows and becomes a better fit for certain kinds of project management work, FogBugz can increasingly integrate with and offload those areas to Trello. At the same time, it can target specific problems that software development teams face, and provide value by solving them well.

In the end our customers will be able to have their cake … and their ice cream too.

The Agonies of Picking a Product Name

September 15th, 2011 by Dan Ostlund

Picking a product name is all agony and no ecstasy. It’s also a giant time-slurping vortex. And in the end, it kind of doesn’t matter.

A product, or a company name, only really needs to achieve one thing: not remind us of some unpleasant bodily function, or the results of a wild and drunken night. But even this seemingly common-sense advice is often and successfully broken. Wii anyone?  No thanks, I went this morning.

Yes the name matters if it’s truly totally weirdly awful, but outside of that it just doesn’t.

Recall that “iPad” was the subject of all kinds of snark and scorn in the first couple of weeks after launch. Who makes those jokes now? No one.

Amazon? I remember lots of people making fun of that name and insisting there would be endless confusion, but it worked out fine, and at least it wasn’t Cadabra, one of the early names Bezos considered, and something sure to upset the Steve Miller Band.

At least a dozen people I know wondered why you would name an e-reader Kindle, something that reminded them of fire. Fire. Books. Fire + Books, bad. Anyone think that anymore? Nope. Everyone just buys them by the millions.

If Google wasn’t such a familiar and ubiquitous name, most people would reject it as a company name on the sensible grounds that it is sillier than a bald cat. But we’re all used to it, and we don’t care. And that’s the point.

And of course there is no shortage of bad-seeming names on really successful products. Dare I mention FogBugz in this context?

We just recently went through the naming agony since we just launched Trello, a tool for project and task and process management, and…well, go check it for yourself. 27,000 users have signed up in the last 24 hours, and they’ve been saying really nice things on the Twitters.

Trello was code named Trellis when it was in development. It got that name because one of Fog Creek’s co-founders, Michael, suggested it as a code name in an early meeting. It was fine. It stuck.

Eventually we decided that we needed An Actual Product Name. Which, of course, we did, but we spent way more time on this than we needed to. Two of the team members took some time to come up with some names. Actually, a couple of hundred names. For one reason or another, these were all rejected or shelved, mainly because all possible domains have been plucked up by an automatic domain-registering spaceship.

Feeling morose over this, they then hired a professional naming person. He came up with about 200 names, some of them very good, and one of them “lasagna”.

Not knowing about the previous naming efforts, I jumped in one day with about 125 name ideas. Then several of us sat down together and reviewed our name ideas, and came up with about 200 more. We tried everything: animal names, plays on various aspects of what Trello does (board, card, list, task), Japanese words, and every combination in between. We threw them all at the wall, from the practical to the nutty. Kardboard, Hippolist, 5 Camels, Listly, Idealist—all were suggestions at one point or another.

Late in the process we thought, maybe we could just use the code name, Trellis. Why did it have to change? But, we couldn’t buy trellis.com. They weren’t selling. We tried to buy trell.is, but it was more than we wanted to spend. We really thought it was important to get a .com domain anyway, so we weren’t thrilled with this option.

The wheels continued to spin and every couple of weeks the product name came up and we would lurch off on another round of fumbling around for a new name.

Work continued on the product code named Trellis and for a couple of months we didn’t have much time to think about the name until the mid-September launch forced the issue: nothing like a deadline to provide some clarity.

So Joel organized a company-wide brain storming session and we got out our markers and some giant pieces of paper, tacked those up on the wall, and came up with about another 150 names. Some really good names came out of that session. It was raucous, and it was fun.

We argued, we lobbied, we pointed out when a possible name rhymed with wee, and then we voted. Of our choices, about none had available .com domains. The whole thing was getting depressing. And we were out of time.

Trellis was still one of the contenders, so, after all of these sessions, and all of this brain-storming, and the many hundreds of suggestions, Michael just decided to start playing with variations on Trellis. He came up with a number of them, and then looked for domains he could buy. Trello.com happened to be one of the domains he could get for a reasonable amount of money and we decided it sounded good. We had made a grand wandering journey all the way from Trellis to Trello. That’s like leaving New Jersey and getting to New York by way of Kinshasa. But here we are.

After all of that it’s clear that the name just isn’t that important.

Gold Bond Medicated Powder. What’s a Gold Bond, actually? And Medicated Powder isn’t a name, it’s a thing. Might as well call your product Lined Paper With Three Holes. But Gold Bond Medicated Powder works, doesn’t it? No one ever thinks about it, they just get some if they have itchy feet.

We ended up with a name very similar to the one we started with, one that all of us like just fine, and one which is just going to be what people call our new, supremely free, project management app. I think everyone would have gotten used to Hippolist too, but it doesn’t matter, because it’s called Trello now.

In the end we should have just had Michael do the whole name picking in thirty minutes and been done with it.

Fog Creek Launches Trello

September 13th, 2011 by Dan Ostlund

Today we’re happy to announce a new product. It’s called Trello and it’s used for all kinds of project and task management. It’s based on a simple board and card metaphor, and we hope you’ll find it as useful as we do. Oh, and it’s free. But wouldn’t you rather hear all the details about Trello from Joel?

You can follow the Trello twitter here. Or you can check out the Trello blog here. There will be several posts there over the next couple of days.