Jakob Nielsen says mega drop-down navigation menus work well.

Given that regular drop-down menus are rife with usability problems, it takes a lot for me to recommend a new form of drop-down. But, as our testing videos show, mega drop-downs overcome the downsides of regular drop-downs. Thus, I can recommend one while warning against the other.

We’ll +1 that. A good, related example from our world: The project switcher in Basecamp.

Design Decisions: Basecamp Project Switcher [SvN] explains how we redesigned the project switcher from a normal drop-down to a mega drop-down.

Ryan adds this:

The original design was a single pulldown (a <select> tag). It was cramped and you had to scroll inside of it to find the project you wanted. Now the five most recently accessed projects have big easy-to-click targets, and you don’t have to scroll to see them. They’re all laid out in big type. The result is that you can navigate between the most recent projects without squinting and leaning close to your monitor. It’s really comfortable. Then since we had the free space inside the project switcher, we could also offer a big selection of more recent projects in a pulldown with a bigger font size. So in the cases where you need to dig beyond the last 5 projects, you can still do that. But most of the time it’s super fast to pop open the switcher and just click on one of those big targets without fussing around in a pulldown.

Another nice example of what Nielsen is talking about can be found at the Rails Guides site.

Last week David and Ryan were working together on a new Basecamp feature that provides a link to a milestone on a to-do list if that list had a related milestone. We’ve always displayed a link to the list on the milestones screen, but we didn’t display a link to the milestone on the to-do list.

After David and Ryan made it work, Ryan wanted to run the implementation by me for a visual review. We ended up making some minor changes to the implementation based on this review and we wanted to share the quick iterative process we used to get there. Ryan and I often work this way either via IM or Campfire.

While the position of the implementation changed, the biggest change was the wording. I think this is a great example of how words can make or break a feature.

Here is the relevant part of the chat transcript with inline images from that conversation (some parts were removed since they weren’t relevant to this post). You’ll see we spent just under an hour on this:

(14:35:37) Ryan Singer:

Recent posts at the 37signals Product Blog:

Multiple products
How a business school student uses Highrise and Backpack to aid in his internship hunt
“Without Highrise, I’d still be sputtering along with a series of file and folders on my Mac. That process would dramatically slow me down, as I’d have to keep paper to do lists all over the place (and paper doesn’t send you an email reminding you to get on the ball, but Highrise does).”

Basecamp
Basecamp helps Peek team deliver value and affordability
“We early on split into multiple projects. Peek had a lot of concurrent projects from building the Peek device, to nailing down our PR/marketing strategy, to building the email servers, the list went on and on. We built projects for many of the streams, particularly ones with different vendors… but we always kept a main Peek Launch project so we all knew what was going on, from the earliest sketches of the device to the final excel sheet of software bugs, Basecamp kept us in touch. The highs and lows of starting up Peek all live in our Basecamp message history!”

Moses says, “Tools like Basecamp need to be part of every small business’ process”
“Today, most companies have either laid off staff or placed a hiring freeze, which means, companies require more out from their team than ever before. Where we’ve seen Basecamp add a ton of value with our client work, is the process in which the productivity of the team members raises to a higher level, where smaller teams are now producing more in less time; because, where before time was wasted on minuscule items and the back and forth, now time is invested in output and getting projects done on time.”

Last Friday (March 20) Highrise turned two. We couldn’t be more proud of how much it’s grown since it popped out of our dev servers and onto the internet. Here’s the original post that launched Highrise back in 2007.

For the past year or so, Highrise has been our fastest growing product on a month-to-month revenue growth basis. And lately it’s really taken off. We see Basecamp-like growth patterns which has us very excited.

For fun we’ve posted some growth charts below. We love the slow and steady curves. No sharp bull or bear markets — just steady predictable growth.

BTW: Highrise Deals were launched last October so the chart is shorter and steeper. We expect this to take on a more steady form as time goes on.

To everyone who uses Highrise: Thanks so much! We really hope you’re finding it useful. To those who don’t, how about giving it a try? It’s the best way we know to keep track of who you talk to, what was said, and what you need to do next. It helps you prepare for that next call, that next meeting, that next conversation. You’ll be amazed at how amazed other people are when you’re better prepared.

Last month I suggested that learning from failure was overrated. My point was that learning from failure may tell you what not to do the next time, but that doesn’t tell you what to do next time. I believe paying more attention to your successes leads to better outcomes.

A couple of days ago the New York Times ran a piece called Try, Try Again, or Maybe Not. It refers to a recent Harvard Business School study that found that when it comes to venture-backed entrepreneurship, the only experience that counts is success:

