RNZAF – Step Up

Firstly, towards the end of last year, the game we built for RNZAF – the Royal New Zealand Air force – was awarded an FWA Site of the Day and a Bronze in New Zealand’s Best Interactive Design awards.

The site allows you to practice being a search and rescue pilot by remotely connecting to a robot on an airbase in Blenheim, New Zealand and flying around a specially designed landscape.
Online for only a little longer, check it out.

Threaded

Next up, after bending and melting minds on Twitter, the internal Resn creation Threaded was awarded an FWA Site of the Day, nominated numerous times at the Pixel Awards and heralded as the #1 Flash site of 2011.

Originally created as an accompaniment to a magazine and now unleashed online and in the App Store, it’s probably best described by Apple :

Profanity, Crude Humor, Horror, Fear, Mature/Suggestive Themes. Free.

The Camry Effect

Not content with Pixel Award nominations, The Camry Effect and Rhizopods were selected as Pixel Award People’s Champs. And then The Camry Effect received an FWA Mobile of the Day award. Built to target both multiple languages and multiple devices using HTML and Flash, The Camry Effect is a place for Toyota Camry owners to share their stories and experience the global effect that the car has had on so many lives.

2012

Far from being the “difficult second album”, 2012 is already set up to blow 2011 out of the water. Stay tuned.

FYI, my role in these projects was technical director-ing and prototyping, along with a sprinkling of production code. No risqué serious dev needed.

Getting up and running

Installation was super easy :

gem install compass
compass create [[project dir]]

(There are more detailed steps here if you’re sans-Ruby or still getting to grips with the command line.)

By default, compass auto-generates scss and corresponding css files for IE, print and screen. For this WordPress theme, I needed just a styles.css file in the root of the theme, so I removed the default files and tweaked the config.rb file to show Compass who’s boss:

http_path = "/"
css_dir = ""
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "javascripts"

One of the best bits of Sass, or more specifically the scss syntax, is that a regular css file is already an scss file. So I moved my style.css file into the sass directory and renamed it to style.scss.

Next, I told compass to watch the sass directory, and compile my scss into css whenever it detects a change :

compass watch [[project dir]]

And Bob’s your uncle… a new CSS file. We’re up and running.

Refactoring

Up until this adventure with Sass, the CSS for this blog had been full of small experiments and fragments of long forgotten layouts. The finer points of the design were made up as I went along, and there was only ever time to work on it every now and then.
So the first thing I did was to organise the code a little better using partials and nesting.

Partials & Nesting

Partials allow you to break your scss file up in to numerous files. I created _tables.scss and _typography.scss – styles for data tables within an old post and the site-wide typography styles. Naming the file with an underscore tells Sass not to compile it into a css file, but just to import it as scss when requested, like so :

@import "typography";
@import "tables";

This is clearly a nicer way to organise groups of rules that are relatively independent. Have you ever worked on a seemingly endless CSS file that contained multi-line comments full of uppercase text trying to grab your attention and separate the different sections of the file? This fixes that.

And because Sass compiles these partials up in to the file they’re imported by, you only end up with one CSS file and your number of HTTP requests stays low. Double win.

Nesting helps you keep these individual files in even better shape and make your code an order of magnitude more readable. I went to town with these, starting with small tweaks to readability :

/** Before - CSS **/
th, td {
  padding: 6px;
  border-right: $tableBorder;
}
th:last-child, td:last-child {
  border-right: 0;
}

/** After - SCSS **/
th, td {
  padding: 6px;
  border-right: $tableBorder;
  &:last-child {
    border-right: 0;
  }
}

and then moving on to organising related styles together under one parent rule.

#latest-tweet {
  word-wrap:break-word;
  clear:both;
 
  p {
    &:BEFORE {  content:open-quote;  }
    &:AFTER {   content:close-quote; }
  }
 
  a {
    text-decoration: none;
    &:hover { text-decoration: underline; }
  }
}

Much nicer.

Using partials and nesting was a great help in refactoring the code to make it more organised and readable. These features are also invaluable at making it clear which old styles need removing and re-writing, and also making the process of doing this painless.

Just don’t take it to the extreme and break the Inception rule. You’ve been warned.

SassScript – variables and logic

