When the German map manufacturer Falk approached us to relaunch their mobile website we knew that we wanted to do it completely web based. No native code should be used for this application.

The building blocks

The app is realized as a single-page web application using the popular JavaScript library Backbone.js with Handlebars.js for the templates. The map component was built with the powerful Bing Maps AJAX Control SDK.

The backend was created with our good old friend Ruby on Rails. ;)

Here are some stats:

Lines of code:

• 3838 CoffeeScript
• 4310 Javascript
• 727 Template code

Size:
The JavaScript code was uglified to 272.63 KB of pure awesomeness.

The project diary

Backbone.js is a nice framework to build a client side web application. But don’t let all the built-in simplicity and goodness fool you! With frontend and backend combined your stack consists of MVC for the backend and MVC for the frontend… – that’s a pretty high stack! – Luckily, leveraging CoffeeScript, the code stays clear, readable and maintainable.

Initially, we started with Zepto.js which is a lightweight jQuery replacement but due to some complex UI components we had to switch to jQuery-UI. The switch to jQuery was very smooth. Everything that worked with Zepto.js worked perfectly fine with jQuery.

The first 80% of the application took 20% of the time, the last 20% took 80% of the time. The main reasons for that were the following:

1. Opening Pandora’s box and unleashing everything that CSS3 has to offer brings some serious problems.
   For example, we are using a transition to show and hide most of the views, some of them containing different kinds of inputs. First we used the transform:translate(x,y) CSS attribute for that, because it performs very well on the mobile Safari. Unfortunately, on the Android browser the transition is not working correctly and the JavaScript hitboxes for buttons and inputs were not on the right position. We solved this issue by using CSS transitions for Android.
2. Resizing DOM elements beyond screen size yields in an ugly render bug on the mobile Safari. Fortunately there is an easy fix for that. By touching some CSS attributes you can trigger a relayout of the page. Details can be found here.
3. HTML5 is a wonderland in theory but in practice you will have to sniff operating system and browser to provide the best user experience. Depending on the iOS version we had to render either a HTML5 range input or the jQuery-UI range slider. Also we have slightly different CSS for iOS and Android browsers. For example on Android 2.3 box-shadow did not work at all and border radius looks butt ugly.
   We needed to do a lot of tweeking to deal with the fragmentation of browsers on the Android platform and we are happy to see that google is tackeling this problem by providing chrome for Android and decoupling the browser evolution from system updates.

Despite the problems we had developing this application it still was great fun. Again, we pushed the limits and saw once more that web and native are moving closer and closer.

Finally, we are very happy with the result and the users also seem to like it. In the first few weeks we already tracked up to 7.000 visits per day!

In April 2011, Moviepilot, a successful Berlin-based startup, asked us to help building their new product moviepilot.com. After having established an international fan-base of over four million movie addicts on their facebook page, they wanted to use this momentum to create a social place for discovering upcoming movies and tracking them from rumor to release.

Behind the scenes of Moviepilot

Together with the Moviepilot team we decided to build a large-scale single-page application. The backend was built with a classic and bulletproof technical stack using Ruby on Rails, MySQL and Neo4j databases. The frontend is a sizeable JavaScript application written in CoffeeScript, HAML and SASS.

We chose the popular Backbone library as a basis for our JavaScript code. Since we were always convinced of the idea behind single-page apps, we started working with Backbone pretty early. When we built salon.io, one of our products designed as single page app, we gathered valuable experience (kudos @thedeftone).

By design, Backbone is more of a minimalistic library than a full-featured framework. However, huge JavaScript applications are being built using Backbone and well-known companies like Foursquare, LinkedIn and 37Signals rely upon Backbone. While Backbone is fine for what it’s made for, large projects require a sophisticated architecture on top of it that implements well-proven design patterns.

Recently, several frameworks based on Backbone were released, most notably Thorax and Marionette. Independently from each other, we came to similar conclusions during the development of moviepilot.com.

Meet Chaplin, an Application Architecture based on Backbone

