There are thousands of pieces of work on the Basecamp cutting room floor. Here are 37 random ones from October 2011 until now.

Some of these were ideas in progress. Some of them never left the sketch phase. Some were in production for awhile before we decided to change, redesign, remove, or tweak. And others are still there.

More...

Please welcome Mig Reyes to the 37signals crew.

Mig is a designer. That’s how he describes himself. We’d add “damn fine” to that description.

He’s been making beautiful useful things at Threadless for the last few years. I’ve long admired his work, his work ethic, his interest in learning, his blossoming writing skills, and his dedication to the Chicago design scene. We’re super lucky to have him on our team.

Soon enough you’ll be seeing his creativity make its way to the surface on our sites and in our apps. We’re looking forward to seeing how he influences us.

Welcome aboard, Mig!

It’s hard to believe we didn’t have a proper calendar in Basecamp until June of 2011. Before that we had a list-based view which worked exceptionally well for nearly seven years, but people still like looking at dates and deadlines on grids. We get it! ;)

We’ve made a few calendars in our time. Backpack has a great one – it served as our exclusive company calendar up until we built this new one in Basecamp. Now we run all our schedules with the new Basecamp calendar.

We wanted to make sure the calendar for the all new Basecamp was the best one we ever made. And the best one around, period. It’s not going to launch with everything we want, but all the basics are covered real well. We put a lot of time into the interaction details so it’s fast, smooth, intuitive, and flexible. We’ll continue to improve it and refine in over the coming months, post launch.

Here’s a video peek at what it looks like and how it works. There’s more to it than this – there’s a list view inside projects, and each event has a discussion page as well – but we’ll be saving those details for a future video.

We’ve discussed, debated, decided, changed our minds, debated again, decided again, changed our minds again, and finally decided for sure just recently. Basecamp Next will actually be named Basecamp.

For marketing and communications purposes, once we launch the new Basecamp, today’s Basecamp will be referred to as Basecamp Classic and the all new Basecamp will simply be known as Basecamp.

How we got here

Originally, we didn’t really have a name in mind. We weren’t thinking about the name. The first time I presented the idea I called it BC3, but soon after that we started calling it BCX. X didn’t stand for anything other than “we don’t know what it’s going to be called, so let’s just use X”. We liked the way it sounded, too.

As we got a month or two into the design process, we started seeing it take shape. With shape, we started to toss around some names. Early on we tossed around things like Basecamp 3 (we had already called a major redesign a few years in Basecamp 2). But we didn’t like version numbers – especially since we know there wasn’t going to be feature parity between the current Basecamp and the new product we were building.

To cast a wide net, we asked the whole company what they thought the name should be. As you’d expect from a group of 25+, there were a lot of opinions.

More...

There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton

Doing cache invalidation by hand is an incredibly frustrating and error-prone process. You’re very likely to forget a spot and let stale data get served. That’s enough to turn most people off russian-doll caching structures, like the one we’re using for Basecamp Next.

Thankfully there’s a better way. A much better way. It’s called key-based cache expiration and it works like this:

More...

When we started working on Basecamp Next last year, we had much internal debate about whether we should evolve the existing code base or rewrite it. I’ll dive more into that debate further in a later post, but one of the key arguments for a rewrite was that we wanted a dramatic leap forward in speed — one that wouldn’t be possible through mere evolution.

Speed is one of those core competitive advantages that have long-term staying power. As Jeff Bezos would say, nobody is going to wake up 10 years from now and wish their application was slower. Investments in speed are going to pay dividends forever.

Now for the secret sauce. Basecamp is so blazingly fast for two reasons:

More...

When we started thinking about the design of the all new Basecamp, we had three key things in mind:

1. Speed
2. Big picture
3. Focus

With that in mind, and many experiments later, we came up with a unique interface that is crazy fast, excellent for big picture broad overviews, and perfectly tailored for quick focus with no distractions.

We call it page stacking and we think you’re going to love it. Here’s a brief video I just put together to show you how it works (it looks best in full screen mode, BTW).

We’re just a few weeks out from the official launch. Sign up for a chance at an early beta invite prior to launch. We’ll also use this list to announce the launch.

Back in July when we first presented the idea of Basecamp Next (called BCX internally) at our company-wide meetup in Chicago, we put together two lists: Goodbye and Hello.

Goodbye was a sample of some of the things that Next wouldn’t have that Classic did have. Hello was a sample of some of the things that Next would have that Classic didn’t have.

“Have” is a relative term. Some stuff on the Goodbye list is completely gone from Next, while other things are just executed differently enough that they don’t resemble the way things worked in Classic.