Spending most of my days writing programming code rather than CSS, there were often moments when it seemed like variables, logic, math, conditionals or loops could make CSS less of a beast. Yet another thing that Sass has under control.

Variables helped reduce the repetition in the file too. DRY FTW :

$color1:#33c9f4;
$color2:#37c7bd;
$color3:#fccd0d;
$color4:#ff8e10;
$color5:#ef4b1a;
$color6:#897f7e;
 
$darkgrey:#444;
$borderStyle:1px dotted #C9C9C9;
$totalWidth:800px;
$sidebarWidth:209px;

Next up was a for loop to help manage the color blocks. I already had some selectors which used the color variables, so I referenced these using the @extend directive. Here’s the before and after :

/** Before - CSS **/
.color-block .color:nth-child(5n+1) {
   @extend .color1;
   /** ... **/
}
.color-block .color:nth-child(5n+2) {
  @extend .color2;
  /** ... **/
}
.color-block .color:nth-child(5n+3) {
  @extend .color3;
  /** ... **/
}
.color-block .color:nth-child(5n+4) {
  @extend .color4;
  /** ... **/
}
.color-block .color:nth-child(5n+5) {
  @extend .color5;
  /** ... **/
}
.color-block .color:nth-child(5n+6) {
  @extend .color6;
  /** ... **/
}

/** After - SCSS **/
@for $i from 1 through 6 {
  .color-block .color:nth-child(5n+#{$i}) {
    @extend .color#{$i};
    /** ... **/
  }
}

Mixins

I experimented with mixins and other notable Sass features which seemed very useful. However in the case of this simple blog I found that refactoring my CSS even further meant these features were un-needed and that I could accomplish the same result with a more basic approach. Credit again to Sass for making this refactoring super easy and improving the clarity of what was previously a monster css file.

Tools

Great book, wise words. Tools that I found useful for Sass development included:

• Aptana

  Sometimes seems to slow Eclipse to a crawl, but it comes with Sass code highlighting and includes a Terminal view, which is super handy when using Compass to compile your code. If you do this in a regular Terminal window behind Eclipse, you’ll miss any errors it throws, and wonder why your site hasn’t updated with your changes when you switch to your browser. With the Terminal view in Aptana, you can see the Compass output right below your code.
  Also, the default colour theme uses a black background. This will make you look super-professional in front of your friends.

• CodeKit

  This app lurks in the background watching you. When you update a file it will perform all sorts of pre-processing and compilation and then refresh the site in your browser. By the time you’ve switched to the browser, your code is already there. May only save you a second or two each time, but every little helps.
  As well as Sass and Compass, it also includes support for Less, Coffeescript, minifying and error-checking Javascript, optimising images and more.

• css_parser

  I like a good stat, and using compass stats on the command line gives me my fix. It shows the number of rules, properties and mixins for each sass file. Installing the css_parser gem (gem install css_parser) takes this a step further and shows you how many CSS rules and properties this is compiled in to.

• Documentation

  The Sass documentation is clear, comprehensive and also highlights relatively minor features, such as Sass comments vs. CSS comments.

Next steps

Now the building blocks are in place, my next steps will be to delve deeper into Compass and to use Sass variables and media queries to make implementing a responsive design even easier.

One big difficulty is handling the embedding of large character sets such as Japanese and Chinese.

This post will present the fully automated font embedding solution we used for a 500 page site available in eleven languages (including Traditional Chinese and Japanese) which is regularly updated by users of a bespoke CMS.

The problem

Generally, a Flash site in English will need to embed the characters a to z (upper and lowercase), 0 to 9 and punctuation. A SWF containing just these characters in Arial comes in at 12kb. Supporting other Western European languages, such as French, Spanish and Italian requires adding only a handful more accented characters. The problem comes when building a Flash site in languages such as Traditional Chinese and Japanese which have much larger character sets.

As you can see from the table below, if you were to embed all the characters, the user would have to wait a substantial amount of time before they can see any text on your site.

There are numerous approaches to this problem, which include:

• Using a font of your choice for languages with small character sets, and defaulting to a system font (_sans or _serif in Flash) for languages with large character sets. However this means that styled, designed and intricately laid out typography is sacrificed in the name of convenience. Also, it’s not possible to adjust the rotation properties of text in a system font, so this approach limits animations and transitions that can be applied to the text without a work around such as converting it to a bitmap.
• Manually telling Flash which characters to embed. However, if the copy in the site is likely to change, this approach will make deploying changes painful and impossible to automate.
• Create a custom font which contains just the characters used in the site, and embed the whole custom font in the site. However, similarly to above, if the copy in the site is likely to change, deploying an update becomes a laborious, manual process involving font editing software.

A quick Google search reveals many other approaches and whilst at the end of the day it depends on the nature of the site being created, here is the approach we took.

Our approach – automated, server-side, command line embedding

This approach was developed to meet the following requirements :

• The site should display text in custom fonts wherever possible.
• The font file downloaded by the user should be as small as possible – no superfluous characters increasing loading times.
• There should be no manual aspect to the process – as developers, we shouldn’t need to be involved in the deployment process, this is something the client can do themselves using our bespoke CMS. The font handling system should also be invisible to the CMS user. When previewing and deploying updates, they should instantly see new characters in the custom font. As Steve would say, “It just works”.

The process currently runs on .NET 3.5 on an IIS 7.5 server, and goes like this…

1. A .NET application, running as a scheduled task, polls the database for changes made by a user of the CMS. N.B. For other sites, the script could just as easily check for changes in XML or JSON files.
2. Upon finding a change, the .NET application takes all the user-facing text from the database for the version of the site being updated (i.e. if the content of the site being updated is a Chinese page, only the Chinese font is updated.)
3. It then parses this text to remove duplicate characters, leaving a comprehensive list of all the characters which could be displayed to a user viewing the site in this language.
4. Next, it converts this to a list of comma separated unicode values which represent the characters.
5. The application then inserts this comma separated list of unique unicode values into a template ActionScript file which is used as the document class for the font library SWF. There are different ActionScript templates for each version (language) of the site, due to different fonts being used in each. Here’s an example of the Japanese file :

   package com.example {
   	import flash.display.MovieClip;
   	import flash.text.Font;
    
   	public class [[CLASSNAME]] extends MovieClip {
    
   		[Embed(source="../../fonts/A-OTF-FutoGoB101Pro-Bold.otf", fontName = "HeadingFont", fontWeight="bold", mimeType = "application/x-font", unicodeRange = "[[CHARLIST]]" )]
   		public var headingFont:Class;
   		[Embed(source="../../fonts/A-OTF-GothicBBBPro-Medium.otf", fontName = "BodyFont", mimeType = "application/x-font", unicodeRange = "[[CHARLIST]]" )]
   		public var bodyFont:Class;
   		[Embed(source="../../fonts/A-OTF-MidashiGoPro-MB31.otf", fontName = "MinorFont", mimeType = "application/x-font", unicodeRange = "[[CHARLIST]]" )]
   		public var minorFont:Class;
    
   		public function [[CLASSNAME]]() {
   			Font.registerFont(headingFont);
   			Font.registerFont(bodyFont);
   			Font.registerFont(minorFont);
   		}
   	}
   }

   The application searches the file for double square brackets, and replaces these with the necessary values for this class; [[CLASSNAME]] is replaced with the language, and [[CHARLIST]] is replaced with the list of unicode values. The template ActionScript files use Embed meta-tags to embed the font into this SWF at compile time. The parameters of the meta tag can restrict the characters being embedded to just those needed – the list of Unicode values representing every character needed in the site – rather than the whole font. Also in the meta-tag, each font is given a fontName – HeadingFont, BodyFont or MinorFont – depending on where they will be used in the site. This name is how the font is referred to by CSS or TextFormat objects within Flash. Each language version of the site uses slightly differing fonts to ensure good readability and complete character set coverage. Using the fontName attribute ensures that the code of the site can use this generic name, rather than using the specific name of the font, which will change depending on which language the site is being viewed in. When run, the constructor of the class registers the font with the global Font object, ensuring that the embedded glyphs will be available to any site SWF which loads in this font library SWF.

