Jobs: |
See more on our Job Board. |
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.
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.
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.
Continued…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:
Continued…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:
Continued…When we started thinking about the design of the all new Basecamp, we had three key things in mind:
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…
Continued…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?
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.
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.
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.
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.
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.
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%.
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.
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.
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 recently read and watched “Moneyball”, and enjoyed both greatly. It’s a great story in and of itself, but I also found it to be an interesting parallel to the state of the “web software” industry today.
Moneyball starts in the week before the 2002 baseball draft, with a set of meetings that pit Oakland A’s general manager Billy Beane against his team of scouts. The scouts’ primary mechanism of evaluating players was visual – did the guy look, walk, and talk like a major league baseball player? On the other hand, Billy, with his assistant Paul DePodesta, had a largely objective system for evaluating baseball players based on things like how often they got on base.
Billy won the fight over talent selection and picked players that met his system, even if his scouts disagreed. This pattern continued throughout the season, and the A’s went on to set a league record for consecutive wins.
When I started writing I thought if I proved X was a stupid thing to do people would stop doing X. I was wrong.
—Bill James in his 1984 Baseball Abstract
In many ways, the “web software” industry is still where these scouts are. For most people, the primary way of evaluating their software is with their own eyes and emotions. Over the years, people have tried to bring some objectivity or framework to do thing this with things like “personas”, but the process is still a largely subjective one, just like a scout looking at how a player swings and never really looking at whether he gets on base.
The reality, of course, is that this is no longer necessary. Just like baseball in the years since Bill James coined “sabermetrics”, we have the tools now as an industry to do better. We can identify the outcomes we want to see, and we can objectively evaluate a design in the context of those outcomes.
It’s never been easier to test your designs and find out what works where the rubber meets the road. You can use a tool like Optimizely for any site or something like A/Bingo in a Rails app and have a test running in a matter of minutes. Measuring and understanding behavior in other ways has also never been easier—there are new tools and startups helping to do this every week.
For Billy Beane and the Oakland A’s, using data was about leveling the playing field between their meager salary budget and the huge budget of teams in places like New York and Boston. For the web industry, the playing field is already fairly level – it doesn’t take much more than a web browser and a text editor to build something. What data does for web software is reduce the role that blind luck plays. You’re more likely to – on average – find success if you evaluate your work using real data about the outcomes that matter.
You can choose to keep working like those scouts did and go on gut instinct alone. It might work for a while, but I think most people would say that baseball’s moving forward now, and the people who haven’t made the switch are being left behind. Our industry will move forward too—do you want to be left behind?
We’re seven members strong now and we’re able to add a lot of things our customers have been seeking. The bigger team also lets each of us work on support projects other than answering emails lightning fast. Since our sysops, developers and designers have been rightly bragging about the great things they’re doing, I thought I’d take the opportunity to tell you about what our amazing team has been doing to improve customer happiness.
Basecamp 101
The mere whisper of the word ‘webinar’ used to make my blood run cold. The library and academic worlds (my old stomping grounds) are lousy with them. I found them to be time sinks where people who didn’t have a full grasp of a topic held their attendees virtually hostage as we endured technical difficulties and dry Powerpoint presentations. My bias came with me when I got to 37signals, so I was surprised to see the number of customers who really wanted a webinar.
After a bit of research in the Fall, Merissa and Chase started a “Basecamp 101” online class that now runs almost every week. I have to say, it’s really terrific. If other webinars had butts, Chase and Merissa’s would be kicking them. Their class is fun and it gives space for potential customers to ask questions of Merissa, Chase and Michael at the end.
It’s exciting tell our customers that we can offer them a demonstration of setting up a project before they even sign up for Basecamp. If you want to check it out sometime, the next one is always listed on our Help page.
Help Videos
There’s plenty of research demonstrating different learning styles, and the support team can definitely attest to the fact that not everyone learns best by reading help documentation. We have some pretty great help pages, but sometimes words and screenshots can’t do justice to some of the features and functions of Basecamp or Highrise. Chase made it his mission to create some really great screencasts for many of our frequently asked questions. You can see the ones he’s created for Basecamp and Highrise. They’ve been a great asset for the support team and have helped our customers in a big way.
Live Chat
Through the Summer and Fall of 2011, we ran live help chat (thanks to our pals at Olark) on highrisehq.com to assist potential customers who had a few questions before signing up for a plan. The whole support team spent a few hours on live chat each day and we noticed that a lot of current customers were using the service to get help. We decided to give it a shot in Basecamp accounts as a premium support feature.
If you’re an admin on a Max Basecamp plan or any Suite, you’ll see this friendly little box at the bottom of your Basecamp dashboard:

