14islands

One of our recent projects was a Wordpress website called Sthlm6000+.

When developing a project with a CMS involved, a few questions will eventually come up:

How can we easily update the staging environment, so the client can see the changes?

How can we conveniently make sure that our local databases are always in sync, even though we are developing on our local machines?

The solution

There are a different number of possibilities for this. But we like to keep things as simple and automated as possible.

This is when I stumbled upon Syncdb:

SyncDB is a bash deploy script meant to take the tedium out of synchronizing local and remote versions of a Wordpress site. It allows developers working in a local environment (eg. MAMP) to rapidly "push" or "pull" changes to or from their production server with a single terminal command.

The script gives you a powerful toolbox for backing up, deploying and replacing databases. Both locally and remotely.

With Syncdb we ended up adopting a model where any time somebody would make a change on the Wordpress administration area, such as playing with content, he/she would do it directly on stage.

Then we would all just run ./syncdb pull from time to time or as soon as somebody flags up. Easy to remember when you are doing a git pull often anyway.

That makes it a one way operation: just pulling instead of push & pull and avoids any possible complications.

Conclusion

Needless to say it worked out great and I can really recommend it if you do Wordpress development.

Spreading the word is the least we could do as a token of appreciation and hopefully that helps somebody else out there as well.

Do you have a different way to handle staging with Wordpress? Let us know on Twitter: @14islands

About the Author

We love giving talks on web development and recently got a chance to do a half-day workshop on Responsive Web Development in collaboration with Codecoach.

We were invited by Accelrys, which is in the process of rebuilding their Lab Notebook application as a responsive web app. It was great to see how the team responded to our ideas, and it fueled many good discussions throughout the day.

"This workshop really helped our team to take our responsive workflow to the next level" Andreas Nylén, Accelrys

This workshop is mainly for developers and designers that already have some basic knowledge of responsive web design, and want to take their skills to the next level. We also discovered that it's very useful for non-technical stakeholders, since it provides the whole team with a shared understanding - and vocabulary - of Responsive Web Design.

Feel free to browse through the slides below. To book a workshop for your company or team, send us an email to [email protected] for more details.

Part 1 - Becoming Responsive

Part 2 - Design & Process

Part 3 - Development & Patterns

Part 4 - Performance & Testing

About us

14islands is a company specialized in front-end development and responsive web design. We are three developers, all with more than 10 years of experience in the business, and have worked on projects for companies such as Google, HTC, Desigual, Tictail, and Fantasy Interactive.

A while ago we were asked to help our friends at UENO build a website for the cloud security startup Elastica.

In addition to crafting a fully responsive experience, the goal was to create an exciting story as you scroll through the pages. We ended up building over 20 animations which all run based on the scroll position.

Let's take a look at how we built some of the animations and what we learned throughout the process.

Spinning Satellites

The first animation we created for the site is using DOM elements and CSS animations/transitions.

See the Pen Elastica.net - Satellites by 14islands (@14islands) on CodePen.

We only used transforms on this one which is great because they are hardware accelerated.

The biggest challenge with this one is to animate the length of each 'arm' without causing a browser repaint for each frame of the animation.

Repaints are very expensive in terms of performance, especially on phones with low processing power. In many cases, they cause the browser to calculate the layout of the entire page again.

So, instead of animating the width property, we solved it by using transform translate and a parent with overflow hidden to avoid repaints. Like this:

See the Pen Animate width without repaints by 14islands (@14islands) on CodePen.

Circular mask

We tried a bunch of different approaches for this one before settling on using a canvas to mask out the white image.

See the Pen Elastica.net - Circular mask by 14islands (@14islands) on CodePen.

We first tried to create the mask using a DOM element with border-radius and nested transforms to avoid repaints. This sounds great in theory but unfortunately hardware accelerated children seems to not be clipped by the border radius in some browsers.

Creating a mask in canvas is as easy as using the clip() function - every thing you draw after will be masked, in this case the fill and drawImage:

ctx.arc(pos.x, pos.y, size, 0, Math.PI*2, true); ctx.clip(); // create mask based on arc ctx.fill(); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); ctx.stroke(); // improve anti-aliased edge of arc

We also had to move the circle on a curved path, which we solved by simply using an inverted combination of easeIn/easeOut on the x/y coordinates:

var x = easing.easeInSine(time, startX, endX-startX, MOVE_DURATION), y = easing.easeOutSine(time, startY, endY-startY, MOVE_DURATION);

