Chris asks:

What is your opinion of “stories” which some web development shops write? A Ruby on Rails development shop I have worked with writes a “story” about every piece of functionality they intend to develop. They use those stories to ensure all customer objectives are met. They’re similar to use cases (maybe identical!)... functionality represented as a sequence of simple steps in writing.

We believe in interface-first driven development, but when the UI or feature needs some further explanation we write a story.

A story is usually a paragraph or two. Sometimes it’s 5 bullet points. It’s not an in depth dissection of a feature, or a technical discussion of what needs to be implemented. It’s not a functional specification. It’s simply a general idea of what the feature is about and why it’s valuable.

For example, we’re working on some stuff for Backpack right now. One of the areas we’re looking at is making it more obvious someone changed a page since your last visit to that page. The story might go like this:

Right now it’s tough to know if a Backpack page has been changed since the last time you’ve seen it. If I’m sharing a page with Bob, and Bob adds a new to-do list or a note to the page, it should be clear to me the page has changed next time I visit that page.

This story may be enough to explain why the mockup we design has a yellow strip at the top saying “Bob changed this page. See the changes.”

The story serves to add some context. It doesn’t need to say exactly how to solve the problem, it doesn’t need to refer to specific design elements, and it’s not technical. It’s just a statement of why something is a hassle (“don’t know the page changed”) and a general idea of how we can make it better (“make it clear the page changed”).

The actual solution is presented in the interface design. We may go with a yellow strip or some other notice. We don’t know yet. We just know it should be clear and obvious. The rest happens as we toss around some design ideas.

We’ve definitely found stories to be handy summaries of big picture ideas. But it’s still the interface that drives almost all of our development.

Got a question for us?

Got a question about design, business, marketing, etc? We’re happy to try to provide some insight into how we’d tackle the problem. Just email svn [at] 37signals dot com with the subject “Ask 37signals”. Thanks.

Software can get crufty quick — especially around the edges. We work hard to keep the cruft out, but we can’t win ‘em all.

We’re currently digging through Basecamp looking for those dusty corners so we can clean them up.

Here’s some of the stuff we’re currently unhappy with.

To-do list permissions and exceptions

Basecamp’s to-dos are pretty clean, but there’s still some nastiness depending on the situation. In fact, we’ve dug ourselves into a funky permissions hole trying to deal with a bunch of odd scenarios and exceptions.

In order to get a handle on all the conditions, Jamis whipped up a terrifying chart. Let’s cringe at it together:

There’s too much “this person can do that if…” and “that person can’t do that unless…” in here. Ugly.

Sometimes this chart results in a to-do list view that looks like this:

Those red dots mean “you can’t check this off”—stupid, isn’t it? We agree. We’re currently working on a major simplification of to-do permissions. We’ll be able to burn the chart and no one will see a weird red dot again.

Global access permissions

In Basecamp you can grant people permission on a per-project basis. That works pretty well, but sometimes you want to give a co-worker access to all projects or no projects all at once. We let you do that, but we’re not happy with the way we do it. Here’s what it looks like:

Those buttons bother me. I don’t like they way they look, how they’re stacked, or the jagged right margin. The whole thing just doesn’t feel right. The “Grant” or “Deny” (or “Revoke”) language sounds too militant. The “Change access globally” is a bit confusing too. We have some ideas on how to simplify this process and make it a lot more powerful and flexible at the same time.

Adding a client to a project

When we originally build Basecamp we had a firm-client model in mind. A firm would work with a single client on a project. The firm might want to add that client to the project, or the firm could just make the project an internal project that only they could see.

That model still holds, but now you can add multiple “clients” to a project. Part of the modern problem is that “clients” isn’t really the only way to describe these other companies. They could be collaborators, departments within the same company, divisions of the company, etc.

We have some things to clear up there, but something we’re not thrilled with is how we present this on the new project screen:

This option, below the “Name the project” field, feels slapped on ‘cause it wouldn’t fit anywhere else. It’s in the form of a sentence with a long link and has another sentence below it. You can’t add more than one client/company at a time to the project either. It works, and we don’t get many questions about it, but it’s something we’re not happy with.

We’re on it

From time to time it’s a good idea to walk through your product with fresh eyes. Sign up for a new account, turn off your admin access so you can see what other people see, scale back your permissions and experience that experience. You’ll likely find a bunch of UI and customer experience dust bunnies you didn’t know were there.

Luke asks:

Do you have any plans on ever releasing your applications for purchase to be run internally at a company?

It would be highly unlikely that we’d sell installable software. This question is actually more about business than it is about software.

We’d be a different company

Here’s why: We would have to be a fundamentally different company to develop, sell, and distribute installable software. We probably couldn’t be as small, we certainly wouldn’t be as agile, and we definitely wouldn’t be as happy.

If we built installable software we’d have to spend a lot more of our time on technical support, write a lot more documentation, slow down our development process, and lose a fair bit of control over our customer experience. For some companies this wouldn’t be a big deal, but for us it would be a real drag.

Hosted = Controlled development and deployment environment

Software is hard enough to get right when you control the variables. With web-based software we have a single code base optimized for a single operating environment. We’re in charge of putting together the optimal software and hardware set-up to run our products. The significance of this can not be overstated.

Installable = Lots of room for things to go wrong

With desktop or remote server based software you may have a single code base (as long as you haven’t made custom versions for this, that, and the other customer), but you have to deal with endless operating environment variations that are out of your control. When something goes wrong it’s a lot harder to figure out why if you aren’t in control of the OS or the third party software or hardware that may be interfering with the install, upgrade, or general performance of your product. This is even more complicated with remote server installs when there may be different versions of Ruby, Rails, MYSQL, etc. at play.

Backward compatibility headaches

Further, when you sell installable software you have to deal with backward compatibility. If your latest version is 3.2, and a few thousand people are still running 3.0 instead of 3.1, what does that mean for your upgrade procedure? And what about those people still on 2.9 or 2.8.7? Maintaining backward compatibility is probably the biggest impediment to software progress.

Of course web-based hosted software has similar issues in regards to different browsers and different versions of those browsers, but this issue is the same for web-based installed software. This negative is a wash.

Upgrade cycles

Lastly, web-based software can be updated and improved instantly for every single customer at the same time with no effort on their part. We can update the software daily — or multiple times a day — without placing any burden on our customer base. Installable software usually has slower upgrade cycles because it makes more sense to group releases together so you don’t have ask people to download updates every day.

None of this is to say desktop or installable software is dead or uninteresting to us as consumers. But as far as building it goes, we think we’ll stick to what we love: Developing and selling web-based hosted software.

In a quest to clean up the inbox I’ve been unsubscribing from a bunch of lingering newsletters and merchant email alerts.

Annoying: Some big name brands (J. Crew, FTD, BestBuy, etc.) say it will take between 5-10 days to be removed from their list. During that time they can still send you emails. And they have.

I can order a shirt today and have it waiting at my door tomorrow afternoon, but it takes 10 days to remove my email address from a database? That doesn’t seem like a genuine effort.

I feel like I get emails starting the next day when I sign up for a list. But 10 days to be removed? Something isn’t right.

I realize that many of these companies outsource their mailing lists to third party providers. Perhaps they provide a list of changes to the provider once a week or something, but it sure feels like the unsubscribe process could be swifter if someone cared a tiny bit about the customer experience.

Along with Jim Coudal of Coudal Partners and Carlos Segura of Segura Inc. and T.26, we’re back with a one-day conference on design, entrepreneurship and inspiration on Chicago’s IIT Campus. The date is Friday, January 18th. The last SEED conference sold out quickly so don’t miss this one. For more on what it’s all about, check Mike Rohde’s illustrated notes from the first SEED and these reviews: one | two | three. We look forward to seeing you on January 18th.

