Signal vs. Noise

QUOTE: There is actually a useful tool inside Wolfram

Ryan — Thu, 09 Jul 2009 15:53:00 +0000

There is actually a useful tool inside Wolfram Alpha, which hopefully will be exposed someday. Unfortunately, this would require Stephen Wolfram to amputate what he thinks is the beautiful part of the system, and leave what he thinks is the boring part.

—Wolfram Alpha and hubristic user interfaces. There’s a ton of gold in this article including the pitfalls of natural language input, the differences between predictable and unpredictable search results, and an insightful take on the “demo illusion” that can blind designer-developers to faults in their own UI.

VIDEO: Jason's talk at Big Omaha 2009

37signals — Wed, 08 Jul 2009 16:10:00 +0000

Jason’s talk at Big Omaha 2009

The end of the edge case

Jason — Tue, 07 Jul 2009 23:30:00 +0000

An interesting thing happens when your customer base reaches a certain size: You cease having edge cases. I think we’ve probably been at that point for a good year now – maybe longer – but we’ve really felt it recently.

Mistakes, bugs, incompatibilities, and related issues that used to affect a handful now affect hundreds. 1% is a real number now.

This requires some organizational change. More caution, more testing, more contingency planning, more disaster planning. These are good things in one direction and frustrating things in another. Regardless, they’re real and here to stay.

It’s a healthy reminder that companies can change, policies can change, techniques can change, perspectives can change. This change can come quick or take many years, but it’s usually already happened before you really notice it. It’s your job to catch up with it. What once worked before may not work again just as what didn’t work before may work now.

Personally, I’m finding it invigorating. It’s a new challenge for us as we continue to grow—people, revenues, exposure, influence, and responsibility.

As we approach our 10th anniversary, I’m reminded of what we’ve always known to be true: simpler is better, clarity is king, complexity is often man-made, and doing the right thing is the right way to do things.

At-home good should trump in-store sizzle

Matt — Tue, 07 Jul 2009 16:17:00 +0000

In-store good or at-home good? is a post from a while back here at SvN. Here’s an updated take on the subject…

You know what it feels like. You go to a store. You’re comparing a few different products and you’re sold on the one that sounds like it’s the best deal. It’s got the most features. It looks the coolest. The packaging is great. There’s sensational copy on the box. Everything seems great.

But then you get it home and it doesn’t deliver. It’s not as easy to use as you thought it’d be. It has too many features you don’t need. You end up feeling like you’ve been taken. You didn’t really get what you needed. And you realize you spent too much.

You just bought an in-store good product. That’s a product you’re more excited about at the store than you are after you’ve actually used it.

Smart companies make the opposite: something that’s at-home good. At-home good is when you get a product home and you’re actually more impressed with it than you were at the store. You live with an at-home product and grow to like it more and more. And you tell your friends too.

When you create an at-home good product, you may have to sacrifice a bit of in-store sizzle. A product that executes on the basics beautifully may not seem as sexy as competitors loaded with bells and whistles. Being great at a few things often doesn’t look all that flashy from afar. That’s ok. You’re aiming for a long-term relationship, not a one-night stand.

This isn’t just about in-store packaging or displays. It’s true for advertising too. We’ve all seen the TV ad for some “revolutionary” gadget that will change your life. But when the actual product arrives in the mail, it turns out to be a disappointment. In-media good isn’t nearly as important as at-home good. You can’t paint over a bad experience with good advertising/marketing.

Stop the politicians tagging our infrastructure

David — Mon, 06 Jul 2009 20:31:00 +0000

Graffiti is a problem in a lot of cities, but the tagging that annoys me most is that of American politicians. Take the Secretary of State for Illinois, Jesse White, as an example. I see his name everywhere and it’s making me crazy. He’s adorning my fucking driver’s license in a place more prominently featured than my own!

The website to deal with renewing license plates or anything driving is called “The Official Web site for Illinois Secretary of State Jesse White”. His HEAD is part of the logo! That just pisses me off to no end. If I ever get the right to vote in this country, the first thing I’ll do is vote for anyone but this self-promoting clown.

Stop worrying about spray cans and start worrying about the tagging of these renegade politicians. It’s much more costly to clean up their shenanigans.

QUOTE: C.E.O.’s with law or M.B.A. degrees do n

Matt — Mon, 06 Jul 2009 18:54:00 +0000

C.E.O.’s with law or M.B.A. degrees do not perform better than C.E.O.’s with college degrees. These traits do not correlate with salary or compensation packages. Nor do they correlate with fame and recognition. On the contrary, a study by Ulrike Malmendier and Geoffrey Tate found that C.E.O.’s get less effective as they become more famous and receive more awards…The C.E.O.’s that are most likely to succeed are humble, diffident, relentless and a bit unidimensional.

—In Praise of Dullness

Interview with Ryan Singer at ThinkVitamin

37signals — Mon, 06 Jul 2009 14:45:00 +0000

An interview with Ryan: Ryan Singer on UI design, Frontend Development, Project Management and Inspiration (ThinkVitamin.com).

As a designer, do you need to understand frontend development?

The more you understand about frontend development, the better designer you’ll be. If you are really familiar with handcoding and you understand basic HTML markup and you know how CSS selectors work then you’re really well prepared, for example, to use the fact that jQuery and Prototype both have a way to refer to pieces of your mark-up using CSS selectors even though your not using CSS.