It’s interesting to look back at the two lists now and see how well our original predictions worked out. There’s some stuff on Goodbye that we ended up keeping and there’s some stuff on Hello that we didn’t do (or did completely differently than we originally anticipated). And then there’s a bunch of stuff not on either list that you’ll ultimately find in Basecamp Next.

We’re only a few short weeks away from launch, and we’re still making calls on what’s in and out and how some key features work. It’s a good reminder that lists are moments in time, they aren’t golden rules.

What would you say if I told you that you could get more precise, actionable, and useful information about how your Rails application is performing than any third party service or log parsing tool with just a few hours of work?

For years, we’ve used third party tools like New Relic in all of our apps, and while we still use some of those tools today, we found ourselves wanting more – more information about the distribution of timing, more control over what’s being measured, a more intuitive user interface, and more real-time access to data when something’s going wrong.

Fortunately, there are simple, minimally-invasive options that are available virtually for “free” in Rails. If you’ve ever looked through Rails log files, you’ve probably seen lines like:

Feb 7 11:27:49 bc-06 basecamp[16760]: [projects] Person Load (0.5ms) SELECT `people`.* FROM `people` WHERE `people`.`id` = ? LIMIT 1 Feb 7 11:27:49 bc-06 basecamp[16760]: [projects] Rendered events/_post.rhtml (0.4ms) Feb 7 11:27:50 bc-06 basecamp[16760]: [projects] Rendered project/index.erb within layouts/in_global (447.2ms) Feb 7 11:27:50 bc-06 basecamp[16760]: [projects] Completed 200 OK in 529ms (Views: 421.7ms | ActiveRecord: 58.0ms)

You could try to parse these log files, or you could tap into Rails’ internals to extract just the numbers, but both of those are somewhat difficult and open up a lot of areas for things to go wrong. Fortunately, in Rails 3, you can get all this information and more in whatever form you want with just a few lines of code.

All the details you could want to know, after the jump…

More...

Anyone who builds products is familiar with the mad dash at the end of a project to add those last few features. When you’re running out of time it’s usually because you have more to add than your schedule allows.

But the more I learn about designing products, the more excited I get about the mad dash at the end to remove features.

This means killing work that’s been done and is technically ready to ship. It’s hard to do because it’s already done, but done doesn’t mean it’s right.

Killing stuff right before it ships is the sign of a healthy product and development process. It means you’re always questioning, reconsidering, and reevaluating. It never ever hurts to ask why.

What made sense two months ago may not make sense two weeks before launch. Other features may have taken its place. Newer ideas may have replaced earlier ideas. And sometimes it just takes time and use to realize that feature you built just isn’t scratching the itch you thought it would.

We’re just a few weeks out from the Basecamp Next launch. Last week we killed two features we’d already built and were initially pretty excited about. But they just weren’t right, they weren’t doing the job. And they were introducing new problems that we just didn’t feel good about.

Remember that people get used to the way things are. Even things that are broken or complicated become things some customers want to protect from change because they’re familiar with the intricacies of how those things work. That’s why it’s so costly to let bad designs slip into products.

Just like you shouldn’t let sunk cost determine future decisions, don’t let sunk design trick you into keeping something in your product because you already put the work in. If it’s non-essential, take it out, think it over, and invest the time post launch to make it right.

This is how I made a graphic I’m using to represent “the world”.

When the Series A check clears, most startups send out a bragging press release, the equivalent of flashing your grill. The VC backing is supposed to mean that the company has experienced hands in its corner. That it’s financially solid. A shoe-in for a puff profile piece in a magazine. Eligible for lunch conversation in Silicon Valley.

But if customers actually think about what a venture capital injection entails, it’s not all California Love. The company’s cash concerns might have (temporarily) vanished, but they’re replaced with a new list of problems. As a user you might be looking at any one of the following:

1. The Pivot
Sure, the product as described today sounds great, but if that hockey-stick growth pattern doesn’t emerge in six months, the product you wasted your time and money on might quickly turn into something else entirely.

2. The Talent Acquisition
Big companies like Google love to buy small bands of developers their VC friends tell them about (the risk easily triples if said band comes with Stanford or MIT pedigree). When the developers behind the app are acquired for their “talent”, you can expect a “sunset” to follow soon thereafter. That combination is the perfect euphemism for fuck the app and fuck the users.

3. The Runway
They don’t call it venture capital because you’re supposed to put it back in the bank. No, fool, that green gots to get spent. The quicker the better. So while $10 million dollars sounds like a lot, it might only just buy a company 12 months of runway. You know, once the swanky office in San Francisco has been decorated and the 100 programmer rockstars, designer ninjas, and bizdev suits have been bought.

