When you work in a traditional office and have a question, instant gratification is hard to resist. It’s so easy. Just stumble over to a co-worker’s desk, make sure they stop whatever it was they were doing, blather on until the lights of recognition come on in their eyes, then await the answer. Unless your query concerns inflammable materials currently engulfed in said flames you’ve likely wasted their time – in fact, you may have even wasted your own.

One of my favorite side-effects of working remotely is the way slow-time communication forces you to stop and think before you speak. When I have a question for one of our programmers, for example, here’s a bit of what goes through my head:
How should I ask this question? He’s online, I could just send a quick IM…
...but is this important enough to risk interrupting with an instant message? No. I’m not even sure I can even explain it one line at a time like that.
What about email? Nah. It’s about some specific code, maybe I should ask on Github.
It’s complicated. How can I explain this as directly as possible? I can post a comment right on the helper method…
...but is the problem really in the helper or is it because of the collection set in the controller? It’s definitely in the controller, let’s start there. Wait a second…!
It’s usually at this point that I either figure out the answer for myself or come up with a new way of considering the problem, never having to even ask the original question. I didn’t bother my co-worker, I didn’t look like an idiot trying to articulate the question on-the-fly, and most importantly I figured out the answer!

People who struggle to work remotely often bemoan the lack of in-person collaboration jumping from this tool to that tech in an effort to recreate the magic that only happens when we’re all in the same room. There are definitely advantages to face time, but too often it seems like facial expressions and waving arms are substituted for clear thought and courtesy.

The next time you have a question for a coworker, try writing it out as if they were 1000 miles and 3 time zones away – even if they’re sitting right next to you. You might surprise yourself with the answer.

Designing the mobile version of an existing app is about so much more than screen size.

The fundamental concept of the new Basecamp is this: a project on a single page. Projects resemble a nicely organized paper document with wide margins, familiar proportions and plenty of white-space. In a glance you can see what’s happened in the project, what’s left to be done, and any relevant files. You can almost imagine peeling the sheet off the screen and handing it to a co-worker to get them up to speed. It’s an iconic design.

We knew that this design would be instrumental in making Basecamp for iPhone feel like Basecamp so it’s no surprise that we attempted a very literal reproduction in an early version of the app.

It’s all here: the clean, white sheet topped with the project’s name followed by sections with snapshots of the latest Discussions, To-dos, Files, etc. A virtual clone in smaller package. We were pretty happy with this mini-me design for awhile, but the story doesn’t start here.

Here’s a great bit of advice from Jakob Nielsen’s 2001 post about writing company taglines:

…look at how you present the company in the main copy on the home page. Rewrite the text to say exactly the opposite . Would any company ever say that? If not, you’re not saying much with your copy, either.

Great copy doesn’t remind people what they already know and expect about your product, it tells them why they should care.

There are plenty of books that will teach you to be a better writer, but I’ve never found one so immediately useful as Revising Prose by Richard A. Lanham. Following along as Lanham revises example upon example of real world writing is like exercise for your writing muscles.

My favorite takeaway is this tip for improving the rhythm and cadence of your writing. Many of us have learned to read text out loud as a method to reveal awkward transitions or generally dull passages, but you can also spot poor rhythm visually. A red flag for dull cadence is a run of sentences that are all of similar length. Try adding a carriage return after every sentence or phrase, the rhythm is evident:

While other books have increased my knowledge of writing, Revising Prose changed the way I write and how I think about writing. Buy a copy at Amazon.

If you’re interested in adding retina image support to your website or app and you happen to be using SCSS, here’s a handy shortcut that makes it dead simple.

Just include this SCSS mixin in any rule and specify the high resolution image’s path and device independent pixel dimensions. Here’s an example:

div.logo {
  background: url("logo.png") no-repeat;
  @include image-2x("logo2x.png", 100px, 25px);
}

Putting the high resolution alternative in the same rule as the normal image instead of putting it in a separate @media query rule or in different stylesheet altogether is a big win in terms of clarity in our CSS. It’s easier to read, easier to understand and easier to maintain.

The image-2x mixin detects high resolution displays like this:

@mixin image-2x($image, $width, $height) {
  @media (min--moz-device-pixel-ratio: 1.3),
         (-o-min-device-pixel-ratio: 2.6/2),
         (-webkit-min-device-pixel-ratio: 1.3),
         (min-device-pixel-ratio: 1.3),
         (min-resolution: 1.3dppx) {
    /* on retina, use image that's scaled by 2 */
    background-image: url($image);
    background-size: $width $height;
  }
}

The mixin not only makes development easier, but it centralizes the definition of high resolution displays so it can easily be changed globally as more devices come to market. The @media query is based on the one in Thomas Fuchs’ Retinafy book but, for example, we’ve already modified it to define the Google Nexus 7 with it’s 1.3 pixel ratio as a retina-capable device.