If you’re designing web app user interfaces, then I think it’s important to get into understanding how an MVC framework works like Rails or Django. If you can understand how your templates fit in to the view, as the “V” in MVC then that’s a huge leap. You can really start doing work with programmers and you can have ideas and you can make them into reality instead of just making designs and handing them off to somebody and hoping that someone else can plug them in.

Read the full interview.

QUOTE: 'Rock Star' is perhaps the most abused phrase

Matt — Thu, 02 Jul 2009 21:02:00 +0000

‘Rock Star’ is perhaps the most abused phrase in the history of job listings. Nobody should be looking for a “rock star” accountant, HR recruiter or janitor. Whomever is posting these jobs is grossly misinformed as to the nature of rock stardom. Or accounting. Or both.

—AvoidThisJob.com on the differences between a Rock Star and a Planet Funk Store Manager

Product Blog update: New Basecamp features, Highrise/Harvest integration, etc.

37signals — Thu, 02 Jul 2009 15:18:00 +0000

Some recent posts at the 37signals Product Blog:

Basecamp
New File Uploading features in Basecamp
We’re excited to announce a batch of improvements to File Uploads in Basecamp. Now it’s easier to attach multiple files at once, we’ve improved our progress bar to show you as each file is uploaded, and you can click thumbnails to zoom image attachments without leaving the current page. These new features make it faster and easier to attach, review and discuss files in Basecamp. Here’s a demo video to show you all the improvements.

New Basecamp feature: The Daily Digest
We’re excited to announce a great improvement to Basecamp. The new Daily Digest feature makes it easier than ever to track the progress of your projects. The Daily Digest is an email that Basecamp sends you once a day. The email tells you about any to-do items or milestones that were checked off or added in the last day. Daily Digests are per-project, so you can subscribe to the projects you really care about without being distracted by any unnecessary information. Now you’ll always know day-by-day as work is completed or new work is assigned. It’s a really powerful feature.

Timy: “An easy-to-use desktop application to fill out your Basecamp timesheet”
Timy is “an easy-to-use desktop application to fill out your Basecamp timesheet.”

More...

Oldie But Goodie: Sketching with a Sharpie

Jason — Wed, 01 Jul 2009 14:16:00 +0000

I’ve always preferred sketching UIs with an as-thick-as-I-can-find Sharpie over a thin ballpoint pen or finely sharpened pencil.

Ballpoints and fine tips just don’t fill the page like a Sharpie does. Fine tips invite you to draw while Sharpies invite you to just to get your concepts out into big bold shapes and lines. When you sketch with a thin tip you tend to draw at a higher resolution and worry a bit too much about making things look good. Sharpies encourage you to ignore details early on.

If you sketch, try a thick Sharpie next time. You may find you’re better able to focus on the concept and less on the drawing. That’s a good thing.

Design Decisions: Results from the Basecamp account screen redesign

Jason — Tue, 30 Jun 2009 16:54:00 +0000

Just about two weeks ago we launched the a redesign of the account chart in Basecamp. This is where people can upgrade or downgrade their accounts.

The goal was to increase overall upgrade conversions and encourage people who are on Basic plans or lower to upgrade to the Plus plan (our lowest priced full-feature plan).

Results

I’m glad to report our design hunches appear to have paid off. We’re only about two weeks in, so we don’t have a ton of data yet, but we can compare the 14 days since the upgrade with the 90 days prior to the upgrade.

Average upgrades/day: up 13%
Average Plus upgrades/day: up 33%
Average $ value increase per upgrade: up 8%

We’re thrilled with these numbers. We’ve moved the new design to the Highrise account chart as well. We’ll watch and see if we see the same improvements with Highrise as we have with Basecamp.

Working at 37signals

JZ — Tue, 30 Jun 2009 15:54:00 +0000

It’s been several weeks since I was hired here at 37signals so I thought it might be interesting to share some of my experiences so far.

Ready, set, go!

One of the best things has been how quickly I’ve been able to jump in and start contributing. The very first project I worked on was a refresh of the Account screen in Basecamp. What started as an exercise quickly escalated to a new design that we wanted to actually put into the app. So it wasn’t long before I moved from Photoshop right into the app code to integrate the new design. This required me to build on my limited experience with Ruby on Rails, setup my computer for development, learn enough Git to be dangerous, and get a feel for application structure and conventions. None of this could have happened without the patience of my co-workers and the solid development structure/process that is in place here. Here are a few general observations:

The 37signals community is huge! Every change is noticed — sometimes within minutes of being launched. Receiving instant feedback to your work is great (at least so far :)
Git has been a surprisingly nice addition to my workflow. The ability to quickly switch branches and compare my version to the original has saved me countless hours
There are new things being added to the apps constantly. It’s exciting to see all of the new features and improvements every day. It can be hard to appreciate all of this activity from outside the company, but we’re working on that
No longer supporting Internet Explorer 6 is liberating!

In the first ten days or so I was able to design and implement a single screen redesign, get it deployed and write it all up at Signal vs. Noise. It’s pretty great to feel like you’re contributing and making a meaningful impact so quickly.

Working remotely

