In our previous post, we talked about we modeled our app to make Backbone and Redis integration as seamlessly as possible. Now as we develop our app and start adding it’s vital organs around the skeleton (backbone?) we designed, we need to keep in mind our end goal as we develop the basic “Single User” version, since everyone hates to refactor code.

In this post, we will do a step by step of how to transform that prototype version of the app into something people can actually use. In order to do that, we’ll look under the hood and check out Backbone, Redis, Node.js, Socket.IO and how everything is glued up together.

Backbone and Redis to the rescue

Whenever a user requests a new session, we randomly generate a session id and store that data in Redis. This is done when a user accesses the landing page for the first time and clicks the “Start” button. We use the basic Sinatra session management (cookie based) to identify each user.

Clicking the button results in a post to “/” that retrieves the session id (basically the session model data) as json:

post "/" do
    content_type "application/json"
    {:id => get_new_session}.to_json
end

def get_new_session
    begin
        #generate a key
    end while $redis.sismember("melee:sessions", key)
    $redis.sadd "melee:sessions", key
    return key
end

Now let’s imagine our user (lets call her Alice) wants to invite a second user (Bob) to join her newly created brainstorming session. All she has to do is copy the URL, which by this point is “//ideate” since Ideate is the first step in the process, and share it with Bob.

Bob accesses the URL and triggers the following action on the server:

get "/:id/ideate" do
    @ideas = get_ideas(params[:id]).to_json
    erb :ideate
end

This will render the ideate view inside the standard layout (that includes all the client application code), bootstrapping the application state with this additional data:

$(function() {
    /* bind melee var to global scope to ease debugging */
    window.melee = new Melee({
        /* 
           in case any ideas have already been created,
           before the user opened the link,
           we send them through right away 
        */
        ideas : new IdeaList(<%= @ideas %>, {url:'/<%= @sessionid %>/ideas'}),
        session : new Session({id : '<%= @sessionid %>'}),
        socket_url : 'http://<%= SOCKET_IO_HOST %>'
    });
    Backbone.history.start({pushState : true});
});

So what we have now is a way to access a session, loading the relevant session data, through an entry point. We replicate this behaviour to all the steps in the Brainstorming process, and build the navigation accordingly.

In order to create an idea, or any other resource in our app, we perform an AJAX request to Sinatra and receive a response handled by Backbone that contains the Model and creates the associated View(s). This kind of work is done almost automatically since that’s what Backbone was built for.

post "/:id/ideas" do
    content_type "application/json"

    idea = JSON.parse(request.body.read)
    idea_json = save_idea(params[:id], idea).to_json

    #ignore the following line for now, we’ll go back to it further ahead
    $redis.publish "melee:data:#{params[:id]}:new idea", idea_json

    idea_json #backbone will process this json response automatically
end

The same process is used to create Clusters and to move ideas into clusters, although here we had to hand-code the drag-n-drop behaviour and callbacks so that the proper AJAX action is triggered:

put "/:sessionid/clusters/:cluster/ideas/:id" do
    content_type "application/json"

    add_idea_to_cluster params[:sessionid], params[:cluster], params[:id]
    idea_json = get_idea(params[:sessionid], params[:id]).to_json

    $redis.publish "melee:data:#{params[:session]}:move to cluster", idea_json

    idea_json #bacbone ill proces this json response automatically
end

That action is triggered here:

/* Idea view */

