You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !

Recent jobs posted to the 37signals Job Board: Facebook, Netflix, Happy Cog, Joost, Yelp

Basecamp
Basecamp wrote this on 1 comment

Design Jobs
Facebook is looking for a Product Designer in Palo Alto, CA.

Six Apart, Inc. is looking for a Web Designer in New York.

Netflix is looking for an Information Architect in Los Gatos, CA.

Happy Cog is looking for a Web Designer in Philadelphia, PA.

Clinton Global Initiative is looking for a Web Producer (New Media Specialist) in New York.

TripIt is looking for a Visual Designer in San Francisco, CA.

Brainbox is looking for a Senior UI Designer anywhere in the USA.

The Mechanical Zoo is looking for a Senior User Interaction Designer in San Francisco, CA.

Programming Jobs
Joost is looking for a Flash ActionScript Programmer in New York.

Zivity is looking for a Javascript Application Developer in San Francisco, CA.

Creative Circle is looking for a Ruby on Rails Developer in Chicago, IL.

Yelp is looking for a Software Engineer in San Francisco, CA.

Avid Life Media is looking for a Senior Web Developer in Toronto, Ontario.

Prosper, Inc. is looking for a Senior Marketing Web Developer in SProvo, UT.

Ideate.com is looking for an Experienced Web Services Developer located anywhere.

Click Harmonics is looking for a Rails Developer in Boston, MA.

More Jobs
View all of the Design Jobs and Programming Jobs at the 37signals Job Board. The Gig Board is the place to find contract jobs.

Lesson from The Flip: Do less and you get to print less

Matt Linderman
Matt Linderman wrote this on 20 comments

One more thing that’s cool about underdoing the competition: You get to streamline your documentation.

For example, this Sony Handycam manual (PDF) has 40 pages. Compare that to the quickstart guide that comes with a Flip camera:

flip_quickstart.png Click for larger version.

Wow, an instruction manual that actually gets read. Impressive. In fact, it’s almost like the instruction manual is an ad for the product. “It’s so simple this is all we have to say about it.” And I bet there’s a lot less support documentation needed too.

Related: The Flip takes 13% of the camcorder market by doing less [SvN]

New in Backpack: Customize your color scheme

Ryan
Ryan wrote this on 18 comments

We just released a really great update to Backpack. Now you can completely customize your color scheme! Whether you want to personalize your individual account or brand your business account, this feature is a lot of fun.

You can set your own colors for the header, the links in the header, the sidebar, and also the general link color. The color customizer uses the same beautiful picker we released for Basecamp last year. And you can preview each color choice live, so you can be sure each color fits perfectly with the rest.

To customize your color scheme, just click the “Settings” link. Once you’re there you’ll also find a new selection of preset color schemes (by our designer Jamie) to give you inspiration. Thanks for your continued support and enjoy customizing your colors in Backpack!

Why you shouldn't copy us or anyone else

Jason Fried
Jason Fried wrote this on 48 comments

The hot article of the day is Why Your Startup Shouldn’t Copy 37signals or Fog Creek over at OnStartups.com.

I agree. And I’m sure Joel Spolsky agrees too. I think this comment on Hacker News nails it too.

Here’s the problem with copying: Copying skips understanding. Understanding is how you grow. You have to understand why something works or why something is how it is. When you copy it, you miss that. You just repurpose the last layer instead of understanding all the layers underneath.

The article is referring to ideas and business models, but I think interface design is an example more people can relate to. Have you seen an interface that was obviously copied from someone else’s interface? The copy usually lacks depth and detail. They miss the spacing, the proportions, the relationship between colors and objects and buttons and links. It’s usually pretty close, but there’s something not right about it.

Why? Shouldn’t copying something be easier than creating it? Someone else already did the work, right? The problem is that the work on the original is invisible. The copier doesn’t know why it looks the way it looks or feels the way it feels or reads the way it reads. The copied interface is a faux finish.

This is why future iterations of a copied interface begin to break down quickly. The copiers don’t understand where to take it next because they don’t understand the original intention. They don’t know the original moves so they don’t understand the next move.

Look around at interfaces that were clearly copied from someone else’s UI and you’ll find a lot of inconsistencies and sore thumbs. That’s the new stuff.

While I’ve been using interface design as an example, the original article was more about business models. I think copying leads to a lack of understanding there as well. Be influenced by many, copy none.

So bottom line: Copying hurts you. You miss out on what makes something good. Instead, try to be exposed to a variety of perspectives and points of view. Take whatever you find useful and leave the rest behind. Fill in the gaps with your own ideas. In the end you have make your own way forward.

Axl vs. Frank: More time doesn't mean a better product

Matt Linderman
Matt Linderman wrote this on 44 comments

Commonly held notion: “The longer I work on this, the better it will be.” Maybe up to a point. But after a while — and it might be just a short while — you’re being overly fussy.