Of course, we did endure some “Who the heck is this?”s and “Are you a robot?”s the first few weeks, but we’re almost two months into offering the feature and it’s been a great experience. The team can answer questions faster and it’s a true pleasure to interact with our customers in a new way.
Faster Common Requests
Resident support whiz kid Ann is not just great at helping us answer support questions, she’s also quite handy with the console as well. Every day we see some common requests that involve some On Call programmer work and Ann’s been taking on a lot of the common tasks that we used to send to the programming team, including things like:
It’s been a huge load off our On Call team and it helps us take care of our customers much faster than they expect.
These are all things we’ve been able to add to support in the past five months, and Basecamp Next isn’t even out yet. I don’t know about you, but I’m excited to see what the rest of 2012 holds.
Boney Money Brown.
It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.
Chrome ushered in a new era of the always updating browser and it’s been a monumental success. For Basecamp, just over 40% of our users are on Chrome and 97% of them are spread across three very recent versions: 16.0.912.75, 16.0.912.63, and 16.0.912.77. I doubt that many Chrome users even know what version they’re on — they just know that they’re always up to date.
Firefox has followed Chrome into the auto-updating world and only a small slice of users are still sitting on old versions. For Basecamp, a third of our users are on Firefox: 55% on version 9, 25% on version 8. The key trouble area is the 5% still sitting on version 3.6. But if you take 5% of a third, just over 1% of our users are on Firefox 3.6.
Safari is the third biggest browser for Basecamp with a 13% slice and nearly all of them are on some version of 534.x or 533.x. So that’s a pretty easy baseline as well.
Finally we have Internet Explorer: The favorite punching bag of web developers everywhere and for a very good reason. IE represents just 11% of our users on Basecamp, but the split across versions is large and depressing. 9% of our IE users are running IE7 — a browser that’s more than five years old! 54% are running IE8, which is about three years old. But at least 36% are running a modern browser in IE9.
7% of Basecamp users on undesirables
In summary, we have ~1% of users on an undesirable version of Firefox and about 6% on an undesirable version of IE. So that’s a total of 7% of current Basecamp users on undesirable browser versions that take considerable additional effort to support (effort that then does not go into feature development or other productive areas).
So we’ve decided to raise the browser bar for Basecamp Next and focus only on supporting Chrome 7+, Firefox 4+, Safari 4+, and, most crucially, Internet Explorer 9+. Meaning that the 7% of current Basecamp users who are still on a really old browser will have to upgrade in order to use Basecamp Next.
This is similar to what we did in 2005, when we phased out support for IE5 while it still had a 7% slice of our users. Or as in 2008, when we killed support for IE6 while that browser was enjoing closer to 8% of our users.
We know it’s not always easy to upgrade your browser (or force an upgrade on a client), but we believe it’s necessary to offer the best Basecamp we can possibly make. In addition, we’re not going to move the requirements on Basecamp Classic, so that’ll continue to work for people who are unable to use a modern browser.
Basecamp Next, however, will greet users of old browsers with this:
We send a lot of mail for Basecamp, Highrise, Backpack, and Campfire (and some for Sortfolio, the Jobs Board, Writeboard, and Tadalist). One of the most frequently asked questions we get is about how we handle mail delivery and ensure that emails are making it to people’s inboxes.
First, some numbers to give a little context to what we mean by “a lot” of email. In the last 7 days, we’ve sent just shy of 16 million emails, with approximately 99.3% of them being accepted by the remote mail server.
Email delivery rate is a little bit of a tough thing to benchmark, but by most accounts we’re doing pretty well at those rates (for comparison, the tiny fraction of email that we use a third party for has had between a 96.9% and 98.6% delivery rate for our most recent mailings).
We send almost all of our outgoing email from our own servers in our data center located just outside of Chicago. We use Campaign Monitor for our mailing lists, but all of the email that’s generated by our applications is sent from our own servers.
We run three mail-relay servers running Postfix that take mail from our application and jobs servers and queue it for delivery to tens of thousands of remote mail servers, sending from about 15 unique IP addresses.
We have developed some instrumentation so we can monitor how we are doing on getting messages to our users’ inbox. Our applications tag each outgoing message with a unique header with a hashed value that gets recorded by the application before the message is sent.
To gather delivery information, we run a script that tails the Postfix logs and extracts the delivery time and status for each piece of mail, including any error message received from the receiving mail server, and links it back to the hash the application stored. We store this information for 30 days so that our fantastic support team is able to help customers track down why they may not have received an email.
We also send these statistics to our statsd server so they can be reported through our metrics dashboard. This “live” and historical information can then be used by our operations team to check how we’re doing on aggregate mail delivery for each application.
Over the last few years, at least a dozen services that specialize in sending email have popped up, ranging from the bare-bones to the full-service. Despite all these “email as a service” startups we’ve kept our mail delivery in-house, for a couple of reasons:
Given all this, why should we pay someone tens of thousands of dollars to do it? We shouldn’t, and we don’t.
Read more about how we keep delivery rates high after the jump…
Continued…As we announced at the beginning of the month, we’re always on a mission to improve our uptime. Inaccessible apps are the cause of much frustration and users don’t care whether that’s because they’re scheduled or not.
While publishing our own uptimes have been a great step towards getting everyone in the company focused on improving, we also wanted to compare ourselves to others in the industry. So since December 16, we’ve been tracking five other applications through Pingdom to compare and contrast.
The goal is to have the least amount of downtime and here are the results from the period December 16 to January 31:
Congratulations to Github for the number one spot on the list. We are definitely going to be gunning for them! We’ll publish another edition of this list in a month or so.
Today Matt Kent started at 37signals as the sixth member of our operations team. Previously Matt worked for 10 years(!) at Bravenet as a System Administrator handling application deployment and scaling tasks. Some of Matt’s managers and coworkers used phrases like “backbone of our team” and “a great person, and a fantastic engineer” to describe what working with Matt is like.
Recently Matt was selected as an Opscode MVP for his contributions to Chef not once, not twice, but three times. Less than a day after Matt’s first interview, he resolved both our Chef bug reports endearing him to the entire team. In addition, Matt has experience with multiple data center setups, automated deployment, monitoring, and just about every other area we touch.
Welcome Matt!
When I did all the programming for the original version of Basecamp back in 2003, we ended up shipping with just about 2,000 lines of code. A lot has happened in those eight years and we’ve acquired a more delicate taste of just how beautiful we want the basics executed.
This means significantly more code. Here are the stats from running “rake stats” on the Rails project:
On top of that we have just over 5,000 lines of CoffeeScript — almost as much as Ruby! This CoffeeScript compiles to about twice the lines of JavaScript.
Basecamp Next is running Rails 3.2-stable and we’ve got a good splash of client-side MVC in the few areas where that makes sense through Backbone.js and various tailor-made setups.
Got any questions about our stack or code base? Post them in the comments and we’ll fill you in.
REWORK
The new business book from 37signals shows you how to build, run, and grow (or not grow) a business.
Getting Real
The smarter, faster, easier way to build a successful web application. 171 page PDF ($19) or paperback ($25). Buy it now.
Basecamp project management
Everyone's favorite web-based project management tool. Easy, fast, elegant. Free trial.
Highrise simple CRM
Keep track of who your business talks to, what was said, and what to do next. Free trial.
Campfire group business chat
Simple and easy web-based group chat for business has finally arrived. Try it free today.
Backpack information manager
Gather your ideas, to-dos, notes, photos & files online. Set email and mobile reminders. Try free!
Writeboard collaborative writing
Write, share, revise, compare. Sharable web-based text documents with simple version control.
Ta-da List, to-do list manager
The web's simplest, fastest, and most useful to-do list manager. Get things done. Free, 10 second signup.
Ruby on Rails
For developers we present our powerful yet simple open-source web application framework. Make coding easier on yourself.