One of the biggest changes for me when joining the company was working 100% remotely. 37signals is based in Chicago, but half the team works outside the office — even the Chicago crew isn’t in the office every day. So it has been great to join a company that knows how to work with a widely distributed team. As you might assume, communication is the key to making the team effective and productive. Here are a few ways we stay connected:

Campfire

I have to admit that I didn’t get Campfire before I started working here. I’d been a long time user of Basecamp and Backpack, but Campfire never clicked for me despite a couple of attempts to bring it into a team workflow. What I was surprised to see is that Campfire might be the most important app that we use.

Our “All Talk” Campfire room is where the entire team gathers each day — we all stay logged-in anytime we are “at work”. Throughout the day we post questions, share screenshots, get feedback, collaborate on copy, and troubleshoot code. Campfire also talks to our apps so we get notifications when they are updated as we develop. It also serves as a way to quickly note to the team that you’re heading to lunch or will be away from the computer for a short time. But it’s not all business. We also find time to talk about the latest gadget/news/link/app/controversy and generally have a good time. Campfire is where all the typical conversations that happen in a physical office occur, but the difference here is that everyone can hear them, anyone can pay attention to what they want to, and it’s all archived so we can search through it later.

Campfire is also used along with instant messaging for the one-on-one and sidebar conversations when we want to chat, but stay out of the noise of the All Talk room. Jumping into our Small Talk room to work through a bit of code lets me work directly with a co-worker AND allows me to save a link to that conversation for future reference. This has been immeasurably helpful for me as I dig more into the tech side of our apps. Screen sharing via iChat is another great way a couple of us can quickly work together on a tricky bit of code.

In/out

Another key part of knowing and sharing what is going on with the comapny is with Backpack’s Journal screen. The journal lets everyone on the team set their current status (e.g., “Reviewing design comps”, or “Out to lunch”) and log the last few things that they have recently completed. There is no forced structure to it, we typically just update it a couple times a day as necessary. It’s a great way to get a quick snapshot of what is going on, who is working right now, and what they’re working on.

Of course we also follow project updates in Basecamp and keep an eye on external communications by checking into our Highrise account. Everything is out there for us to keep up with as we need to or want to.

Perfect balance

At 37signals I really feel more connected and current with what is going on than in any physical workplace I’ve been a part of. It is effortless to keep up with what my co-workers are doing and how what I’m doing contributes to the whole. I’m free to keep up with projects and learn new skills as they fit my interests. We collaborate how and when it makes sense, and stay away from each other when that’s the best way to work. That makes for a really effective working environment.

PHOTO: Elbo.ws puts a special message at the top

Matt — Tue, 30 Jun 2009 15:34:00 +0000

Elbo.ws puts a special message at the top of the page for visitors who wind up there via Google.

The risks Michael Jackson took on Thriller

Matt — Mon, 29 Jun 2009 15:02:00 +0000

In Artistic Value of Thriller [via JS], “Scorpeze” writes that many overlook Michael Jackson’s role as a songwriter and producer on his landmark albums and tend to overestimate Quincy Jones’ role. The post includes links to demos (Billie Jean, The Girl Is Mine) that MJ created for those records. Assuming they’re legit, it’s pretty amazing how close they are to the final product.

From a biz/marketing perspective, it’s also interesting to note how many risks MJ took on Thriller. There were so many things on there that people said you couldn’t do on a R&B record. But he did ‘em anyway and created the biggest selling album of all time.

people glaze over it now…but what soul/R&B figure could create a hit rock record that was embraced across the board…AND considered authentic by the rock audience?(the snobs may have been pissed off, but they werent the ones buying the records)…what soul/R&B cat was collaborating with Van Halen….and have it WORK?

it wasnt Prince….w/out Beat It, could you have a Let’s Go Crazy?

what other soul/R&B cat could get one of the Beatles on Black radio in the 80’s?

what soul/R&B cat would get Vincent Price to drop spoken word in the middle a funk/R&B cut cum horror movie?

who was else at the time was incorporating African chants and percussion at a time when everyone was whitening it up sonically(including MJ)…and who would reference Soul Makossa in the 80’s?

listen to the fact that a Black artist who was considered strictly soul/R&B decided to do a stylistic tour de force in one album when it hadnt been done before…

Thriller had: Funk straight R&B Quiet Storm MOR Pop Rock

…all in one album by a Black aritst when such a thing was not only unheard of but frowned upon…..

futhermore, on Thriller he spoke abt teen preganancy, gang violence, challenging the social constructs of manhood, the culture of gossip, emotional blackmail, obsession, false accusations of paternity, and belief in one’s self…

fluff?

these are ARTISTIC RISKS….they could have gone horribly awry, but they didnt….he did the record HIS way….and in a rare occurence that we will only see once in a lifetime, hit the bulls-eye and pleased EVERYBODY…the effects of that had both deep positive and negative effects on his work and the entire music industry after that….

Looking back, it all seems perfectly logical. It’s easy to forget how much of a singular vision it took to pull off that unique combo of ideas.

Design Decisions: Redesigning Basecamp's global milestone view

JZ — Fri, 26 Jun 2009 19:10:00 +0000

Yesterday we pushed an update to the Basecamp global milestone view. This is the calendar-style view of all milestones on all projects over the next 3 months. The goal was to make this screen cleaner and more useful.