A key insight here is that with SCSS, @media queries can be nested inside other rules. Such that these both work the same:

@media print {
  body {
    // print styles
  }
}

body {
  @media print {
    // print styles
  }
}

Purists of hand-crafted CSS may rail that this method results in the rule being repeated in the compiled CSS each time we use this mixin and that’s true. Basecamp is light on images so we’re talking about a handful of repetitions, not dozens or hundreds. It also seems likely that as SCSS continues to improve, these rules will be smartly combined. For now that trade-off is worth the improved clarity and convenience in our code.

Speed is a core value for 37signals and it’s easily Basecamp’s most important feature. When you have the luxury of that kind of focus, decisions about the product are easier to make because you have something to measure against. Will this feature make Basecamp slower? Is it worth that trade-off? So when we designed the mobile web version of Basecamp we knew that speed would be just as important as it was in the full desktop version. What was different was how we got there.

On the desktop, Basecamp’s speed is the result of some nifty tech that minimizes network requests, reduces page rendering and aggressively caches content. Moving through a Basecamp project is nearly instant as new content appears in real-time without re-loading the page. It’s great! I typically keep Basecamp open in my browser all day long as my co-workers’ activity streams in on the Progress screen.

When it came to the mobile version the goal that Basecamp should be super-fast was the same, but there were new forces at work: low cellular bandwidth, small touch-enabled screens, slow JavaScript performance, and context considerations (what’s useful and functional on mobile). It was tempting to turn to responsive design techniques on this project. Basecamp was already functioning fine on mobile browsers, but it required a lot of pinching, swiping, and zooming. CSS media queries would have let us craft a mobile layout for all kinds of devices with a limitless array of screen configurations. We’d be on the exact same codebase with all the same features – and new features would automatically be available on mobile when they launch as long as we remembered to test and optimize them.

Only using responsive design for Basecamp mobile would have been like fitting a Prius body to a Hummer… under-the-hood it would have been all wrong.

On the surface it sounded great, but there were some big problems. The JavaScript that powers the real-time feel of Basecamp is heavy both in terms of file size and resource usage. This is no problem on the desktop where bandwidth is abundant and CPUs are excessively fast, but mobile browsers aren’t nearly as capable of processing JavaScript and the initial download would have been oppressive.

Not only would the browser have to download and process all that code, but much of it would have gone unused. Making a design responsive generally means taking things away. You hide features, menu items, sidebars – anything that isn’t needed in the mobile context. They’re still present in the document and the mobile browser still has to download and load into memory all the CSS and JavaScript that defines them. Not to mention the additional CSS overrides that you added to the stack in order to define the responsive layout in the first place. Only using responsive design for Basecamp mobile would have been like fitting a Prius body to a Hummer. It might have looked like a mobile web app, but under-the-hood it would have been all wrong.

Today we announced the new Basecamp mobile, a special version of Basecamp fine-tuned for speed, easy reading and easy tapping on mobile phones and tablets. It works automatically in your mobile device’s web browser – no app needed.

This has been a top request in the new Basecamp since launch and we’re really thrilled to finally deliver. It’s live for every Basecamp account today.

How it all came together

The project started from a simple need. Up until now the mobile experience on Basecamp has really meant one thing: email. Email notifications from Basecamp work great on the phone – you can even reply to them and your comment will show up in your project. But clicking a link to Basecamp on your phone was miserable. Tiny, slow and really tough to read. So we thought, What if you clicked to read a discussion on mobile and we served a nicely formatted mobile-optimized view? No navigation, no interaction, just a clean, readable page. So we set off to prove the concept. The result was an instant hit (read the discussion in our Basecamp project). The new mobile pages were even nicer to read than the email itself and, because they were plain HTML and CSS, they were wicked-fast.

So we kept proving and kept asking questions. If you’re reading the comments about a to-do you might want to see the entire to-do list, let’s see what that looks like. What if you want to see the all the Text Documents in a project – or even the project, itself? Can we try that? So we started to connect the dots, linking pages and optimizing views every time we missed something else. Pretty soon we had a fairly complete mobile version of Basecamp. It doesn’t do everything but it does a lot of what you want to do most on-the-go, without a bunch of stuff you don’t need.

Designed for the job to be done

We didn’t set out to build a feature-for-feature version of Basecamp that magically fits on a mobile phone screen. We built it for the job to be done on mobile. What you hire Basecamp to do when you’re using your computer at your desk isn’t is the same when you’re on your phone at the airport. In the evenings, I use Basecamp on my phone to see what I’ve missed. Checking the Progress timeline, adding my comments, searching for and viewing attachments – Basecamp for mobile is ideal for these tasks. By having the focus of a clear job to be done it was easy to make decisions about what to include in this mobile experience and what could be left out.