4. The Pressure Cooker
Once a company takes millions of dollars of other people’s money, they’re instantly under extreme pressure to perform LIKE A TIGER. This kind of pressure can easily lead otherwise decent people to do indecent things with your data, your privacy, or anything else you hold dear. Because the scoreboard has already been set: winning means blowing it out of the park. And hey, sometimes a playa gots to cheat a little to make the magic sparkle, if you know what I’m saying.

5. The Acquisition Graveyard
If the product is strong enough to prevent a talent acquisition, you earn a few more years of fun and games before the product acquisition is likely to happen. With great fanfare some big company will announce what awesome synergies are in store now that the youngsters have “access to all the resources they need to take it to the next level”. The founders will spend two years on “integration” with the acquiring company’s legacy systems, and then – wait for it – their golden earn-out handcuffs will unlock and they’ll be long gone, along with any chance of the product ever getting better.

Of course, every now and then the clock that’s stopped tells the proper time. The fantastical success story somehow ends up being enough to swallow a hundred bad ones, so the crowd still cheers. See, world, we were there when this wee little lad got his first series A round and just look at him now!

Don’t fall for it. Given the odds involved, if you’re a user, or worse yet, a customer of a product, and the company behind it announces venture funding, the proper response is aahhhh, shiiiiiit.

One of the most pervasive myths of startup life is that it has to be all consuming. That unless you can give your business all your thoughts and hours, you don’t deserve success. You are unworthy of the startup call.

This myth neatly identifies those fit for mission: Young, without obligations, and few if any extra-curricular interests. The perfect cannon fodder for 10:1 VC long shots.

They’re also easier to rile up with tales of milk and honey at the end of the rainbow, or the modern equivalents, “compressing your working life into a few years” and “billon dollar waves”.

But running your life in perpetual crunch mode until the buy-out or bullshit-IPO fairy stops by your door is not surprisingly unappealing to lots of people.

The problem is that most “exciting new company” lore is intermingled with that of Startup Culture™. This means it’s hard to find your identity when it doesn’t match the latest company write-up of How Those Crazy Kids Turned VC Millions Into Billions!!!

Most people will look at that and say that’s not me. I don’t have 110% to give. I have a family, I have a mortgage, I have other interests. Where’s my place in the startup world if all I have to give is 60%? What can putting in part-time give?

The good news is much more than you think. The marginal value of the last hour put into a business idea is usually much less than the first. The world is full of ideas that can be executed with 10 to 20 hours per week, let alone 40. The number of projects that are truly impossible unless you put in 80 or 120 hours per week are vanishingly small by comparison.

This is of course nothing new. We’ve been playing this bongo drum for years. But every time I see people crumble and quit from the crunch-mode pressure cooker, I think what a shame, it didn’t have to be like that. It’s the same when I read yet another story about someone who won the startup lottery, and the stereotypical startup role model is glorified and cemented again.

It’s almost like we need another word. Startup is a great one, but I feel like it’s been forever hijacked for this narrow style, and “starting a business” just doesn’t have the sex appeal. Any suggestions?

Mister Default

Here he is: our default profile picture. You may know him as “Generic Avatar”. He’s the picture you get when you create a new account and profile on Basecamp, Highrise, Backpack, and Campfire. Mr. Default is a standard guy. He’s found everywhere on the web (in variations): message boards, comments, activity streams.

He forces everyone to look like him regardless of gender, race, and physicality. He’s also very boring.

Time for a change

People don’t usually have a picture on hand to change the default avatar. What happens is none of the default pictures ever get changed. Basecamp looks boring when everyone is Mr. Default. Splashes of color and personality from peoples’ pictures bring life to a product.

We want your first experience with Basecamp Next to be colorful, welcoming, and friendly. First, we’ve improved the flow for replacing the default avatar. Additionally, we’ve improved the default profile pictures. Say goodbye to Mr. Default.

Literal Icons

Initially I thought about approaching the pictures like the game Monopoly. Everyone has a different icon much like the pieces in that board game: an iron, a thimble, a race car, etc. Here are some sketches from that session.

I had been experimenting with a painterly style for a different project, so I tried that with this literal icon imagery.

Jason Fried’s feedback: Having literal and distinct icons might cause people to want to switch one out with another, or not find a suitable match. Would we need to build an interface to “choose your default icon”? Too complicated. Maybe we should go abstract.

37signals Office Surface Textures

Another idea I had was to try our office surface textures. The 37signals office is made of so many great materials. Basecamp is basically our office. Perhaps it was worth a try.

