Smartwatches, internet of things & future of tech

This message was shared internally at 14islands. We want to share it with the world as it might be relevant to people working on the internet.

Hi guys,

I like to put a thought here, its about the future of technology.

I’ve been reading quite a lot and listening to podcasts lately. Seems like all the big players (Apple, Google, Samsung and so forth) are putting their attention on wearable technology and the connected internet of things. Its supposed to be the next big thing.

In other words: the world around us is becoming smarter and more connected. Our clothes, cars, washer machines, coffee machines and sensors all around will be sending information and we’ll be able to interactive with these things wherever we are.

Apple will soon release iWatch with focus on health. Today Google realised a concept for their newest thing, Android Wear:

Motorola & LG release watches using the OS:

This makes me convinced that it’s happening for real, the future is really coming :) It’s really cool with the concept how contextual its supposed to be and the speaking input is #disruptive. There will also be a kit for developers.

One thing I really doubt is that these smart-watches will have a web browser. They seem to small and contextual for it to be a good idea: It’s likely an app only experiences, the same goes likely for the iWatches.

This brings me to 14islands. We are a very small company, specialised in web development. We’ve all been doing web for 10 years or more. We are really good at it, but we also love UX so maybe it would be cool to experiment in this space.

I don’t think the web is dying or anything like that, but guessing that there will be a lot of action in this space going forward. I can imagine all the cool companies wanting peace of the action.

All I know is that if this is to become a big thing, it’s usually better to be at the beginning. Perhaps we should stick to what we are good at, focus on being best at web. Its just good to be aware of the options and make a conscious choice before the lightning strikes.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands. Also a father of two boys, basketball fan and loves beautiful digital things.

Multiple Artboards in Illustrator for SVG icons

We find ourselves using SVGs increasingly when building responsive websites. The output is scalable graphics supported by all modern browsers.

We just discovered a faster way to work with multiple SVG icons using Artboards in Illustrator that we like to share with you. Instead of creating one Illustrator document per icon, we create multiple icons per document and can export SVGs all at once.

Open Artwork panel in Illustrator and click “New Artboard” to add new boards. Arboards can have different sizes, to make sizes fit each icon select it, double-click box for board and select “Fit to Selected Art” in preset selection, this will adjust the size.

Artboards in Illustrator

When all boards are ready: go to “File” > “Save As” -> pick “SVG” in the selection input. Now check the “Use Arboards” checkbox to make sure each icon gets its own SVG file.

Export as SVG

This will output multiple *.svg files with the Illustrator file name as prefix and name of each Artboard as postfix.


Fast and easy. If you have any comments or feedback please reply to our our tweet.

Our principles for BEM + Sass

BEM & Sass

There is a common misunderstanding that CSS is easy. It might be on small projects, but when the scope gets bigger and complexity grows it becomes really important to have a solid structure and common guidelines to follow.

There are many techniques now available to help out with this task, such as: OOCSS, SMACSS, SUIT, BEM. We tend to lean towards @csswizardry flavoured BEM and recommend reading his article about it.

We are also big fans of Sass to bring computing power and speed to the development process. BEM and Sass are powerful horses, so to tame these animals we have few principles to live by - to nicely structure our CSS.

In this article I like to share these principles, plus show how the Sass code looks in practise.

Principle 1: Classes as selectors, not ids or element tags

We like to use CSS classes as selectors, instead of using IDs or Element tags.

While IDs are handy as fragment identifiers and JavaScript hooks, its better not to tie the CSS to IDs. Some argue that IDs are the fastest CSS selectors, which is true, but the speed difference between IDs and classes almost irrelevant and it only applies when IDs are the key selector.

Elements tags are useful for semantic markup, but not well suited as selectors. They are slower and not very flexible as the same set of styles often applies to different elements. As an example a button design can apply both to <a>, <button> and <input type="submit"> elements.

CSS classes are best suited to keep the code modular, easy to change and have additional benifits, such as being able to mix styles together.

If we’ve done a good job of building up our styles, it should be very fast to prototype and build out new layouts. Look at Twitter bootstrap and Designmodo as good examples.

The main risk using classes as selectors is the possibility of conflicts if two different classes get the same name. This is where BEM comes in handy with prefixes and naming conventions descriptive enough to prevent this from happening.

Principle 2: Keep it flat

As a rule: Never nest CSS more than 2 levels. Otherwise it becomes coupled and hard to change. In fact 1 level is preferred. It will require more classes in the markup but gives extra flexibility.

This is also where Sass comes in handy by making it possible to store all states within the same CSS class.

Lets take an example of a module called toolbar that includes a search input. We only want to make the search input visible when the toolbar is set to an active state. To do this we use the Sass parent selector (&) to detect a parent state class called toolbar—active.

Example markup:

Example Sass:

Now we have covered the active state, lets add other states to the mix. Say we want another border for the :focus state and increase the input width on a breakpoint for screen sizes bigger than 900px.

Sass example:

All our states for this particular class are now contained in the same place instead of being scattered all around the CSS.

The output will still be a level 1 CSS.

CSS Output:

This is a big key to keep the Sass code simple and the CSS output as fast as possible.

Principle 3: Break it down to modules

We always create one file per module to keep things lean and to make sure the files don’t grow to large. As an example, the toolbar module will be in a file called toolbar.scss.

We still have CSS files for generic classes that apply in multiple places on the project.

File examples:

  • layout.scss for global layout styles.

  • typography.scss for all the different font styles.

  • forms.scss for form element styles.

This idea maps quite nicely to the structure in SMACSS, also a good read. The general rule is to use common sense on how to break down these files.

To broaden this concept a bit, we also try to use the same names for related files on a project. For example Javascript modules and server side partials that act on the same scope.


  • toolbar.html.erb: Partial server-side template.

  • toolbar.js: Javascript module.

  • toolbar.scss: Sass module.