The old milestone calendar looked like this:

It did a great job of effectively using the space with empty days that collapsed to a very small size. This made it easy to get a good quick view of the whole picture. But it was hard to dig-in further. You couldn’t tell which project each milestone belonged to or who was responsible for completing it. The pull-down at the top right did filter by person assigned, but even in that view it was hard to see which project the milestones applied to.

So, one of the first things we knew we wanted was to add the project name and person responsible for each milestone. Each milestone now shows both without adding a lot of visual clutter. We think this instantly makes this screen more useful, but wanted to explore more ways to make it better.

When we thought about how people use this screen it became clear that the empty days could be just as important as the days that have milestones. One reason to check this global view was to find the holes — the places where new milestones could fit.

So we explored sizing each calendar day to an equal width — much like a more traditional calendar. This had the added benefit of making the whole screen more understandable simply because it looks like a traditional calendar. It is more clear what you’re looking at and what you can do here. This is the revised look with equally-sized days and some small visual tweaks:

We added a subtle visual style for the days that fall on weekends to differentiate from weekdays. It then occurred to us that some businesses operate almost exclusively on a regular Monday–Friday schedule. For them it was a waste to have almost 30% of the available space each week used to show empty weekend days. So we brought back some of the table collapsing for weekends. If there are no milestones on any weekend day in the current view they simply shrink to a minimal width, allowing more space for the weekdays. However, if any weekend day has a milestone, then weekends become full-fledged citizens again. Here’s what it looks like when weekends aren’t being used:

One more thing…

While re-working the CSS for this particular screen, we noticed that we hadn’t defined any print styles. So we spent a little time adding some CSS to our print stylesheets for the global milestones calendar. Now when you print it will look something like this:

New Jobs on our Job Board: iPhone Developer Jobs, Apple, Trek, Wall Street On Demand, etc.

37signals — Fri, 26 Jun 2009 17:04:00 +0000

Here’s a sampling of available Design and Programming jobs.

iPhone Developer Jobs

Big in Japan, Inc. is looking for an iPhone Developer in Dallas, TX.
View all iPhone Developer Job listings

Design Jobs

Apple is looking for a Creative Director, Information Architecture in Cupertino, CA.
Rocket Matter, LLC is looking for a User Interface Designer / IA in Boca Raton, FL.
Harvest is looking for a Visual Designer in New York, NY.
Trek Bicycle is looking for a Visual Designer-Web in Waterloo, WI.
Southern Poverty Law Center is looking for a User Interface Designer/Developer in Montgomery, AL.
Engine Yard is looking for a Senior Interaction Designer in San Francisco, CA.
View all Design Job listings

Programming Jobs

Wall Street On Demand is looking for a Web Developer in Boulder, CO.
Kickball is looking for a Product Engineer in Palo Alto, CA.
Modernista! is looking for a CRM Supervisor in Boston, MA.
Cramer Production Business Trust is looking for a Technology Manager in Norwood, MA.
TutorSource is looking for a Software Developer (Ruby on Rails/OO/web) in Santa Monica, CA.
CivicPlus is looking for a .NET Software Developer in Topeka, KS.
View all Programmer Job listings

Are you hiring?

The 37signals Job Board attracts the cream of the crop because it’s featured prominently on five industry-leading sites: Signal vs. Noise, A List Apart, Kottke.org, Coudal.com, and the Ruby on Rails site. And not just anyone reads these sites. The people who build the best of the web read these sites. People who value beautiful design, beautiful code, high standards, and doing great work. The kind of people you want to hire. Post a job (or internship) and find the right person today.

The natural evolution from side project to full-time business

Matt — Thu, 25 Jun 2009 15:18:00 +0000

Some have doubted our advice that you should hold on to your day job and start something on the side. They argue building a business requires such persistent effort that you need to devote all your time to it to do it right.

And it’s true that building a business requires plenty of time and effort. But the idea that you need to quit your job to do it right is misguided. If you quit your job, you shift everything. You don’t gain time, you lose it. You put a shot clock on your business. You box yourself into a position where you have to profit immediately or the whole thing goes under. You’ve got to make it work now or give up forever.

Hanging on to your day job gives you a longer period of time to build your idea. It lets you give a sustained effort over time. There’s no get rich quick option. You build it slowly, one day at a time.

Yes, you need to find time to do both your side business and your normal gig. But there’s always enough time if you spend it right. Instead of watching TV or playing Grand Theft Auto, work on your idea. Instead of going to bed at 10, go to bed at 11. We’re not talking about all-nighters or 16 hour days – we’re talking about squeezing out a few extra hours a week. That’s enough time to get something going and then keep giving it gas.

Let your side business evolve into a full-time business naturally. Go for organic growth. Start as a side project. Build it slowly. Keep putting time into it. As pickup of your project grows, then you can justify devoting more resources to it. Eventually, if everything goes according to plan, you’ll be able to quit your job and devote all your time to it (if that’s what you want). But doing so right out of the gate is putting the cart before the horse.

Think how evolution happens in nature. There aren’t huge leaps. Things incrementally change. That’s the model to shoot for.

Nickel and diming

Jason — Wed, 24 Jun 2009 13:48:00 +0000