The browser support for canvas is at least as good as most CSS3 animation features. However, to be safe, we load the background with a normal image tag. If the browser doesn’t support canvas, users will see the background image.

Additionally, the masked image asset is nested as an img tag inside the canvas tag - which means that browsers without canvas support will skip downloading it.

Uncover on scroll

This one is a bit more interactive as it unmasks the hidden image based on the window scroll position.

See the Pen Unmask on scroll by 14islands (@14islands) on CodePen.

In this case it's extra important to not do any type of heavy work in the onscroll event handler. Instead, we make sure to only read the current scrollTop value on each scroll event and store that value for later. We then used a requestAnimationFrame loop which updates the animation based on the latest known value. This lets the browser schedule the visual updates at the correct time without affecting the scroll performance. Paul Lewis wrote a great article on this topic on html5rocks.

Instead of animating width (which repaints on every frame) we use nested transforms and overflow hidden. As you can see, we get no paint rectangles around the animation at all:

Unmask animation without repaints from 14islands on Vimeo.

Canvas & CSS3 Hybrid

The last animation we want to share is a hybrid, using Canvas for the moving circles in the background and CSS animations for the checkmark.

See the Pen Dancing Circles by 14islands (@14islands) on CodePen.

For more complex canvas animations like this one, it's amazing what a little object oriented Javascript can do to improve code readability.

Smooth scrolling

In order to kick off the animation at the right time, we need a way to get notified when an element enters the viewport. It's important to pick a solution that doesn't affect scroll performance, since we might have many animations on the same page. We settled on using scrollMonitor which is build with speed in mind and minimizes the work done on each scroll event.

Responsive scaling

We built all animations so that they can scale down to any size like a normal image. For Canvas this is easy - just set max-width=100% on the element and let the browser do the work.

For CSS animations this becomes a bit more tricky since all sizes and positions of elements have to be set in percentages. Because percentages are relative to the containing element it will also be relative to the aspect ratio of the container. Keep this in mind in case you need to change the width or height of the container at a later point.

Summary

It's a lot of fun to figure out how to implement animations with as few repaints as possible. It's not always possible to avoid them completely, but at least we should be making informed decisions.

Go make stuff move, have fun, and tell us about it!

Check out all of the animations on the Elastica website.