Doing this makes it easier to find related components within a given project.

Principle 4: DRY it up

DRY (Don’t repeat yourself) is a common practise in programming that also applies to Sass code.

In Sass we can use variables to store common values in one place. Variables in CSS are being introduced but a common browser support is still a thing of the future.

Variables are more readable then colour codes or random numbers. Lets use our loved toolbar example and DRY it up, the code will look something like this:

The first thing you will notice is that we have a global variables.scss file that stores all variables on the project. The module name is also a variable since we use it multiple times in the file.

Notice how this makes the code more descriptive and easier to read.

Bonus Principle: Style guides

As a bonus principle: It’s very useful to create a style guide to have a quick overview of all the styles within a give project.

Style guides are just simple HTML document that include all the visual elements of a project with all possible states. This is usually quick to create, but requires a team effort to keep up to date.

We recommend it, specially on responsive projects where some elements have multiple states depending on multiple breakpoints.

Be careful out there.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands. Also a father of two boys, basketball fan and loves beautiful digital things.

Case Study: How we built the scenes on Google Santa Tracker

The christmas spirit has arrived early this year at 14islands!

We got approached to help on a very exciting project from Google called Santa Tracker.

Google Santa Tracker

Google Santa Tracker is a christmas calendar that consists of 24 interactive scenes. From elves having a good time and doing some work to mini-games to keep you entertained - Google Santa Tracker is a massive christmas environment with lots of fun.

One scene is unlocked per day, from December 1 until December 24th. We had the pleasure to collaborate on 9 scenes for this project.

Goole Santa Tracker calendar

Thus we would like to share our experience on the process from design, coding to debugging and testing in various devices.

The design

The whole experience was directed by our friend and multi talented designer Haraldur Thorleifsson.

The design features colourful flat elements and details, like iconic animals and nature. The elves are shown in different colour outfits and you can always see them posing in different perspectives.

Everything is vector based and got delivered to us in Illustrator files. That gave us the freedom to slice and scale them how we see fit. Good approach to keep things responsive and resolution independent.

Building this design was loads of fun. It was not uncommon to laugh about the scene because it was so captivating.

Say, an elf animation moving too fast because you are experimenting with the animation? “Haha - look at that elf!”. And so on.

Santa Tracker streets scene

Bringing the design to life

Looking at this project design we could see straight away that we should give SVGs a try.

The elements were not too complex and the SVG’s potential was staring right at us. Some reasons that pushed us to stick to SVG on almost all of the graphics we took care of:

  • A SVG file size if compared to a PNG is smaller.
  • A compressed SVG file size gets even smaller than an optimised PNG.
  • We love markup. Glancing through a SVG markup and it’s quite straight forward to understand what’s happening, making it easy to tweak where necessary without opening jumbo Illustrator.
  • No extra requests. Put this bad boy inline with the HTML and you’re gold.
  • It’s crisp. Hello, retina! Long time no see.


  • First image is a SVG and it weights: 4KB (uncompressed)
  • Second image is a PNG and it weights : 10KB (uncompressed)

With Illustrator opened and SVG in mind, we would spend some time on each scene thinking on what would be the best way to tackle them.

Our process of working on Illustrator was something like this:

  1. Study and strategise the scene. How many layers should be separated, grouped, etc.
  2. Copy the object that you want to export and paste it in a new document.
  3. Fix the “artboard” dimensions in Illustrator based on the graphic.
  4. Make sure the export settings are optimal for web (see screenshot below).
  5. Compress it if possible and make sure it still looks good. Here you have to be careful, compressing might remove some things you need.
  6. Code!

Illustrator export settings

It’s important that we compress the SVGs to keep the size small and optimal. Performance matters!

A quick search on compressing SVGs I came across svgo by chance.

That was our tool of choice for compressing SVGs to keep them optimal and we can recommend it. There’s a grunt plugin for it, even.

Separating different elements

Given some time studying the scene we could then conclude on which elements needed to be separated in many graphics and which elements could stay all together in one.

It was important to divide the scene properly in different layers to get some nice effects. That way you can have some elements staying on top of others, acting as a “mask” for some animations.

Check out the airport scene, for example. The elves just re-appear fully clothed. For this effect to happen properly, we needed the “closet” to be in a separate layer being on “top” of the “conveyor”. So the elves can show up behind it.

Airport scene

Animating with CSS3 keyframes

We have our scenes in place responding well. Now how will we animate them?

There are a few different ways to animate an SVG.

1. You could use the SMIL spec to animate some SVG elements

SMIL stands for “Synchronized Multimedia Integration Language” and it’s basically markup that let’s you specify attributes that should change for a given duration. The SMIL syntax can be used in combination with SVG.

Syntax example:

Pretty much like animating elements with XML. It’s a very interesting approach, introduced initially by Mozilla.

The problem is that Internet Explorer doesn’t support it and likely never will. So this option was out.

2. You can use Javascript to update the built-in attributes of an SVG.

SVG has some very interesting attributes that you could update on the fly by using Javascript. Radius, x, y, stroke, etc.

There is a article from polygon showing a nice use of stroke-dasharray and stroke-dashoffset for a cool effect.

3. You can animate the SVG just like any other element by using CSS3 keyframes

Being a responsive project, we wanted everything to perform the best possible way.

We thought that CSS3 keyframes was a good performance bet - considering we animate only the “safer” properties as much as possible.

Also for the fact that we wanted to keep things simple with Javascript and that our animation could be easily solved with CSS3 transforms - this became our choice.

We won’t go deep on how CSS3 keyframes work because there’s plenty of material out there.

But one typical and interesting task that we would need to do is how to synchronise some animations together.

CSS3 keyframes and the animation-delay

With Javascript out of question, one way to make the animations synch is to use “delays”.