Over the years I’ve seen a lot of proposals from professional services firms. Designers, architects, lawyers, consultants, and others.

Many of them included a small price list at the end. Here’s one from a recent proposal I received from a landscape architect I’m considering hiring:

These nickel and dime items have always rubbed me the wrong way. I’m about to pay someone many thousands and they’re about to bill me $0.15 for a copy.

Plenty of people bitch about ATM fees, but these copy and print fees feel even more obscene to me. I recognize paper costs money and toner costs money and machines cost money, but come on – isn’t this just part of the cost of doing business? It feels like they’d charge for bandwidth used to email you a file if they were sophisticated enough to track it.

Further, many of these professional services get annoyed when their clients cut back budgets or say they can’t afford this or that. But then the professional services themselves pinch pennies even tighter by trying to pass the cost of a piece of paper on to their client. The disconnect couldn’t be more obvious.

I can’t recall if I’ve ever actually been billed for any of these items, but it just seems unnecessary. Perhaps they are worried about clients that require thousands of pages or hundreds of plots. If that’s the case, ok – how about saying “After 100 copies, we will bill $0.15/copy” or something like that. Absorb the routine costs and bill the excessive costs. That feels reasonable and respectful on both sides.

At the end of the day another $15 here or $36 there isn’t going to break a client’s bank, and complaining about $0.15 feels petty – and in some ways it is – but these nickel and dime fees put up a sign that says “we’re passing every little cost on to you, no matter how insignificant.” That just doesn’t seem like the right way to start a business relationship.

How we use Backpack to keep track of our email newsletters

Jason — Tue, 23 Jun 2009 18:32:00 +0000

This post kicks off a series of posts designed to share how we use our own products for our own business. It’s something we don’t talk that much about, but it’s something a lot of people have asked about. So here goes.

PROBLEM: We didn’t have a simple, accessible-company-wide list of email newsletters we’d sent out.

SOLUTION: Make a Backpack page.

We use Campaign Monitor to send out our email newsletters. While Campaign Monitor does keep a list of previous newsletters, it’s not convenient for everyone else at 37signals to log in and go through the overhead of another app just to see a list of previous newsletters. So we made a Backpack page instead. We’ve made the page public so you can see it for yourself.

Dead simple, one page, quick summaries of every newsletter, grouped by product, direct links to the HTML versions of the newsletters. The page is shared with everyone at 37signals. It’s also tagged “37signals” “Newsletter” so anyone can find it quickly if they haven’t added it to their Backpack sidebar.

Whenever Jamie sends a newsletter he takes about 60 seconds to add the link and brief description to the Backpack page. We use Backpack page dividers to group the newsletters for different products and add each newsletter as a note. The note subject is the date and the note body is a link to the newsletter plus a summary of the main points.

And that’s it. Not rocket science, but who needs rocket science? Backpack is anti-rocket science.

It’s just a shared Backpack page with a list of stuff grouped up, linked up, and summarized up. In one place all the time so everyone knows where it is.

Christopher Alexander on the perfection of imperfection

37signals — Mon, 22 Jun 2009 12:38:00 +0000

Christopher Alexander on the beauty and sense of wholeness that comes from the irregular construction of buildings such as La Casa de los Azulejos in Mexico City. From his 1991 essay “The Perfection of Imperfection,” as cited by Richard Gabriel in Patterns of Software (1.2 MB PDF).

More...

QUOTE: In retrospect, all revolutions seem inevitable

Matt — Fri, 19 Jun 2009 17:40:00 +0000

In retrospect, all revolutions seem inevitable. Beforehand, all revolutions seem impossible.

—Michael McFaul, National Security Council

How to mock alternate states of a new UI template using helpers

Ryan — Thu, 18 Jun 2009 19:05:00 +0000

You’re working on some new UI and there are multiple states that could be displayed based on some conditions. How do you communicate the possible states to a programmer? You could mock them all up separately as wireframes. Or you could comment them out in your HTML mockup and then walk through them face to face, explaining each one. Both of these methods work, but they leave a gap between your intentions as a designer and the programmer’s interpretation. The best way to ensure the conditions are understood and agreed upon between both of you is to actually write them into your template using stubbed Rails helpers.

Here’s an example from Basecamp. We want to improve performance on comment threads with a very high number of comments. The idea is to paginate comments. We’d display the most recent n comments, (let’s say 50) and earlier comments could be fetched dynamically with a “show more” link. Here’s a sketch:

The template for that sketch looks like this:

<h2 class="paginated_comments_header">
  <strong>These are the last 50 comments</strong> out of 160 total &mdash; <%= link_to "Show 50 more" %>
</h2>

But that’s not the end of the story. What do we display if there are no more comments to show? What if we are showing fifty out of sixty comments, so “Show 50 more” wouldn’t apply? The best way to communicate and test these conditions is to stub out some helpers. First I’ll write what I want to happen even though the helpers don’t exist:

<h2 class="paginated_comments_header">
  <% if showing_all_comments? %>
    <strong>Showing all 60 comments</strong>
  <% else %>
    <strong>These are the last 50 comments</strong> out of 60 total &mdash; 
    <% if more_than_one_page_of_comments_left? %>
      <%= link_to "Show 50 more" %>
    <% else %>
      <%= link_to "Show remaining 10 comments" %>
    <% end %>
  <% end %>
