Blog

Getting Things Done

Monthly Archives: October 2009

Piloting an airplane

October 29 2009 - Design - Write Comment

I studied aerospace engineering because airplanes are an amazing mix of every possible high-tech industry: Advanced composites, radars, fluid mechanics, electronics, economy, operating systems…

But it didn’t come until later that I noticed that airplanes were also about design for human interaction. The pilot is constantly overwhelmed with information, and it’s important to let him focus on what’s important.

Airplanes can predict, more or less, which maneuvers are potentially dangerous for the flight and prevent you from doing them. Manufacturers choose to do this in different ways:

  • Alert whenever you’re doing something dangerous, but still do it. Which is potentially dangerous.
  • Other would prevent the pilot from doing the dangerous maneuver, thus limiting his ability to act against common sense in difficult situations.
  • Others chose a smarter approach, based in active materials: The control level, which is usually easy to move, becomes stiffer when you’re trying to do something dangerous.

The latter is another great example of suggesting over forcing. We could draw an analogy with web apps. When typing a field that is too long, or a password too weak, pages can:

  • Tell you it’s wrong, but still accept it, which is noisy.
  • Reject it and force you writing the required length. Which leads to hard to remember passwords.
  • Suggest with proper design how long something should be.

I can also see how cars could use this, not to limit speed but to suggest it’s not right to go above the speed limit by making the pedal harder to push beyond a limit. This way, if you are in an life emergency you will still be able to override this behaviour.

For Teambox 2, we chose permissive lengths over artificial restrictions. Although it is true that many may benefit from an very clear length limit in their data, if that’s the goal.

Missile Command is fun atari game

Pablo Villalba

Teambox founder

@micho

MrProper: Cleaner blocks in Ruby

October 28 2009 - Programming - 13 Comments

I love blocks in Ruby. I use them all the time: each, collect, map, etc. And they’re a great way of making code more readable and fun.

But I don’t like it that when I call them for a nil object, they raise an exception. So I have to add an if around them, and my codes becomes ugly. I get this often when trying to evaluate params for a form that may not have a given field, like checkboxes.

A fix for this would be using an or, so if the object is not defined the blocks will use the empty array and not get run. Like this:

But then I remembered why I love Ruby: You can rewrite everything! So I came up with #is_defined, which you can call to clean up your code in this way:

Since this is pretty cool, I turned this into a MrProper, a plugin that you can download at Github. Just drop it inside config/initializers/mrproper.rb

Note: You could also overload NilClass with methods called each, map, etc. The problem with this is that other libraries may use exception control to manage the flow in part of their code, so these solution could break things by failing silently. Therefore, it’s better to explicitly call a method to avoid errors and be aware that they won’t rise.

Update:
Thanks to @raganwald, @peteforde and @heycarsten for the interesting links. There are better alternatives to this, like andand. I enjoyed the posst about Array-ifying values and Self confident code, too.

Pablo Villalba

Teambox founder

@micho

Persuasive design: Suggesting over forcing

October 28 2009 - Design, Teambox - 3 Comments

This past week we stopped using lighthouse and w’ere just using Teambox 2, to manage Teambox 2. We’re eating our own dog food!

In Teambox 2 we’ve reworked tasks so that they are more like conversations. This is great because it allows you to post links that will be useful for tasks you have to do weeks later, or report what you’ve done by attaching files, or start conversations about important issues.

An issue we initially had with this is, since every task is displayed in the sidebar, that we need to keep the sidebar uncluttured. One way of doing this is avoiding lines wrapping, so you need to have titles as concise as possible.

While forcing the user to do this by limiting the number of characters they can type, it’s not a good idea because sometimes it has to be so. We preferred to suggest the right length by making the font size bigger. If you’re trying to make a field too long, you’ll notice the text gets clipped and that’s a bad thing.

Suggesting is better than forcing. Visual design is better than words. Users can be guided not only by words, but also by design clues. Width and font size help in this case. Colors and placing can be important, too. For everything else, remember to use proper wording for every section and action.

Suggesting the right width

Same goes on for the tweet-like field in the project field, where you can post comments or share interesting links and insight:

Activity comment field

Pablo Villalba

Teambox founder

@micho

Meet us at the RailsConf!

October 27 2009 - Teambox - Write Comment

Teambox will be attending the Amsterdam RubyEnRails conference. (Oct 30th – Nov 1st)

Florian, Andrew will be there meeting up with @norbertc and other cool rails developers.

The conference will be covering Rails 3.0, jQuery, Prototype, scaling Rails apps and some new community concepts. If you happen to be around, we’ll meet you in a few days! Which will be exactly at the same time Teambox 2.0 comes out!

RubyEnRails 2009

Pablo Villalba

Teambox founder

@micho

Development Lobster!

October 26 2009 - Programming - 11 Comments

I used to always lose my keys, so I a long time ago I bought a giant lobster keychain so that it would be obvious If I had my keys are not.

lobster_pants

So in Teambox we are getting to the point where we have two deployments at every moment: one in our local computers for development, and one in a shared server which we use to test the app in a real-world scenario.

Sometimes you’re changing stuff in the app and you refresh the browser to see the changes. But if you mistakenly reload the shared server, you won’t see the changes and never know why, thinking there’s an error in your code.

We keep forgetting when we’re in development but what can we do?

Lucky Development Lobster came to the rescue!