You want animation B to only play when animation A is completed. So you add some delay to B that equals the duration of A.

The CSS3 animation spec has a property called “animation-delay” for this.

To be honest, it would make more sense to me if this property would be named “animation-initial-delay” because the delay only happens once.

Specifying a delay of 5 seconds on animation B, means it would run 5 seconds after the page loads. As soon as the animation comes to the second iteration, the delay won’t be applied.

Sometimes that is enough depending on what you need to build. A very good example of animation delay usage is the digital clock that you can find in the Command Centre:

See the Pen yJnLi by Marco Barbosa (@marcobarbosa) on CodePen

Here each digit gets a delay before fading-in/out to “offset” it from the other digits animations. That way the seconds play before the minutes that play before the hours.

But what if you want this delay to happen in every animation cycle instead of just once?

Read on!

Adding empty frames as delay gaps

The idea is to increase the duration of an animation just to be able to have “delay gaps”.

Total duration = duration + some delay gaps


See the keyframe there at 50% and then next is 54%? That’s a 4% difference between them, right? That’s our desired duration: 20 (total duration) * 0.4 (that’s 4%) = 8 seconds.

So our animation is 8 seconds long but we use the other 12 seconds to do nothing - acting as a delay.

That way in another animation, also with a 20 seconds duration, we would do something at 54% to match.

This way you can synch a lot of animations together by adding larger durations and making sure the keyframes are similar.

One scene that shows a very nice synchronisation is Call from santa:

Call from santa

Make sure the animations that you want to synchronise have the same duration, delay and preferably are linear (or have the same easing). That will make things a lot easier.

Debugging and testing

iPhone4S happened to be a very good test device for this project. That is because CSS3 keyframes performance in both Samsung Galaxy S3 and iPhone5 were a breeze.

Chuck in some animations and things will “just” work. Pretty powerful devices.

iPhone4S, however, would crash if you’re pushing too much.

Because of that, iPhone4S quickly became our reference test candidate for the scenes: if you have something crashing on iPhone4S then it’s really too much going on.

The worse part about testing and debugging was Android browser.

Android browser

Android browser has some weird behaviours to when it comes to animations. Debugging was even more difficult because you’d nee to toggle things on/off to find out what’s going on.

Fortunately, for that, there is Weinre.


Just to give you some examples of Android browser issues that we found on the way:

  • Android doesn’t like animation shorthands
  • Iteration count is not properly supported
  • direction reverse doesn’t work properly
  • negative delay doesn’t work properly (or at all in some cases)

This will be improved very soon though since Chrome is now the default browser on Android versions starting from phone 4.3.


Building these scenes was a true joy. From putting SVGs together in the browser, to spicing things up with some animations and debugging.

A few points to sum things up:

  • SVGs are awesome.
  • CSS3 animations are good until a certain point. With more complexity they get pretty limited.
  • Javascript still has a very strong spot when it comes to animations. Simply because of control and flexibility. Animation order, delays..the more complexity you need the harder it gets to handle it with CSS3 keyframes.
  • Be careful with Android browser. Test as early as you can to just be safe.
  • Responsive Web Design can also be interactive.
  • Ho ho ho.

Looking for a cutting edge project? We love those! Get in touch!

Smashing Conference 2013 take-aways

The Smashing Conference Band

This was the second Smashing Conference in Freiburg. We also wrote about our take-aways last year, in essence 2012 was an eye opener to responsive web design.

Here is our summary for this year’s event.

Honor the content

The highlight for us was the typography workshop with Dan Mall, he gave practical tips on how to find appropriate typefaces:

  • Differences: Look at the characteristics of typefaces. Is it serif or sans-serif? Does it have soft or hard curves? Capital “R” is a good place to start and on light and heavy versions the differences are often more clear.

  • History: Read about the typeface history. When and why was it made? How is it intended to be used? Typedia is a helpful place to study about typefaces.

  • Message: A typeface is meant to honor the content so look for typefaces that fit the message at hand.

The problem with web fonts is that they don’t render equally in all sizes and on all systems. Some services such as Typekit always hint their fonts, but not all services take as much care to the web medium (Read more about hinting).

There are two ways to use web fonts: through a service or self-hosted. Not all typefaces exists in both places. Services might improve fonts on-the-go but usually depend a subscription.

Performance by design

Performance was also a big theme throughout the conference.

Ethan Marquette, who coined the phrase “responsive web design”, said performance is the main problem on most responsive web pages. The average page today is 1.5MB.

That is a worry considering that Asia and Africa are the fastest growing parts of the internet, where most people access the web on mobile, often over a poor internet connection.

Tim Kadlec talked about performance should be treated as part of the design process, not as an afterthought.

He recommends using visuals to convince people to focus more on performance, is a helpful resource.

Respect your users time, bad performance is bad business.

Responsive design process

Dan Mall talked about how he uses element collages to communicate design to his clients. Making full page comps is both time consuming and gives impression of a complete web site with a fixed width.

Element collages show suggested design elements for the site design, he even makes the collages horizontal to decrease the feeling of a webpage. Dan uses Photoshop to design and tests things out in the browser. He suggests that we change the phrase “designing in the browser” to “deciding in the browser”.

Read/Write web

Luke Wroblewski talked about the constrains of designing mobile apps and we should not assume that users have two hands on the device.

A step in that direction is to eliminate the use of keyboard as much as possible. Instead provide suggestions and minimize input from our users.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands. Also a father of two boys, basketball fan and loves beautiful digital things.

How we built the website for

Responsive Images. Solved

It’s been few weeks now since we released, a service that delivers perfect images for every screen. The feedback has been really good and the beta release exceeded our expectations.

We spent many months making the service good, but what surprised us was all the compliments we got for the website. Some people were asking about our responsive process building it, so we would like to share the process in this article.

