Kyan blog

An online education

2012-02-03T09:39:18Z

As web developers we really have to keep on our toes. The pace of change on the web is ever quickening and we must embrace new technologies, frameworks and ideas nearly every day. Whilst it’s what makes the job very challenging it’s also, at least for me, what keeps it really interesting.

Last year I attended the online course ‘Ruby Reloaded’ hosted by Peter Cooper (author of the ever popular Ruby newsletter Ruby Weekly and blog Ruby Inside) and I have to say I really enjoyed it. Obviously the beauty of hosting it entirely online is that people were able to attend from all over the world.

However I’m not here to simply promote the course, but comment on the ever increasing amount of high quality resources there are online for learning Ruby, Rails or indeed your particular web technology of choice. Particularly in the realm of screencasts.

Things have come along way since that infamous 10 minute blog that first introduced Ruby on Rails to so many people (myself included). Unfortunately it’s so old now that it appears to have been taken down, which I guess is fair enough. However, in it’s place is an entire page of screencast resources. We really are spoilt.

One additional resource that was highly recommended at the recent Surrey Ruby Group was the screencast series from Destroy All Software. They don’t just focus on ruby, as their subjects include orientated programming, git, vim and test driven design. Something for any discerning web developer.

If you are looking to learn Ruby, Rails or just keep pace with the world of web development then you’ve never had it so good.

Web Meet Guildford is back for 2012

2012-02-02T17:14:00Z

The next meetup is from 6pm on Thursday 8th March at The Three Pigeons pub on Guildford High Street.

The upstairs of the pub will be reserved just for us with a tab running behind the bar. Please come and join us for a drink and to talk all things web.

If you haven’t seen it already, we have created an official website for the meetup at webmeetguildford.com.

On the site you can discover the web community local to Guildford and surrounding area. Please register your details so that we can add you to the directory.

Look forward to seeing you there. @kyan

Sticking your tongue out

2012-01-20T17:18:23Z

Designers seem to love these:

See it? That little tongue seems to work its way through the majority of our designs, popping up in all sorts of unexpected places.

Traditionally we would have made it with a background image on the container that pulled some of the background colour of the main page into our box, leaving a tongue of the box’s background colour sticking out. Easy, but fairly inflexible and requires another image download.

Abusing generated content

All lot of you will have played with generated content, but if not a quick recap. In CSS you can define extra content to be pre- or appended to an element. This is useful in and of itself but potentially more useful is that we can style these additional pseudoelements as if they were in the markup, effectively giving us two blank divs inside every element in our page.

These pseudoelements are supported in IE from version 8 and in every other browser, so a couple of years ago I started playing around with them to make our tongues. This could be a little tricky if you’re not familiar with the general idea so I’ll step through it. First, we’ll give our content a height and width, and a background image that’s our tongue. We need to actually give it some content to be able to style it, so I’ve gone with a non-breaking space.

div:after {
  content: " ";
  width: 20px;
  height: 10px;
  background: url(tongue.png) no-repeat 0 0;
}

That gives us a tongue, but at the moment it’s just sitting at the end of our box. Let’s position it:

div {
  position: relative;
}

div:after {
  content: " ";
  width: 20px;
  height: 10px;
  background: url(tongue.png) no-repeat 0 0;
  position: absolute;
  top: -10px;
  left: 10px;
}

By making the parent position: relative our tongue will position itself relative to that. We use top: -10px as that will pull it above the box by its own height, making it sit flush to the top.

This is much better than our first attempt at solving the problem. For a start, we can have a background colour on the box, and a tongue that’s transparent on either side down to the content below. That’s great for popups and draggable boxes. We’ve still got a few problems though. There’s an extra image for users to download, and if you want adjust the size at any point you’ll need to regenerate that image.

Adding borders into the mix

Luckily, it turns out that in a lot of cases we can get rid of the image completely! Our tongue (at least when if comes from my designers) is often triangular in shape which means we can use a very old trick: a judicious application of borders. Let’s rework our previous example. If we assume our box has a green background and we want a green tongue then we can use borders like this:

div {
  position: relative;
  background: green;
}

div:after {
  content: " ";
  width: 0;
  height: 0;
  border-style: solid;
  border-color: transparent transparent green;
  border-width: 0 10px 10px;
  position: absolute;
  top: -10px;
  left: 10px;
}

Easy enough? First, we set the width and height of our generated content to 0. We’re going to build the tongue out of borders so we don’t need any size to the box itself. Next, let’s think back to our image box. It was 20 pixels wide and 10 high. To get this, let’s have a border that’s 0 pixels high on the top, 10 on the right, 10 on the bottom and 10 on the left. Finally, we set out border colour. The top is 0 pixels high so we could put anything we want there, but let’s leave it as transparent for clarity. On the left and right we want to be able to see down to the content so we need those to be transparent too. Finally, we make our bottom triangle of border the colour we want: green.

