This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Visit the Product Blog for more information on our products.
Yesterday, we pushed an update to Campfire that added some new functionality to the transcripts screen. You can read the details in this post on our product blog, but I wanted to share the thought process on a small change we made as part of the update.
While working on the “Files, Transcripts and Search” tab in Campfire we noticed that the heading for each transcript day was kind of a mess. Here’s what it looked like before the update (the image has been reduced, click to see it full size):
The design has essentially four elements using 3 font sizes, 4 colors, and 2 font weights. It certainly gets the job done, but it adds a lot of noise to the screen and can only make scanning the page slower than it needs to be. Contrast is essential to differentiating elements of a design, but here everything is unnecessarily different from everything else.
As we looked more critically we also felt like the link to read the transcript could be more obvious and that the link to delete a transcript was far too prominent for a feature that is rarely needed.
Here is what it looks like today:
The redesigned header reduces the contrast between the date and room name to just the weight of the font — a good example of least effective difference. The link to read the transcript is now explicit, reducing confusion, and the delete transcript link it subdued. Aligning it to the right keeps it out of the way where it is less likely to be accidentally clicked. Finally, a heavy black rule decidedly separates each day while giving each entry some visual weight.
The new design retains the same four elements as the original but by reducing unnecessary contrast, and refining the arrangement makes it feel like fewer to the eye. This results in less clutter and better scanability. It’s a small change that we think makes the whole page better.
I love my iPhone and I love Apple (cue images of flag pins and “I love muh countray!”), but I believe they’re blowing it with the App Store gate keeping. That’s of course not a new opinion. Developers left and right have been decrying the broken process. But there’s nothing like feeling it on your own bones to make the point.
We have a couple of new features in the wing for Campfire. They’ve been done for more than 10 days now. Why haven’t we released them yet? Because the iPhone app Ember needed to have a simple regular expression updated to support the features. We really like Ember, so we decided that holding back the features until this pro forma update went through was prudent. We’re still waiting.
This has made me think about all the ways the app store process sucks and how little we get back in return. The argument I keep hearing for why this terrible process is worth it is quality control. Here’s a breakdown of each argument:
Applications will be more stable: No they won’t. Echophone still crashes on me all the time. It’s not like the iPhone is immune to crash bugs. And why would it be? You’re writing native Objective-C here. Shit is going to crash every now and then. No 10 minute look-over by a App Store clerk is going to help that.
The App Store will be free of malware: That’s certainly no given. If you really wanted to be evil, you could very well hide your malice underneath a cute game and have a time bomb or a remote trigger installed. Do you think the App Store clerks are combing through source code to look for security issues? Ha!
Only good stuff in the App Store: Ha! The App Store has some 140K+ applications. I can guarantee you that the bulk of that is less than average. There are some 100 fart apps for christ sake!
We’re paying for the inconvenience of quality control without the quality part. In fact, lots of software has lower quality because of the App Store process. Developers can’t easily get bug fixes out and they certainly don’t release new versions as often as they otherwise would. This harks back to the era where software was really cumbersome to release on CDs, so you did it much less frequently.
Contrast this with OS X and the web. Both platforms are much more open and on a mac you have very little trouble with stability or malware or even quality. In general, the market is pretty good at sorting this stuff out. If you make a crappy application, people don’t buy or recommend it. And OS X seems to be holding up well as a secure platform compared to, say, Windows, so malware isn’t much of a concern either.
What I think Apple should do instead is to reserve the power to nuke apps that prove troublesome. Have a “if you fuck it up, we’ll yank it” policy rather than a “we’ll review everything poorly and slowly and still not catch it all” policy. They’d be able to get by with a much smaller App Store clerk staff, developers would be thrilled to escape the needless gate keeping, and consumers would enjoy more applications updated more frequently.
What’s there to lose except for the feeling of powah?
Sometimes you are coding a template and you need to refer to the same method chain over and over. For example, you’re coding a template that summarizes activity on recent messages. You iterate through a block of messages, and for each message you want to display some information pertaining to the last comment. You could do it like this:
<div class="active_messages">
<% @active_messages.each do |message| %>
<h1><%= message.title %></h1>
<div class="latest_comment">
<div class="avatar">
<%= avatar_for(message.comments.last.creator) %>
</div>
Latest comment <%= time_ago_in_words(message.comments.last.created_at) %> ago by <%= message.comments.last.creator.full_name %>
</div>
<% end %>
</div>
Everything inside of div.latest_comment deals with the exact same comment, but we have to use a method chain to get the comment each time (message.comments.last).
One solution is to set a local variable inside the iterating block with the knowledge that the variable will be reset after each iteration:
<div class="active_messages">
<% @active_messages.each do |message| %>
<h1><%= message.title %></h1>
<% comment = message.comments.last %>
<div class="latest_comment">
<div class="avatar">
<%= avatar_for(comment.creator) %>
</div>
Latest comment <%= time_ago_in_words(comment.created_at) %> ago by <%= comment.creator.full_name %>
</div>
<% end %>
</div>
One on hand, this is better because the methods called on `comment` are easier to scan. The whole div.latest_comment is more readable without the repeated method chain. On the other hand, setting a local variable is bad style. The local variable assignment creates state without explicitly showing where that state applies. It feels a little too PHP for my taste.
A better approach is to use the `tap` method to scope a variable to a block:
<div class="active_messages">
<% @active_messages.each do |message| %>
<h1><%= message.title %></h1>
<div class="latest_comment">
<% message.comments.last.tap do |comment| %>
<div class="avatar">
<%= avatar_for(comment.creator) %>
</div>
Latest comment <%= time_ago_in_words(comment.created_at) %> ago by <%= comment.creator.full_name %>
<% end %>
</div>
<% end %>
</div>
The `tap` block shows exactly where the scope of the assignment starts and ends. I like how the template explicitly says “now we are going to deal with a comment in the following section, and this is the comment we are working with.”
I just hit on this pattern today while working on a feature and I think it’ll come in handy in the future.
What doesn’t this stuff do? Lather up and this naturally gentle, richly foaming, pure and soothing nourishing cleanser will synergistically refresh, harmonize, replenish, protect and restore balance with cool soothing botanicals.
Kinda ridiculous, isn’t it? Reading this should remind you to read your own site, your own marketing copy, your own definitions.
What claims are you making? Do you really believe them? What are you saying? Does it make any sense? How are you describing your product? Is it accurate or just a sea of adjectives that look good and sound good together? What story are you telling or selling? Whatever it turns out to be, are you really OK with it? Deep down inside, is it something you’re proud of?
When debating UI, a picture is better than a description. And a functional mockup is better than both. But debating UI without being able to look at something is a waste of time.
Was filmed using Errol Morris’ Interrotron (or a similar device). That’s how you get the direct eye contact. Jason’s take: “Was weird for 5 seconds then it was totally natural.”
The story of the Interrotron is also a neat example of scratching your own itch. Morris explains:
Q: Is it true that you interview people using a machine?
A: Yes, the (patent pending) Interrotron. It’s a machine that uses existing technology in a new and novel way. When I made my first film, Gates of Heaven, I interviewed people by putting my head right up against the lens of the camera. It seemed as though they were looking directly into the lens of the camera, but not really. Almost, but not quite. Of course, they were looking a little bit off to the side.
Q: What’s wrong with that? What were you trying to achieve?
A: The first person. When someone watches my films, it is as though the characters are talking to directly to them… There is no third party. On television we’re used to seeing people interviewed sixty-minutes-style. There is Mike Wallace or Larry King, and the camera is off to the side. Hence, we, the audience, are also off to the side. We’re the fly-on-the-wall, so to speak, watching two people talking. But we’ve lost something.
Q: What?
A: Direct eye contact.
Q: Eye contact?
A: Yup. We all know when someone makes eye contact with us. It is a moment of drama. Perhaps it’s a serial killer telling us that he’s about to kill us; or a loved one acknowledging a moment of affection. Regardless, it’s a moment with dramatic value. We know when people make eye contact with us, look away and then make eye contact again. It’s an essential part of communication. And yet, it is lost in standard interviews on film. That is, until the Interrotron.
Birthday stats are always fun. Here are some of our favorites:
55,700,000 comments
53,000,000 megabytes of uploaded files (that’s 53 terabytes)
38,000,000 to-dos
24,600,000 messages
8,600,000 completed milestones
3,600,000 users
3,600,000 projects
And for the technically minded: At peak we’re doing 220 requests a second with an average response time of 160ms.
These numbers are based on open accounts. We’re not counting cancelled accounts or deleted messages/comments/to-dos/files etc.
We’re thrilled with the growth over the last year. Thanks to everyone who uses Basecamp or any one of our products. We’ve got some great stuff in store for you this year so stay tuned!
Predictably, some argue the iPad doesn’t do enough. It needs a keyboard or a removable battery or multitasking ability or whatever.
But there’s an interesting backlash to that backlash. (Meta-backlash!) The discussion has people openly discussing an ugly truth that doesn’t typically get a lot of play among tech geeks: People don’t know how to use computers. And not just stupid people. Millions of people. People who are adults. And that’s pretty damn lame.
(Bold emphasis in the following excerpts is mine.)
I’m often saddened by the infantilising effect of high technology on adults. From being in control of their world, they’re thrust back to a childish, mediaeval world in which gremlins appear to torment them and disappear at will and against which magic, spells, and the local witch doctor are their only refuges…
The Real Work is not formatting the margins, installing the printer driver, uploading the document, finishing the PowerPoint slides, running the software update or reinstalling the OS.
The Real Work is teaching the child, healing the patient, selling the house, logging the road defects, fixing the car at the roadside, capturing the table’s order, designing the house and organising the party.
Since the days of the Apple ][, C64, and Atari 400, all we’ve done is add, add, add. Add more features to sell more computers. We’ve never stopped to take anything away.
I’m weary of this notion (even when presented as satire) that anyone who can’t master a computer must clearly be mentally retarded.
So while we trump up our skills at designing “easy to use” interfaces for our applications, millions of people are still trying to figure out how to get our beautifully designed application out of its zip file or disk image. Or where in fact the Downloads folder is. Or what, exactly, a folder is. If we hadn’t been there for every step of the personal computer evolution since the days of DOS and AppleSoft, I wager we’d find it pretty bloody confusing as well.
My mother-in-law walked in the door the day of the keynote and the first thing out of her mouth was “Did you see that new Apple iPad? That looks like it would work for me. Would that work for me?”
I was utterly flabbergasted. She NEVER talks about computers or technology. She tolerates them at best. Her attitude is typical of most baby boomers I’ve talked to regarding computers. She wants to benefit from them but is frustrated by the wall she must climb in order to do so. She’s learned how to use email and a couple of other things on the Internet and that’s about it…
I’ve long felt that computers were too hard to use, that the filesystem should NEVER be seen by the user. That human-computer interaction should favor the “human” side.
That these conversations are even going on is a good sign. For those of us surrounded by the minutiae of computers all day, it’s easy to forget there’s a world of people out there who just don’t get it. And it’s not their fault. It’s ours.
Apple has decided it’s worth throwing out advanced features in order to get these people onboard. Anyone who builds apps would be wise to consider taking a similar path. (Note: It’s not just about making a computer or an app more accessible for people who don’t get it. It’s also for people who do get it because this way is better.)
You can spend so much effort tweaking code or a specific part of the UI or adding a new pet feature that you forget the most important thing of all: People need to be able to START using your product. If they can’t do that, who cares about the rest?
You can crank up the snow machine. You can set up the slalom course perfectly. You can shape all the moguls so they’re just right. But if people can’t ever get on the ski lift, there ain’t gonna be any race.
“When is it going to be done?” is a reasonable question and we as software developers should try to come up with the best answer we can based on our experience and analysis. What we should not do, however, is treat our answer as solemn oath.
When you treat estimates as promises instead of guesses, you bind your worth as a worker to it. If you do not meet your own deadline, you are a failure. And since nobody likes to be a failure, they’ll indulge in risky behavior to avoid it, like burning the midnight oil and checking in bad code with scanty or no tests.
Rushing to meet your estimate promise once or twice might be bearable, but it’s ultimately unsustainable. Software development is inherently unpredictable. There are just too many moving parts and ice tips that turn out to be icebergs.
If you treat the estimate as a “best guess based on the limited information available to me before I start the work”, though, you’ll change the frame and break the cycle of deadline anguish. Now the task becomes collaborative and you can share new discoveries with the stakeholders.
Found out that doing the feature as originally designed requires changing some fundamental infrastructure that’ll add another two days to your one day estimate? Maybe it’s not worth it any more. Ask the stakeholder if he’s still interested in the feature when it costs three days instead of one. Or if there’s a way to simplify it such that the infrastructure change is not necessary.
That’s the true value of estimates. That it sets up conversational constraints that can be used as boundaries for trading concessions. Not that they’re nails for your own self-erected cross.
Like this episode? Please share it with your friends:
Life as a 37signals Project Manager
Ryan Singer, who manages 37signals’ products and designs interfaces, talks about the company’s design process. He discusses how the design team works with each other and collaborates with programmers. He gives advice to other design/development teams on how to work together smoothly. He talks about how studying Rails has made him a better designer. He explains why Christopher Alexander and Edward Tufte have been big influences. And information architecture even gets some love!
We’re really having fun digging into all the useful things we can do now that our customers have 37signals IDs. The Launchpad is one of those playgrounds.
Last night we added deep links to Basecamp accounts. Deep links let you jump into an account without having to first log into the account and then choose where you want to go.
For example, deep links for Highrise let you jump right to your deals, cases, tags, tasks, or contacts. Deep links for Backpack let you jump right to your calendar, pages, reminders, or journal. And now deep links for Basecamp let you jump right to one of your five most recently accessed projects.
There’s more to building a great product than just studying the market or the technology or competitors. You need to have taste too. You need to understand what “great” means in a big picture sense, not just in your chosen field.
Great products, according to Mr. Jobs, are triumphs of “taste.” And taste, he explains, is a byproduct of study, observation and being steeped in the culture of the past and present, of “trying to expose yourself to the best things humans have done and then bring those things into what you are doing.”
Want to build a great iPhone app? Go listen to Billie Holliday. Trying to design a piece of hardware? Visit a Frank Lloyd Wright house. Aiming to write great marketing copy? Read Aldous Huxley. Need a color scheme? Go to the museum and check out some Mark Rothko paintings.
Studying masters in a wide range of fields is how you learn greatness. Their creations may not have a direct, instant benefit on whatever you’re making, but soaking them in will change the way you think and the decisions you make. (Side benefit: You’ll be a lot more interesting person too.)
Men don’t like appliances. We want things that can do lots of different things, that we can tweak and fiddle with, and then argue with each other about which one is better. Women aren’t like this, and because of this I have a feeling that it’s women who actually determine the eventual winners in consumer tech.
—
Ultimi Barbarorum on the iPad. Who knows if it’s true. But I can say this, whenever we hear praise from women on a product, it gives me more confidence that we hit the “useful” mark.
Pages 13 & 14 of the January issue of Interface (PDF) feature an article about Jason and 37signals. Interface is a publication of the Chicago chapter of the American Marketing Association.
Of all the sources of funds for an early stage venture, revenue is the most compelling demonstration of traction. Too many entrepreneurs view fund raising as an accomplishment in and of itself…A lot of what’s written about Silicon Valley entrepreneurship is actually part of a sales pitch or positioning for the venture ecosystem.
A few weeks ago we posted about our new way of working. Small teams of three, two-week iterations, and two-month resets.
First iteration
For the first two-week iteration, Team Bravo took on a revamp of our customer forums. For a couple of years we’d been using forum software called Beast. It served its purpose well, but it was time for something better.
The forums were structured in the traditional way: They were separated by product and grouped into categories. There were forums for feature requests, troubleshooting, how-tos, etc. It worked well enough, but it really wasn’t a good match for the primary use of the forums: asking and answering questions.
We also didn’t have any formal spam protection on the forums so every day we had to go in manually and clean out spam. Plus, the anonymity of the forums led to the common devolution of discussion seen across anonymous forums across the net. We had to do better.
So Team Bravo pitched a total re-do. We accepted.
A change of direction
The early mockups for the revamped forum followed the structure of the old forum. Products and categories. We fell into the trap of redoing something by using the old as the guide for the new.
But a few days in we shifted directions and decided to structure the forums in more of a Q&A format and less of a “subject” and “body” format with the usual categories. 37signals Answers was born.
How it works
When you visit 37signals Answers you are shown a list of the products supported by Answers.
81% of tech company founders came from “regular” schools as opposed to elite institutions. Also, young guns may get more attention from the media, but most tech companies are founded by people who are out of school 13+ years.
Always interesting to see western and eastern characters intermingling.
Who are 37signals?
Jason Fried, David Heinemeier Hansson, Ryan Singer, Sam Stephenson, Sarah Hatter, Jamie Dihiansan, Michael Berger, and Josh Peek in Chicago, Matt Linderman in NYC, Mark Imbriaco in Wake Forest, North Carolina, Jeremy Kemper in Pasadena, California, Jeffrey Hardy in Vineland, Ontario, Joshua Sierles in Granada, Spain, Jason Zimdars in Oklahoma City, Craig Davey in Ottawa, Ontario, and Mr. Jamis Buck in Caldwell, Idaho.