It was in fact a good time for us to polish our process, as we were in charge of all aspects: content, design, development and release.

The mission was born out of our need as web developers/designers to solve the responsive image problem. Therefore we knew we wanted to target the site towards similar audience as us: people that build responsive websites.

We started out with 5 main goals:

  • Be professional: In order to get other web professionals to believe in the service the site needed to say: “Trust us, we know what we are doing”.

  • Be responsive: It only made sense to have the site fully responsive for this service. We also strongly believe that is the right path for most websites.

  • Be fast: Have you experienced a 1MB responsive site on a slow connection: it’s sloooow. is about making sites faster so we wanted to walk the talk, not just talk the walk.. you know what we mean.

  • Get people interested: Knowing ourselves that the responsive image problem is hard to solve well, we wanted that message to come across and how makes life easier.

  • Get beta signups: It was important for us to get people to start using the service in beta. We needed real-life testing and to get as much feedback as possible while in beta. The signup experience played a big part.

Writing the content

The first step in the process was to write copy for the landing page. We made few versions of the copy in markdown using iAWriter that we shared over Dropbox.

iAWriter content

After few iterations we felt we had something good. This was our content prioritization:

  1. What, why & signup: Quick summary of what it is about and why it matters.

  2. Benefits: What you get from using the service, so people realize all the awesome features.

  3. How it works: As developers we like to understand how things work before using it. We figured others would to.

  4. Getting started: Real code examples that show how simple it is to get started.

  5. Footer: Navigation and contact details.

Reading on different devices

The next step was to read the copy on different devices to get a better feeling for the end-result. Reading it on mobile for example made us realize that some parts needed to be shorter and some parts were better with bullet points instead of long paragraphs.

Content in browser

Since we wrote markdown in iAWriter, it was easily exported to HTML markup. With small dash of extra HTML and CSS, we made the content adaptable to different screens.

Validating the idea

Since we were building a brand new service from scratch we wanted to validate the concept before spending a lot of time on design details. We decided to invite few good friends to validate and give us feedback.

A signup form was required to start using the service so we built that before sending the invites. The signup form needed to accept email address from people and their website domain in order to use the service.

Signup form without design

To save time we only implemented the signup functionality without any design. The signup form validated correct email and domain fields client-side to provide a better experience.

Out the door

We picked Ruby on Rails for the back-end. Rails has become a mature web framework over the years and makes development enjoyable for database-driven web sites and apps.

We used Heroku as the production environment for the alpha/beta releases. Heroku makes it so easy to deploy Rails apps to production, just a simple push from Git that we were already using for version control.

We created a project on Basecamp to contain all the discussions in one place and to send out invites to our friends. The feedback we received turned out to be very valuable. After few adjustment our friends were happy with the concept, so we went on with it.


So far we mostly focused on content and signup functions, so we were anxious to start designing the user experience.

First iteration

The service is all about images, so at the beginning we wanted to use big imagery.

The first iteration looked like this:

Iteration 1

While this design “looks” nice, it felt more like design for the next MySpace rather then a professional image solution.

The typography on top of an image was also hard to read. The design had to-do a better job of explaining the service.

Second iteration

In the second iteration our focus was on explaining the service by using multiple devices and demonstrate that the same image scales nicely on multiple devices.

Iteration 2

Now the message became clear but everything around it was a bit dull, to say the least.

However, we felt we were on the right track. The next step was to experiment with different typography, colors, imagery, icons, look and feel.

Final design

After few more iterations this was the final design (note: it´s never really final).

Final design


Oxygen font

We picked Oxygen from Google fonts. It’s a sans-serif font with a professional feel, very readable and renders well on most devices.

Color palette

Blue/green color palette

We used shades of Blue as the base color. Blue is calm and breeds trust, but we included lighter versions to make it more playful.

Green is the positive color of nature, we used it for action buttons and to give positive feedback.

Main image + logo

logo + image

We wanted images to speak for the service and used this nice image taken by David Lindkvist as a base. The logo is very simple, using the same font as we have in our company logo at 14islands.



Iconic is an awesome free web font library with lots of nice icons. It’s all vectors so it’s a great fit for responsive sites.

Getting our hands dirty with code

We designed for large screens first to nail the high-end experience. We then took a step back and started building the site mobile first. Having done that we had covered the two extremes and could continue to design in the browser, using progressive enhancement techniques to bridge the gap.

Starting on mobiles made the site more accessible and faster for low-end devices. The user experience was enhanced when scaling up to bigger screens by basing breakpoints on the content at hand.

The biggest dilemma we had while working our way up to bigger screens was making it look pixel perfect. We soon realized that we were applying the old mindset of fixed design to a responsive website.

When everything is fluid, the way to stay sane is to let go of control. Our design was better used as a guideline, not as the Holy Bible of pixel perfection.

Instead we created guidelines on how content should flow. As an example, here is our typography system built with CSS:

Signup experience

One of our main goals was to get people to signup for the beta.

The signup experience was therefor very important, here is how we designed it for multiple states:


Default state

Valid email

Valid email

Submit success

Submit success

Submit error

Submit error

The code

Using the HTML5 email input type and url input type for domains gives a more suitable keyboard on touch devices.


The email keyboard has a handy “@” signs for writing emails and the url keyboard has “.com” for writing domains.

The no-validation attribute is to disable browser validation errors as we wanted to provide custom made interactions in JavaScript to make it more pretty.

What we learned

The truth is that the process was not as linear as in this article. We wen’t back and forward, discussing the pros and cons of each approach throughout the process. It basically all boils down to communication.

A key factor is to prototype early and gather feedback before spending to much work on the wrong thing. Focusing on content first helps to build out the whole experience and deliver the core message more effectively.

Our approach to start with raw text and functionality before spending time on design details is something we will take with us into future projects. It’s really fun to see a small beast take shape and grow into full grown monster.