There’s an optimal release point for anything you make. That’s when you should get it out there. After that, you’re just fiddling for the sake of fiddling. And you might even make it worse. Sometimes what you make will be just fine if it’s released after three months — but add another six months (or longer) and it turns into a jumbled, complex mess.

Case in point: “Chinese Democracy,” the Guns N’ Roses album that Axl Rose worked on for over a decade, going through at least three recording studios and four producers. Everyone knew that it wasn’t getting better with more time. In fact, it became a running joke in the music industry. It was just a sandbox for a control freak who couldn’t let go.

Frank Sinatra, on the other hand, was known as “one take Frank.” He’d walk into the studio, sing a song live with a full band, turn around, and walk out. Quincy Jones produced Sinatra and described recording an album with him:

He came in at 2 p.m., and in less than two hours we had rehearsed, had keys and routines on ten songs…Frank is one take, that’s it. If the band’s not in shape, he leaves them behind…he came in at 7, and at 8:20, baby, we went home. None of that three month stuff.

U2 singer Bono always respected Sinatra for that approach too:

It’s all about the moment, a fresh canvas and never overworking the paint. I wonder what [Sinatra] would have thought of the time it’s taken me and my bandmates to finish albums, he with his famous impatience for directors, producers — anyone, really — fussing about. I’m sure he’s right. Fully inhabiting the moment during that tiny dot of time after you’ve pressed “record” is what makes it eternal.

frankSinatra’s one take style produced classics. Axl’s dithering produced a pile of mush. We can all learn something from that. It’s easy to fall into a trap of nitpicking over things that don’t really matter. Instead, focus on the essence of what you’re doing. Press record, get it done, and get it out there. (And that’s even more true if what you’re creating is something you’ll get to improve upon after it’s released.)

Really nice screencast from Krop. Good flow, moves quick, and interesting how they include the signup process too.

Matt Linderman on Feb 5 2009 25 comments

JavaScript makes relative times compatible with caching

David
David wrote this on 49 comments

It’s easy to think that the relative-time style of “this comment was written 15 minutes ago” is incompatible with caching. How are you supposed to cache something if the text changes every minute? Static pages with JavaScripts, that’s how!

I put together a new mini app for our new status site yesterday that needed exactly this technique. I wanted the content of the application to be entirely page cached, so it would withstand the onslaught if the terrible should happen and we need to redirect all trafic to the status site.

I also wanted the relative time style, especially since it’s timezone independent and you don’t want people to think you’ve been down for two hours when it’s really only been twenty minutes because they did the timezone conversion wrong.

It looks like this:

37signals status site screenshot

To make this trick work, I embed the time stamp for a given entry in the DOM as a custom attribute that I can query for conversion like this:

<li>
  <span time="Feb 05, 2009 15:30:00 GMT">09:30 AM CST (15:30 GMT)</span> /
  The aliens came out of no where and took Basecamp!
  We're trying to hunt them down now. Stay tuned while we bring the lasers online.
</li>

I only want to convert the entries from today into relative time. The entries from yesterday and before should just use the specific time-only style. This means looking for just the span’s inside li’s from the ul with the class “today”. They’re then converted when the document is loaded with this function:

convert_all_times_from_today_to_words: function() {
  $$('.today li span').each(function(e) {
    e.innerHTML = this.time_ago_in_words_with_parsing(e.getAttribute('time'));
  }, this);
}

The function uses a simple DateHelper JavaScript class that mimicks the DateHelper in Rails.

This technique can be used for things other than just dates. You could imagine a cached page where you wanted the name “David Heinemeier Hansson” replaced with the text “You” if there was a match.

It’s a great way around otherwise cache-busting requirements.

Happy Birthday - Basecamp Turns Five!

Jason Fried
Jason Fried wrote this on 209 comments

Today is a very significant day in the life of 37signals and Basecamp (and, indirectly, Ruby on Rails). Today Basecamp turns five years old.

We launched Basecamp with a post right here on Signal vs. Noise on February 4, 2004. No traditional PR blitz, no advertising, no real expectations of big success. Just a product and a post and “let’s see what happens.”

Basecamp was a side project. We were a web design firm at the time. We built Basecamp because our projects and client communications were a mess. We were using email to update our clients. That works for about 5 minutes, then goes from ripe to rotten pretty quicky.

We looked around at some of the industry standard project management tools at the time. The leader was Microsoft Project. We didn’t get it. Projects aren’t about charts, graphs, stats, and reports. Projects aren’t broadcasts. Projects are about people and communication and collaboration. Projects are about back-and-forth, give and take.

Collaboration, not management

We also didn’t really like the idea of “management.” Management is hard work. Management is administrative. Management gets in the way. Collaboration better described what we were after.

So after experimenting with a manually updated blog-like project site, we decided to build our own tool. At the time, 37signals was just myself, Matt, and Ryan. Three designers. We weren’t programmers, so I hired a student from Denmark who I met over the web to write the code. I’d hired this guy before to write some PHP for a client project. I was happy with his work. We saw things the same way. This guy was was David Heinemeier Hansson. You know the rest of that story.

Continued…