We recently updated ShowCaster Studio to give users the ability to customise how they embed the ShowCaster player. This has become a common feature amongst some online services, however everyone seems to have their own interpretation of how to present this information to the user.

We approached this task as we do all of our user interface designs: the goal is to only present critical information to users and minimise their cognitive load. This combined with traditional UI design principles forced us to consider presenting the embed code alongside a responsive preview of the embed itself. The idea was to add a few options that would tweak the look and feel of the player and have the preview automatically update to reflect those settings. We also added tabs to differentiate between the major layouts, giving the user quick access to a variety of common embed types. The result of this design looks like this:


A crucial part of the work was to make our embed player flexible in terms of its layout and presentation, however in this post I only focus on the builder and not the embed. A follow up post will touch on how we implemented a flexible embed player.

The main technical challenge of this implementation came from the interactive preview that we chose to implement as an iframe pointing to our embed player. In order to keep a consistent feel and not throw off the page layout, the iframe width should remain the same at all times but we also wanted the preview to be interactive in terms of size. This can be easily be achieved through dynamic scaling of the iframe to always fit the allocated space using CSS3.

.embedPreview iframe {
  transform-origin: top left;
  -moz-transform-origin: top left;
  -webkit-transform-origin: top left;
  -o-transform-origin: top left;
  -ms-transform-origin: top left;
var scale = (iframeContainer.width()) / iframe.width();
iframe.css("transform", "scale(" + scale + ")");
iframe.css("-webkit-transform", "scale(" + scale + ")");
iframe.css("-o-transform", data);
// Resize height of the container to fit the transform
iframeContainer.css("height", height * scale);

The main problem now came from detecting the new width and height of the iframe once its contents had been reloaded. This was slightly more complex since we cannot query the contents of an iframe on a different domain to adjust the scaling and height of the preview.

We used HTML5 messages to pass the size parameters of the iframe contents once it had finished loading.

// Code on the embed client page (embed player)
// Fire load event to parent once the document is loaded
$(window).load(function() {
  var data = new Object();
  data.type = "embedLoaded";
  data.eventId = ;
  data.contentWidth = $(document).width();
  data.contentHeight = $(document).height();
  data.layout = "";

  window.parent.postMessage(JSON.stringify(data), "*");

We can then listen for those messages on our Studio page and adjust the scaling and height accordingly.

// Code on the Studio page (embed buidler)
$(document).ready(function() {
 // IE8 handle
 if (typeof window.addEventListener != 'undefined') {
   // Add event listener for onLoad event of the embedded iframe
   window.addEventListener("message", onIframeLoad, false);
 } else if (typeof window.attachEvent != 'undefined') {
   window.attachEvent("onmessage", onIframeLoad);

function onIframeLoad (pEvent) {
  var data = JSON.parse(;
  var width = data.contentWidth;
  var height = data.contentHeight;

It is important to note here that we are passing the object as a string and not simply as an extended JSON object. The reason for that being due to IE not having access to any other attributes than the event data, i.e. the string.

Hope you guys found this post useful and you now have a better idea of how to improve your embedding experience. Happy coding! :)


ShowCaster’s success is down to its ability to scale up and down and meet the varying demands of live events – sometimes during short periods of time (typically around an hour) we will receive bursts of hundreds of thousands of users interacting with our platform concurrently (eg. when promoted on a mainstream TV channel).

We’ve just completed a project rebuilding our auto-scaling infrastructure – consisting of 2 weekends creating ShowCaster Tools. ShowCaster Tools keep track of the health and usage of our servers as well as demand-based auto-scaling, wrapped in a simple GUI .

Let’s get technical

In order to automate this process, we needed to integrate our system with Rackspace Cloud APIs. The brief was to create a simple web interface for anyone in the team to use (both techies and non-techies). Seeing as we (the techies) are always up for challenges and exploring the world of languages & tech, we thought that this would be a great opportunity for us to try a different tech stack from our usual Java.

Ruby as a replacement for our perl scripts

We currently write all our scripts using Perl. So far it has done the work without issues. However, everyone who has used Perl knows that it’s not the easiest to learn. Every time a new developer joins our team, it takes a while until they fully understand the language and how to make the most out of it.

Ruby on Rails as the MVC framework for the front-end

At the same time we were learning Ruby for the server side interactions, we thought that the best tool to create the web GUI was Ruby on Rails. This is one of the most famous MVC frameworks out there for web development. We always have read that the the different helpers offered by Rails together with Ruby increases the productivity of any web development so we decided it was the right time to give it a try.

The architecture

One of the first things we realized when we started to architect the application was that there is no direct support for multithreading within Ruby on Rails. There are some “hacks” but none of them were appealing to us. For this reason, we ended up splitting our application into two main components. The first component was entirely implemented with Ruby and is in charge of all the business logic of the application. Things like:

  • Multithreading
  • Rackspace APIs interactions
  • Server monitoring and management

The other component was built with Ruby on Rails and looks after the user interface. This provides two main benefits:

  • Split the logic from the view (MVC)
  • If we decide that Ruby on Rails is not for us, we can easily bin it and start from scratch with another framework

The conclusion: Ruby yes, Rails not so much

After creating ShowCaster tools, Ruby has impressed us – especially for its SPEED. Other reasons:

a) The number of lines of Ruby code is significantly less – meaning a faster development cycle, less bugs and easier maintenance resulting in increased productivity.

b) We liked the simplicity of Ruby when integrating with other libraries – thanks to their valuable gems. We installed the Rackspace Cloud gems for their load balancers and servers and within 5 minutes we were ready to make requests to their APIs.

Ruby on Rails provided a good implementation of the MVC pattern, awesome helpers to speed up the entire development, and we easily understood how using it would improve long term productivity.

Working with the Rails ActiveRecord helper was a great experience compared to similar frameworks – we’re very familiar with Hibernate for Java and ActiveRecord was far simpler, better and faster in terms of data definition and usage than Hibernate.

In order to take full advantage of Rails, you really need to make complete use of all their helpers and tools – but in most of our user interfaces these helpers and tools wouldn’t be applicable, losing some of the potential of Rails.

Based on this experience, we’ll use Ruby to replace all our Perl scripts over time, providing us with benefits in the long term.  Rails won’t replace the web development tools used on our core products but it will definitely be considered on future projects where the potential of Rails can be used to its maximum.


Development Infrastructure ShowCaster

The brief

The team @ShowCasterTV has recently completed a make over of its interactive polls feature. ShowCaster Polls enables user to run live interactive polls across the web, tv, tablets and phones and is a great use for 2nd screen applications. ShowCaster is used by a large TV broadcasters such as Channel 4 and Sky so scalability is a key consideration – all features need to support extreme load from large numbers of concurrent users.

A poll’s functionality by design is quite simple – a single question and a few options to choose from. Its simplicity should also be reflected on the user interface in order to deliver a good looking, yet focused poll-driven experience. The task at hand was to give the previous design a make over, but at the same time ensuring its simplicity remains intact, as well as ensuring the new UI adapts nicely across the multitude of screen sizes and applications that ShowCaster integrates with and is embedded into.

The challenge

The challenge was small – choose a design that will fit across multiple screen sizes and render the experience nicely across all platforms. However, the bigger challenge was the fact that our UI designer had decided to leave the country and begin his adventures elsewhere. This then lead to a bunch of hardcore engineers used to writing awesome code, instead spending time scratching our heads staring at something called a paintbrush tool. It wasn’t going to work, but we needed to refresh the UI quick.

The saviour

So, after looking around for help, we stumbled across something we were on more familiar grounds with. Twitter? Good. Framework? Good. Open-source? Good. Twitter’s open-sourced UI framework? Awesome.

With Twitter’s Bootstrap UI framework, we were able to use predefined UI elements, which come with all the bells and whistles i.e. nice CSS3 features like border radius, box shadows, transitions, and it includes all the browser specific shims and prefixes – all supplied by Bootstrap! Not only does it render well, it all works beautifully by simply adding a predefined style or data class to an HTML element – well, with exception to IE8 – but since no one uses IE8 anymore cause its crap, we’re fine right? :)

Responsive UI

For those who know a little about Bootstrap, the scaffolding structure is pretty neat – especially since it works nicely when enabled with ‘responsive features‘. With the responsive features enabled, Bootstrap adjusts the scaffolding structure to stack when the screen width is less than 767px using CSS3′s media queries. As powerful as it is, we have disabled it on our design because the simple design of the Polls concept needed the page to be ‘adaptive’ (to grow and shrink with the page) rather than responsive (stacking elements / increase element visible measurements).

So, without further ado, below are some screenshots of what we were able to churn out within a couple days.

Want to see the whole thing in action? Sign up for ShowCaster (free) and try it out yourself.


Oh… and btw, looking for a design role? We’re hiring!

Design ShowCaster