We will share more about our experiences building going forward. Follow us @responsive_io as we talk about the journey and release some amazing features.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands. Also a father of two boys, basketball fan and loves beautiful digital things.

Meet - perfect images for every screen - a better way for responsive images

As web developers that build responsive web sites, we experience the same problem on every project.

We do all the responsible “responsive” things. We start with the content, prototype in the browser, build mobile first and enhance the experience for bigger screens.

Life is good, until we have to deal with images.

The elephant in the room

Most responsive websites send huge images to small screens resulting in slow performance, wasted bandwidth and a bad user experience.

Just look at these numbers:

"60% of all web traffic is images" Source

"69% of mobile web traffic is images" Source

"57% will abandon a site after waiting 3 seconds for a page to load" Source

"87% of mobile users expect sites to load at least as fast, or faster than on their desktop." Source

We should be loading optimized images for every screen. However, web standards don’t provide an easy way to do this without resorting to complicated client and server-side techniques.

Let’s be honest, on most projects we don’t have the time to solve it in a proper way as we are usually busy building awesome websites.

A better way

This is why we built, to solve this problem once and for all. automatically resizes and optimizes images on the fly, delivering perfect sizes for every screen. We serve high resolution images for retina and high density screens. We convert images to WebP (currently only supported in Chrome), progressive JPG and use other clever optimizations to reduce the image file size.

Speed is important, caches all images on a global Content Delivery Network (CDN), making sure that images load from a location near you. After a resized image has been served once, the next delivery will be blazing fast.

The philosophy

Our goal is to make it easier to build responsive web sites by serving perfect images as fast as possible. We all have more important things to focus on then re-inventing the wheel.

Let us do the hard work so you can focus on your website.

We don’t apply watermarks on your images. We don’t use user-agent sniffing, cookies or other shaky techniques to resize images. Instead, we use feature detection of browser capabilities to make sure we are future proof. respects styles applied to each image element. It doesn’t force you to specify any custom style attributes, instead it picks up the style you’ve already specified using normal CSS or image attributes.

In essence, images should behave as they would without the service, with the addition of better performance, faster downloads and a greatly improved user experience.

We’re in Beta!

Please visit for more details.

Sign up for a free beta account to start using the service.

We have many exciting features on the roadmap, so make sure to follow us on twitter and please reach out if you have any questions.

Happy responsivizing!

Racer - A Chrome Experiment

Developing the Google Chrome Racer sound experience

Racer is a chrome experiment by Google Creative Lab, where you and your friends line up your phones or tablets to create a scalectrix-like race track across several screens.

We teamed up with Plan8 to create a dynamic music and sound experience out of an original composition by Giorgio Moroder. It features dynamic engine sound, and other race effects, but more importantly a dynamic music mix that spreads out over all connected devices.

Read the full case study on HTML5 ROCKS: Case Study: The Sounds of Racer

Watch the live demo from the Google I/O 2013 keynote


Production companies: Plan8, Activetheory, HUSH

Case Study: Betting on a fully responsive web application

Kambi app as second screen

Sports betting is a popular entertainment among people that love sports. Today people are always connected to the internet so betting is possible anywhere, even while watching live sports events.

Kambi is one of the top sports betting providers and their services include popular sports from all over the world.

This is the story of how we were part of taking their sports betting web application to the next level.

The Kambi Story - Separator

The Challenge

At the time we joined the team, a mobile web application had just been released to users. Soon, users also wanted an application specially designed for tablets such as the iPad & Nexus 7.

At that same time it was becoming clear that the desktop application would not stand the test of time. Not because it wasn’t good. It was very good and mature after years of development.

The fact that it was built in Flash was a burden for few reasons:

  1. It required users to install Flash.
  2. It required features in two places, HTML5 and Flash.
  3. It required talents with different skill-sets to develop the product.

HTML5 is now ready to deliver the quality user experience Kambi wanted for their customers. The first idea was to build three versions of the application in HTML5. One for mobiles, one for tablets and one for desktops.

However, we quickly realized that it would complicate our work a lot. It would require us have three separate teams, code-bases and todo lists to manage these applications. It was just not likely to result in a consistent and good user experience for different devices.

We believe the path we took was more future friendly.

The Kambi Story - Separator

What we built

In the multi-device world we live in, building responsive web applications that adapt to different screen sizes and capabilities is the sensible way forward.

At Kambi we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms.

Live Right Now

Live Right Now Live score-board that scales nicely from small to big screens.

The Betslip

The Betslip

The betslip is always visible on the desktop, but on mobile it shows up when the user places a bet.

Live Streaming

Live Streaming Video streaming for live sport events, using the HTML5 video element.

Multiple Themes

Multible Themes The platform is growing fast, each customer gets a branded theme for their users.

The Kambi Story - Separator

What we learned

Making a complex web application responsive, without sacrificing usability, performance or good development process was not just a walk in the park.

Here are the lessons we learned along the way.

Mobile First

Starting with the mobile web app in the beginning turned out to be a huge benefit. The limited screen size required the team to prioritize features and to keep the user interface simple.

We would enhance the user experience as scaling up to bigger screens, but starting mobile first forced us to constantly focus on the most important parts.


Some people say that Photoshop is dead for responsive web design. That fluid layouts can’t be designed on a fixed canvas. We don’t believe it to be 100% correct.

Instead making prototypes while designing becomes really important. We were lucky enough to work with talented designers that constantly built prototypes to feel out the user interface. This was a key factor in getting the experience right.

Thanks to the awesome designers Nico & Magnus.

Responsive JavaScript

Using CSS media queries, layout can be adjusted for certain breakpoints based on user screen size and other capabilities. In JavaScript however, there is no easy way to change functionality based on these breakpoints.