Today we’re releasing the application architecture of moviepilot.com: Meet Chaplin! It’s free and open-source, MIT-licensed.

Chaplin is not a ready-to-use library, but an example how a real-world Backbone application might look like. Consider it as a scaffold which you might build upon and adapt to the specific needs of your application. The key features of Chaplin include:

• Pure CoffeeScript classes wrapped in RequireJS (AMD) modules
• Cross-module communication using the Mediator and Publish/Subscribe patterns
• Separated routing and business logic by introducing controllers
• Application-wide view management
• Strict memory management and object disposal

You will find an in-depth explanation of the application structure on the Chaplin Github page.

Chaplin comes with a simple demo application which allows you to log in via Facebook on the client-side and browse your Facebook Likes. While this isn’t by far as complex as moviepilot.com, it demonstrates how application modules interact and how a client-side login might be implemented.

Fork Chaplin on Github

By releasing Chaplin into the public, we’d love to share our experience on building large-scale JavaScript applications and contribute to the discussion on Backbone development. Chaplin is also our testbed to evolve our application structure, and it’s already ahead of the moviepilot.com codebase.

Since we’re constantly improving the architecture, your feedback is highly appreciated. Feel free to contact us, fork the code or create a new issue on Github.

We’re also considering initiating a Backbone usergroup meet-up in Berlin in the next months. Let us know if you’re interested to join!

Recently Martin created attackemart.in, a simple and elegant personal website. It quickly became viral and eventually won the prestigious Awwward. He did this after his first year. And boy, are we proud.
We asked Martin to write down his story and share it on our blog, because we think this is a success story of its own. The successs of having unearthed the talents of a prospect carpenter.

Hey, my name is Martin Gauer, I’m 23 years old and live in Bochum, Germany.
Two years ago, I was about to start an apprenticeship as a carpenter. However, it wasn’t really what I wanted to do, since I had a deep interest in designing stuff. I had created cover designs for some bands and photoshopped some small websites before. Therefore, I was desperately looking for a place where I could learn more about these things, and eventually succeed as a designer.
While googling around I came across the website of 9elements, and loved what I saw. I immediately contacted them to ask if I could work there.
Initially, they hesitated but since they saw some potential in the stuff that I’ve designed, they offered me an internship.

My internship felt a little like a total brain wash: When I started, I quickly found out how little I knew about design and user experience. I didn’t really know what’s going on in the internet, what’s hot and cool. I’ve never heard about HTML5 and CSS3. Bottom line, I started from almost zero.
During this time, almost all my designs were smashed down by either Eray or Sebastian, who told me I could do better. They asked me to start bookmarking and collecting websites that I like and to mimic their style, before creating my own. They asked me to sign up to Twitter and to follow the best designers around the world. Set your benchmark as high as possible, so you’ll never have to chance to tread water.

It was pretty frustrating to see how far I was from being a good designer, but it also fueled my curiosity and determination to succeed. I stayed in the office as long as I could. Sometimes I just didn’t want to leave at all.
Later, they told me that exactly this attitude convinced them to open the doors wide for me. At last, when I asked them to become an apprentice at 9elements they agreed.

Learning you are, young padawan.

Their offer came with one condition though. They wanted me to enroll as a software developer rather than a designer. ‘Design and Code go hand in hand, it’s almost the same thing. The one you’ll see, the other you’ll feel’. They argued that it’ll be far more powerful to build what I envision than just to design it.
This offer was somewhat unexpected, but honestly, the more I thought about it the more I liked the idea. It turned out to be great decision.

So I started to learn how to code. It was a very steep learning curve since I had no coding background at all. I learned how to create clean and scalable markup, and had the luck to look over the shoulder of one of the bests. I had the chance to work extensively with CSS3, media queries and mobile design.
Today I’m already in charge of creating and maintaining HAML / SASS for most of the 9elements projects.

When 9elements launched their new website in the beginning of this year they got some traction and won some awards. And I thought: hey, this is something I want to accomplish, too! I was determined to build my own website and to make it awesome.