Whenever you’re editing something locally, Development Lobster will be there so you can tell the difference! No more confusing mistakes, no more frustrations!

development-lobster

development_lobster

Andrew Brown

Andrew Brown

Forgot Password done the right way

October 24 2009 - Design, Teambox - 12 Comments

Most sites today still are vulnerable to a simple and stupid attack: Password reset.

When a user forgets his password, he should have a way to retrieve in his email. Which needs a confirmed email address, that’s reasonable. But then, in many apps it’s possible to reset somebody’s password by hitting the I forgot my Password button and entering their e-mail so their new password is sent there.

This doesn’t make any sense:

  • I won’t remember the automatically generated password you’re sending me.
  • Other users can reset my password.

Worse offenders will store your password in the database in a retrievable format, which will email you your password. A site should never store a password somebody can retrieve, because of the obvious security risk.

We’ve given this some thought for Teambox 2.0, and this is the way we think Password Retrieval should be done:

  1. User mistypes or forgets his password, so he hits I forgot my Password.
  2. An email is sent to him with a special log-in link. The password is not reset.
  3. When following the link, you go to a page where you can choose a new password.
  4. Never store passwords, just one-way encrypted versions of them to compare against.

This way, attackers can’t reset your password and in order to log in, you need to set a password you’ll remember Obvious benefits in both.

Why are most doing this wrong?

key security

Pablo Villalba

Teambox founder

@micho

Designed for Sales vs. Designed for Use

October 20 2009 - Design - Write Comment

When visiting a book-shop, you’ll likely find two kinds of books:

  • Visually appealing, recommended by authorities in the subject, attractive, big font sizes, sometimes hard covers. Most likely to be found by the entrance to be found easily.
  • Smaller books, classified by subjects, not as costly editions and sometimes paperbacks. Look harder for these.

What’s happening here? Don’t the second kind of books’ authors want to sell?

Odds are that probably whoever is looking for them will find them. And they won’t care about fancy looks and big font sizes, because they just want to read that book. The sale has already been done.

In other terms, there are books designed to sell to people who wouldn’t otherwise buy them, and there are books designed to be used.

It’s amazing how more and more money is being put into selling better and getting noticed, rather than delivering contents. Classics managed to get sold without national ad campaigns. Can’t it be done today?

Some ideas on how to get noticed without screaming loud for it (which costs a lot of money):

  • Target better to get noticed. People looking for related products will be more likely to find you if you’re focused.
  • Satify those few who discover you. Make them feel as they’ve just found something special. Nothing is better than a customer with an urge to tell his friends about you!
  • Disguise. In the same way many are attracted by ads and big quotes about how great your book is, a small group will be attracted if you counter-mainstream.

I found a nice example of the third idea in the Aneto soups. Soups that show how natural and healthy they are by not telling you how natural and healthy they are. Classic style:

Pablo Villalba

Teambox founder

@micho

Fun: Beyond usability

October 19 2009 - Design - 8 Comments

Visit a site without a clear objective for its users, and you’ll quit in a blink.

Visit a site with bad usability, and you’ll quit after some frustratied searching.

If a site’s well-defined and usable, you’ll use it when you need it.

But how can you make people come when they don’t need it? Fun is the next big thing!

I like the ideas The Fun Theory came up with. You can bring some attention over everyday things just by making them fun to use:

Nice javascript-driven apps can be fun to use. Fun wording can also help, Feedburner and RememberTheMilk understand this.

What can you do to make your users came back, just for the fun’s sake?

(Thanks for the link, @jandreu. Image by casch)

Pablo Villalba

Teambox founder

@micho

Experts, not managers. Taking your product to the next level

October 18 2009 - Insight, Startups - Write Comment

Thanks, @jordi9, for the conversations that inspired this post. @jordi9 and @jandreu run a spanish event-organization and ticketing site in its infancy now.

So you run a business. You’ve probably been running it for years, or maybe you’re thinking of starting one now. However, you’ve done deep research about its possibilities and environment.

But you feel you’ve already done everything you could come up with to make a great product. Is it the time to look for a new role in your team? Should you look for an experienced CEO with MBAs to take you to the next level? Where can you find insight?

The answer, in my opinion is: While MBAs may be great for running organizations, nobody can ever know more about your product than you. An expert CEO can help you evolve the insides of your company, like human-resources or financials, but he can’t replace the role of the product manager.

If a management guy isn’t the answer, how can you build a better product?

It turns out there are great rsources out there, endless sources of knowledge, that can help you a lot:

You need experts, not managers. Experts have spent years becoming really good at something, and they will come up with great ideas about your product as soon as they see it. Why would you invest years trying to master something that’s not your core business? Ask an expert about SEO. About proper wording to sell. About pricing, servers, design, usability.

You need specialized books and blogs, not general guides. Nobody learns how to program from a single source. The great thing about books on very specific subjects is that they mean something different for each reader. Try getting some of these and read them while thinking how to apply what you’re learning to your product:

I’m just listing non-fiction books. Fiction books are priceless for insight, imagination and writing style. Some, like Atlas Shrugged, come close to philosophical essays every entrepreneur should read.

Lastly, you need feedback from users. Look over their shoulders when they use your product. Learn how they behave. Explain better what they didn’t understand. If something is not being understood, it’s probably your fault.

Pablo Villalba

Teambox founder

@micho