Archive for February, 2007

Simplify the problem first!

Friday, February 23rd, 2007

1) Simplify the problem first!

Tools should be designed with one problem in mind. By losing focus on the one problem, they don’t solve it! Too many applications are designed to match every possible need. They said “this problem is complex, it requires a complex tool”. They actually are looking at too many problems. Pick one, let someone else solve the other ones.

Highrise simplified the problem down to the need to keep track of people and related actions. That’s it. No need to replace e-mail or try to be everything. (link to Highrise description)

Facebook solves keeping track of friends and what they are doing
Ruby on Rails solves building web-based database-backed applications
Google solves finding things based on keywords
Anyone have more examples?

2) Complex problems are really many simple problems that need many simple solutions
Highrise solves one problem, e-mail solves a different problem (quick communication), address books solves another problem (storing and organizing contacts). They work TOGETHER because they are compliments that solve different things.

I found this awesome quote from Marc Hedlund about 37 signal’s new contact management program:

“What I like most is that it takes my favorite feature from Backpack, reminders, and links them to people. Rather than having to keep an email in my Inbox to remind me to get back in touch with someone, this will let me sweep all that away, and have the Inbox be an Inbox instead of a half-assed to-do list.

Also, I think a lot of productivity tools assume that they’ll replace all the other productivity tools in my life - like how everything you attach to the “home entertainment” complex wants to be the One True Remote Control you use from then on. I like that Highrise assumes the opposite - it doesn’t replace email, it doesn’t replace address books—instead, it works with those tools.

Let Everyone Participate!

Friday, February 23rd, 2007

Permissions and Controls limit Communication. Let Everyone Participate

In reference to: “Preview 2: Highrise permissions and groups
37 signals decided to default to let everyone view anything posted within their new contact management application. Knowing that some people wanted to make certain things private, they put in the functionality for an individual contact to be limited to the poster, certain people, or a group.
This makes a lot of sense. Let the person who is posting something figure out permissions. Big permission schemas (which I find in big programs like Sharepoint) are a PAIN IN THE ASS. Seriously. And they take the wrong approach… by default they assume people should be limited in what they can see. I like this “default to everyone” approach.

Of course, you should impose some limits on who can change what. My idea would be to let everyone be able to change everything with approval of the author (except for admins).

Jason from 37 signals has a great post about control vs. communication:
[in reference to customers] ” They’re almost always asking how to prevent someone from doing something.”
“Preventing someone from saying or doing something often breaks these free flowing communication channels and introduces miscommunication or silence—two cancers of collaboration.”
When they ask how to prevent people from doing this or that I usually reply with something like “Have you tried asking them not to do this or that? If you don’t want them to upload files just ask them not to. If you don’t want them to create to-do lists just ask them not to. Communicate with them as you would if you weren’t using software.”