Naturally, it wasn’t that easy. It took me several iterations – you probably know the game – sketch, code, redesign, throw away, create from scratch, design, code, etc. Finally, in October 2011 it was finished, polished and ready for deployment.
The development process was extremely valuable: I learned turning a vision into design and design into code – full stack!

Of course, I was very curious if the concept would get any traction. After launching the site I’ve submitted it to various CSS galleries and tweeted the link. And boom! People started tweeting about it and the feedback was overwhelming. Two days later, Jan emailed me that @soxiam, the lead designer of vimeo featured me on his personal blog. The internet is such a wonderful place :)
Finally, my goal was to win the prestigous awwward. It took almost 8 days – but here it is, I got it! And I’m proud as hell.

Huge thanks to my team for helping me to be more than I could have ever imagined. I consider myself really lucky to be part of it!

At Nodecamp 2011, we wanted to present a live tracker built with node.js. After seeing the popular facebook map by Paul Butler, I was wondering why not create something like that with live data. The appeal of watching the temporal dynamics within such a visualisation is obvious.

Of course, the problem with live data is that there is no way to tweak it with some nice afterfx, or play it in fast forward to make it look awesome. Mastering the art of live visualisation requires to create something meaningful while it looks stunning at almost every single instant. That’s not easy.

After giving the idea some thought, I decided to go with data from img.ly. Img.ly is one of our projects which has shown some serious traffic lately, mainly because img.ly became the default image service of the popular twitter client Twitterrific. Needless to say the guys from Twitterrific deserve some serious credit, not only for creating awesome apps, but also for supporting other services without asking anything in return. After some years in this business I can tell you: this is more than unusual.

The idea

We still had to figure out what exactly to visualise. There are already many apps plotting visitors on a map, so obviously this was not very interesting. We were interested in connections, and basically there is already a very important type of connection on img.ly. Whenever you call a picture on img.ly, you create a connection to the user who posted it. We can apply this idea to location, thus all we had to do was to connect the location of visitors with the location of the picture they’re viewing. That’s the idea.

The technical setup – Backend

As mentioned before, we wanted to do something realtime. Sascha (@rattazong) therefore made an awesome setup for the backend. When someone views the experiment, a persistent connect to a node.js server is established using socket.io. If another person views an image on img.ly we send a message to the server with two parameters: The location of the image that has been viewed and the location of the viewer. Inside the server we’re accumulating these views in a datastructure and then propagating the information to all clients. The heavy lifting is done by the in-memory database Redis. The locations are determined using the geoip package for node.js. If the node process crashes, it’s automatically restarted with forever. Deploying is done with capistrano using this recipe.

The technical setup – Frontend

We considered different rendering techniques which could draw such a large amount of data on the screen. I decided to go with canvas, since I wanted to use procedural drawing instead of drawing every pixel of canvas on each frame. That turned out to be a wise decision.

I was able to “exploit” three features of the canvas API:

1. You can apply a shadowBlur attribute to your canvas to make it glow. I was playing with a custom gaussian blur before, but it was far to expensive in terms of CPU performance. The shadowBlur was a nice workaround, it creates the “lazoresque” appearance in the visualisation.
2. You can use use different blending modes in HTML, and by successively applying the “lighter” and “source-over” option you can generate both a heatmap and a decay over time. Effects 1 & 2 combined produce quite a stunning visual.
3. You can draw curves with the drawBezier function. Of course it’s not that simple in my case. I had to calculate segments of a Bezier curves, there is a nice explanation how it works on wiki. A tiny segment of the curve is drawn and moving forward every frame. By applying the “lighter” blending mode, overlapping segments created a lighter color and consequently I was able to produce the gradient effect on the curve. Getting there took quite some time though.

One of the first visual outputs with random data.

Mapping the data

Fine-tuning the visualization was the most time-consuming and probably most important part of the project. If it doesn’t look sexy, nobody will watch it. There are many parameters to tweak and it’s been very time consuming to find out the best configuration.

Let’s sum up the most important decisions which made a deep impact into the visual:

