Manage time better with Range.

Range is team scheduling software designed to improve time utilisation for agencies, studios and other teams. br

With a sleek interface and lean process, it allows project managers and team leaders to effectively manage the time of individuals on their teams, across diverse projects.

The story

Writing Range:
a technical focus

When we started the Range project, AngularJS was in the 1.0.7 version. It was already considered stable (post 1.0) but, along with its integration with rails, its worldwide adoption was just beginning. At that time everyone was still using jQuery, hence most of the UI widgets were based on that library.

While building Range, one of Monterail’s first Angular apps, we decided to try as hard as possible to avoid using jQuery. We were determined to take this proactive step, even if it meant we would need to write our own implementations of common UI controls, which is in fact what we were forced to do.


User interface components

One of the most important parts of the Range interface is the date range picker that allows a user to select the dates for scheduling. After much searching, we simply could not find one that would suit our needs, so we decided to write the ideal range picker for our project using only Angular, with no jQuery whatsoever. This was 2013, and an innovation we are proud of. See more on our GitHub:angular-mighty-datepicker

UI components

Assets management

The other missing part of the Rails + Angular ecosystem was JavaScript dependencies handling. At that time most developers were simply putting JS files into the `vendor/assets` directory. This obviously quickly led to unmanageable cross dependencies between JS libraries and made the upgrades very painful, if not impossible.

To combat this problem, the Rails community introduced "asset gems", basically a bunch of JS files wrapped up as a ruby gem, which tended to be versioned as the underlying lib and published to rubygems.org. The biggest issues with this approach stemmed from the fact that asset gems were always a few versions behind the originals.

It is worth noting that, while working on Range, we had to deal with numerous JS libraries, and so we decided to solve all the above mentioned issues once and for all. This was how https://rails-assets.org was born. You can read more about it at Assets management solved on our blog.


Rendering performance

Besides lack of good Angular components and problems with JS dependencies, we struggled with one more riddle, namely, performance.

In this connection, the most crucial piece of Range interface is the Rangeboard. Every team member gets a row with nested rows showing availability and their projects assigned in the selected time frame. This spans 56 columns, one per day with granularity of a single hour, all calculated in the browser and draggable. In addition, these are all updated in real-time, so, yes, there were quite a few performance issues to address.

Some of you might think, ‘Well obviously, Angular is slow.’ However we found that in fact, lack of performance is not the fault of Angular exclusively. While we did optimise a few `ng-repeats` and that type of Angular performance improvement, the biggest bottleneck hindering application speed was the rendering and updating itself.

To start with we used SVG for drawing. Initially, it seemed like a great solution since it had a DOM-like structure, was easy to manipulate with Angular's build-it directives, and was easy to style using CSS. Unfortunately it turned out that this basic setup was very slow and we also needed some more complex features.

To resolve this issue, we first turned to the beloved D3. As a result we managed to come up with a rendering that was faster. But soon we started dealing with real-time updates and drag & drop, so predictably, we faced performance issues again.

Our solution, after lots of tries was to rewrite everything from scratch using only raw Canvas API. We ditched both SVG and D3 and wrote our own micro rendering enginethat did nothing more than we needed, kept everything in sync via Angular's scopes, reacted correctly to all changes, supported drag & drop, keyboard navigation and synchronised animations. With that,the performance of our application was finally up to scratch.

Rendering performance

Tech Summary

Range is an in-house product of Monterail and we are extremely happy to claim it as our own. From the beginning of the design process to the current beta stage of development, both the product vision and implementation of design ideas are the result of the hard work of our internal team, resulting in an innovative, efficient and practical product.

The process

Product summary:
time is money

Range is an impressive piece of team work scheduling kit that, in the capable hands of your management teams, is an excellent way to reduce confusion, slim down budgets, save stray minutes and pull even an already formidable team into a veritable powerhouse of quality performers, ready to take on even the toughest of project challenges.

Why not join the smart money and rove confidently through your team scheduling problems, whether in schools, agencies, studios or any competitive teamwork environment. You are sure to feel at home on Range.

Try new things


Krzysztof Jung
Krzysztof JungFront-end developer
Szymon Boniecki
Szymon BonieckiProject manager

They also took part in the Range project
  • Tymon Tobolski
  • Dominik Porada
  • Piotr Sokólski
The future

Are you interested?

Your idea should not wait
— let’s set everything in motion.

Contact us