What We Learned About MeteorJS While Building UsabilitySqaure

In case you haven’t noticed yet, our UX family is richer for a new member! Namely, Koncept got its little brother – UsabilitySquare.

What Is This Square About?

We’ll be honest with you – unlike Koncept, UsabilitySquare wasn’t really planned. The idea for UsabilitySquare just came to us, so we decided to create it out of pure love for (obviously 😀) usability.

The best thing about UsabilitySquare is that it turned out to be altruistically inclined. Namely, it represents a place where everyone interested in validating their ideas can connect with usability enthusiasts and get totally free, instant and unbiased feedback from real people.

Giving MeteorJS a Chance

From the very moment, we decided to create UsabilitySquare, we saw it as an opportunity to try out some new tools and frameworks. The MeteorJS platform won the contest, so the fun could start!

Meteor’s reactive data (real-time updates over DDP) and instant changes on the interface were a real treat to work with. They allowed us to provide users with a smooth experience without writing hundreds of lines of code.

MeteorJS: The Good Parts

These real-time functionalities are generally seen as one of the major merits of using Meteor. Thanks to these features, the end product always feels snappy and responsive for the end-user. This is due to the interesting paradigm of “the Optimistic UI” – Meteor assumes that operations are successful and updates the interface instantly.

Implementing this concept from scratch would be a very difficult and time-consuming task, but Meteor handles the issue right out of the box. This is done via a client cache (Minimongo) that can be used for quick (but temporary) client-side updates. This compensates for the wait time and Network latency of persistent database operations. When the operations finish, Meteor handles conflicts between the client and server and does all the work that’s needed to patch the UI with real results.

This is how, simply expressed, “Optimistic UI” update cycle looks like:

It’s good to note that we used React for our Views (instead of the Blaze templating engine that is provided by Meteor) and that everything worked just fine.

As developers we also enjoyed working with Meteor’s Publish / Subscribe / Call model which made it very simple to create interactions between client and server-side code. This allows quick interactions and a reactive data flow over the DDP-enabled web socket APIs.

The Drawbacks of MeteorJS

However, there are certain problems with MeteorJS that simply prevent us from using it on larger projects in the future:

Using Meteor means using MongoDB - in fact the entire concept of Meteor’s Optimistic UI is dependant on Mongo and its cache. While MongoDB is great, it’s not always what you need or want to use.

The build system and tests have been painfully slow for us, especially as the project grows.

The amount of control that developers are given over the Meteor core is minimal. This is fine if you’re okay with “marrying into the Meteor platform”, but it just isn’t for us.

Besides the revelations regarding MeteorJS that we got thanks to UsabilitySquare, it also confirmed us that people are honestly interested in ways to get simple and fast validations for their ideas.

We Had a Great Time!

The secret of our Square’s adorableness lies in all free information one can get from real people who are gathering here, willing to help each other.

Simplicity also plays important role, since the whole ‘procedure’ is consisted out of just 3 steps. In short: Everything one should do in order to get feedback is to set an experiment and ask other Squarers how they would answer certain question about their project.