This is why we built a library called js-breakpoints. The library uses breakpoints in the CSS to trigger events in the JavaScript. That way changes in the layout and functionality are always in harmony.

The library is open source, it’s available on github.


One of the main challenges of building responsive was making sure everything works on all modern devices and browsers. We built unit tests and other automatic methods, but that only solves the logical part of the problem.

Truth is, there is no replacement for real manual hands-on testing for the user interface. In the end everything has to work for real.

Style Guide

Kambi provides a branded theme of the application to all their customers. Each theme has different colors, fonts and background-images. Making sure the themes were looking good while many people worked on the code-base turned out to be a hassle.

That is why the team created a style guide. Style guide is a HTML document that shows all the user interface components of the app and possible states for all the themes. This gave us a quick overview for the styling of the application.

Another great benefit, it helped us to build components that were reusable and forced us to keep the CSS clean.

Lean Process

In the beginning we used to work in two week sprints. After few sprints we felt that there was wasted time between completing and planning new sprints.

So we thought, why having sprints at all? In our team we decided to skip sprints and do more continuous flow of working. We did planning for each feature just before implementing instead of planning two weeks in advanced.

This made us more productive as a team and gave us more time for actual work.

Frequent Releases

Following our two week sprints we were used to package new releases every two weeks. Problem is, the longer time it took to release, the longer time it took for us to learn how users responded.

Therefore we changed to frequent releases and ship as soon as completing new features or fixes. This gave us instant feedback while building the product.

We used Google Analytics to track and validate how users responded to new features. Often our assumptions about the product turned out different from expected.

High Quality

Faster releases called for better ways to work and constantly make sure that the everything works as expected.

Our team at Kambi made many improvements. More pair programming and code reviews. Limit tasks in progress. Always improve code while touching it. Keep retrospectives open and be honest as a team.

One of the great thing about Kambi’s culture is trusting teams to make their own decisions, both about the product and how to work.

The Kambi Story - Separator

Technology Stack

Talented people is key to deliver quality services, but the right tools are important to keep everyone sane while doing it.

Following is the front-end technology stack that evolved at Kambi, we feel very good about it.


Brings structure to JavaScript applications. Components communicate via events making all the layers loosely coupled, reusable and testable.


DOM manipulation made easy. First we used Zepto.js as a lightweight library for mobile devices, when extending support to desktop browsers jQuery was the choice.


CSS3 pre-processor that is hard to life without. First we used LESS but it fell short on many features, specially for responsive web design.


Behavior-driven test framework for JavaScript. We used it to write tests to for all the application logic to make sure everything works as expected.


JavaScript file and module loader. We used it to define dependencies between modules and to minimize the file-size of the JavaScript before going to production.


Opinionated front-end library from Google to rapidly build web applications. We used to build an back office application as fast as possible.


Eliminates the 300ms click delay for touch events. This library serves its purpose to make the user interface respond as quickly as possible.

Apache Ant

Mature build tool to run tasks such as unit tests, code quality checks, deploy to servers, to compile Sass to CSS, and others to automate our processes.

JavaScript Breakpoints

We built this library to trigger events in JavaScript based on different breakpoints in the CSS. Breakpoints are fired via media queries, check out the project on Github.

HTML5 Video

Native video player, supported by all modern browsers. We used it to stream live sports matches while betting on mobiles, tablets and in desktop browsers.

Server Sent Events

Communications from server to client, also known as EventSource, part of the HTML5 Spec. We used it to instantly push odds updates to users.

The Kambi Story - Separator


Fully responsive web applications is not just a pipe dream anymore. With the right mindset, tools and processes it all becomes possible.

We are truly thankful for the time at Kambi. Awesome place overall and fantastic people in every position.

Tack så mycket!

Hopes for Apple WWDC

Apple WWDC 2013 Logo

WWDC is coming up, where Apple announces their newest innovations.

There are countless rumors about what Apple will bring this year, but no ones seems to really know what the hell is coming up. One thing for sure, people at Apple know how to keep secrets. The silence is screaming.

Here is the list of things I hope to see.


The only thing that seems certain is the launch of iOS7, new operating system that runs on iPhones, iPods and iPads.

Few months ago Jony Ive, the product design hero at Apple, was assigned to step-up their game in that space.

Some people predict a new flat design to iOS, but I expect their changes to go much deeper because many of the default apps are falling behind.

Thinking about the apps I use daily, it’s actually more Google apps then from Apple.

I use Gmail app for email, not Mail. Chrome for browsing, not Safari. Google Maps for finding places, not Apple Maps …and so forth.

I hope Apple will become better in that space.

iCloud pics/videos

Another area where Apple is lacking is storing pictures & videos in the iCloud.

If you are not convinced, read this ranting about it. Its basically a mess and I have no idea where my pics are at the moment.

That is why I use Dropbox to handle these things, but I hope Apple can become better at it.


The iPad is growing fast in popularity. My kids for example really like it, in fact they also try to touch the screen on my laptop.

However, the iPad 3 is a bit to heavy as a reading device and to hold in a upwards position. I’m hoping for a lighter version this time.

The iPad Mini is perfect for holding upwards, but the screen has lower pixel density, so one could expect a retina version coming soon.

MacBook Air

This might become Apple most popular laptop going forward.

I currently use a MacBook Pro at work, but carrying a lighter computer around would be even better.

If there was a MacBook Air that had similar power and preferably retina display, I might make the switch.

MacBook Air improvements would not come as a surprise.

Surprise Me

The biggest excitement evolves around new gadgets.

Talks about new digital TV from Apple are still in the air, have been last two years.

Then there is iWatch, a watch and smart mobile device strapped to your hands.

Who knows? I didn’t know when the iPhone was released in 2007 that it would become a thing I can’t life without.

Exciting to see what Apple brings this time.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands. Also a father of two boys, vivid basketball fan and loves beautiful digital things.

