Teamweek is a project planning tool from the Toggl team. We’re currently in the middle of a total makeover of Teamweek’s user interface. The new interface will be released to early beta testers within a few weeks.
In this blog post I will talk about what technologies our new user interface is using and why.
Taking the leap
According to Cisco Visual Networking Index and various other sources, global mobile traffic increased roughly 70% in 2012. Teamweek though, doesn’t run too well on mobile devices. This will have to change if we want to keep up with the world.
In hopes of delivering a good user experience across various devices, we’ve taken the leap and ditched our HTML-based Timeline for HTML5 canvas. This also means cutting off Internet Explorer 8 support for good – a rather bold move but if we choose to be bound by the past, we will never move forward (Barack Obama, speech, May 21, 2009).
Since we’re targeting tablets and other mobile devices, we have to compare ourselves to native applications. While we will never be able to match the feel of a native application, html5 canvas can take us pretty close to it.
Canvas vs HTML (and jQuery)
For comparison, let’s take a look at the total from-scratch rendering speed of the timeline. Currently, this can take up to a couple of seconds if you’re using Firefox on a not-so-blazingly-fast PC. With canvas, we can improve that by an order of magnitude.
Animations – most native applications aren’t too worried about performance issues if they’re simply moving a couple of objects around. With HTML and tablets this can be a serious issue. You can’t simply write
$(...).animate() and call it a day. You have to watch where you’re causing browser reflows and force hardware acceleration where possible. CSS transitions can yield better performance, but are extremely limited. Once you’ve covered that, you have to deal with odd rendering artifacts and browser repaints occurring at very inconvenient moments. With html5 canvas you control exactly what will be rendered, and when.
Using HTML5 canvas solves a lot of the problems we have with HTML but presents us with a whole new set of challenges.
When developing large canvas applications you really need some sort of framework that serves as a layer of abstraction between you and the fancy pixel buffer we call canvas. You want to manipulate objects, not draw shapes.
We have chosen the CreateJS suite for that purpose. CreateJS is a well-written suite of libraries that tries to mimic Adobe Flash in many ways, which is great since Adobe Flash is, after all, a very mature platform that allows very fast development of interactive user interfaces.
We are also using HammerJS to provide us with better multitouch and gesture support. You can read about how we combined HammerJS with CreateJS in another blog article soon.
Vanilla CreateJS doesn’t cut it, though. To offer the best possible user experience on multiple platforms, we also had to implement a series of optimizations and work around some of canvas’s limitations.
You can read more about this here: 6 Performance Tips for HTML Canvas and CreateJS.
HTML5 canvas is missing much of the functionality web developers are used to. Some of it may have to be implemented by hand, while most of it is provided by various frameworks. Having such a low-level API, however, allows us to do so much more.
So far, choosing canvas over HTML seems to have been the correct choice and definitely a step in the right direction.
At the moment, the new interface doesn’t contain all the functionality of Teamweek but we’ll continue developing it and in the end, there should be one uniform interface across all devices.