6. The application then uses command line compilation (mxmlc) to compile this class into a SWF. Here’s an example mxmlc command :

   mxmlc -o {rootDir}Webrootfonts{lang}.swf
   	-sp {rootDir}FontGeneratorsrccomexample
   	-library-path {flexSDKDir}frameworkslocaleen_US
   	-library-path {flexSDKDir}frameworkslibsplayer10playerglobal.swc
   	-library-path {flexSDKDir}frameworkslibsflex.swc
   	-library-path {flexSDKDir}frameworkslibsframework.swc
   	-library-path {flexSDKDir}frameworkslibsrpc.swc
   	-library-path {flexSDKDir}frameworkslibsutilities.swc
   	-managers=flash.fonts.AFEFontManager
   	-default-size 550 400
   	-default-frame-rate 31
   	-default-background-color 0xFFFFFF
   	-target-player=10
   	-debug=false
   	-- {rootDir}FontGeneratorsrccomexample{lang}.as

7. Finally, the application uploads the SWF into the appropriate location on the server and increments a font file version number property.
8. The code which loads this SWF into the site appends this version number to the SWF’s url as part of a query string – e.g. “fonts/japanese.swf?fv=15″. This ensures the SWF is cached by the user’s browser between visits, until it is superseded by a new version.

Advantages of this approach

The main advantage of this approach is the file size; only necessary characters are embedded, keeping file size as low as possible. The Japanese font file used was 1.6mb, this contains 3 fonts, and if the whole Japanese character set was embedded in each font, the file size would be 9.8mb.

Secondly, the process is entirely automated. Triggered by a CMS user’s actions, .NET compiles and deploys the font file. It involves no human interaction. As well as reducing the time it takes to update and deploy the site, this also reduces the opportunity for human error.

Disadvantages

One disadvantage is that the font compilation system needs to know the characters which need to be displayed in the site before it can compile them into a SWF.

This means that for input fields, we use a system font. This is an extremely minor issue due to the rare use of input fields in this site, and due to the nature of system fonts, it also ensures that input fields are as clear and readable as possible.

The future

One improvement we’re working on is to only embed characters in the fonts they will be shown in. For example, if the character ‘Z’ is only used in headings in a site, why embed it in the body font?

Hopefully knowledge of this approach will help others in creating similar sites in the future. If you have a unique approach to font embedding, have worked on a site that would benefit from this system, or have any tips, thoughts or recommendations, then let us know in the comments.

One approach would have been to transfer all of this data in XML or JSON. However we turned to FluorineFx which is a Flash (and Flex) remoting framework for .NET which facilitates data transfer using AMF (ActionScript Message Format.) It is similar in functionality to BlazeDS (for Java) and ZendAMF (for PHP).

This article is going to show how easy it is to use Fluorine in a Flash site, and introduce the ActionScript classes we’ve written to make it even simpler!

Why?

Fluorine removes the need for coding your own serialization (converting back-end data into XML or JSON) and deserialization (converting the XML or JSON into ActionScript objects) by transferring data in AMF – a binary form of ActionScript. Because Fluorine takes care of this ‘behind the scenes’, there are two fewer steps of the data transfer process for you to build, which saves time and reduces the opportunity for errors.

Also, due to the structure of the data (raw binary ActionScript – no XML or JSON markup) it is smaller in size, improving the speed of communication with the back-end.

More general information on FluorineFX can be found at the main site (including information on using Fluorine with Silverlight and AJAX.)

How?

Configure .NET

So, to set Fluorine up within your .NET project, you just need to add a .dll to your project and a few lines to your web.config file :

<!-- Reflection optimizer provider="codedom|il" debug="true|false" -->
<!-- <optimizer provider="codedom" debug="true" /> -->
<wsdlGenerateProxyClasses>true</wsdlGenerateProxyClasses>
<wsdlProxyNamespace>FluorineFx.Proxy</wsdlProxyNamespace>
<!-- Time Zone Compensation ="none|auto" -->
<!-- <timezoneCompensation>none</timezoneCompensation>  -->
<!-- Any value-type that is not explicitly initialized with a value will contain the default value for that object type -->
<acceptNullValueTypes>false</acceptNullValueTypes>
<!-- value="browse|access" -->
<!-- <remotingServiceAttribute>browse</remotingServiceAttribute> -->

Merge these nodes into the equivalent nodes in your web.config file, and you should be good to go.

ActionScript – Class Mapping

Within Flash, the first step is to map the .NET classes to their equivalent ActionScript classes.