…
events : {
    "cluster:idea:add": "addToCluster",
…

addToCluster: function(ev, clusterView) {

    /* 
      remove an idea from the collection 
      without triggering the remove event on the whole structure, 
      which would cause backbone to try to destroy the model in the backend.
    */
    this.model.trigger('destroy');
    this.model.collection.remove(this.model, {silent: true});

    /* this will trigger an Http PUT in the backend. */
    clusterView.model.ideas.add(this.model, {silent: true});

    this.model.save({}, {success: $.proxy(function(){

        /* manually trigger the add into the correct cluster ideas collection */
        clusterView.model.ideas.trigger('add', this.model);
    }, this)});     
}

And finally, still working our way up the chain, the addToCluster function is bound to the “cluster:idea:add” event, triggered here:

/* Cluster step View */
…
this.clusterListView.bind("cluster:add", this.makeDroppable);
…

makeDroppable: function(clusterView) {

    /* 
      Add droppable behaviour to a cluster in the clusterate view 
      (that is comprised by several clusters, 
      and the form to create a new cluster)
    */
    clusterView.droppable({
        accept: ".idea", 
        drop: function(ev, ui) {

            /*
              when an idea is dropped, hide it and trigger the cluster:idea:add
            */
            ui.draggable.hide('scale', {}, $.proxy(function(){
                $(this).effect('highlight').trigger("cluster:idea:add", ui.draggable);
            }, this));
        }
    }).addTouch();
    /* 
      addTouch is a call to a jQuery plugin 
      that enables drag an drop behaviour on iPad.
    */
},

That was a long chain of triggers! Looking back at it:

• On dropping an idea into a cluster (visually) => trigger “cluster:idea:add” on idea view
• On receiving a “cluster:idea:add” on an idea view => do ajax request on server to update data

What’s next?

Users can already access the several actions to request the entry point views, can create content using regular AJAX calls, and if we have more than one user working on the brainstorm, if that user refreshes the page, he will see the changes others have done. But that’s not good enough.

The brainstorming process needs to happen in realtime. You need to see what others are doing, as another person idea can trigger a new idea of your own, and while you’re focusing on the task of thinking of new ideas, you can’t really waste time refreshing your whole page and have a huge new chunk of information distract you from your strings of thought and take you out of your “flow”.

So let’s look again at the snippet that creates an idea:

post "/:id/ideas" do
    content_type "application/json"
    idea = JSON.parse(request.body.read)
    idea_json = save_idea(params[:id], idea).to_json

    $redis.publish "melee:data:#{params[:id]}:new idea", idea_json

    idea_json
end

This is where our syncing work began. Using Redis PUB/SUB feature, we publish a message to a very specific channel, that is named after our session identifier. That message actually contains the same payload we’re delivering back to the user that made the AJAX call in the first place, just to make things easier in the next step.

Let me introduce you to Node.js and Socket.io

Now that we have started adding a nice (and damn simple) Event Queue system to the actions on our App that alter data, we need a way to broadcast that data to every other user interested in it (users connected to the same session as Alice: Bob, Charlie, David, …)

/*
  Nothing fancy here, 
  just create the socket.io server and prepare the Redis pubsub connection
*/
var io = require('socket.io').listen(8000),
redis = require('redis'),
sessions = {},
rc = redis.createClient(),
pubsub = redis.createClient();

/*
  This will tell node to subscribe to the melee:data:* channels, 
  so that any message arriving on any of those channels will be handled
*/
pubsub.on("connect", function() {
    pubsub.psubscribe("melee:data:*");
});

/*
  When we get a message in one of the channels we've subscribed, 
  send it over to all connected clients
*/
pubsub.on("pmessage", function (pattern, channel, message) {
    var channel_meta = channel.split(":");
    io.sockets.in(channel_meta[2]).emit(channel_meta[3], JSON.parse(message));
});

Hold on a second.

What are these channel_meta[2] and channel_meta[3] thingies ?

Well, when a message is received on a channel we’re subscribed to, the Redis pubsub Javascript API tells us that we will receive 3 parameters: pattern, channel and message.
Here we pick up the channel parameter and split it on every occurrence of “:”, so that way we get an array with [“melee”, “data”, ?, ?] as a result.

To understand what can go in the question marks, we need to look back at the place where we publish data into the redis channel in the first place.

Let’s check out the line we highlighted before:

$redis.publish "melee:data:#{params[:id]}:new idea", idea_json

As you can see, the format is quite obvious. So, the first question mark represents the session ID, and the second question mark represents the specific message title or subject. It’s a good practice to comment these out on your javascript, so that people won’t get confused later on staring at “magic” array index numbers.

The only thing left now, is to let node (socket.io) know what session each socket client corresponds to. We achieved this by doing the following:

io.sockets.on('connection', function(socket) { 
    socket.on('join session', function(session_id, current_user_id, step){

        /* 
          The session id generated in sinatra, 
          passed to the backbone initialization and passed back to node. 
          The same session id used to namespace the redis pubsub channels and objects.

          This the line that will allow us to do the io.sockets.in(session_id) call
          and broadcast the pubsub synchronization messages to each user connected
          on a specific session.
        */
        socket.join(session_id);

        /*
          These are needed later on to send a list of 
          already connected users to each new user entering the session chat room.
        */
        socket.set('sessionid', session_id);
        socket.set('currentuserid', current_user_id);
        rc.hset(current_user_id, 'step', step);
        socket.emit('ask nickname');
    });
});

Almost done, we just need to handle these messages on the client side

On our main Backbone Router we have this function:

initSocket : function(session, user) {
    /*
      This function is called just after bootstrapping the application 
      (on any of the entry points), 
      and it will take the session object as a parameter.
    */
    this.socket = new SocketHandler(this.opts, {

        /*
          This will setup the callbacks for each socket event 
          defined on the SocketHandler object.
        */
        onWelcome : session.setUserId,
        onAskNickname : this.chatView.askNickname,
        onSessionStarted : this.chatView.sessionStarted,
        onUserConnected : this.chatView.addUser,
        onNewCluster : $.proxy(function(cluster) {
            this.clusterateView.onNewCluster(cluster);
            this.prioritizeView.onNewCluster(cluster);
        }, this),
    …
    });
    …

    /* connect to our node.js through socket.io */
    this.socket.connect();

    /* send the “join session” message downstream */
    this.socket.joinSession(session.id, user.id, this.currentStep);
},

The SocketHandler object in it’s turn, works as the communication layer with socket.io.

Here is what the connect function looks like

connect : function() {
    this.callbacks = callbacks;
    this.socket = io.connect(opts.socket_url);
    _.bindAll(this, 
        'askNickname', 
        'userConnected',
        'userDisconnected', 
        'setNickname', 
        'newMessage', 
        'newMessageIn', 
        'welcome',
        'newIdea',
        …
        'voteReceived',
        'voteRetracted');

    this.socket.on("welcome", this.welcome);
    this.socket.on("ask nickname", this.askNickname);
    this.socket.on("user connected", this.userConnected);
    this.socket.on("user disconnected", this.userDisconnected);
    this.socket.on("user updated", this.userUpdated);
    this.socket.on("new message", this.newMessageIn);
    this.socket.on("new idea", this.newIdea);
    this.socket.on("new cluster", this.newCluster);
    …
},

and an example of a downstream message function implementation,

joinSession : function(session_id, current_user_id, step) {
    this.socket.emit('join session', session_id, current_user_id, step);
},

and an upstream one.

newIdea : function(data) {
    if(this.callbacks["onNewIdea"]) {
        /*
          This will call each callback registered with the SocketHandler
          with the data received from the websocket through socket.io
        */
        this.callbacks.onNewIdea(data);
    }
},

Finally, what happens on, for example, the ideate view:

/*
  S O C K E T   E V E N T S
*/
onNewIdea : function(idea) {
    if(this.bootstrapped && !this.ideas.get(idea.id)){

        /*
          Backbone will take over from here and perform it’s magic,
          since the “data” we received from the socket is actually 
          a json representation of an Idea Model, whenever we add a new idea to
          the ideas collection, Backbone will render it’s corresponding view
          automatically!
        */
        this.ideas.add(idea);
    }
},

onDestroyIdea : function(idea) {
    if(this.bootstrapped && this.ideas.get(idea.id)) {
        this.ideas.get(idea.id).trigger('destroy');
    }
}

So there you have it, after all this work is done, Melee is now a realtime application. Notice the importance of defining an architecture that is flexible enough to allow for this kind of implementation process (single user first, multi user later).

Conclusion

After all these years, technology has yet evolved again, and nowdays there are frameworks other than Backbone that are a great fit for the kind of problem that we tackled here. Ember.js, for example, allows you to write much less boilerplate code, which is awesome!

Nevertheless, looking back at the work we’ve done here, we feel like sometimes being explicit is not such a bad thing, specially when we want to demonstrate something.

One question that people ask us is “Why haven’t you build everything with just Node.js ?”. Well, first, back in the day we didn’t had much experience with Node.js programming style and it was much more complicated for us to adapt and build the first version of the app due to the async-callback paradigm.

On the other hand, this decision made it so that we can now look at this app, and easily figure out what we need to do, case we ever have to add realtime functionality to an existing app.

Keep on reading to learn about the story and the technology behind Melee!

The story

It all started on a hot summer afternoon of 2011, when one of us mentioned some amazing new javascript framework called Backbone, that provided the bare essentials an MVC pattern should. We’ve always had a thing for trying out new stuff and this was just about a good time as any.

So, in order to be able to try out this awesome new toy – yes, learning Backbone was so fun that it wouldn’t be fair to call it a tool -, we picked up an old idea that we had shelved in the past and went with it.

While developing Goplan 2.0, we began using a software development process that goes by the name of SCRUM. One of the things we used a lot back then was the card-sorting. Basically we would brainstorm on a lot of features we’d like to see implemented and then using that technique, we would end up with several groups or clusters and on each of these, we would have the top scoring ones. Those were the ones that went through and actually evolved from Ideas into Tasks and ultimately into Features.

At that time we looked at each other and said:

Hey, wouldn’t it be nice if we had an app that could mimic this so that people working remotely could do this aswell?.

And so, Melee was born.

The first iteration of Melee was somewhat clunky: server push techniques were still in embryonic state, so we actually ended up building a regular rails app, using a gem called juggernaut for our server push needs. Juggernaut basically worked with an HTTP server and a flash client that ran inside the views of the rails app. A mess.

This actually worked out pretty well as a prototype, but we knew it didn’t scale. We did end up making a nice video about the product, but it never saw the light of day. In good truth, we weren’t sufficiently confident or happy with it.

So, back to a more recent past.

Technologies

With Backbone in hands we decided it was time to give a bunch of new sexy technologies a go; we threw in mix Node.js, Redis and Sinatra and the result was pretty impressive.

Sinatra

To serve the primary end points that serve the app and the REST actions for our models. Has a connection to the Redis server to publish the data changes.

Backbone and Node

The Backbone client (supported by the standard Underscore.js templates) also includes a Socket.IO connector that links to Node in order to receive sync messages. Those messages get to Node through the Redis PUBSUB functionality.

Redis

Working as the middle-man between Sinatra (the endpoint for data creation, except for chat) and Node (the synchronization mechanism through websockets), Redis provided us with the PUBSUB functionality. In addition, Redis also served as the database.

But doesn’t MongoDB makes sense when using Backbone?

Usually it does. It does a lot of sense, and I really recommend looking into it and give it a thought when you’re building your apps, but for us, since the App isn’t supposed to hold the data entered permanently, it made sense to use Redis for it and simplify the whole system a bit. This is because after the card-sorting process ends, we provide the user with an export/download functionality and expire the whole session data after a period of inactivity.

Internals. Part 1: Modeling

After rebuilding the wireframes, we started by implementing a single-user version of the app, keeping in mind that it would later need to support more users. With this in mind, we started by designing the Data Model. The basic objects we identified were:

• User { id, votes_count }
• Idea { id, title, cluster_id, score }
• Cluster { id, title }

We modeled these in Redis, using the standard structures provided: sets, sorted sets, hashes, etc. Note how from those objects and relations identified, a quite larger number of data structures spawned, due to relations and the need for session closure:

In Backbone we created Models in a way that they mapped seamlessly to what we had in Redis (so that we could just fetch data from Redis, invoke a to_json method and be done with it). This was an iterative process and it took us a couple of cycles to fine-tune.

In Backbone.js, Models and Collections are the core of your app. Everything that happens, every bit of data passes through them and is handled by them. They are quite lean, and as you can see on Backbone.js documentation, you basically only need to provide them with an URL when you’re declaring them.

But in our app, some models aren’t even directly accessible (like ideas), unless they’re part of a collection. Also, we wanted the URL to contain the session id so that users could share the brainstorm session with others… How will that work?

window.Idea = Backbone.Model.extend({}); 

Looks weird right?

The solution was to take advantage of the Collection and make sure that when the initial collection of ideas is bootstrapped from the server the correct URL is assigned, since our URLs all obey to the /:session/* format!

So,

window.IdeaList = 
  Backbone.Collection.extend({  
    model: Idea, 
    initialize: function(models, options){ 
      this.url = options['url']; 
    } 
  });

combined with

new IdeaList(
  <%= @ideas %>;,
  {url:'/<%= @sessionid %>/ideas'
})

made sure that Backbone would build the urls for things like

var idea = 
  new Idea({
    title: this.input.val()
  }); 
idea.collection = this.ideas; 
idea.save();

as

POST /<session_id>/ideas 

which is exactly what makes sense and what we need!

That’s all for today!

With this post, we looked into Data-modeling for Redis, how to use Backbone with dynamic urls and some background story and motivations for building up Melee.

On the next post, we’ll talk about how we built the Views, the Routers and how we leveraged on Socket.IO and Node.js to add realtime functionality and multi-user collaboration features to the app.

It’s great because it’s really motivating to work with a new technology and by doing so implementing an idea of our own. Not to mention that regardless the idea turns out to be great or break, the learning experience will always pay off!

A few months ago, when we launched Bling, we felt that it would be amazing if we could improve the user experience by auto-magically recognising products just by the picture. We did some study on that subject back then, but eventually the idea was abandoned and we moved on. The “problem” was that we didn’t forget about what we learned back then and we had the urge to still build something with that knowledge, still lingering inside our heads…

Last week Fábio tweeted about 2 things he’s been working on lately:

• An iOS app for recognising Magic: The Gathering cards and tell the user relevant information about said cards (like price, for example).
• A blogging engine he built based on Meteor.js.

If you’ve ever wondered about ways to handle image recognition on iOS, or you are curious about the practical application of Meteor as a web development framework, you should check out his blog and the post about image recognition. The iOS app isn’t finished yet, but it will be soon.

After all this, we feel like we need to tell you: Try new things. Build new stuff. Even if you’re working on a corporate environment, talk to your boss / manager / superior and suggest that once every 2 weeks everyone takes a half a day to just brainstorm an idea and pick a new technology they are curious about and just hack away.

It doesn’t matter if it’s an idea completely out of scope of your business area (in fact, it’s even better if it is!) and it doesn’t matter if the ideas actually go through till the end. The point is widening your mind’s eye. Learn. New. Stuff.

You’ll feel like when you were a kid and you built your first original creation out of lego blocks.

This week we felt like something was missing to maintain the team productive and communicating efficiently. We needed a simple way to keep everyone in sync without causing too much of a hassle. We figured that the solution would be a very simple app which allowed everyone to sum up their work day in a few sentences, kind of like a tweet about your output for the day.

We put on our Rails cap and made log(r) in a few hours – never mind the name, we really suck at that.

After trying it out for a few days we really like using it. In a couple of minutes it makes you go over the whole day in your head and compact it into a small textarea for others to read. You can think of it as an agile version of the 15-5 feedback report. On that same screen you have all your teammates’ reports. It also reminds you by email if you forget to log your day.

We decided to open up the app for everyone to use, so we had to make a few changes, like adding teams and timezone settings (oh, the dreadful timezones!), while trying to keep the app super simple.

Give it a spin at logr.webreakstuff.com, get your workmates on it and let us know what you think!

For most of the last 9 months, we’ve been exploring several ideas in the social shopping and recommendation space, eventually culminating in the official launch of Bling, a platform where people share the things they’re buying and add things they want to a wishlist. In return, we’re able to provide users with all sorts of smarts regarding products they might like, what shops may have cheaper items, among other things. The amazing thing about Bling is that once you start uncovering the veil of possibility, it becomes immense.

Bling is also the first project where we’re considering bringing in external funds to help us grow our talent faster. I’m a big proponent of going all-in and bootstrapping businesses – mostly because it is a great way to keep your ass on the line and make people move -, so this is definitely a conflicting position for me personally and the company as a whole. We’re lucky enough to have had a couple of offers already, which we are considering, but they all depend on a visit to California in January (more on that below).

Parallel to Bling, we’ve been mulling a few other ideas for products and expansion. We’ve (very) quietly rolled out a private beta of a product we’ve had on the backburner for a while, that we rebuilt from the ground up with technologies we wanted to explore. More on project M – on which Fabio took lead development role, churning out exceptional stuff – soon, when it is closer to an actual launch.

Plans are being made for a company-wide trip to California in January. I’m sure we can all benefit from a few days in a different environment, and we’re taking the opportunity of the 500 Startups demo-day – I’ll be going as a mentor – to go over for two weeks. Resting, sightseeing and a bunch of meetings with smart people should definitely stir up things around here. Plus, this is something that has been long overdue.

More notes next week. Merry christmas!

We have, though, been missing writing on our blog here, and we’ve made the decision of bringing this baby back, with a vengeance. Expect a flurry of new posts about our typical subjects of development, strategy and design (we have some exciting stuff to talk about) – starting first thing tomorrow. Now, we rest – today has been along, exciting day.

Goplan has been growing steadily, which is definitely exciting. Having companies like Boxee or Mozilla – both of whom we’re big fans of – using the product means we’re doing at least something right. Tiago has been working with our new credit card payment gateway to finally bring credit card processing into the application and dump Paypal, which will make it easier for us to change our pricing, give accounts away or offer discounts. Meanwhile, I’ve been tightening pixels inside the application, improving things one page at a time (no app is ever truly “done”).

We’ve been thinking a lot about the iPhone and the iPad. We have ideas we want to try out on both platforms and we can’t wait to finally begin in a week or two when the bulk of the stuff we’re working on gets done. It’s weird that we’ve been on the development program since day 1 and haven’t been able to dedicate much time to it.

Conference season is right around the corner. We’ll be at Ux-Lx, Shift and Switch in the next couple of months – hopefully others later in the year ^[1]. My new talk on entrepreneurship – a follow-up to the Lessons Learned talk I did way too many times last year – is on the light table and I’m quite excited about it. If you’re in or around Lisbon in a few weeks, you may catch it at Shift. Thanks to a partnership we just did with Adaptive Path, we’re probably heading out to UXWeek in San Francisco in August as well ^[2].

Speaking of conferences, we’re organizing a startup contest at Switch Conference this year and all the details on it are coming this monday. We’re excited to see what people around us have been working on – that should be pretty good.

Have a great weekend!

Footnotes

^[1] It’s a shame that there will be no Reboot in 2010, but I’m sure Thomas needs a rest. Reboot is a delightful conference that everyone should experience at least once. I hope someone else steps up to organize a conference to fill its shoes this year.

^[2] If you’ve read our notes for week #241 you know we’re thinking of moving out to the bay for a couple of months – for the change of air, mostly -, so it may end up being that we head out to UXWeek and just stick around.

Decisions, guts

Monday’s highlight, however, was not the smell of clean floor tiles, the renovated color of our carpets, or the pixelated video-game-inspired posters that were hung on the walls. On Monday, right before dinner, we hit an odd milestone – one I briefly mentioned on twitter: We said no to a candidate that hit the mark on 99% of our hiring criteria.

As you might have guessed if you’ve been reading our weekly notes, we’ve been rethinking the way we work for ourselves and our clients (we’ve recently decided to only take 4 consulting jobs in 2010 to make sure we’re completely passionate about everything we do – more here). So we’re not hiring until we have everything figured out. It was tough saying no to someone when our gut said yes but we believe it was for the best. If you’re hiring and looking for someone who’s revealed to be extremely passionate, a great PR person and an inspiring individual, get in touch and we’ll connect you.

Preparing for a stint in the valley

Anyway, we’re making big plans for the future and it seems like we (the whole team) may be spending a few months in Silicon Valley soon. Me, I can’t wait to go back, and the rest of the guys can’t wait to see how things are like over the pond. The whole idea is still in its embryonic stage – and there’s quite a few things, namely with immigration, to figure out -, but we’re all very excited about the prospect.

If you have ideas on how to solve the problem of hosting 6 or 7 people in or around San Francisco for about 4 months, please let us know. Housing is our number one concern at this point. But honestly, we see this as a good problem to have. We can’t wait, really.

We’re bringing the whole team to Lisbon for three days packed with great talks and what we hope awesome inspiring conversations. And we’re not only bringing everyone down, we’re also – through our project management and online collaboration app, Goplan – sponsoring the event. We’re giving everyone attending the conference 6 months free of Goplan’s professional plan – which we believe will make a few people quite happy. It’s a great way to give back to a community we love, and to hopefully get feedback from likeminded individuals.

We do hope to see you at the conference, and if you’re not attending, we hope you’ll keep an eye on our blog as we’re planning on some really exciting ways to cover what’s being said on the event. Cheers!

This was a slow but important week. 2009 is done – it’s funny how time flies. The office stood still as we gathered with families, friends to celebrate the new year. Ourselves, we’re concentrating on 2010 – it’s going to be an important, career (and company) defining year.

Important decisions were made. As I briefly mentioned last week, we have always struggled with the question of whether to focus on our products (which we love) or to help other people with their own through consulting (which we also love to do). We’ve reached a conclusion, we’re happy with our decision and we’re sticking with it.

The decision is to do both, but with a twist: we’re taking a very limited number of consulting projects each year from now on – we’re thinking of about 4. This is the best of both worlds. When we’re consulting, we’re inspiring and getting inspired by other people. When we’re working for ourselves, we’re reinventing our ideas and hopefully building special products that you can use.

I wonder (and the others do too) how clients will receive the idea of us only doing a limited number of projects. We want to make the best out of the time we dedicate to other people. We want to be completely passionate about it, so four projects seems like the sweet spot. We’ll see how it goes.

If we have one new year resolution, it is to bring passion back to our business. If you want to work with us (or to have us work for you) in 2010, get in touch – we’ll try to help. Thank you, and happy new year!