Now that we’ve got our tongue as a separate pseudoelement we can do all sorts of cool things with it. How about changing the color of the box and the tongue at the same time on hover?

div:hover { background: blue; }
div:hover:after { background: blue; }

Doesn’t get much easier. What about increasing the size of the tongue on hover with a slight transition?

div:after { transition: border-width .2s, top .2s; }
div:hover:after { border-width: 0 15px 15px; top: -15px; }

(Obviously you’ll need to add your favourite vendor prefixes here)

Have a play around, and if you come up with anything cool let me know!

Behind our jukebox

2012-01-05T16:18:11Z

If you take on Kyan as a client you’ll soon be aware that we love our music in the office.

We used to use a 3rd party music player, but decided a few years ago to build our own; this gives you a lot more flexibility in exactly how it works.

The basics

At the most basic, the jukebox is comprised of everyone’s music shared in from their machines, a command line player called MPD hooked up to an amp and speakers, and a Rails app that controls music selection. On top of that we’ve added a bunch of extras: last.fm scrobbling for our account, stats on everything, voting on tracks and lots more.

Where it gets interesting

Fairly soon after building our initial implementation we ran into scaling problems. Think about it: a jukebox doesn’t just display what track is currently playing, but also the state of the entire interface including the volume and (problematically) the current state of play of the track. It’s this last one that caused us issues as each client was polling the jukebox every second to update its interface. That meant that an average of twenty-five clients were putting 90,000 hits an hour onto the little Dell the system was running on. We needed a better solution.

Luckily, at about that time one presented itself: WebSockets. Simply put, this tech lets the server push out updates to the client rather than the client request them. On top of that, as the server knows its own state, it only needs to push out updates when that state changes. Finally, we changed the ‘current track time’ to increment automatically on the client and sync up only when another part of the system state changes.

WebSockets haven’t been flawless: the spec has changed several times and they got removed from browsers entirely for a period due to a security hole in the spec. When they work though they work exceptionally well. So let’s have a look at how they work in our system:

var conn, uri = "ws://jukebox:8080";
if ("WebSocket" in window) {
  conn = new WebSocket(uri);
} else if ("MozWebSocket" in window) {
  conn = new MozWebSocket(uri);
}

Unfortunately WebSockets are still a prefixed interface in Firefox. This changes in Firefox 11 so we’ll remove the check at some point after that (the benefits of a limited audience!). This code simply tries to create a new WebSocket connection to the jukebox server. We then bind a listener to the socket:

conn.onmessage = function(msg){ 
  var data = JSON.parse(msg.data);
  for (var key in data) {
    switch(key) {
      case "state":
        updatePlayPauseButton(data[key]);
        break;
      case "time":
        updateCurrentTime(data[key]);
        break;
      case "rating":
        updateRating(data[key]);
        break;
      case "track_added":
        addStatusUpdate(data[key]);
        break;
      case "raters":
        setVotedState(data[key]);
        break;
      case "track": // The track has changed
        updateCurrentSong(data[key]);
        break;
      case "playlist": // Track added or removed
        updatePlaylist(data[key]);
        break;
      case "volume":
        volume.slider({value: data[key]});
        break;
      case "refresh":
        window.location.reload(true); // force the browser to reload the page from the server (not from cache)
        break;
      default: console.error('Unrecognised action: '+key);
    }
  }
}

Every time we intercept a JSON message from the server we parse it into an object, then look over it for data to apply to our interface. Not every update contains every key but that’s not a problem: we just update with the data we get from the server.

From the server’s point of view there are two parts to the puzzle. For the first (the actual WebSocket server) we used the em-websocket gem which leverages eventmachine for an asynchronous socket server. Behind that we built a status dispatcher that monitors the system for state changes, bundles them up every second, builds a JSON object out of them, and passes them over to the WebSocket server to be distributed.

This is remarkably elegant in practise and makes for a very responsive application interface, whilst massively reducing overall load! Of course, there’s a downside: no WebSockets in IE (until 10) or Opera (yet). It’s only a matter of time until support lands though.

The real benefits

Due to the predominance of up-to-date browsers in the office, we can use internal systems as a testbed for new technologies before we get a chance to implement them on client projects. The jukebox has turned out to be a fantastic system to try out new stuff on. WebSockets is only the start of it: the system was HTML5 before anything else we did and has given us valuable insights into CSS3 specifications such as webfonts and gradients.