This is done using flash.net.registerClassAlias :

registerClassAlias("com.specialmoves.example.Cake", CakeVO);
registerClassAlias("com.specialmoves.example.Slice", SliceVO);

This code tells Fluorine that our ActionScript class CakeVO is equivalent to the .NET class com.specialmoves.example.Cake.

N.B. In Flex this can be done using a meta tag above the class definition :

[RemoteClass(alias="com.specialmoves.example.Cake")]

ActionScript – Connecting to .NET

To make a connection, we use Flash’s NetConnection object, making sure to specify the correct encoding.

Here we are connecting to a hypothetical Fluorine gateway at http://www.specialmoves.com/example/Gateway.aspx.

_connection = new NetConnection();
_connection.objectEncoding = ObjectEncoding.AMF3;
_connection.connect("http://www.specialmoves.com/example/Gateway.aspx");

Now we have an open connection, we can start making some calls.

Call and Response

Here’s an example of making a call and receiving a response :

private function getSlice(sliceType : String) : void {
   var getSliceResponder : Responder = new Responder(getSliceSuccessHandler, getSliceFailHandler);
   _connection.call("com.specialmoves.example.Cake.GetSlice", getSliceResponder, sliceType);
}
 
private function getSliceSuccessHandler(slice : SliceVO) : void {
   trace("We have cake! Is it iced? " + slice.hasIcing);
}
private function onFailed(result : Object) : void {
   trace("What? Why no cake? " + result['description']);
}

Firstly, in the getSlice function, we create a responder, which defines 2 handlers; a function for a successful call, and a function for a failed call.

Next we make the call using the connection instance which is connected to our Fluorine gateway. The first argument in the _connection.call method is the method name to call on the back-end (the GetSlice method of the Cake class), the second is the responder, and any arguments after this are used as arguments in the GetSlice method.

The C#, .NET implementation of the Cake class would look something like this :

using System;
using FluorineFx;
 
namespace com.specialmoves.example.Cake {
	[RemotingService("Cake")]
	public class Cake {
		public Slice[] slices { get; set; }
 
		public static Slice GetSlice(string sliceType) {
			//get the slice from the database...
			//and then return it
			return slice;
        	}
    	}
}

The main things to note here are that line 5 lets Fluorine know that this class contains methods for Flash to call, and that the GetSlice method returns a Slice object, rather than a serialized, XML or JSON representation of a Slice object.

As for handing this returned object in Flash, that’s simple…

A failed call returns an object to the failHandler which contains information about the error to aid debugging and error handling.

The success handler receives a typed object – SliceVO, ready to be used in ActionScript, rather than a chunk of XML or JSON which needs deserializing.

Whilst this may seem like a trivial example, when developing a 500 page Flash site available in 11 languages, a fast, simple and reliable approach to data transfer can save a lot of time and headaches!

As can a good tool for debugging, introducing Charles…

Debugging AMF data transfer

Charles is a web proxy – it lets you view web traffic being sent and received by your machine. A tool such as this is essential when working on sites which depend on custom data structures and bespoke CMS’s – it can help you diagnose and fix bugs quickly and easily. What sets Charles apart from tools like Firebug is that it understands AMF and shows AMF requests/responses in a clear tree structure. This makes it incredibly useful when working with Fluorine connections (and any other form of Flash Remoting.) Charles also provides connection throttling, repeat requests and request editing, as well as many other useful features.

Specialmoves Labs Libraries : FluorineConnection

Whilst implementing Fluorine connectivity in our own projects, we’ve created a few classes which make creating, configuring and debugging Fluorine connections incredibly simple :

var fluorineConnection : IFluorineConnection = new FluorineConnection(new FluorineConfig("/Gateway.aspx"));
fluorineConnection.addEventListener(FluorineErrorEvent.CONNECT_ERROR, errorHandler, false, 0, true);
fluorineConnection.addEventListener(FluorineErrorEvent.CALL_ERROR, errorHandler, false, 0, true);
var responder : Responder = new Responder(onSuccess, FluorineUtils.onError);
fluorineConnection.call("Cake.GetSlice", responder, sliceType);

To find out more, see full examples and download these classes to use in your own projects, view the project on GitHub.

And if you have any comments, questions or ideas let us know below.