Mike asks:

...I imagine that there isn’t much of a hierarchy [at 37signals]. But in situations where you arrive at an stalemate, and a decision needs to be made, who makes the call? I am referring more to design decisions rather than business decisions.

We’re rarely find ourselves in a design decision stalemate. A stalemate means someone has to ask permission to do something and the other party says no. A battle ensues with neither side backing down.

Getting real breaks stalemates

We don’t get into those battles. If someone feels like a change should be made they usually either just 1. make it, or 2. mock it up to show it off before making it. Once it’s real we can all make a more informed decision about it. At this point a stalemate is the least common outcome. Stalemates are often the byproduct of abstraction or illusions of misunderstanding. Getting real breaks stalemates before they even happen.

Diffuse through responsibility

However, when we do run into two strong opposing viewpoints on a particular design decision, we usually diffuse the tension by making the person championing the progressive idea responsible for any issues related to their decision.

For example, if Ryan wants it this way, and I want it that way, I might acquiesce say “Ok let’s go with your solution, but you’re responsible for any support emails, confusion, or questions that are directly related to your implementation.” Ryan can accept that responsibility and move forward, or he may say “It’s not worth it right now, let’s just go with your solution.” Or maybe we’ll both agree to not do anything right now. That’s a reasonable decision too.

Decisions are temporary

Since we believe decisions are temporary, we’re open to revisiting, repairing, or replacing a decision if it doesn’t pan out. No one at 37signals is personally invested in a bad decision. If it’s bad, we know it’s bad and we do what we can to make it better. Instead of throwing good money after bad, we get rid of the rot and try something else. You can usually tell pretty quickly if something isn’t going to work out. We don’t pretend we can get it right all the time.

So if you hit an impasse, ask one party to step up and take ownership of the implementation, support, and customer feedback loop. They may feel it’s worth it and move forward. Or they may have second thoughts. Either way, it’s a great way to move past a stalemate if that’s where you find yourselves.

Keep the questions coming

Got a question for us? Please send it along to svn [at] 37signals dot com and use the subject “Ask 37signals”. Thanks again!

The Guardian reports on an interesting study that suggests police should skip photofit composites and go with exaggerated caricatures of criminals instead.

A study at the University of Central Lancashire found that over-emphasising prominent features on people’s faces made them twice as easy to identify than before… On average, a photofit face was correctly identified 20% of the time, compared with 40% for the caricature, according to a report in this month’s Visual Cognition journal.

That’s really interesting. Getting closer to the truth by warping reality. Point out what’s different, what’s obvious, what’ll really help to identify someone. After all, positive identification — not photorealism — is the ultimate goal.

If the guy has a distinctive chin, play that up in the sketch. If he has distinguishing eyes, highlight them. If he has a unique crook to his lips, draw ‘em so you can’t miss ‘em.

A photorealistic sketch is an exercise in accuracy, but an exaggerated caricature is an exercise in identity. Of course this is just one study, but it’s an interesting look at what really matters to get a job done.

Yesterday Amazon released an eBook reader/service called Kindle. Yesterday a lot of people wrote reviews of Kindle. Yesterday barely anyone on the planet had actually used Kindle, but they just couldn’t wait to tell you how much it sucked.

There’s a lot of premature hating going on. Hypercritical negativity is in season among a large set of the web’s independent tech observers.

Most of the 300 reviews on Amazon’s Kindle product page were overwhelmingly negative. Most of the blog posts on the web were overwhelmingly negative. Much of the tech news/review sites were overwhelmingly negative. Again, few people had actually used a Kindle. And none of the reviewers had a chance to live with one yet.