Every front-end developer needs some way to play around with upcoming specifications and having a project that is used by multiple people every day is a great way to push yourself and hone your skills.

Colophon the 2nd

2011-12-14T10:17:00Z

I’ve had some requests for more info on the challenges involved in building the new site; read on for more.

For the most part the design is actually fairly simple. Nice clean fonts and a clear rhythm, but I had strong design direction which always helps when building a new site. I sit back-to-back with the designer on this so I could just turn around and ask questions if I needed clarity.

The carousel

The carousel was interesting to build as the finalised design didn’t come into place until quite late in the project. We originally just had a ‘standard’ site carousel built, but we always knew we wanted to do something more. In the end I sat down with Lee and thrashed out an idea for the animation. He then went off and implemented exactly the design he wanted in Flash, which I then converted to CSS animation. This way of working appeals: I get design direction on the animation and timings as well as the static assets.

The carousel was initially built with standard absolute position & top animation using jQuery, but these turned out to be extremely slow on iPad (a target browser for the launch). Dropping in CSS3 translations fixed that, but obviously didn’t work on older browsers. In the end I found jquery.transform.js that abstracted the interface and made it work on everything. Unfortunately (with a couple of weeks to go) I ran into alpha-transparency glitches and performance issues in IE7 and 8 that meant that turning off the animation in those browsers was the most expedient route to getting the site launched. Together, those are currently running at <3% of total users anyway, so it’s not a huge issue and the site works better for them now regardless.

One interesting (and annoying) bug I ran into on the carousel was jerkiness in Chrome. I use Firefox as my main development browser so didn’t really notice the problem until more in-depth testing. It turned out that the problem arose from me triggering hardware acceleration for iOS using the -webkit-backface-visibility trick. Chrome’s animation was much smoother when that line was removed; Safari on OS X performed about the same with it in or out. In the end I used a media query filter to hide the trigger from desktop Webkits: hopefully browser progress will obviate the need for such workarounds in the future.

Difficult decisions

A design request I did’t implement in the end was a request for the team carousel to blur the images out towards the edges. After a bit of thinking and research I came up with a way to blur the photos after the animation finishes, but nothing that would blur in realtime as the slide animation happened. I suspect given time I could have done something, but a performant solution in the development time available wasn’t going to happen.

Webfont problems