Jason Fried’s feedback: We want people to see Basecamp as theirs not ours. This isn’t about 37signals. Who wants to be represented by cork? Also the imagery feels too masculine. Let’s go softer and more cheerful.

Abstract Paintings

I liked the painterly style of the first batch of icons. They were colorful and cheerful. What if I tried some abstract shapes and patterns?

Jason Fried’s feedback: These are closer. The patterns might be too distracting. Try shapes and lines like that one on the upper left.

Refining the Abstract Paintings

Concentrating on shapes instead of patterns was a big breakthrough. The shapes started to take on face-like features.

Jason Fried’s feedback: Loving these. These are great!

Jason Zimdars’ feedback: When I see these I think of cars. The headlights and grill make a face. I wonder how they’d look with a slight smile?

I’m very happy with the way these default profile pictures turned out. When someone creates a new Basecamp account they will be randomly assigned one of these custom painted pictures. As you’d expect, each picture can be easily swapped with their own personal photo.

The difference now is straight away, out of the box, Basecamp will have color, personality, and vibrancy as you start managing and completing your projects.

“If a customer asked you why, how would you answer?” This is a question I’ve been asking a lot lately. Why could be “why does it work this way?” or “why can’t I do that?” or some variation on that theme.

I think your answer to those questions is a great way to measure your product. Are you happy with your answers? Are they fair answers? Are they clear answers? Would you be happy with the answer if you were the one asking the question?

The goal isn’t to get to “Yes” on every answer. The goal is to listen to your answer and ask yourself what it really means about how you approach product development.

If the answer is something like “well, because it was too hard for us to make it work the way it should” or “because we couldn’t figure it out” or “because we didn’t spend the time to think about the problem thoroughly enough” or “we just didn’t feel like putting in the work to make this easy for you” it may be a red flag.

Now, sometimes those are just truthful answers. Every decision involves a sacrifice. You may have had to sacrifice some thoroughness here so you could be more thorough there. But when answers like that pile up it’s worth looking yourself in the mirror and ask why you’re satisfied with answers like that.

This approach is especially helpful during product development, prior to launch, when many things are still in flux. This is the moment when you should be asking these questions repeatedly. The more you ask, the more you have to consider, and ultimately the better decisions you’ll end up making.

It goes without saying that we use Rails a lot here at 37signals. Often times, when we look at a problem, we turn to Rails or something similar, because when you have a high-performance precision screwdriver, everything starts to look like a finely engineered screw. Sometimes, what you really need is a big hammer, because what you’re looking at is a nail.

Our public sites – sites like 37signals.com and basecamphq.com – are a perfect example of this.

Let me tell you about our journey with these sites over the years, and how we’ve landed on a simple solution that boosted conversion rate by about 5%.

Good enough

There’s nothing particularly dynamic about these sites; we might throw a “Happy Monday” in there, or we might make some tweaks based on a URL parameter, and we A/B test them extensively, but there’s no database or background services involved.

Stretching back to the pre-Basecamp days, the 37signals.com site was written with PHP. There was no Rails back then, Ruby wasn’t commonly used for web development, and DHH and others worked in PHP, so it was the logical choice. As we added sites, they continued to use PHP since it was fast and easy. This worked well for years and years—our public sites were relatively performant and rock-stable, and we didn’t really have many problems. The biggest pain was in setting up for local development, which ended up being quite the pain to get set up in OS X in a way that behaved well with Pow, Passenger, etc.

Getting better

A few years ago, Sam Stephenson and Josh Peek wrote Brochure as a way to translate our marketing sites to Rack apps. This solved the local development challenges, and let us use a language we were all generally more comfortable with. It was a little slower than PHP, and meant dealing with Passenger on deployment, but it was a fair compromise at the time. We moved one site to brochure, and then ran out of steam to move the rest – work on our applications took a higher priority.

A few months ago I took a serious look at our public sites’ performance. They were making a lot of requests for individual assets and page load times were pretty poor – Basecamp itself loaded much faster than the essentially static signup page for it. Local setup problems with the PHP sites also meant that it was harder to work on the sites, and so we were less productive and less inclined to work on them.

Back to the basics for fun and profit

Our solution to this (in addition to spriting images and cleaning up unused styles and Javascript) was to switch to using totally static HTML pages. We’re using the stasis gem to compile .html.erb files locally and on deploy, along with Sprockets to pre-process and concatenate stylesheets and Javascript. Our web server ends up serving plain old HTML and a single CSS and Javascript file, with no interpretation.