Talk to Hjörtur on Twitter.

Useful Search Features

It’s often said that “no interface is the best interface” and that rings true for search.

Lately I have discovered some useful things to-do with search that I will share in this write-up.

Google it!

Having computers around me all the time has made my brain incapable of calculating the simplest things.

I’ve just learned on to write “calc” in the almighty search input an voila! got myself a calculator.


Another task hard to perform by the brain is converting amounts between currencies. There are numerous apps that exist for this only purpose but why not just google for the answer.

"X USD to EUR"

Currency Convertion

I moved to Sweden few years ago and been learning Swedish ever since. Google Translate has been a good companion but sometimes it’s faster to use search to help me translate.

"Translate X to English"


Stockholm, where I live now, is a beatiful and a lovely city but in the winter the weather is often shitty. Google can’t fix the weather but it can easily tell how laim it actually is.

"Weather X"


Thank god the spring is coming.

Social search

Google is great to answer general questions but when it comes to my friends it does not have a clue.

Facebook recently released a search feature called Graph Search that I find useful. Its still not released for all users but its coming up soon.

As a random example, lets say I want to have a Gin & Tonic party and invite all my friends that live in Stockholm. This is what I write in the Facebook search.

"Friends that live in Stockholm"

Facebook Graph Search

Now I got my inviting list with friends in Stockholm. Its also possible to search for stuff my friends like:

"Restaurants in Stockholm liked by friends"

"Hotels in Iceland liked by friends"

"Music my friends like"

This also makes it important for products and services to be liked on Facebook and people to update their info so they will be invited to my Gin & Tonic party. Smart move by Facebook.

Got any other useful search examples? Post it in the comments.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands. Also a father of two boys, vivid basketball fan and loves beautiful digital things.

You can follow Hjörtur on Twitter


The Importance of Performance

If you think that performance is something to think about late in the development process, maybe these numbers are worth looking at:


100 ms of extra load time caused a 1% drop in sales (source: Greg Linden, Amazon).


500 ms of extra load time caused 20% fewer searches (source: Marrissa Mayer, Google).


400 ms of extra load time caused a 5–9% increase in the number of people who clicked “back” before the page even loaded (source: Nicole Sullivan, Yahoo!).

37 Signals - Basecamp

500 ms increase in speed on resulted in 5% improvement in conversion rate. (source: Signal vs. Noise).

About the Author

Hjörtur is a creative web developer and co-founder at 14islands.

You can follow Hjörtur on Twitter


Client Side Library Tradeoffs

The Client side vs. Server side

Client side libraries such as BackboneJS, EmberJS and SpineJS have become very popular to build interactive web applications. These libraries take full advantage of JavaScript to create better experiences and to avoid unnecessary page reloads.

While client side libraries certainly help achieving this goal, it does not come without any costs. This article highlights drawbacks of going for full client side approach and brings up alternatives that are better suited in many cases.

The Problem

Client side libraries handle server communication mainly by sending JSON over the wire. That has benefits because JSON is lightweight and based on JavaScript objects, making it easy to parse and play with data on the client side.

Rendering HTML is therefore achieved on the client side without any page reloads. The problem is that content becomes harder (or impossible) to access by search engines and your stuff might not show up on Google as often as you hope.

The same goes for using the HTML5 History API push state to enable back and forward history in the browser. Push state expects server side endpoints that respond with HTML, not JSON, so it does not really work. It’s possible to create fake endpoints to make it work, but its kind of a hack.

Another common way to achieve browser history is by adding hash in the URL and trigger hash changes to switch states in the application. However, hash in the URL looks ugly and is not easy for users to write or remember.

Rendering HTML on the client side can also become slow when pages grow big and include multiple parts. Each part of the page usually has a template that needs to be stitched together with JSON and rendered to the DOM in the browser, causing many writes to the DOM.

Server side rendering

PJAX is another technique to avoid page reloads by rendering HTML on the server and using JavaScript for updating only the necessary part on the page.

This approach solves the performance issue for big views as templates don’t need any processing in the browser before being added to the DOM.

PJAX stands for push state + Ajax. URLs are mapped to real endpoints on the server so the HTML5 History API works without any hacks.

Mixing it up

Here comes the unexpected twist in the story, this approach is also not perfect, huuu? HTML is heavier over the wire and harder to manipulate compared to JSON. That is why mixing server and client side rendering together is often a good approach.

This is what Twitter did to improve performance and intergrade with the History API. They use the HTTP “Accept Header” and check if its “application/json” or “text/html” to determine whether to return full page response or JSON including data and the partial HTML template.

Twitter also released a new client side library called Flight that works without data being sent as JSON. This is a component based library that is being used to build the Twitter front-end.

37signals took a similar path in their revamp of Basecamp, in combination with a lot of caching resulting in a very snappy user interface. In fact they used BackboneJS to implement features that they could not accomplish using PJAX.

I recommend everyone interested to watch the video with David Heinemeier Hansson, co-founder at 37signals, explaining their design decisions in details.

Progressive Enhancement

Client side libraries use JavaScript for many things. To communicate to the server, manage state, enable browser history, for url routing and to render HTML to the DOM.

Problem is that JavaScript becomes the single point of failure. Errors can cause the whole application to fail and it can be hard to prevent these kind of errors. In browsers with poor JavaScript support nothing might work at all.

However, progressive enhancement becomes easy when the server takes care of the rendering and links can be enhanced so clicks without JavaScript result in full page reloads.

As navigation still works without JavaScript, content remains discoverable by search engines, making server side rendering a good approach for content driven sites and applications.

Going Responsive

Still, there are few issues. For developing responsive web applications one might wan’t to render different markup for different screen sizes. Server-side rendering requires browser agent sniffing to figure out device information, not very future friendly as new devices might be unknown.

