Signal vs. Noise
view rss
Why underdogs should take more chances
24/6/2009 | external link
In an email exchange with Malcolm Gladwell, ESPN’s Bill Simmons wonders why NBA teams rarely, if ever, take chances — specifically: Why don’t more underdogs try full court pressing opponents? The conversation then extends to the NFL too. Gladwell’s response: Is there any other industry in the world (well, outside of Detroit) so terrified of innovation? I went to see a Lakers-Warriors game earlier this season, and it was abundantly clear after five minutes that the Warriors’ chances of winning were, oh, no better than 10 percent. Why wouldn’t you have a special squad of trained pressers come in for five minutes a half and press Kobe and Fisher? Worst-case scenario is that you exhaust Kobe, and make him a bit more vulnerable down the stretch. Best case is that you rattle the Lakers and force a half-dozen extra turnovers that turn out to be crucial. And if you lose, so what? You were going to lose anyway… I feel the same way about the attitude of professional football teams toward the no-huddle offense. Right now, great teams (such as the Colts and Patriots) use the no-huddle selectively, as a way to maximize their dominance. But why don’t bad teams use it? If you were the Lions, why not run the no-huddle this season? Why not put together a lighter, better-conditioned offensive line and a radically simplified playbook and see what happens? It’s not as if you are risking a Super Bowl if it backfires. Your offensive line is lousy anyway, so there’s no harm in tearing it down, and your fans aren’t going to turn on you if you get killed while you work out the kinks. Last I checked, your fans have already turned on you. On the plus side, maybe the no-huddle exhausts the other team’s defense so much you slow down their pass rush in the second half. And maybe giving your quarterback a bit more autonomy helps develop his knowledge of the game, and his leadership skills. The consistent failure of underdogs in professional sports to even try something new suggests, to me, that there is something fundamentally wrong with the incentive structure of the leagues. Obvious parallels to the business world here too. (“No one ever got fired for buying IBM? anyone?) Sometimes the riskiest thing to do is not take any risks. If you’re outmatched by the competition, isn’t it silly not to take a chance? If you’re an underdog in your niche, the Warriors or the Lions of your industry, playing it safe and imitating the established players will probably doom you to failure. One or two-person businesses that think they need to follow “common sense” advice that’s worked for the big guys are missing the point. When you’re small and risking less, you don’t need a business plan. You don’t need a board of directors. You don’t need to study the techniques of Fortune 500 CEOs. You don’t need to know Six Sigma ideas. The strategy that’s right for heavyweights has nothing to do with how welterweights should fight. Related pieces on underdogs who use innovation to compete: “How David Beats Goliath” is Gladwell’s piece in the New Yorker about the topic. Michael Lewis wrote about the unorthodox success of Texas Tech’s football team in “Coach Leach Goes Deep, Very Deep” [NY Times]. When Texas Tech reached the No. 2 ranking in college football last year, Lewis followed up with a piece that discussed how Leach knew he had to be different to have a chance. To appreciate what he?s done you have to appreciate how hard it is to get players—he gets third or fourth bite of apple down there. He’s working with everyone else?s rejects. Generally, he?s doing so much more with so much less. Lewis also covered similar ground in Moneyball, which analyzed the Oakland A’s success despite its limited payroll.
We're hiring a junior support programmer
24/6/2009 | external link
We?re looking to hire a support programmer who can work with Sarah and Michael on customer issues. This includes investigating reports of abnormal behavior and fixing bugs, but it also means building tools to automate the work. See the full job posting on the 37signals Job Board for more details.
New in Highrise: Twitter integration
24/6/2009 | external link
Highrise is the best way to keep track of who you talked to, what was said, and what to do next. Twitter integration allows you to have an even better view of what?s on a person?s mind, what they?re saying right now, and what their current interests are. Now you can check your previous communications history as well as what they are tweeting right now. Tweets are great conversation starters that show you?re paying attention to what?s going on in their world. Here’s a video to show you how easy it is to add Twitter info for a contact: We really hope you like this feature (and be sure to follow us on Twitter at twitter.com/37signals).
Forget the resume, kill on the cover letter
24/6/2009 | external link
A great resume will get you not-rejected, a great cover letter will get you hired. That’s the conclusion I’m left with after going through the applications for our junior support programmer position. Most people can make their resume look reasonable which makes it a poor qualifier. We don’t believe in years of irrelevance, so you’re not going to beat out another candidate by having four instead of three years of experience. That means all you’re left with is just check marks: Yes, there’s Rails experience. Yup, there’s the sysadmin stuff. Poor qualifiers filter out few candidates. When I’m saddled with 70 applications for a job, I have to make some rough cuts very quickly. I literally have to decimate the pool. With the resume only doing 20% of the job, the key is left with the cover letter. This means that “If you like my resume, give me a call” doesn’t make the cut for a cover letter. I need more romance and originality than that to pick up the phone. Strike a tone in tune with the company It also means that you really have to tailor your tone to the company. Pulling out your Business Serious voice and addressing “Dear Hiring Manager” instantly kicks you down a few levels. Just like showing up in a suit would do when everyone else is wearing jeans and t-shirts (except of course if you have extreme pizazz to pull it off). The gut reaction builds immediately. If the first paragraph is a strike, the second has to work that much harder. If there’s no hook in the first three, it’s highly unlikely that anything is going to come of it. This advice is probably exactly the opposite of what you’ll if you’re aiming to get into a big shop with a formal HR department. In that scenario, it’s often last man standing in the numbers game and checklist requirements. Personality doesn’t matter to make it through the first cut. But when you’re looking to get hired by managers who actually have to work with you, personality is almost all that matters to get to the interview. So beef up your cover letter and let your personality shine (Jason Zimdars who we recently hired set the gold standard).
Doubling down in business
24/6/2009 | external link
Larry Cheng in “How Can We Double Down?”... [During an MFG.com board meeting,] Jeff Bezos asked the question, ?Is there anything big or small, that is working better than you expected? Is there any where we could double down?? Jeff?s point was that we spend a lot of time focusing on what?s not working in Board meetings (especially in times like these), and not enough time focusing on what is surpassing expectations and how we can ?double down? on those areas. Often times the key levers in businesses are found in little things that are really outperforming whether by intention or not (often not, actually). Sometimes these are things that are either adjacent enough or small enough that they wouldn?t make a board presentation or be an obvious discussion point because they?re just seedlings that need to be watered. I appreciate how Jeff wanted to bring these seedlings to the forefront to see if they deserved some real investment. Reminiscent of Jason’s recent post here about how failure is overrated. What’s working is where the gold is. Focus and learn from that instead of fixating on the negative. FYI, if you’re not a big blackjack fan already, here’s “doubling down” explained.
ThinkGeek: "We'd never get away with taking advantage of you guys, so why would we try?"
24/6/2009 | external link
Gizmodo ran a post saying ThinkGeek’s New Dreamcasts Aren’t Looking So New. According to one Destructoid tipster, that new stock of $100 Dreamcasts offered by ThinkGeek may not be so new after all. His console was “roughed up ? the barcode has been scratched, the console’s plastic has gunk on it.” And here’s the thoughtful response ThinkGeek gave in the comments: First, a little backstory: We came upon an amazing cache of new-in-box Dreamcasts not too long ago. We had a bunch of units shipped to us to inspect them, and indeed, though the boxes were a little worse for the wear on the outside, the consoles had nary a scratch and even the wire twists that bundled the cables had never been undone. It was like magic—magic that had been hiding in a warehouse, unknown, for years. So we asked our source from whence these beautiful Dreamcasts came, and they didn’t know—could’ve been a liquidator, or a Circuit City that had closed shop. (Hear that? It’s the sound of a plot thickening.) But we’d seen them with our own eyes and figured it was best to share our discovery with the world. Hundreds were snatched up quickly and squees were heard ‘round the internets. So far we’ve had 2 instances of not-so-new-in-box Dreamcasts. The individual who received the one reported here contacted us via email (which never appeared in our inbox, for some reason) and Twitter (through which we’ve taken care of the situation) has already been issued a return shipping label. We’re more than happy to refund him for the Dreamcast as well as shipping. We’re very sorry about the whole thing—we never meant to ship used Dreamcasts. We know our customers are smarty pants and could tell if they’d been duped with a stale Dreamcast; we’d never get away with taking advantage of you guys, so why would we try? And now we have 3 options: 1. Stop sharing the gift of new Dreamcasts; 2. Have them all shipped to us and inspect each one individually and then ship back to the warehouse; and 3. Continue spreading the (mostly) untainted Dreamcast love and working with the very few customers who get lemons. We hope you’ll understand why we’re continuing to offer them on our site (when we get our grubby little paws on more, of course). And again, we apologize to the 2 customers who ended up with what appears to be returned merchandise. SvN reader Daniel Øhrgaard spotted the exchange and gives ThinkGeek high marks for its response: ThinkGeek just handled some customer complaints perfectly over on Gizmodo... My vote: Highest marks for ThinkGeek. Granted, I’m not among those who bought a Dreamcast from them, so I didn’t harbor any ill will toward them before I read the apology. But even I felt like a (for real) “valued customer” when I read it. I’ve read many other stories on Gizmodo that’d been updated carried had a link to some company’s response to a widespread issue, but they were just that: links to the apology. For most of those stories, I never bothered reading the company response, because I couldn’t be bothered to go to the company’s home turf to read it. So when I saw “ThinkGeek responds in the comments below” I had to see it; they came to the reader to apologize, giving up the control over content their own site would offer, and allowing the generally bawdy Gizmodo flock to judge them. As one other commenter said: Respect.
QUESTION: What does a Community Manager do? I see a
24/6/2009 | external link
What does a Community Manager do? I see a lot of job postings and mentions of this position, but I’m not entirely sure what the role is. How does it different from customer support/service? Is it a component of that role? A dedicated role? Would love to hear from anyone who does it or who has hired for it in the past. Thanks!
Hindsight on default styles in Basecamp
24/6/2009 | external link
In Basecamp’s early days “semantic HTML” was all the rage. It still is in some ways, but we were hitting the kool-aid a lot harder than we are today. One area where this has bitten us is in our default styles for the UL element. When we started styling Basecamp we were mostly working with interface elements, not text documents. True to the semantic kool-aid we used UL tags mainly for tabs, category links, lists of project links, attached files etc. Everything but actual plain-jane bullet lists. It all worked fine, but just now I wanted to include a bulleted list in some copy I’m sketching for a dialog. Check out how the unordered list looks in this draft using default styles: That list in the middle is actually a UL. There are no bullets, the font size is wonky, the margins are different. This default must have made sense when all of our ULs followed a certain pattern for interface use. But here in the future, I wish we would’ve been more selective about those styles and left the default alone. Or better yet, we could’ve used DIVs in the first place for those tabs, attachments, and category links. I’ll surely keep this in mind the next time we start a fresh project.
Recent jobs posted to the 37signals Job Board in London, Paris, New York, Toronto, SF, etc.
24/6/2009 | external link
Design Jobs Dayforce is looking for a Senior UI Designer in Toronto, Canada. Wesleyan University is looking for a Web Developer in Middletown, CT. Diary.com is looking for a Lead Web Designer in London, UK. AnyClip is looking for a Senior Designer / Front-End Developer in New York, NY. Vodpod is looking for a Web Designer in San Francisco, CA. View all Design Job listings Programming Jobs Firstborn is looking for a Software Engineer in New York, NY. Metaboli is looking for a Ruby On Rails Developer in Paris. Yahoo! is looking for a Sr. Software Apps Dev Engineer, Yahoo! Mobile in Sunnyvale, CA. Sitezoogle is looking for a Web Developer to telecommute. Wall Street On Demand is looking for a Junior Web Developer in Boulder, CO. View all Programmer Job listings More jobs View all of the jobs at the 37signals Job Board. (The Job Board now has internships too.)
QUOTE: How you do anything is how you do everything
24/6/2009 | external link
How you do anything is how you do everything. Your ?character? or ?nature? just refers to how you handle all the day-to-day things in life, no matter how small. —Derek Sivers: Character predicts your future
Forbes profile of David and 37signals
24/6/2009 | external link
The Pied Piper of Pay [Forbes] is a piece that profiles David… You can tell a lot about a culture by the sort of person it ostracizes. David Heinemeier Hansson, 29, a successful tech entrepreneur, is something of an outcast in Silicon Valley. Here are the pronouncements that have earned him his banishment: Companies should not be ashamed to charge for their products. They should expect to be able to make money off their customers. Finally, they can’t use volume to turn losses into profits… “Startups these days are getting all the wrong lessons,” says Hansson. “[They think] that all that matters are users, that they should take on plenty of debt from venture capital investments because something magical will come along at some point and everything will be okay. But you can’t make up something in bulk that is a losing prospect to begin with. Isn’t that self-evident?” Read the rest of the piece to see what DHH thinks of Twitter and Facebook. (Note: There are a few inaccuracies in the piece, most notably that Ruby on Rails is a 37signals product which impacts our financial success. Not so, it is an open source framework.)
Last week's 37signals retreat in Kohler, Wisconsin
24/6/2009 | external link
Last week we had a 37signals retreat in Kohler, Wisconsin (the company that makes faucets and plumbing fixtures also has a resort). We got to catch up, plan ahead, meet the newest members of the team, took the Kohler factory tour (some pretty amazing stuff happens to get those faucets, tubs, and toilets made), dined at a cabin in the woods, made lots of trips to Sheboygan to eat at the excellent restaurants of chef Stefano Viglietti, and went canoeing. And by the way, contrary to popular belief, this is NOT how 37signals handles feature requests…
A reminder of how simple business can be when you don't make it complicated
24/6/2009 | external link
Yesterday I found a flyer on my front door. I’ve been staring at a project in my backyard for a few weeks. Staring hasn’t gotten it done. So I figured I’d see what it would cost to have these guys do it. I called them. 10 minutes later the guy came by. He was down the street on another job. We walked out back. I told him what I needed done. He looked around for 20 seconds and said $300. I said “deal.” That’s it. No proposal. No “I’ll get back to you tomorrow”. No “Let me see how much the materials will cost and I’ll drop an estimate in your mailbox next week.” Just $300. Deal. When can you start? Wednesday. How long will it take? A few hours for a few guys. He knows his business. I know what my time is worth. End of transaction. It was so damn refreshing. I know everything can’t be done like this, but often it seems like we’ve slid down a path of formality with so many things that really don’t need it. Extensive contracts, delays, red tape, precise cost estimates based on precise amounts of materials, “let me think about it and I’ll get back to you,” etc. Essential? Sometimes yes, but most of the time probably not. I remember the tail end of our time as a web design company. When we started we did 20 page proposals. I remember pulling all nighters getting a proposal ready. Pages and pages of stuff. What a waste of time. Towards the end we were doing one page proposals. It didn’t seem to matter. We were going to get the job or we weren’t. Over six years I never saw a connection between length and detail of proposal and winning a job. Same thing with contracts. Sometime we hire an outside contractor or specialist to give us a hand on a project. Our contractor agreement used to be 8 pages long. Lawyers wrote it. Our current contractor agreement is one page long. I wrote it then showed it to our lawyers. They said it was fine. Done. I know it seems like a stretch to compare lessons from a door flyer for a small landscaping job to 10 page legal contracts for 3 month long expensive web design projects. But maybe it isn’t.
QUOTE: The moment a man begins to talk about technique
24/6/2009 | external link
The moment a man begins to talk about technique that’s proof that he is fresh out of ideas. —Raymond Chandler
Rediscovering Jakob Nielsen
24/6/2009 | external link
When I was first getting serious about web design I discovered Jakob Nielsen’s Alertbox and was totally inspired. There was something about the ascetic style, black verdana type, yellow header and scattershot of bold that just fascinated me. I pored over the site and stayed up late at night reworking projects with fresh inspiration and higher standards. I even found a company to work for that was as nerdy about this stuff as I was. And then somehow—I don’t know how—I just forgot about the guy. Today my forgetfulness took a kick in the seat when Jason linked me to this Alertbox article. This site just doesn’t look old. It’s still fresh and clear and distinctive. And the content? Show numbers as numerals. The F-Pattern. Active versus passive voice. The first two words. It’s all rock solid. It still has that new car smell. There’s no fad in here. Timelessness is a mark of mastery. And few things are healthier than being reminded of how your best work rests on the shoulders of people who inspired you through their example. So I’m glad I took some time today for a usability refresher from Mr. Nielsen.
QUOTE: People want to know how I started Teach For
24/6/2009 | external link
People want to know how I started Teach For America straight out of college, and honestly, my greatest asset was my inexperience. It proved absolutely critical at many junctures. When I declared in my thesis that I would try to create this corps myself, my thesis adviser pronounced me “deranged.” When he looked at my budget of $2.5 million for the first year, he asked me if I knew how hard it was to raise $2,500, let alone two and a half million dollars. But aided by my inexperience, I was unfazed by these reactions. When school district officials literally laughed at the notion that the Me Generation ? this was the label for my generation ? would jump at the chance to teach in urban and rural communities, their concerns, too, went unheard. My very greatest asset was that I simply did not understand what was impossible. —Wendy Kopp, Teach For America founder
QUOTE: Big, as a business model (let alone as an
24/6/2009 | external link
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.
24/6/2009 | external link
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...
"Good enough" instead of "absolutely perfect"
24/6/2009 | external link
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
24/6/2009 | external link
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.
Your branding shouldn't give customers a headache
24/6/2009 | external link
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
24/6/2009 | external link
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.
QUOTE: I don't care how good you are at programming
24/6/2009 | external link
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
24/6/2009 | external link
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
24/6/2009 | external link
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.
Design Explorations: Basecamp Account Screen
24/6/2009 | external link
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
24/6/2009 | external link
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
24/6/2009 | external link
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%.
PHOTO: Neat infographic: A beat-by-beat breakdown
24/6/2009 | external link
Neat infographic: A beat-by-beat breakdown of a single track by “mashup DJ” Girl Talk.
How to mock alternate states of a new UI template using helpers
24/6/2009 | external link
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.
QUOTE: In retrospect, all revolutions seem inevitable
24/6/2009 | external link
In retrospect, all revolutions seem inevitable. Beforehand, all revolutions seem impossible. —Michael McFaul, National Security Council
Christopher Alexander on the perfection of imperfection
24/6/2009 | external link
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...
How we use Backpack to keep track of our email newsletters
24/6/2009 | external link
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.
Nickel and diming
24/6/2009 | external link
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.