The distance between both endpoints of the curve determines the bending and the opacity of the curve. The further two points are away, the more the curve bends. This significantly decreased collision between curves. Furthermore, the curves are directional, which means that a curve connecting Berlin with New York will bend up, while the opposite direction will produce a curve bending down. This is a simple way to give us more information about the connectivity: e.g. you can see with one glance that Europe drives more traffic to the US than the other way around.

Creating patterns

While working on this project I was lucky to see many intersting findings. For example, at one point popular football player Sergio Ramos (>1million followers) posted a picture, and suddenly all spanish speaking countries on this world turned their attention to it:

The Sergio Ramos Effect.
You can see this pattern whenever some popular twitter user posts a picture on img.ly.
During the riots in Syria something similar happend, after a Syrian posted a related picture on img.ly. It was far less dramatic than the Sergio Ramos effect – however the visualization showed a gradual incline of views. Even the propagation of this image across the world became visible.

Some other facts:

1. There are more people in Europe ‘connecting’ to the States than the other way around.
2. Tokio never sleeps.
3. img.ly used to be among the top alexa 500 websites in china. Now we’re blocked by the great chinese firewall.
4. Far less Mac traffic in the industrial states than expected.
5. Spotting Neil Patrick Harris’s picture on img.ly was legen…wait for it… dary!
6. Never show a live demo when there is no internet, and the room too bright to beam a decent visual ;)

I can haz internet? Nodecamp crowd waiting in vain for some live data.

Now watch the img.ly “live is beautiful” experiment here!

Today we have finally released Watchlater for iPad! Watchlater transfers the idea of Instapaper to video. The app lets you watch video bookmarks anywhere and anytime. To accomplish this we have created a caching function which supports most video platforms. Videos are also automatically converted into an iPad ready format. The app comes with 300 ‘caching’ minutes, and users can add more minutes through in App purchase.

Check out the Watchlater website to get more info about features and scope.

In this post, we’d like to shed some light on the process of creating Watchlater and some of the pain we had. After all, creating software is not always a one way road.

The idea of Watchlater came already in the summer of last year and we were quick to implement the first version of the app. The first app submission was in September 2010, and it took Apple a blasting 55 days to get back to us just to tell that the app was rejected due to shortcomings such as a missing icon and some random app crashes. This submission, however, was critical to see that Apple had no problem with the idea of caching online videos. You never know.

Consequently, we continued development. We rewrote the app entirely from scratch, acknowledging that our first attempt was simply not good enough.

We then made a technical mistake by rewriting the backend with Node.js. Using Node at this point was far to early (v0.2) – the bulletproof Rails tool chain was missing, hence slowing down the development process. Don’t get us wrong – we think Node is awesome! It was just a bad idea to use it for the whole backend. Instead, the video processing and transcoding layer provided by our partner Filsh was implemented entirely with a Node.js and Redis stack. With over 40 servers clustered together, this might be one of the largest Node installations so far.

When we submitted the second version we had to again deal with a slow and unresponsive Apple process. Our company changed its legal form, and we wanted to change that in our development account. Apparently, there is no way to make such a change. Instead, Apple advised us to create a new account and undergo the enrollment process again. If this wasn’t painful enough, we lost the “Watchlater” name for the app, which is still taken up by our old account. Up to this point nobody at Apple has provided us with a valid solution for this problem.

Even though these backslashes were good enough reasons to get us down, we did not. We received lots of encouraging feedback. People loved the idea and pushed us to keep on moving. And then there were the good news. HackFwd invested in Watchlater. We took this outside investment not because we needed cash. 9elements is doing well, so we were perfectly fine with bootstrapping our ideas. It was because we were looking for a partner who can boost the product with their experience and network. We had several options, but HackFwd made us feel right at home by sharing the same enthusiasm for technologies and building stuff. So we found a perfect match.

Apple finally approved the app, but we decided to stay under the radar until all major milestones were completed. It also helped us to add over a thousand users, get their feedback and take some time for essential improvements on the app. It also gave us the opportunity to iterate over the UI and the overall user experience. All users who bought the app up to this point received additional 300 free caching minutes. The app is now out in the open, and we believe it brings the kind of uniqueness and usefulness that users will find it and love it. And we are already working on bringing even more of that in the upcoming updates!