Already-successful entrepreneurs were far more likely to succeed again: their success rate for later venture-backed companies was 34 percent. But entrepreneurs whose companies had been liquidated or gone bankrupt had almost the same follow-on success rate as the first-timers: 23 percent.

I was thrilled to see this. I’ve never understood Silicon Valley’s obsession with failure. Many investors and entrepreneurs out there believe that you should fail a few times before you succeed. That the people worth funding are the people who’ve failed a few times. I’ve heard from a few VC who won’t fund an entrepreneur until they’ve failed at least once. I don’t get that.

Mark Pincus, founder and chief executive of Zynga Inc., (and Tribe.net before that) says “As an entrepreneur, you have to get used to failure. It is just part of the path to success.”

What? Failure is part of the path to success? This industry’s obsession with failure has got to stop. I don’t know when it became cool or useful, but the industry has been steeping in it for so long that it’s become normal to assume failure comes before success.

Don’t be influenced by this. If you’re starting something new go into it believing it’s going to work. You don’t have to assume you’re doomed from the start. You shouldn’t believe your first idea won’t be your best one. And you definitely shouldn’t treat your first venture as a stepping stone towards something else. What you do now, what you do first, can be the thing you do well for as long as you want to.

Also, don’t let the old “9 out of 10 new businesses fail” cloud your vision. It has nothing to do with you. If other people can’t market their product that has nothing to do with you. If other people can’t build a team that has nothing to do with you. If other people can’t price their services properly that has nothing to do with you. If other people can’t earn more than they spend that has nothing to do with you.

Yes, starting a business is hard. And you certainly could fail. I’m not suggesting failure isn’t an option. I’m only suggesting that it shouldn’t be the assumed or default outcome. It doesn’t need to be. Have confidence in your ideas, in your vision, and in your business. Assume success, not failure.

Oh, and one more thing… While I liked the article, this part of the study made me gag:

Success was defined as going public or filing to go public; Professor Gompers says the results were similar when using other measures, like acquisition or merger.

Going public, being acquired, or merging with another company is a skewed measure of success. It’s easy to measure for a study, but it’s barely what really defines success for most entrepreneurs. How about sustainable profits, loving your work, and making a dent in your universe?

There are two common issues people face when trying to get others onboard with using 37signals tools:

1) “The IT department doesn’t like employees doing anything outside of its firewall.”

2) “I love your tools but I can’t get the rest of my team (or my clients) onboard with using them. They keep using email instead because it’s what they already understand.”

We’d love to hear solutions you’ve come up with for these trouble spots.

For #1, have you gotten your IT deparment to green light 37signals apps? How did you do it? Any suggestions for others who face the same battle?

For #2, how do you get busy people/clients to start logging in and using 37signals apps instead of messy email threads, phone calls, or whatever? Any suggestions for others who are in the same position?

Leave a comment here or write us at email[at]37signals[dot]com.

Scott Semple asks:

Like crack cocaine, we are using a little more of each of your products each day… Now I’m at the point where I have to pause and ask myself, “Is my next piece of communication best disseminated as an email or a comment on a milestone in Basecamp? An email or a note to staff in Backpack? An email or a note in Highrise? An email or a chat message?”

I’ve also just enabled the global RSS feeds for each of the above, so I’m starting to fantasize that in-app comments and reviewing RSS may reduce the email glut.

Anyway, I would certainly be keen to hear how 37signals uses their own products on a day-to-day, piece-by-piece basis. I suspect that other customers would be keen on reading that as well.

First off, there’s no “right” way to decide what goes where. We keep our products simple in part because it allows people to decide for themselves on a system that’s best for their needs.

One thing I know plenty of customers do is use Highrise as a sales funnel. Any pre-project communication goes there. Once they win the deal, they move communication with that person/company into a Basecamp project.

For us, that method wouldn’t really apply (no sales funnel). I’d say our process is an unstated approach that goes like this:

1) If it’s a comment revolving around an item that’s already posted somewhere, we’ll put it up as a comment to that item.

2) If not, does it relate to one (and only one) project in Basecamp? If so, we’ll generally place the communication within that project.

3) If still no, then we’ll decide between the other apps. If it’s an internal item, it goes in Backpack. If it’s an external conversation with someone outside the company, it goes in Highrise.

Some examples…

Our conversations about the book go in Basecamp:

That way we can share them with our book agent and publishing company easily. If there’s something we want to discuss internally about the book, we post it as a private item so only we can see it.