One thing we have all had a chance to live with are books and newspapers. They’re stacks of dead trees. Bulky blocks of words. They take up a lot of space, need to be pushed around by plane and truck, and quickly fill up your carry on if you want to take more than a couple with you. When you buy a book, you’re buying a tiny piece of furniture that you usually carry with you the rest of your life. Moving? Time to pack up the books!

I know book lovers like to talk about the permanence of books, but I think that’s overrated and over-romanticized. Some people love to build extensive physical libraries to house their books. Not me. I’d prefer to read it and move on. Sure I could buy a book, read it, and sell it or give it to a friend or a library, but I’m just looking for the knowledge, not the inventory or an exit strategy.

That’s not to say books are bad. Books are wonderful, important things. But they’re also terrible at a lot of things. You can’t search paper. You can’t bring that many with you at once. They suck up valuable resources in production and transportation. They take up a lot of space. They leave an artifact when you’re done with them.

I’m not suggesting we get rid of books as we know them. Ever. I’m suggesting there’s plenty of room for another model that shines the spotlight on convenience rather than the legacy attributes of print.

The Kindle sounds like a really interesting device with an interesting value proposition. It’s not tethered to a computer. That’s big. It’s more about the convenience and benefits — your books, small size, instant new books, morning paper delivery — than the physical product or the technology.

Kindle isn’t the first eBook reader, but it’s the first portable bookstore. That’s novel. A book in 60 seconds whenever I want it at used-bookstore prices. And the daily push newspaper feature sounds like one hell of a bonus. I love getting the paper, but I hate getting the paper. What a complete waste of resources just so I can get yesterday’s news. I like that there’s some genuinely new thinking behind Kindle. We should embrace this, not tear it to shreds before it even has a chance.

So I’m going to withhold judgement. Our Kindle arrives today. We’re going to live with it for a while and then we’ll write an honest review. Until then…

Full Disclosure: Jeff Bezos is an investor in 37signals.

Putting together a new presentation for a conference/meeting can be stressful. What do you say? How do you say it? How do you structure it? What’s first? What’s last? How do I pull it all together?

I used to build my presentations first and then talk them out second. I’d make an outline or create some slides to get started. I’d try to think logically about how to begin, how to fill the middle, and how to end. Then once I had all the slides done I’d talk through them for the first time. I usually wasn’t happy with the outcome. I’d over-think and under-deliver. This process churned out clinical, sterile presentations. Yuck.

Last year I tried something different. I just started talking (out loud, to myself) about something I was passionate about. Maybe I’d look at a screen from Highrise and just talk about it. Why did we do that? Why did we make this decision? Or maybe I’d just stat ranting about my aversion to functional specs or meetings. Or maybe I’d just go off about collaboration and productivity. Or maybe I’d gush on about VC investments or the state of small business software.

Whatever it was, I’d just talk first and write second. I found that going off on an unstructured rant would expose all sorts of fresh ideas. In 30 minutes I could churn out four or five solid directions instead of spending 30 minutes outlining just one.

I also found that the ideas developed more naturally this way. I made better points and the persuasion was more powerful. Talking without a plan mined thoughts I didn’t know I had.

I encourage you to give this technique a try sometime. It works really well for me. I hope it helps you.

I’ve always been fascinated by factories. The automation, the assembly, the highly specialized single-purpose machines, the absolute precision. Discovering how things are put together is a great way to learn about how things work.

I’ve long been a fan of the How Stuff Works website, but recently I stumbled upon the How It’s Made TV show on the Science Channel.

How It’s Made is simply narrated, sparsely produced, and puts the spotlight on the factory process. Each episode usually focuses on about four different items. So far I’ve seen segments on tape measures, book binding, steel wool, umbrellas, cotton yarn, padlocks, violins, self-inking stamps, and synthetic leather. It’s fascinating stuff. I especially love when they break down lightning fast mechanical processes in slow motion.

If you get the Science Channel (it’s in the 200s on my Comcast cable service), check out How It’s Made. You’ll learn a lot and have a new found respect for those every day items you take for granted.