This makes local development easy, and what you see locally is always what will be deployed. This also makes it trivial to distribute the marketing site to multiple datacenters or distribution networks around the world—just upload the compiled files, rather than worrying about dependencies for running an interpreted site.

While we haven’t done that yet, just from some mild spriting and cleanup and moving to static HTML, we shaved about half a second off the total load time for basecamphq.com, and saw about a 5% improvement in conversion rate result from that (the link between page speed and conversion rate has been studied more rigorously as well by the likes of Google, Amazon, etc.).

Basecamp just turned 8 years old. Here’s the launch announcement right here on this blog back on February 5, 2004. That’s a long time ago.

We’ve learned a ton since then. One of the most interesting lessons has been the increasing degree to which time influences change.

When we first launched Basecamp, we could iterate rapidly. We were incredibly prolific those first few months. We launched a bunch of new stuff and made rapid improvement every few weeks. Eventually it plateaued and slowed down.

Why is that? Part of it is because many of the improvements we wanted to make have been made. Part of it is that we want to keep Basecamp focused on just a few things. Part of it is that the code base gets more and more tangled over time which makes change more difficult. Part of it is that we’ve also been working on other things.

But that’s nothing new. Those concerns have been part of software development since the start.

What’s new with SaaS (Software as a Service) products like Basecamp is that legacy doesn’t just build up in the code base, it builds up in customer expectations. People get used to the way things are. Even things that are broken or complicated become things some customers want to protect from change because they’re familiar with the intricacies of how those things work.

In the traditional software world, new releases were bundled up into distinct versions. And it was up to the customer if they wanted to upgrade or not. If they didn’t like the opinions of the new version, they could stick with the old, familiar version. If the new version didn’t solve any new problems they had, they could keep using the version they already had.

Not so with SaaS. When updates are deployed, they’re deployed instantly for everyone. That’s not always the case – sometimes you phase in a release – but for the most part the end game is the same: This is new and it’s making its way into the product. This means customers often don’t get the chance to opt out of changes in the SaaS world.

All of this is managable for companies and customers as long as the changes are incremental and somewhat predictable. And the younger customer base the easier it is to manage. But every once in a while a company has brand new opinions about a problem they’ve already solved before.

What then? Do you totally change the existing product to fit the new opinions? What about all the customers who are used to the way things currently work? They’re going to be upset. They’re going to feel forced and bullied into something brand new they didn’t ask for and can’t ignore. No one wants to feel like that. It’s often a recipe for a lot of turbulence.

This is why change gets really hard as a SaaS product matures. Existing customer expectations are some of the strongest forces pushing back at a company with new ideas.

This is the situation we found ourselves in with Basecamp last year. We had all new ideas about how to manage, organize, collaborate, and run projects. While some of the fundamental tools were the same, the application of these tools, the way in which they interacted, and the entire execution was different. Making the current Basecamp work the way we wanted the new Basecamp to work wasn’t possible without completely forcing huge change on people who didn’t ask for it. That wouldn’t fly.

I think there’s only one fair way to introduce significant change like this: Let people choose change. I don’t think people are afraid of change, as a concept. They’re afraid of change that’s forced upon them. That isn’t change, it’s violence. And violence is never customer friendly. Just about every time I’ve seen a big transition go wrong in this business it’s been because customers were forced to change, not offered the option to change.

This is why we decided to do the right thing. Design, develop, and launch an entirely new version of Basecamp along side the existing version of Basecamp. The new Basecamp is entirely opt-in. You can even use both at the same time, if you’d like. But if you prefer not to change, you won’t be forced to change. If the current Basecamp works well for you, you can continue to use the current Basecamp for as long as you’d like.

We’ve put in an extra months worth of work to make sure the optional transition is as smooth as possible. We’re excited to share Basecamp Next with everyone soon.

I’m from Ohio. I’m proud to work in Michigan for ROUSH CleanTech. But, I’m from Ohio. When I heard the news that Government Fleet named the City of Columbus the “2011 Government Green Fleet in North America,” I was excited. (I’m also thrilled about the awesome recruiting class Ohio State has going for the next [...]

Over the recent holidays, I heard a friend say, “The cost of gasoline sure has dropped. I filled up for less than $50 today.” As he was saying that, tensions with Iran were on the rise. And, little did he know, his next fill-up would be more expensive, and the one after that even higher, [...]

I recently delivered a keynote speech regarding the development of alternative fuel technology; however, this time I pursued a different angle with my message. The “green/clean” energy message is crisp and clear to everyone willing to listen. I decided we needed to peel the layers back a little further and identify other benefits of deploying [...]