</h2>

Look carefully at the code to see how it reflects the different edge cases mentioned above.

Next I’ll write the helpers so that the template works. Since I’m only mocking the helpers, I can just make them return “true” or “false” depending on the condition I want to demonstrate.

module CommentsHelper
  ...

  def showing_all_comments?
    false
  end

  def more_than_one_page_of_comments_left?
    true
  end
end

All I have to do to test the different states is toggle those “true” and “false” values. The code communicates directly to the programmer when and why the different parts of the template should render. When it’s time for the programmer to implement, all he or she needs to do is replace the boolean with the actual conditions.

Even if the final template is going to be implemented differently, like in Javascript instead of ERB, it’s still helpful to deliver the template in ERB with the mocked helpers because the conditions are completely nailed down. I hope this technique helps you navigate that communication gap the next time you mock a template with more than one possible state.

PHOTO: Neat infographic: A beat-by-beat breakdown

Matt — Wed, 17 Jun 2009 16:23:00 +0000

Neat infographic: A beat-by-beat breakdown of a single track by “mashup DJ” Girl Talk.

Design Explorations: Basecamp Account Screen

JZ — Tue, 16 Jun 2009 22:40:00 +0000

As the new designer at 37signals, I am working on a series of short-term projects, much like the old 37express projects and my recent Highrise contact screen exploration. The idea is to work through some long-standing areas of the apps with a fresh eye and an outsider’s perspective. It also allows us to revisit some areas that we know can be better, but for various reasons haven’t had the time to rework.

So the goal is for me to tackle one of these design challenges a week for the next 8 weeks or so. We may get sidetracked like we did on this first one, but that’s the plan for now. I’ll be looking at solutions that we can implement immediately, but also digging in to see where else the process might take us. I’ll also be documenting these explorations for all to see.

Redesigning the Basecamp Account Chart

The first exploration was of the “Account (Upgrade/Billing)” tab in Basecamp and my write-up of the process is live. Not only that, but we went ahead and implemented the final design into Basecamp. It was pretty cool to get in here, get to work, and have my design live all in the first 10 days or so as a signal.

See the Basecamp Account Chart design exploration.

Reminder: Know what you're measuring

Jason — Tue, 16 Jun 2009 17:58:00 +0000

Yesterday David and I met with Sarah and Michael for a bit to get an update on how customer support/service is going. We recently switched from using Gmail to HelpSpot and we were curious how the transition felt. Basically, how was the workflow and were we learning anything?

Why the switch?

One of the reasons we switched to HelpSpot was so we could do a better job tracking which requests and issues were top requests. Sometimes support will say “People have been having a hard time uploading files this week” but it’s hard to know what “people” means. Is it two people? 10 people? Dozens? If we made changes to the app, would we reduce support demands and customer frustration? Gmail couldn’t really give us specifics, and HelpSpot could, so we switched to HelpSpot.

Knowing but not learning

In our review yesterday we discovered that were were tracking everything in detail, but not really learning anything. Why? We were tracking for the sake of tracking, not tracking for the sake of learning. We weren’t really sure why we were tracking what we were — but we kept on doing it because, well, momentum is a powerful force. It became an exercise in seeing how organized we could get in spite of what we actually needed.

Our extensive use of categories and tags and custom fields and pulldowns could give us a whole lot of report-friendly information, but it didn’t give us any useful information. Information without insight is junk. That’s what we had. Plenty of it.

Going back to simple

So yesterday we decided to change everything. Let’s point the ship towards simple. Every mistake we’ve made as a company has been because we tried to do too much, not because we didn’t do enough. So let’s apply that lesson to how we track support requests too.

What really mattered?

Instead of neatly categorizing every request, we’d just roughly categorize them. So instead of multi-level categorizing like “Milestones > Editing > How to move milestones between projects” we’d just track the “How do move milestones between projects” part. The “Milestones” and “Editing” categories didn’t matter. We didn’t need the hierarchy or extensive organization. All that mattered was the bottom line: The question/issue.

Basically as questions/issues came in, we’d create new long tags that paraphrased the question/issue. And whenever another question/issue came in that was roughly the same as the paraphrased question, we’d tag the actual question with the paraphrased question. This way we could get a count on these paraphrased questions and see how many people were basically asking “how can I update my password” or “how do I move information between projects?”.

We could run a report that would simply give us the top 10 questions this week. Are they the same as last week’s top 10? Are we seeing a pattern? What’s up? What’s down? Now we have specifics that we can act on. In the past we’d know there were 60 questions in the “milestones” tag, but that doesn’t really give us anything to act on. But now we’d know there were 23 questions about “How do I add more than 10 milestones at a time”, 21 about “Can I move milestones between projects?”, and 16 about “Can I add times to milestones?”. Now we’ve learned something.

Obvious isn’t always obvious

Looking back at this it seems obvious. We should have done this from the start. But like many things, it’s easy to get carried away. This new tool gave us all sorts of tracking options. Categories, tags, custom fields, lookups, etc… So we got excited and confused enthusiasm with priority. We did a lot of busy work but didn’t learn anything.

So just a reminder: Know what you’re measuring. Data for the sake of data can be a fun intellectual exercise, but practicality is usually what you’re after.