Client side rendering makes it possible to produce different output by checking browser capabilities, that is more future friendly. At 14islands we use Modernrz to check for capabilities or techniques such as JavaScript Breakpoints to render based on different screen sizes.

Native Apps

If the plan is to release you web application in app stores, using native wrappers such as PhoneGap, there is no need for pretty URLs or search engine optimization. In that case many benefits of server side rendering are lost and client side libraries might be appealing.

The Split vs. The Holy Grail

The split between client and server code becomes more unclear when rendering is handled on the server side with added logic in Javascript.

Today with NodeJS entering the stage, some smart people are seeking to reuse code between the client and server. Airbnb has some of this people on board and its interesting to read how they use BackboneJS in all places in order to reach The Holy Grail.


The web was not really built with JavaScript at the center. It was built to get, post, put and delete documents over the internet using URLs. JavaScript became popular later to add interface sugar to mostly static web pages.

Today with client side libraries, behaviors that are native to browsers, are being built in JavaScript. That can make our applications interactive but its important to understand the drawbacks and that server side rendering still has its place.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands.

You can follow Hjörtur on Twitter


Debugging Mobile Web Apps

You are building a mobile web application but are experiencing problems on some devices. Emulators never work the same as the actual devices, so we need to remote debug on the devices.

Enter the world of remote debugging tools for HTML, CSS & Javascript. This article aims to cover the options we have today and start a discussion about better ways to remote debug on mobile devices.


Apple introduced remote debugging for iPhone with the recent release of iOS6. For this to work you need to fulfill the following requirements:

  • Mac computer
  • Safari version 6.0
  • iOS6 on device

You also need an adapter to physically connect your iPhone or iPad to the Mac, this is explained well in this Modus Create article.

You should now be able to inspect DOM elements, modify CSS on the fly, run Javascript commands, and do everything you could normally do from the desktop inspector.

Modus Create


Google has also released remote debugging for Android, using the Chrome browser. These are the requirements.

  • Android 4.0+ (Ice Cream Sandwich and later)
  • Chrome browser on computer and device
  • Android SDK on device

You also need to follow few steps as explained on the Google Developer - Chrome Remote Debugging page.

The problem is that Chrome is just available on Android 4.0+ and is only setup as the default browser on the newest Android devices. This makes it less useful right now as most users always use their default browser.


Weinre is a web inspector that runs in the browser and needs to be setup as a server. The cool thing about Weinre is it can be used to remotely debug on all devices and its free.

Weinre has most of the features to expect from a web inspector but its currently not possible to add breakpoints in Javascript. Also worth noting is that Weinre does not support debugging for apps running on HTTPS. If you are new to Weinre here is a good video by Jonathan Stark that explains how it works.

Weinre comes as a npm module therefore requires Node.js to be setup. It can be a bit painful to setup for the first time but works well when that is done.

To connect your web app to Weinre add a script tag pointing to the Weinre server. The web-inspector runs in all webkit bases browsers.

Adobe Edge Inspect

Adobe Edge Inspect, previously Adobe Shadow, is a “pain-free” way to remote debugging and works on iOS and Android devices.

One of Edge Inspect main selling points is synchronized browsing, the ability to browse on the computer and all connected devices update at the same time. Its useful for development and its a real time saver for testing on different devices.

Edge Inspect also keeps device screens from dimming or falling asleep, provides easy cache clearing, and allows you to easily grab screenshots from your devices.

Edge Inspected is installed as a Chrome plugin on your computer and uses the familiar development tools. Free app is available in the marketplaces that is installed on the devices.

However, Edge Inspect is not free and has a subscription model, witch is a bit annoying. The minimum price is $10 per month. There is a free option but its limited to one concurrent device, that kind of defeats the purpose.

Taken from the Adobe Edge Inspect blog:

To use the full version of Edge Inspect and connect an unlimited number of devices, a paid Creative Cloud membership or an upgrade to the full version of Edge Inspect at USD $9.99/month is required.

Free version is limited to one concurrent device connection. We hope this will allow you to use all of the features of Edge Inspect, and determine whether an upgrade is right for you.


There are few other options out there to help out in some ways such as JSConsole.

I would be curios to know about other options so please comment if you have suggestions.

About the Author

Hjörtur is a creative web developer and co-founder at 14islands.

You can follow Hjörtur on Twitter


The Art of Quality

In Robert M. Pirsig’s 1974 bestseller “Zen and the Art of Motorcycle Maintenance”, he explores the meaning and concept of quality, a term he deems to be undefinable. Good quality simply can not be measured – it’s a work of Art.

Pirsig argues that to truly experience quality one must both embrace and apply it as best fits the requirements of the situation. Such an approach would avoid a great deal of frustration and dissatisfaction common to modern life.

This is highly relevant to software development and experience design. Blindly adding features, just for the sake of it, does not necessarily improve quality. On the contrary:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

- Antoine de Saint-Exupery

Quality should not be confused with perfection though. A good example is the Japanese “Ensō”, a form of minimalist expressionist art in the shape of a circle. Some artists paint ensō with an opening in the circle to symbolize that imperfection is an essential and inherent aspect of existence.

Pirsig was early to realise that technology, and the “dehumanized world” it carries with it, appears ugly and repulsive to a non-technical person.

What’s wrong with technology is that it’s not connected in any real way with matters of the spirit and of the heart. And so it does blind, ugly things quite by accident and gets hated for that.

We have artists with no scientific knowledge and scientists with no artistic knowledge and both with no spiritual sense of gravity at all, and the result is not just bad, it is ghastly. The time for real reunification of art and technology is really long overdue.

- Robert M. Pirsig

About the Author

David is a creative web developer and co-founder at 14islands. We believe that quality lies in exceeding the expectations of our clients and our users.

You can follow David on Twitter

<< Read more