So maybe you heard, we released a new version of Notable, and it has some smoking fast interactions.
One of the biggest pain points that we kept hearing about, in the previous version, was that moving between the post (viewing) and annotate (adding notes) page was too slow. Both pages were very important: the former allowing you to see who the post was shared with, comments, and the description; and the later allowing you to actually add notes to the post. It was a single click to move between pages, but the 2,000 milliseconds of page load felt heavy for taking an action on the object I was currently looking at.
2,000 milliseconds of page load felt heavy
We played with the idea of combining the two pages into one, but it was too much functionally, and we could not come up with a design we were happy with. Ultimately we decided to simply make ten louder, i.e. make the transition between pages fastera''like, one hundred times faster.
The page load had to go
- The two pages needed to be kept in sync, when a note was added to the annotate page, it needed to be shown on the post page as well.
- Having all the elements for both the post and annotate page in the document caused the page to respond slowly. So slowly.
- It we can move from post to annotate page without reloading, it would be awesome to move between different posts in a set without reloading.
The next, and final solution proved to be more complex, but supremely fantastic. All the data required for both the post and annotate page would be loaded from the server in a JSON object, and then that object would be used to generate the markup for the post or annotate page, client side. To switch from the post to annotate page, we blow away the post page markup, and replace it with newly generated markup for the annotate page. This change is so fast it appears to happen instantly. Bang.
This change is so fast it appears to happen instantly.
Generating entire pages client side sounds painful
Generating entire pages client-side sounds painful, especially if ita''s not something you typically do, or your application is built using the more traditional architecture of page loads, as ours is. Rather than re-architecting everything, we decided to use a lovely little framework called Backbone.js, that we have been working with lately. Backbone was a great fit for this problem because:
- It plays nice with the common web application.
- We could use it for just part of our application without worrying about how it would effect everything else.
- It has no special build or deployment requirements.
- All we needed to know was jQuery.
Basically adding Backbone was like installing a plugin. Ita''s only 3.9kb compressed, and the annotated source code is just over one thousand lines. A very well written and annotated thousand lines, making reading the source a snap, and alleviating any fears of being stuck with an unmaintainable, or unsupported library.
Overall, the way Backbone abstracts views makes a lot of sense to us
We found a few small bugs related to our usage. But they were easy to fix, and our patches were reviewed and merged into the source hours after submitting them. Overall, the way Backbone abstracts views makes a lot of sense to us, and we were very happy with how the implementation came together for Notable. So happy that wea''re going to be speaking about it at both the jQuery Conference in San Francisco, and RailsConf in Baltimore. You can expect a talk similar in style to the one we gave last year at jQuery conf.
If you are interested in learning more about Backbone.js check out their excellent documentation, come hear our talk live, or wait for the video. Want to see the new and awesome interaction for switching between the post and annotate page on Notable? Sign up for a free account at Notableapp.com.