PHOTO: LessEverything's UI Test Results #3: Flipping

Matt — Tue, 16 Jun 2009 17:43:00 +0000

LessEverything’s UI Test Results #3: Flipping “See the Tour or Try Less Accounting Free” so button is on the right improved conversions from 12.3% to 13.8%.

QUOTE: I don't care how good you are at programming

Sarah — Tue, 16 Jun 2009 01:20:00 +0000

I don’t care how good you are at programming, finding bugs, whatever. If you’re rude, or if you speak poorly to people who don’t understand your… quirks…. you will wind up being shunted to the side. No one wants to work with someone who makes them feel beat down all the time, or someone who they simply can’t understand, or someone whose reaction to every issue is to start wailing about the end of the world.

—Excellent advice I need more and more of, everyday. Catherine Powell. {via blankenship}

Mark's upcoming technical presentations

Mark — Tue, 16 Jun 2009 00:30:00 +0000

I have a couple of technical presentations coming up that I wanted to let everyone know about. I’ll be talking about a couple of things that have been holding my interest for the past few months: Chef and Erlang.

For the first talk, I’ll be giving an overview of Chef, a tool that we’ve been using for few months to automate our system administration tasks. If you’re in or around the Raleigh, NC area tomorrow night (June 16th), come out to the Raleigh.rb meetup and join us.

The second talk will be at Erlang Factory in London next week. I’ll be talking about our use of the Erlang programming language in the Campfire poll server that we recently discussed right here on SvN. I had the good fortune to attend the first Erlang Factory in the United States at the beginning of May in Palo Alto and it was one of the best conferences I’ve been to in years. If you’re at all interested in Erlang, it would be worth your while to think about attending the conference.

Lessons learned from Spike Lee's profile of Kobe Bryant

Matt — Mon, 15 Jun 2009 15:09:00 +0000

So the Lakers win another NBA championship. I haven’t always been a fan, but I’ve got to admit it was really fun to watch Kobe Bryant this season. He seemed to have an almost maniacal determination to win another championship. People compare him to Michael Jordan and, while they’re both incredibly talented, you get the feeling that what really separates them from the pack is how badly they want to win.

Along those lines, a great documentary to check out is Spike Lee’s Kobe Doin’ Work (Netflix). Bryant gave the filmmaker unprecedented access to his life for one game. He’s mic’d up, 30 cameras follow him, and coach Phil Jackson lets the crew into the locker room before the game, at halftime, and after the game too. Here’s a preview:

It’s fascinating to watch even though the game was a blowout. Also, there’s a great storytelling lesson here too: Tell a story about less. See, the impulse is to go for a grand tale. In this case, it’d be to prove how great Kobe is by profiling his entire career or trailing him for an entire season. Along the way, you’d interview teammates, experts, etc. And you’d come up with a pretty generic piece.

By focusing on just a single game, Lee put a magnifying glass on how Kobe plays. Cameras trail his every move so during every timeout and every play, you get to see and hear how Kobe guides his teammates. It completely changes the way you view both the player and the game. There’s no filler or outside input. It’s just a laser focus on this one subject during this one day.

Sometimes it’s easier to get a big message across if you narrow your scope. It’s what we tried to do with our Behind the scenes at 37signals series which presented a look at one week of 37signals’ Campfire usage. Not as exciting, perhaps, but the idea was similar: To tell the big story of how integral Campfire is to us, it was best to focus on a short period of time. Sometimes the perfect way to explain a universal truth is through an individual example.

Also, if you watch the documentary, Lee is incredibly loose with how he asks his questions. It means that Kobe is really relaxed and open with his answers too. If you’re ever doing interviews, it’s something to note: Go in with stiff questions and you’ll probably get stiff answers. Go in loose and you’re more likely to get your subject to open up and admit things to you they probably wouldn’t otherwise.

Your branding shouldn't give customers a headache

Matt — Fri, 12 Jun 2009 17:25:00 +0000

This new animated YouTube logo is super distracting. How are you supposed to concentrate on a video when there’s this flashing static/rainbow thing in the corner? It’s like the site is trying to force you to go fullscreen mode now. If your branding gives customers a headache, it’s not really such great branding.

Update: Apparently it’s a one-day thing to commemorate the change of TV from analog to digital. But still…

Click “Continued” to see the animation.

More...

The planning fallacy

Matt — Fri, 12 Jun 2009 13:44:00 +0000

We blame bureaucracy for being wasteful and taking too long when things like the Denver International Airport or Boston’s Big Dig arrive years overdue and billions over budget. But it’s not just huge organizations and the government that mess up planning. Everyone does. It’s the “planning fallacy.” We think we can plan, but we can’t.

Studies show it doesn’t matter whether you ask people for their realistic best guess or a hoped-for best case scenario. Either way, they give you the best case scenario. It’s true on a big scale and it’s true on a small scale too.

We just aren’t good at being realistic. We envision everything going exactly as planned. We never factor in unexpected illnesses, hard drive failures, or other Murphy’s Law-type stuff.

If you believe 100% in some big upfront advance plan, you’re just lying to yourself. There’s a good side to this too though: You’re liberated. That messy planning stage that delays things and prevents you from getting real is, in large part, a waste of time. So skip it. If you really want to know how much time/resources a project will take, start doing it.