Regarding the fonts, for the most part they were trivial to implement using webfonts.fonts.com. The only surprise in that was when we moved all our assets to Amazon S3. We were self-hosting League Gothic and it turns out that Amazon don’t have in place (or let you add) the cross-site request header that Gecko needs for font embedding across domains. Luckily we found that the original font that League was based on (Alternate Gothic #1) was on fonts.com so we just moved over to that instead.

Fit and finish

What I really feel proud about with this site is not any one part of it, but that there was enough time available to add a really nice level of fit and finish to the whole thing. Even smaller subpages were graced with decent illustrations and I had time to make the interface feel as slick as possible to as many users as possible. This seems to have been borne out with the overwhelmingly positive feedback we’ve had from Twitter and our clients.

Hosting Kyan.com

2011-11-21T17:17:00Z

It’s now been a week or so since we put the new Kyan.com live and we’ve been getting nothing but rave reviews from everyone who has seen the site. Whilst this is an amazing thing for us to get, it does come with some added side affects, namely the thirty thousand visitors we’ve had from around the globe coming in to see the new site for themselves.

Hosting this sort of thing can usually be a tricky affair as normally a corporate website doesn’t normally receive enough traffic to warrant any high throughput hosting from a cost point of view, but you also don’t want to have the site go down when some high profile twitterers mention your site at peak time.

To the cloud!

So, enter Heroku stage left. We’ve been using Heroku for a few months now, and some of the team have a few years of experience with the platform. Kyan is a Heroku development partner so we thought we should probably eat our own dog food and host our website on what we recommend. Everything you see before you is coming to you from one element or another of cloud hosting. We’re using Heroku for the site itself, S3 for some of the graphical elements, and services such as RedisToGo for some ancillaries such as caching.

Due to the flexibility of the platform we’ve got all sorts of background monitoring and scaling processes running, being able to see more of what’s happening on the site than ever before.

Keeping it fresh

Normally we would resort to using static pages for a site which doesn’t change that much, but Kyan.com is still a fully content managed website using a custom backend. What’s more there is content that is always changing. For instance, in the footer of each and every page we have some statistics about the company. These stats are changing second by second and update on the site regularly. A feature such as this instantly makes static caching less than ideal.

Our main focus with the hosting was to be able to return pages nice and snappily, whilst also being able to scale as far as we may need to without any fuss. This ruled out most standard hosting straight away. Using Heroku allows to scale our resources on-demand, so when floods of traffic come we’re able to deal with them and ensure that users don’t see any issues.

Caching

So, how do we ensure we can scale? Well, 90% of the site you see before you is coming from Amazon’s S3 service which is an ideal platform for simple serving static files such as CSS and images up to some massive throughputs (Personally I’ve seen 18,000 requests/second on S3 before). By using Rails 3.1 and the new asset pipeline we’re able to do this automagically, making the development and deployment process as streamlined as possible.

We’re also doing some low-level caching, for instance in the footer. By using a Redis key/value store we’re able to cache the website footer for a few minutes at a time periodically updating on a needs basis. This means that every user isn’t having to wait for the live stats to come through, we’ve already done it before they turn up.

Overall we’ve had a great time using Heroku for Kyan.com and we’ve been able to scale for the response we’ve had without batting an eyelid. What’s more we’ve got a stack of features behind the scenes that we get for free that we may talk about in the future.

Kyan.com design process

2011-11-15T14:29:00Z

It’s great when you get a project you can really sink your teeth into. We pride ourselves on the effort we put into all our projects, of course, but when it’s for your own agency you can really ‘go to town’ and try new things. Our current website was out of date and needed to better reflect the business rather than just brochureware. We wanted it to focus more on solutions and our applications work. It’s great that applications are a big proportion of our work, so we needed something new and fresh… something that showcased our web talents (HTML5, JQuery, Ruby on Rails).

Strategy

So, we determined our goal, we needed to set out a strategy. We started out by giving ourselves a clear, concise brief which included content, message, tone of voice and structure. We knew we would have to work in chunks of time between paid work, so our schedule was relatively flexible until most of the ground work was done. We also had a strong message we wanted to convey; Handbuilt (Bespoke design and development) for web and mobile applications and that it is a fun and creative process, not just for us but also our clients.

Art direction was the fun part. We all had ideas, these included: Heath Robinson, Terry Gilliam, Jan Tschichold, papier découpé, popup books, dioramas, British heritage, modern, clean and big. Other ideas were thrown into the melting pot such as blueprints, engineering, retro and Paddington bear. With this in mind we put together a mood board, fine tuned our direction and set about laying down some rough layouts.

Design

We were very attached to our previous site design in terms of colour, illustration style and use of Avenir®, so we wanted to reflect elements of this somehow. We kept Avenir® and introduced Sabon® (later we settled with Sabon Next® as we felt this viewed better on screen), they complemented each other really well and fortunately for us these classic fonts were available from our web font supplier Fonts.com by Monotype. Lastly we needed something to show off our office statistics at the foot of the page. The stats come in useful to illustrate to our clients how we feed sources of information onto a page—we wanted something chunky and condensed so we settled on League Gothic® as our signature data style.

Our primary colour palette consisted of the Kyan blue and a deep brown (an almost charcoal colour) combined with neutral shades to add depth. We wanted to introduce another colour, so we tried gold. It worked really well! It added that extra touch of class, so we stuck with it quite early on in the design process.

We went through a several iterations using our previous site copy and placeholder imagery, before settling on a final look and feel. This was then applied to some of our key pages. We wanted the content to breathe and pace itself well and once the content came flowing in it started to evolve. Our layout decisions were fine tuned until we had something that was clean and kept your interest. Adjustments were constantly made, right to the end in fact, but what it really required was a way to illustrate the content and bring it to life even more.

Illustration

We already had an illustration style from our previous site; clean, simple and fun. We felt we needed to develop this somehow to convey our messages. We drew a pop up book style using illustrated cardboard cut outs of the elements and then settled on a more arranged diorama that we could animate. We tried various animations in Flash as this was a quick way to demonstrate it to the development team and we could easily make changes. Once we decided on how it should work we were able to implement it using CSS3. The illustrations have a great presence and brightened up the pages considerably. Big Rainbow head (Kyan’s mascot) appears every now and again to add a bit of character.

As I mentioned, the previous site already had some eye catching imagery so it was a nice gesture to gently nod to this, so we included the clouds, paper plane and worm somewhere in the site. It also adds a bit of familiarity to those who remember our old site.

The final result

We didn’t want to make the site responsive. It didn’t need to be. We felt it would jeopardise the typographical layout so Instead we settled on clear hierarchy, a good grid and stacked the information down the page to encourage users to scroll down. We applied a style sheet for mobile and we are all happy with the result.

You can check out some of the design process in illustrative form here: http://www.flickr.com/photos/kyanmedia/sets/72157628008649733/