We recently had the chance to use [Wordpress](http://wordpress.org) as a CMS for a project. Coming from a back-end background, we had some high expectations on using Wordpress as fully-fledged CMS solution. Here's our first impressions. ## The flexibility Wordpress still shows its roots of being a blog platform. And that is cool. But sometimes the settings can get in your way when you know exactly what you want in a CMS but Wordpress's UI seems to be speaking a more _blog-ish_ language. At least until you get more familiar with it.  Custom fields do give a more _CMS-ish_ perspective though - making it more flexible to be used as a CMS. **Specially** after you find [Advanced Custom Fields](http://www.advancedcustomfields.com/). Advanced Custom Fields is probably my favourite plugin for Wordpress. It pushes the custom fields even further by providing a nicer interface to manage the content.  ## The hierarchy WordPress uses a pretty nifty [template hierarchy](https://codex.wordpress.org/Template_Hierarchy) to decide on which template file to load for a given post/page. If a given file is not found then it will fall back to another one and keep falling back until the mandatory _index.php_ kicks in. You see, it's hard _not_ to get at least a little lost at first: you open 5 different files and their code look all too similar. For example, a file called _'home.php'_ can actually be your blog page if you have chosen the home page to be a static page.  _Wordpress hierarchy example_ ## The famous loop You have probably seen _the_ Wordpress loop trademark code: The code should be self-explanatory: A loop that looks for the posts that you current have. But then you open a file called _single.php_ which is supposed to show only a single post and there's the loop again. Do they love this loop so much or...wait a minute. Is that a loop that runs only once? Well, _yes_! [For consistencies sake](http://stackoverflow.com/questions/21249888/why-i-need-a-wp-loop-in-single-php), having a loop which works for any number of posts can be useful. Otherwise you would have need a specify logic for one post and another for multiple posts. And also because the loop is cool. The WordPress Loop also makes [some other functions](http://codex.wordpress.org/The_Loop#Loop_Examples) available for you such as _the_title()_, _the_content()_ and others. This is one of the a-ha moments I had with Wordpress and helped me realise the importance of its famous loop. ## The good and not-so-good It always puzzled me the fact that Wordpress was praised to be the easiest CMS when you actually have to code some PHP to get to do even the simplest task. If you don't mind hacking away then you will be glad to hear that Wordpress's documentation is one of the most complete I have seen and it's API pretty much covers anything. It's pretty funny when you're looking for something _"man, I wish I could get this category as a link"_ and, as you search the extremely well documented [codex.wordpress.org](codex.wordpress.org), the first result happens to be a function that is named _get_category_link_. You can almost guess how the function you're looking for should be called if you're feeling lucky. You can even "challenge" codex by trying to search if a random function that you thought about that _could_ be useful exists. My bet is that it does. Seriously, everything I wanted (and it was quite much) existed and it was called _exactly_what_I_wanted()_. And if I didn't want to necessarily display the value but do something else with it, it would be prefixed with a _get_ instead of _the_ like _get_title()_ vs _the_title()_. Talk about a robust API. ## Just because you can doesn't mean you should Being able to code your own function to show something you want doesn't necessarily mean it's a good thing in all cases. What if you didn't even _have_ to code that little snippet you in the first place? Some other CMS'es out there can give what you are trying to code out of the box without getting your hands dirty. These are the two sides of the excellent [Wordpress codex](codex.wordpress.org) site. You have functions for everything but some functionality should not necessarily require coding. ## The final impression Wordpress can definitely be used as a CMS today. It is hard to find an open source software that is as up-to-date as this one. And it's popularity is definitely a good thing to consider when choosing a CMS. Just remember that with choosing to use an open-source software comes some responsibility. Making sure the system is always up to date is mandatory - which many people fail to do, thus giving a negative impression on security that it doesn't necessarily deserve. _Did you have a different experience using Wordpress? Let us know on twitter @14islands_

About the Author

We had the pleasure to attend "Resonate" again this year. This is the second time we go to this conference in Belgrade-Serbia. Resonate can be described as a creative festival with digital artists, designers and developers representing the cutting edge of the contemporary creative industry in the world.

If you're like us and love to be inspired by other peoples amazing work, we would really recommend paying Resonate a visit next year.

Highlights from this year's event:

OCULUS RIFT Workshop

OTOTO BOARD Workshop

Inspiring presentations

Onformative - unnamed Soundsculpture

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: http://www.theverge.com/2014/3/18/5522226/google-reveals-android-wear-an-operating-system-designed-for/in/5286837

Motorola & LG release watches using the OS: http://www.theverge.com/2014/3/18/5522340/motorola-lg-announce-upcoming-android-wear-smartwatches/in/5286837

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

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.

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.

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

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.

Example:

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

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 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.

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.

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:

Study and strategise the scene. How many layers should be separated, grouped, etc.

Copy the object that you want to export and paste it in a new document.

Fix the "artboard" dimensions in Illustrator based on the graphic.

Make sure the export settings are optimal for web (see screenshot below).

Compress it if possible and make sure it still looks good. Here you have to be careful, compressing might remove some things you need.

Code!

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.

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

Example:

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:

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.

Conclusions

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.

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,webpagetest.org 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.

Tweet

About the Author

It's been few weeks now since we released responsive.io, 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

responsive.io 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. responsive.io 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 responsive.io 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.

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

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

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

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

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

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.

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.

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.

Design

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:

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.

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).

Typography

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

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

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.

Icons

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: http://responsive.io/styleguide/typography

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

Valid email

Submit success

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 responsive.io going forward. Follow us @responsive_io as we talk about the journey and release some amazing features.

Tweet

About the Author

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 responsive.io, to solve this problem once and for all.

responsive.io 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, responsive.io 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 responsive.io 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.

responsive.io 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 responsive.io 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.

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

RACER IS A MOBILE CHROME EXPERIMENT. TEST DRIVE IT IN A CHROME MOBILE BROWSER AT G.CO/RACER

Production companies: Plan8, Activetheory, HUSH

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 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:

It required users to install Flash.

It required features in two places, HTML5 and Flash.

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.

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 score-board that scales nicely from small to big screens.

The Betslip

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

Live Streaming

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

Multiple Themes

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

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.

Prototyping

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.

Testing

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.

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.

Backbone.js

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

jQuery

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.

Sass

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.

Jasmine.js

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.

Require.js

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.

AngularJS

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

FastClick

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.

Conclusion

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!

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.

iOS7

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.

iPad

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.

Tweet

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.

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 Google.com 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"

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"

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.

Tweet

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

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

Amazon

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

Google

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

Yahoo!

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 basecamphq.com resulted in 5% improvement in conversion rate. (source: Signal vs. Noise).

Tweet

About the Author

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

You can follow Hjörtur on Twitter