In praise of Backpack

After my list of minor quibbles with backpack, i think it’s time for a little praise (and not just because of the feeling that someone’s watching over my shoulder). Today i went out with two dear friends, one of whom asked me why i was so enthusiastic about backpack. After all, it doesn’t do much you couldn’t have done with some hand-coded html ten years ago. The difference lies in the how and i like backpack for the same reasons i prefer mac os x over linux: it’s easy to get started, it’s easy to use, it’s hassle-free.
As a web-application, backpack does many things extraordinarily well: it makes better use of ajax than any webapp i’ve seen before, imho even better than everybody’s darling gmail. But besides being an excellent web-application, backpack has some great qualities that more applications in general should take to heart:

  • You can just dive in. Play around with it for a few minutes and you’ll have a pretty good understanding of its capabilities and limits. There’s not much documentation available, at least that i know of, but you’ll get up to speed with backpack so easily and fast that docs aren’t really necessary.
  • Backpack is rather limited in its form. You’ll get non-hierarchical pages, with sections for different purposes in a fixed order. This fixed form, fixed scope encourages you to become creative to get the most out of it. Need to assign tasks to a particular person for a shared project? Better find your own way of handling it, backpack won’t enforce its way on you to do this “properly”. Some might call this a lack of features, i call it making users think where it makes sense. This tip for creating hierarchical structures in todo-lists is a great example of what i’m trying to convey here. There’s no right or wrong in using backpack and it won’t make you feel guilty down the road for not knowing about best practices. It’s just a tool you can facilitate in whichever way you like, which is great for the same reason that makes paper such a tremendous tool for notetaking.
  • Backpack makes great use of the blank slate stage. Off the top of my head, there are two problems with applications devoid of real data. The first problem is that people will judge your application on their first impression. If you don’t win them right away, they’ll never appreciate how great your application could have been, had they been using it for six months. The second problem is, it’ll leave users clueless about how to get started. Getting started is very different from having accustomed to something. Encouraging your users to use your application, showing them how to get started is fundamental to the lasting success of an application, and lasting success is fundamental if you’re using a subscription model for your application because the deal isn’t done when the checks’ been signed.
  • 37signals has announced that they’ll offer an api to interface with backpack. This kinda thing could solve some of my earlier grievances and i’m very fond of this solution as it allows backpack to grow in capability without risking feature-creep. Nonetheless, i consider some of the things in my earlier post to be viable as core features and i really hope they’ll make it in at some point in the future.

Oh and that conference i mentioned briefly before: i’m going to reboot7 june 10-11 and you can track my travel plans @backpack (that page is gone now). Jason Fried and David Heinemeier Hansson of 37signals will be there as well (here’s a full list of participants), so perhaps i’ll even be able to ask a few questions about backpack in person there. So excited!