Finally, thanks to all our beta testers and supporters. We truly appreciate all your feedback and ideas.

Our beta testers and contributors:

Dion Almaer, Thierry Apelt, Milind Avares, Marcel Fahle, Peter Grosskopf, Tom Hulme, Stefan Landrock, Jens Krahe, Felix Nensa, Diego Petrucci, Stephan Seidt, Timo Schilling, Federico Viticci, Chris White.

As of today we have a new 9elements website. Whereas the old one was quickly put together to deliver an impression of our company culture, we put a lot more effort in developing this site. We now have a decent place where people see the cool projects we’ve worked on and also get an insight on how we work. But not only the content is fresh – with the release of our new website, we revamped our complete production toolchain.

ZOMG – It’s coffee all over the place!

The whole website is implemented as a single page webapplication, so far nothing special here. But we created our own coffee-script haml parser so that we can write our templates in haml and coffeescript. We love haml, we use it in all of our Rails work and we love CoffeeScript since day 1. When we took Backbone.js to create a single page webapp, we realized that there are many choices for templating, but most them force you to write plain HTML, which felt like a step in the wrong direction. On the other side there is already a Tim Caswells very inspiring haml-js library, but sadly this one forced us to write javascript instead of CoffeeScript. So in the end we decided to implement our own haml-coffee script parser to avoid pardigma breaks. It’s not perfect, but stable enough to build this website.

Last but not least we switched from Sass to Stylus, which is a little more radical and has tons of cool features. Stylus plays very nice with rails using the Stylus gem from Luccas Mazza.

So where do we go now?

When we developed the website we’ve realized that there is a lot of redundancy in the code. As example I’ll take the project model. So how do I get it to the client?

• You’ll write it in Rails, tweaking the as_json method since you’ll have to incorporate all images into the JSON hash.
• You’ll write a model for Backbone.js
• You’ll write a collection for Backbone.js
• You’ll create a view…
• …and a template where the data will be finally rendered.

If you repeat that steps for the other models you’ll get the feeling, that the web development is terribly broken at the moment. There must be a more DRY approach on realizing this. I’m thinking of switching from Rails to Node.js and implementing models that can be used on the server and on the client. But this is another step, for now we just established a very cool toolchain for views and templates.

Photo by puuikibeach. And for the big fans of our old page – you can view it here.

Most of you might agree that the pace of web-evolution was impressively intense last year. (Yeah,  the web is dead, we just haven’t found a new name for it yet.)

From a business perspective, 2010 was also pretty good, with many services empowering smaller companies and solo developers. Especially the Apple and Facebook ecosystems continue to nourishing a whole new generation of small dev shops. We like that.

But following Ray Kurzweil’s argumentation in “Age of the spiritual machine“, evolution will accelerate, which results in accelerated cycles of technologies, which in turn implies everything will change. In fact this thought is nothing new, but change is more perceptible nowadays, since it happens faster. That said, just turn your face for a second and you might have already missed the next big thing. It’s important to have an idea of what’s next.

So, curtain up for a random collection of our thoughts about the things to come in the near future.

Raise of the Javascript I: Serverside Javascript.

For nearly two years, we’ve been working on smaller serverside javascript projects, so we kind of expected that this will happen. But node.js still took us by surprise.

While most serverside JavaScript frameworks mimic existing methodologies , Node.js introduced a novel approach to model our server processes.

Node.js is serverside JavaScript with a twist. In Node.js everything is non-blocking and all API calls are handled asynchronously. Behind the scenes this is realized by running V8 in a single process and leveraging libev to process events. Node.js handles backend processes the same way jQuery handles frontend events.

This is a pretty bold move, and it has to be appreciated. Node.js caught the attention of many prominent developers in an unprecedent rush, dominating topics of one JavaScript conference after the other. And JavaScript is huge: With the usage of Javascript in Frontend, Database (MongoDB, CouchDB) and now backend, JavaScript evolves to become the very DNA of the web.

