<img height="1" width="1" style="display:none" src="https://q.quora.com/_/ad/33f0a6b82950498f9c3809eb5e1c32a2/pixel?tag=ViewContent&amp;noscript=1">
This website uses cookies for analytics and to improve provided services. By choosing I Accept, you consent to our use of them and other tracking technologies according to our Privacy Policy

Range.Your team's time is priceless. Take better care of this.

Range is a team scheduling software for agencies & studios that helps improve their time utilisation. With a sleek interface and lean process, it allows project managers and team leaders to effectively manage team members’ time across diverse projects.

The story

Focus on building quality


By the time we started the project AngularJS was in the 1.0.7 version. It was already considered stable (post 1.0) but the adoption was just about to grow, not to mention the integration with rails. At that time everyone was still using jQuery, hence most of the UI widgets were based on that library. When building Range (which was one of the first angular apps at Monterail), we decided to try as hard as possible to avoid using jQuery, even if that meant we will need to write our own implementations of common UI controls. 

And in fact - we did.


User interface components

One of the most important parts of Range's interface is the date range picker that allows a user to select the dates for scheduling. We couldn't find anything that would suit our needs, so we decided to implement our own using only Angular, no jQuery whatsover,and it’s 2013. Explore on our GitHub:angular-mighty-datepicker

UI components

Assets management

The other missing part of Rails + Angular ecosystem was JavaScript dependencies handling. At that time most developers were simply putting JS files into `vendor/assets` directory. This obviously quickly led to unmanageable cross dependencies between JS libraries and made the upgrades very painful (if not impossible). To fight this problem, the Rails community introduced "asset gems" - basically a bunch of JS files wrapped as a ruby gem, hopefully versioned as the underlying lib and published to rubygems.org. The biggest issues with this approach was that asset gems were always few versions behind it's originals.

While working on Range, we had to deal with numerous JS libraries and decided to solve all mentioned issues once for all. That's howrails-assets.orgwas born. You can read more how we solved assets management at ourblog.


Rendering performance

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

The very main piece of Range interface is the Rangeboard. Every team member gets a row with nested rows for her availability and projects assigned in selected time frame. This all spanned across 56 columns, one per day with granularity of single hour. All calculated in the browser. All draggable. All updated in real-time. And yes, there were quite a few performance issues.

Some of you might think - that's obvious, the Angular is slow. In fact, it wasn't Angular's fault that much. While we did optimised few `ng-repeats` and those kind oftypical performance improvements, the biggest bottleneck was the rendering and updating itself.

Rendering performance

At the beginning we've used SVG for drawing. It seemed like a great idea - DOM-like structure, easy to manipulate with Angular's build-it directives, easy to style using CSS. Unfortunately it turned out this basic setup was very slow and we also needed some more complex features. We then turned out to beloved D3. The rendering was faster, but we started dealing with real-time updates and drag & drop we faced performance issues again. After lots of tries we decided to rewrite everything from scratch using only raw Canvas API. We ditched both SVG and D3 and written our own micro rendering engine that did nothing more than we needed: kept everything in sync via Angular's scopesm reacted correctly to all changes, supported drag & drop, keyboard navigation and synchronised animations. With that the performance was finally satisfying.

The process

Everyone cares

Range is an in-house product by Monterail: from the beginning of design process to the current beta stage’s development, both the product vision and implementation are results of the hard work of our internal team.

Try new things

Meet the team

Szymon Boniecki

Szymon Boniecki

Project manager

Krzysztof Jung

Krzysztof Jung

Front-end developer

They also took part in Range project:

  • Piotr Sokólski
  • Tymon Tobolski
  • Dominik Porada
The future

Are you interested?

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