"Good enough" instead of "absolutely perfect"

JZ — Wed, 10 Jun 2009 22:35:00 +0000

For my first project since joining 37signals I’ve been working on an update to the venerable Account (Upgrade/Billing) screen in Basecamp. We’ll post more about that update and the process to get there soon, but I wanted to share an experience I had as part of this design.

We had decided to include a few short handwritten phrases as graphic elements. Sometimes in the perfect world of web design, elements that have an organic, handmade look can soften the message and draw the eye. These phrases enhance the message but don’t convey any hard data that is intrinsic to the upgrade decision. That makes them a good place to have a little fun and lighten things up.

So, I wanted to make them look as if they’d been casually written directly on the page. They needed to look casual and authentic so no fonts. It can be tempting to use a script or handwriting font for an application like this, but they never fool the eye. I learned a long time ago that you can’t fake it — if you want something to look handmade, make it by hand.

But what I found is that this task was a lot tougher than it sounds. I must have written and re-written some of these phrases more than 50 times trying to get just the right flow, the perfect amount of flair, and a cohesiveness with the other phrases. But “perfect” was exactly the wrong approach here. Handwriting isn’t perfect and the irregularity is where the character and charm I was going for would come from. So I settled for “good enough”, which turned out to be ideal.

So instead of carefully drawing each letter and placing them together, I practiced a few times and just wrote each one out as quickly and naturally as if I was writing in my notebook.

My fingerprints — almost literally — are going to start showing up in 37signals products in the coming weeks. I’ll be sharing more of the process as we go.

Why it's wise to launch softly

Matt — Wed, 10 Jun 2009 15:20:00 +0000

How the term “trial balloon” originated: The Montgolfiere brothers came up with a design for the hot air balloon but wanted to make sure it would really work before getting in one themselves. So they first released several unmanned trial hot air balloons. Then they sent up several farm animals to make sure the air at higher levels was safe to breathe. After that, they tried a manned expedition.

It’s a smart approach. But in the business world, a lot of people think the opposite is the way to go. They want to launch big. They want a huge PR splash right away. They want the big bang.

Too bad. You don’t need a big bang – slow evolution is what you want. Unless you absolutely must “open wide,” abandon the mass introduction strategy. Instead, launch softly.

Restaurants start off by serving friends and family before they invite the media.

Movie studios use test screenings to fine tune movies. The people behind the scenes know that until you get into the test screenings and see what people really think, you just never know.

Likewise, Jerry Seinfeld and Chris Rock try out jokes in small clubs before hitting arenas.

Authors test out material by writing magazine articles, ebooks, and/or releasing chapters online. Michael Pollan started off an article in the New York Times with these words: “Eat food. Not too much. Mostly plants.” Those same words appeared as the main theme of his book “In Defense of Food: An Eater’s Manifesto,” published a year later.

You don’t have to paint a finished picture before launching. Customers can connect the dots.

Soft launching lets you tweak and revise. You get the word out there and you gauge interest. You know what works and what doesn’t.

Plus, you get to make mistakes while you’re still in the shadows. Messing up in front of a smaller crowd means you’ll be better off when the bright lights eventually do shine upon you.

QUOTE: Big, as a business model (let alone as an

Matt — Tue, 09 Jun 2009 18:30:00 +0000

Big, as a business model (let alone as an expression of the national mood), seems bound for obsolescence.

—“A Study in Why Major Law Firms Are Shrinking”

Product blog update: API developer list, iPhone app for Backpack, etc.

37signals — Tue, 09 Jun 2009 16:32:00 +0000

Some recent posts at the 37signals Product Blog:

Developer/API
The new 37signals API developer list
“The new 37signals API developer list is meant to be the new hub for all things 37signals API. A place where developers can discuss their experiences and challenges working with the APIs from Basecamp, Backpack, Highrise, and Campfire. We’ll try to make ourselves available as best we can to help answer questions and provide clarification on implementation”

Improving the Basecamp API
“We’ve been working behind the scenes to improve the Basecamp API. One recent change lets developers know whether the person making an API request is from a client or an internal firm.”

Highrise
The Star-Ledger: Highrise is a a new breed of CRM that emphasizes simplicity
“I particularly like the description used by 37 signals, the makers of the Highrise CRM: Highrise is a great way for business to keep track of who talked to whom, what was said and what needs to happen next. The software excels in the way it blends contact management, to-do lists and other features. You look at a contacts page in Highrise, and you have a window into your communications with that person, notes from meetings, background and any tasks related to the contact.”

Put your Highrise Dropbox address in the BCC field automatically in Mail.app
“Want to put your Highrise Dropbox address in the BCC field automatically in Mail.app? Easy Automatic Highrise Dropbox in Apple Mail offers a hack that will make it so.”

Sync your Ballpark estimates with Highrise Deals
“Ballpark, an app that lets you send estimates and invoices, now syncs with Highrise Deals.”

Backpack
TUAW: “Satchel is Backpack on the iPhone done right”
“It’s worth every penny for the true Backpack fanatic. It’s gone a long way to removing the barrier for those looking to embrace Backpack as a service, but feeling a little hamstrung by the lack of a decent mobile interface. If you love Backpack, you’ll love Satchel.”

More...