Want more proof? Some people took the effort and wrote an Emscripten, an engine to compile LLVM bytecode to JavaScript. With Emscripten you can run C++ directly in the browser.

Now that JavaScript has become some sort of religion, it is considered to be the savior of the web, establishing it as THE platform of platforms and reviving openness and compatibility for everyone. Nevertheless, native solutions still outplay their web-based counterparts in terms of performance, functionality and user experience, so let’s watch close if and when this is going to change.

Raise of the Javascript II: Some Coffee to your JavaScript?

Since so much JavaScript  is part of the development process, a lot of effort has been taken to abstract JavaScript in more established languages. Cappuchino tries to bridge it for Objective-C Coders. Google Web Toolkit makes the Java-Guys happy. But why abstract, when you can enhance? CoffeeScript is a wonderful language built on top of javascript that enhances the language to overcome it’s cumbersomeness without getting too far away from the bare metal. And since Rails 3.1 seems to fully integrate CoffeeScript into their toolchain, we have to expect more from it.

User Experience: Shared, Synced and Remote

All that shared data, repositories, and cloud devices, create the strong need for powerful syncing. Services like Dropbox do that job beautifully. While the joy of syncing anything to everything was primarily felt by geeks, this will be big in the mass market very soon. Smartphones, tablets, and embedded devices will force the user to sync the hell of their devices. With increasing bandwith and usage of cloud services, the average user will eventually have little need for local storage at all. In a certain sense, Dropbox could be considered as a solution for just a temporary problem.

Hardware: TV

Apple did a half-hearted job with the release of the next generation Apple TV. They might have been too busy with their wunderkinds, but obviously it’s just a question of time when they (or someone else?) do the job right.

Currently, Apple engages a huge number of talented developers creating successful iOS applications, games and tools through the hugely successful App Store. They are sitting on a pile of existing software that can quickly be ported to new devices running the same successful platform, giving Apple a massive headstart.

It’s also quite a convenience that most TV users already have a smartphone or/and an iPad. At last, we should kiss the good old tv remote goodbye. The remote interaction of TV screen and input device will be an interesting terrain to watch. There is a huge opportunity to revolutionize the TV experience very soon, because concepts like teletext or chunky remote controls don’t belong into this century. And while we’re at it, we might also get rid of our collection of consoles including everthing that comes with it (CDs, cable tangles, etc). There’s a reason Microsoft doesn’t give much about a new physical disk drive for the Xbox anymore after failing with the HD-DVD.

Frameworks: Not without my Tools

While in the last years software frameworks dominated the software scene , tools get more and more important: Sencha Animator, Apple iAd Producer, Radi and even Flash being able to produce high quality HTML5/CSS3/Javascript Output. That shows us that people don’t care about the platform. They care about the tools that embrace creativity. And developers care about an easy workflow – and let’s be honest: Writing good code is hard! Most people just want things to work. The mac store could also play a significant role for the new generation of simple productivity tools.

We just held our talk “if it moves they will watch it” on jsconf.eu – I hope everyone enjoyed it so far. For those how are interested in the demos here are the links:

• Canvas vs. SVG vs. matrix3d
• CSS3 Timing functions

You can find the source code for these demos at github. Our real world examples for doing animations can be found here:

• 100 Tweets (Canvas)
• Networkmap (Canvas)
• Dilution Calculator (SVG)
• HTML5 Game / Firefox only (Canvas)

If you have any question feel free to comment or write us an email.

On May 31st the WebMontag Ruhr took place at Witten University. It was quite packed and there were plenty of talks – most of them focused on internet marketing and social media.

My personal highlight was the fictitious character UWe Haar and the startup Buddy Beer (could anyone provide me a link on that – or is it stealth?). I had a html5/css3 talk about responsive web design as mentioned by A-list-apart – if you’re interested in the slides (German) you can get them from scribd.

Big thanks to the organizers Steuerung-B and Unicum - Hope I’ll see everyone on the next Webmontag!