Kicking TypeScript’s Tires

When Microsoft introduced TypeScript – a language for large-scale web application development – at the begin of this month I noticed something strange. Similar to the process of buying a car I started by asking myself questions like: “Does it do this, or that?”, “Can I use it for that?”. But my questions were not random at all. Instead it seemed that my intuition, which guides my curiosity about languages that cross-compile to JavaScript, must use a secret checklist. In this post I will try to verbalize that checklist.  Frankly, I want to know myself: What do I find important about a higher level language for developing large-scale web applications?

The Water in Aarhus

One day after Microsoft announced TypeScript, Google’s Dart team posted a warm welcome note. They pointed out that there must be something special about the location of Aarhus in Denmark in regards to languages for large-scale web application development:

It must be something in the water. Gilad Bracha and Lars Bak announced Dart in Aarhus, Denmark about a year ago as a “new programming language for structured web programming”. Yesterday, Anders Hejlsberg, once again in Aarhus, Denmark, announced Microsoft’s new programming language, TypeScript, “a language for application-scale JavaScript development”. Obviously, there’s something about the water in Aarhus that causes language designers to want to tackle the problem of large scale web development.

The Dart Team Welcomes TypeScript

Google’s Dart team concludes that Dart and TypeScript clearly have the same long-term goals:

A year ago, JavaScript programmers would frequently ask us why we needed a new programming language for the web. We argued that developing large web applications was hard, and that optional static type annotations could help. We also argued that the web needed better tooling support. We think that TypeScript has validated both of these statements. Going forward, I think the Dart project and TypeScript will learn a lot from each other.

The Dart Team Welcomes TypeScript

Let’s walk over to our neighbor’s house with some pie and welcome them. I would like to get to know TypeScript better!

Does TypeScript have a language spec?

That was actually my first question:  Does TypeScript have a language specification? Now, let me reiterate that a language specification is not a tutorial, FAQ, or online help about that language. A good language specification is so detailed that it can be used to implement a compiler. Most language specifications have more in common with insurance policies and the legal fine print of credit card applications. I am one of those weirdos that love reading them. But that’s probably, because I work in the kitchen while others enjoy eating dinner without having to worry about the details of preparing a meal.

Good news is, that TypeScript does have a language specification and it is actually readable and not as dry as Dart’s. What conclusions do I draw from the fact that there is a language spec for TypeScript? It tells me that I am dealing with professionals that are serious about language design. Sadly, Adobe has missed to provide a language specification for ActionScript and for that reason never really made the list of what I consider well-designed programming languages.

Does TypeScript support types?

Yes, TypeScript does support types! Like in Dart type annotations are optional. That means at least you can write clean code that is fully typed if you want to. But how about those sneaky types that are not really types, like Object, “*”, or Array? In a perfect world I would not allow any of those. I am in particular interested in Array, because Arrays turn everything you put into them into untyped Objects. In ActionScript Vectors are therefore a better choice.

First I thought TypeScript didn’t support typed arrays, or vectors. But I was wrong. I wrote up this language spec request, and the friendly folks at Microsoft pointed out that typed arrays are already support in TypeScript:

var arr : number[] = [];

I clearly overlooked that when I was reading the TypeScript language spec.

Does TypeScript allow explicit casts?

I know, casting is a bad thing but sometimes you have to deal with code that wants to cast a bunny to a toaster, or vice versa. In order to cast safely your code has to be able to determine what the instance is made of (with something like ‘instanceof’ or ‘is’) and secondly you need to be able to express your intent of ignoring types (with something like ‘as’) against common sense. A typical example would be:

// (bad but at least safe) JavaScript
function feedBunnyOrToaster(bunnyOrToaster:Object)
  if( bunnyOrToaster instanceof Toaster )
    var toaster : Toaster = bunnyOrToaster as Toaster;
    toaster.feed(new Bagel());
  else if( bunnyOrToaster instanceof Bunny )
    var bunny : Bunny = bunnyOrToaster as Bunny;
    bunny.feed(new Carrot());

I did learn that TypeScript supports ‘instanceof’ for reflexion but I couldn’t find anything specific about cast operators, i.e. ‘as’. So I wrote up a language spec request called Please add support for explicit casts with ‘as’ keyword. The Microsoft folks replied promptly and provided a solution that works for me:

var toaster : Toaster = <Toaster>bunnyOrToaster;

This notation is called “type assertion” and will throw an error if ‘bunnyOrToaster’ is not of type ‘Toaster’. In ActionScript ‘as’ does not throw and simply returns NULL if the types don’t match. But that behavior can easily be emulated by using try/catch. So I am fine with that.

Does TypeScript support inheritance?

Yes, TypeScript does support inheritance. You can define classes which can derive from other classes and may implement interfaces. Digging deeper into the inheritance topic I usually get interested in encapsulation and interfaces.

  • Can I encapsulate members and methods in private and public sections? (yes, that’s what I want)
  • Is everything public? (bad)
  • Can I use protected? (nice to have, but I don’t need it)
  • Is ‘class’ a primitive type?
TypeScript supports public and private at compile time. Once you cross-compile to JavaScript everything is public. That’s fine with me.
Having ‘class’ as a primitive type is very useful for things like factories.

var c : Class = MyClass;
var x : MyClass = new c();

TypeScript does not support ‘class’ as a primitive type. But they have this weird thing called “brands”. Here is the answer to my language spec request called  Please add a new primitive type ‘Class’ :

A class in TypeScript is a combination of two things: A construct signature and a brand. Brands are unique to each class, so you don’t care about those. Your question then boils down to: what type will be assignment compatible with every class? Consider this:

interface Class {
    new (args:any): any;

This interface will be assignment compatible with any class because all classes will have a construct signature with one or more arguments that returns something assignment compatible with any. You can limit this further depending on your use case.

I first didn’t get the idea. But then I tried it and just by including that definition of Class I could use Class as a generic type for classes!

Does TypeScript support interfaces?

My questions are simply:
  • Can one class implement multiple interfaces, or only one?
  • Can I determine whether an object is an instance of a class that implements an interface?
Yes, TypeScript does support interfaces and classes may implement multiple interfaces.
But unfortunately you cannot use ‘instanceof’ for interfaces. For example this will give you a syntax error:

interface IAnimal { ... }
class Animal implements IAnimal {...}
class Snake extends Animal {...}
class Horse extends Animal {...}
var sam = new Snake();
// works:
if( sam instanceof Animal )
	alert( "Sam is an Animal" );

// flags an error for 'IAnimal' :
if( sam instanceof IAnimal )
	alert( "Sam is an Animal" );

Here is how the Microsoft folks explained to me why ‘instanceof’ interface does not work as expected (for more details see Please add support for identifying classes of objects via ‘is’):

Not a bug. Interfaces are purely type information, and TypeScript’s type information is only present at compile time. Instanceof is a runtime feature of JavaScript so has no idea what TypeScript types originally existed.

Identifying the lineage of objects in TypeScript must be done the same way it is done in JavaScript today, such as by setting sentinel values during construction or by examining the structure of the object (eg. if it has a ‘talk’ property it must be an animal). TypeScript could possibly provide a library method to do this for you, but it’s a difficult thing to do right since the type information is not available at all at runtime.

This is a bit disappointing. So TypeScript supports interfaces but you can’t really use them for reflection? In my opinion you can’t offer a feature that extends JavaScript and then not support it in situations for it was designed for with the argument that JavaScript does not support that feature. I admit it’s work, but I have implemented it in my ActionScript to JavaScript cross-compiler. You need to emit a table to the JavaScript code that maps from a class name to its implemented interfaces. At compile time you need to statically analyze whether the right hand side of an ‘instanceof’ expression is an interface. If so, your cross-compiler has to ‘virtualize’ the expression and emit something like “adobe.instanceOf(a,b)” instead of “a instanceof b”. It’s work but it can be done. If even I can do it, Microsoft can certainly do it.

At least, why not making type assertions smarter?

var samIsAnimal;
  var tmp : IAnimal = <IAnimal>sam;
  samIsAnimal = true;
  samIsAnimal = false;

This might actually already work…

Can I split up my TypeScript project into smaller pieces?

Yes, you can. They call it “modules”. It’s pretty cool especially because Modules are “open ended”, meaning you can add more implementations to pre-existing Modules.

Can I use other JavaScript libraries with TypeScript?

Yes, you can. And it’s pretty easy. You just “import” their declaration source files. By convention declaration source files end with *.d.ts and contain interfaces and APIs provided by the JavaScript library you want to include. It’s pretty easy to write those declaration source files and I suspect that very soon you’ll find declaration source files for all major JS libraries.
I have to admit that TypeScript beats Dart at this feature. Dart’s JS interop library is just awkward to use and most likely dog slow.

What’s the verdict?

I have to say that TypeScript gets good marks for most of the items on my checklist. The only fly I could find so far is missing support for ‘instanceof’ interfaces.
I could probably go on for hours kicking TypeScript’s tires but I think the questions above are probably the most important ones. Once I find answers to those language feature questions I usually move on and have a look at the generated JavaScript. And that’s a whole other ball game…

Hello, TypeScript

Time flies. I just realized that my last entry was from May. Thanks for your feedback on my Pew Pew Manifesto! In the last few months I’ve  had a few things I wanted to write about but just not enough time. Yesterday I read an announcement by Microsoft that seems to be too important to be left out of the discussion about JavaScript cross-compilers.


Microsoft introduces TypeScript

On October 1st, 2012,  Microsoft introduced a new programming language for large-scale web application development called TypeScript:

“TypeScript is a superset of JavaScript that combines type checking and static analysis, explicit interfaces, and best practices into a single language and compiler.”

TypeScript: JavaScript Development at Application Scale

Here are a few links that you might find useful if you are interested in learning more about TypeScript:

In my opinion it is worth stepping back for a second and look at the motivation for TypeScript:
Why did Microsoft decide to invest in TypeScript?

And in extension:
Why did Google create Dart?


Why did Microsoft decide to invest in TypeScript?

It seems TypeScript wants to overcome limitations in JavaScript that prevent developers from writing large-scale web applications:

“With HTML5, the standards web platform has become significantly more compelling for delivering rich user experiences. At the same time, the reach of JavaScript has continued to expand, going beyond the browser to include native device apps (e.g. Windows Store apps for Windows 8), applications in the cloud (e.g., node.js running on Windows Azure), and more. With these developments, we’re starting to see applications of unprecedented size written with JavaScript, despite the fact that creating large-scale JavaScript applications is hard. TypeScript makes it easier.”

“JavaScript was originally designed to be a client-side scripting language for web pages, and for many years it was limited to event handlers that scripted a Document Object Model (DOM). As a result, JavaScript is missing many of the features necessary to be able to productively write and maintain large-scale applications, namely those that create distinct contracts between components and developers.”

TypeScript: JavaScript Development at Application Scale

That echoes pretty much what Google says about their motivations for Dart.


Why did Google create Dart?

In Dart – A Modern Web Language (Google IO 2012) Lars Bak and Kasper Lund describe the thought process that eventually lead to developing Dart. At around 8:30 Kasper Lund explains some of the biggest shortcomings of JavaScript in a section called Fundamental JavaScript Issues. The most important issue is in my opinion JavaScript’s keep-on-truckin’ paradigm, where mistakes are tolerated to a degree where almost anything goes and wrong types lead to unusable results (~11:00). That segment is really worth watching. I highly recommend it.


“Don’t blame JavaScript, it’s the developer’s fault!”

The second session I would like to quote is Google I/O 101: Introduction to Dart. At around 11:00 Seth Ladd uses this JavaScript example for illustrating that in Google’s Dart you can reason about unfamiliar code more easily:

function recalculate(origin, offset, estimate) {

Seth explains:

For example the JavaScript example at the top reads, the calculate method takes an origin, an offset, an estimate, and I don’t even know what it returns.

What is an origin?
What is an offset?
What does this return?

Given this function signature, you know almost nothing.

Of course, you can pray the developer left comments that annotate all the types of the parameters and return value. If you are lucky, they did. But then your tools don’t know how to parse written text. Worse case, you’re reading the function body, and if you’re reading the function body, you’ve broken encapsulation, and you’re in a bad spot. You really want to know what the method is, what you can pass to it, and what it can return.

What Seth describes has happened to me many, many times when working with foreign JavaScript and Lua code (which is another dynamic language that should be avoided in my opinion). I often hear arguments that reiterate the mantra of “don’t blame JavaScript, it’s the developer’s fault”. For example, incoherent JavaScript code is caused by developers who don’t understand how to write code in JavaScript. Or, ambiguous function signatures are the result of undocumented code, which developers failed to provide. Or, developers should read a good book about software design before writing any code. Or, if you use the JavaScript library xyz then you can avoid all of those development problems.

If those arguments from JavaScript enthusiasts were really true, why did Microsoft invest in TypeScript and why did Google create GWT and later Dart?


The problems are real

In my opinion those arguments from JavaScript enthusiasts all ignore structural problems of JavaScript that are very real. To illustrate my point: If a language allows typos and keeps on truckin’ with unusable results – would that be the developer’s fault? Frankly, yes, but developers are humans and make mistakes. That’s why we need languages and compilers that catch errors like typos as early as possible, that is, at compile time. Pointing out that a developer just has to know the language and should simply not introduce any typos doesn’t help anybody.

Nobody is perfect. That’s why we need good tools and languages. TypeScript, Dart, and GWT seem to provide just the right tools for helping you creating large-scale web applications.


The Pew Pew Manifesto

This is the last post of the Pew Pew Chronicles – a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store.

I would like to end this series with summarizing the underlying ideas of my work on Pew Pew.


Please wake up now

Last month I gave a talk about creating Metro applications using ActionScript. In order to spice up the Q&A segment at the end of my talk I thought it would be fun to add a final slide with some provocative statements. I called that slide The Pew Pew Manifesto, which I am going to share with you in a minute.

I suspect that not everybody will agree with what I put into the Pew Pew Manifesto. But before we enter a religious war about dynamically versus statically typed languages, or whether JavaScript can be used for large projects, let me stress that I didn’t write the Pew Pew Manifesto in order to pick up a bar fight. I wrote it in order to wake up my colleagues that fell asleep during my talk! (Just kidding, nobody fell asleep.)

That said, let me present the Pew Pew Manifest:

  1. JavaScript is not suitable for large web apps.
  2. JavaScript is the browser’s assembly language.
  3. Choose a high-level language for developing web apps.
  4. Cross-compile from a high-level language to JavaScript.
  5. Use Google’s Closure Compiler for optimizing JavaScript.
  6. Optimized JavaScript is obfuscated and protects your intellectual property.
  7. Let your app degrade gracefully when OS features are missing.
  8. Invade every Web Platform!

I’ll walk you through the list…


JavaScript is not suitable for large web apps.

I am serious: Don’t write large web apps in JavaScript. As mentioned in Planning A Death March I don’t think JavaScript is suitable for implementing large projects. Last year I was asked to help out with an internal project that used JavaScript. Over time the code had grown out of control and there was only one person left, who really understood how it worked. The project had also become unscalable, because adding more developers would not have increased the overall productivity. It would have taken those developers too much time to come up to speed and work on this particular code base written in JavaScript. I looked at the code and suggested this crazy idea: Why not porting the existing JavaScript code to ActionScript and then continuing development in ActionScript while cross-compiling to JavaScript?

Porting JavaScript to ActionScript in order to cross-compile back to JavaScript? Was that crazy-talk? Perhaps, but it surprisingly worked and probably saved that project. Here is what happened when I ported the JavaScript code to ActionScript:

  • The code naturally distributed itself from about 10 files to over 100 files when creating ActionScript classes.
  • Porting JavaScript to ActionScript revealed inconsistencies and at times incoherent uses of types.
  • My cross-compiler automatically added type annotations necessary for compiling with Closure’s Advanced Mode.

I don’t know why but JavaScript programmers tend to put all of their code into few files. That’s not so useful, though, if you want to have multiple developers work on the same project. Splitting up the code into multiple files enabled us to scale the project.

You wouldn’t believe how many inconsistencies I found when porting JavaScript to ActionScript. Often JavaScript code, which looked perfectly fine at the first glance, revealed itself as incoherent the moment I tried to compile it with an ActionScript compiler. Sloppy usage of types were to blame for most of the inconsistencies. A very popular anti-pattern seemed to emerge: functions, which return incompatible types:

// (bad) JavaScript
function createBunnyOrToaster(createBunny)
  if( createBunny )
    return new Bunny();
  return new Toaster();


Of course if you start writing this kind of code your receiving end gets quickly contaminated with inconsistencies:

// (bad) JavaScript
function feedBunnyOrToaster(bunnyOrToaster)
  if( bunnyOrToaster instanceof Toaster )
    bunnyOrToaster.insert(new Toast());
    bunnyOrToaster.feed(new Carrot());


Nobody in his right mind would write this kind of code. But I have seen it more than once. In fact I have written that kind of code myself. My point is that it’s not necessarily the developer’s fault that we end up with bad code like the examples above. I would argue that dynamically typed languages like JavaScript are too tolerant and don’t slap developers on the fingers when they start mixing up bunnies with toasters. It might cramp your artistic programming style if you cannot mix up bunnies with toasters but where I come from doing so results in bad projects.

Just to be clear: You can write bunny-and-toaster code in ActionScript, too. But I would argue that you get immediate feedback of something being fundamentally wrong as you are typing that code, just by being confronted with questions like “what should be the return type?”. Of course you can choose to use “*” or “Object”. But most people pause and rethink their design at that point.

Not everybody is as smart as Gilad Bracha or John Resig and those that aren’t – like this author – are probably better off with writing their code in a statically typed language. Many will probably disagree with this statement. It might make more sense after reading the next Manifesto statement.


JavaScript is the browser’s assembly language.

In the following week after I gave my talk about creating Metro apps using ActionScript I ran into a few colleagues and I was surprised that it was this statement that they found most intriguing.  One colleague argued that the definition of assembly language implies a one to one correspondence with the underlying machine code. Another characteristic element of assembly languages are that they are also generally understood to be non-portable. Since JavaScript is neither, where does this idea of JavaScript being an assembly language come from and what is this about?

The first time I heard about JavaScript described as an assembly language was through Gilad Bracha’s blog. In 2008 he wrote in java’scrypt:

I’m not advocating writing clients in Javascript directly. Javascript is the assembly language of the internet platform (and the browser is the OS). It’s flexible enough to support almost anything on top of it, and poorly structured enough that humans shouldn’t be writing sizable applications in it.

To illustrate his point let me show you my cross-compiled and optimized JavaScript code of SpriteExample, which is included in Adobe’s online documentation about the Sprite class. As you can see the JavaScript code is extremely dense and no longer readable. In that sense the code looks more like binary code to me. It turns out that this kind of “binary looking” JavaScript is the most efficient version in terms of size and performance.

If you are interested in the discussion about JavaScript as an assembly language I recommend listening to JavaScript is Assembly Language for the Web: Semantic Markup is Dead!


Choose a high-level language for developing web apps.

Implementing your project in JavaScript  leaves you with some tough choices: If you ship the development version of your JavaScript code with your product, it is not obfuscated, and also bigger, and slower. If you want a faster, smaller app that also protects your intellectual property you have to optimize your JavaScript. But then you also have to annotate your code with type hints. If you don’t annotate your code with type hints the Closure compiler won’t be able to optimize as much and your code is less obfuscated, bigger, and slower. If you do find yourself writing JavaScript with type type annotations then why not using a high-level language instead and use a cross-compiler that automatically generates the type hints for you?

That’s really the point of this Manifesto statement.


Cross-compile from a high-level language to JavaScript.

You have several choices:

Some folks are even experimenting with cross-compiling Scala to JavaScript.

In the case of Pew Pew I used my own ActionScript to JavaScript cross-compiler. In Planning A Death March I made the argument that if you had to implement Photoshop in six weeks you wouldn’t pick an assembly language. Being able to cross-compile from a high-level language to JavaScript was a crucial element of my plan.


Use Google’s Closure Compiler for optimizing JavaScript.

In Optimizing cross-compiled JavaScript I wrote a whole article about the importance of optimizing your JavaScript code. As far as I know Google’s Closure Compiler is still the best JavaScript optimizer out there.


Optimized JavaScript is obfuscated and protects your intellectual property.

A nice side effect of optimizing your JavaScript is that it becomes unreadable as I illustrated with my SpriteExample snippet. You would never write “binary JavaScript” code like that manually. But for professional software production it is important to be able to write code in a maintainable high-level language while deploying a product that does not reveal the ideas of your source code.

In my opinion the current version of Visual Studio 11 for Metro is missing this important point. There is no built-in JavaScript optimizer and no support to hook one in. Microsoft seems to assume that nobody wants to optimize JavaScript code. Their current IDE only outputs Debug JavaScript code. There is in my opinion essentially no Release option for JavaScript apps in Visual Studio 11 for Metro. I really hope Microsoft will change that.


Let your app degrade gracefully when OS features are missing.

This might be an obvious statement. But what I am saying is, if you write a Metro app in a high-level language like ActionScript make sure that your code “degrades gracefully” so your app would also run in most modern browsers on other platforms.

I’ll give you an example from my Pew Pew code:

const domWindow : DOMWindow = adobe.globals;
if( domWindow.hasOwnProperty("Windows") )
  var appLayout : ApplicationView = Windows.UI.ViewManagement.ApplicationView;
  appLayout = appLayout.getForCurrentView();
  appLayout.addEventListener("viewstatechanged", onViewStateChanged, false);


The code above only registers onViewStateChanged if the environment is known to support the Windows namespace. In other words, if this code runs in a browser without Metro support, it won’t register for view state changes.

Why going through the trouble? The last statement of the Pew Pew Manifesto will answer that question.


Invade every Web Platform!

I think, being able to write code once and reuse the same code on different platforms without  compromising neither functionality nor aesthetics of your app’s user interface is a very desirable goal.

This might sound like science fiction, but what if all of your apps in the near future were just custom browsers? Like Flash Player playing SWFs your custom browser would run your JavaScript, that is, code written in a high-level language and then cross-compiled to JavaScript. There are many cases where your JavaScript code could run in the browser as is. But how would you get your app into the Apple App Store, or the Android Marketplace? How would you make money?

This is why I find PhoneGap (now an Apache incubator project called Apache Cordova) very intriguing. In many ways PhoneGap’s architecture might lead to a new type of apps that you could call “custom web browser apps”. You can look at the PhoneGap architecture as a framework that provides custom browsers for multiple platforms (iOS, OSX, Android, Blackberry, Windows Phone). All you have to care about are the HTML, CSS and JavaScript parts you have to provide. PhoneGap even supports special JavaScript APIs for features like Camera, Location, or Accelerator, that are not accessible via standard DOM APIs.

For example, if I wanted to get Pew Pew into the Apple AppStore and Android Marketplace I would simply cross-compile my ActionScript project to JavaScript and plug it into the PhoneGap architecture. As far as I know I can even write my own native plug-ins for PhoneGap. If that’s really the case I can pretty much invade every web platform that PhoneGap supports.

Maybe that’s what I should be working on next…

Pew Pew Chronicles: You are a Winner!

This is part seven of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha in December 2011 I learned about Metro and got immediately hooked.  After installing Windows 8 Developer Preview and playing with Metro I discovered that I could even cross-compile Pew Pew to Metro. But there was a problem: this game was “crappy”, not “charmingly crummy” and unsuitable for submission to the Windows 8 First App Contest. My Death March Plan boiled down to improving Pew Pew first before implementing Metro features. Everything seem to be on track until my friend Christina made a video that recorded her first attempts to play the game. I clearly needed to to redesign a new joy stick and there were still a few Metro features missing. In the end everything worked out: after a few intense days of “coma hacking” Christina approved the new joystick and all of my Metro features were finished and I finally submitted Pew Pew to the Windows Store. All I had to do next was waiting for the verdict.


Waiting For Godot

Shortly after submitting Pew Pew to the Windows Store on 1/8/2012 I received a friendly email from Microsoft’s staff to let me know that the finalists would be announced a week later on Sunday, 1/15. After my “coma hacking” week prior to the Pew Pew submission my regular work week felt like vacation. Sunday came and I was checking my emails throughout the day. But there was no email from Microsoft. I had to face the bitter truth: Pew Pew didn’t make it into the finals.

I have to admit I was disappointed as well as a little bit surprised. Granted that Pew Pew was only a “charmingly crummy” space shooter game it was also loaded with Metro style features like view states, tiles, settings charm, share source support, roaming data storage, and pause and resume. Pew Pew must have been up against some tough competition, I thought. I had read that Microsoft teamed up with game developers to create HTML games like Cut The Rope and Pirates Love Daisies. If those had been the kind of games Pew Pew was compared against then it wouldn’t have had the slightest chance.


Off By One

If there is one piece of wisdom I learned from our dog Joe it is moving on to the next interesting thing quickly and not dwelling on failures. It still amazes me how fast Joe is able to disconnect himself from unpleasant events and focus on all the exciting opportunities that lie in front of him. Joe’s “event horizon” is approximately one minute. Mine is in the best case about one day .

“Well, that didn’t work out” was my first thought when I logged into my computers the next morning at work. I almost reached “Joe Zen” state by late afternoon until I saw an email from Microsoft. The subject said, First Apps Contest: You are a Finalist! I guess, Microsoft missed their own deadline by one day and elected the finalists on Monday instead of Sunday. That was fine with me!

After doing a little dance in my office and calling my wife I also contacted Mike Chambers to let him know that Pew Pew made it into the finals of Microsoft’s First App Contest. He laughed and said: Microsoft must be in trouble. He was humbly referring to the crappy quality of his original Pew Pew version.


Sleeping In

Microsoft’s congratulation email included some information about the next steps that would follow. They kindly asked every finalist to do four things:

  1. Install a new development version of Windows 8
  2. Compile and update the app using that new Windows 8 and Visual Studio 11 beta.
  3. Sign up for a Windows Store account.
  4. Submit the app to the Windows Store before 2/3/2012.

I don’t recall the details but I pretty much ended up ignoring that email for a few weeks. Perhaps I was a little bit burnt out, or I thought that installing the new Windows 8 and recompiling my app shouldn’t take that long. But for about a month I did literally nothing for the contest.


Rude Awakening

Then on 2/23 I got an email from a staff member of the  First Apps Contest Team politely asking about the progress on migrating my app to the new Windows 8 version. The term “migration” woke me up. I thought it was just recompiling. I also realized that the next deadline on 2/3 was coming up in less than a week. In fact my sabbatical was starting on 1/30 and our plane to Mexico was leaving on 1/31. In other words I had to be done by 1/30.
Installing the new Windows 8 version was easy but then I ran into unexpected problems when recompiling Pew Pew. When I launched Pew Pew in the debugger I found myself staring at a white, empty screen.

Now, as part of downloading and installing the new Windows 8 build I also did sign a non-disclosure agreement (NDA), which prevents me from getting into any details of this particular Windows build. But let’s say the reason for my broken Pew Pew were a combination of unexpected Metro changes and my own code in respect to loading images. To be fair, I think the problems were more in my code than it was Metro’s fault. In order to fix those problems I had to rewrite the image loading code, which also significantly improved Pew Pew’s performance.


Busy Bees

I was pretty busy that week wrapping up my projects before I was leaving for my six week sabbatical on 1/31. The Pew Pew changes were not that hard but I just didn’t have a lot of time that week. I ended up testing and getting ready for the app submission on 1/31, which was just one day before my wife and I would take a plane to Mexico City. That’s when I hit a pretty big roadblock: Microsoft’s Windows Store website refused to accept my new version of Pew Pew and I couldn’t figure out why.

Finally I gave up and sent an email to my contact person for the First App Contest. I said that I was unable to submit my app to the store and that I would probably not make the deadline on 2/3, because I would leave early next morning for Mexico. I would only have three hours left to get Pew Pew into the store.

I have to admit that I was impressed how fast the Microsoft guys reacted to my email. Another Windows Store specialist got quickly pulled into the thread and he promptly sent me instructions from his Windows 7 Phone. Microsoft’s response team actually helped me with my problems within an hour and the new Pew Pew version was in the Store shortly afterwards. Without their help I would have missed the deadline and Pew Pew would have been disqualified.

Looking back my biggest mistake was probably not starting earlier with my work on Pew Pew. But life is complicated and sometimes you have to improvise. In the end it all worked out and I definitely found new respect for those busy bees at Microsoft.



Sabbatical! Adobe is a great workplace and offers its employees one sabbatical every five years. I have been with Adobe for over 15 years and got the maximum of six weeks. There are three rules for Adobe sabbaticals:

  1. You have to take them within 2 years.
  2. You are not allowed to split your sabbatical up in smaller pieces.
  3. You should have fun.

I made up rule #3. But Adobe really means it: You should have fun and recharge your batteries. For example John Nack went to Guatemala for his sabbatical roughly at the same time I was starting mine. I was definitely planning on having fun and relaxing in Mexico.

For my trip to Mexico I established similar ground rules like I did back in December 2011: no more than 4 hours of work per day. It turned out that I worked perhaps 2 hours of work after one week of not working at all. Frankly, I didn’t know I could do that.


Improving Pew Pew

My time in Mexico was rather uneventful in regards to developing Pew Pew. I worked only for a few hours but continuously and over time improved  Pew Pew little by little.

  • I added a few more settings for adjusting ammunition and speed
  • I also added a button for clearing the high score to the Game Options flyout.
  • I improved the accuracy of the ship movements
  • I improved (“fixed” is probably a more appropriate word here) the collision detection algorithm.
  • I removed the game area boundaries (game objects re-enter on the opposite side).
  • UFOs now shoot too.

In the meantime Microsoft sent me an email asking me to install yet another version of Windows 8 and to resubmit Pew Pew by 2/17/2012. After avoiding a disaster caused by doing nothing I was eager to start my work early. But this time it looked like the re-submission process would be only a matter of recompiling the app, because Microsoft was planning on releasing the next new Windows 8 build on 2/14. There was one tiny problem: Our flight was leaving on 2/15. If I downloaded the new Windows 8 version back in Seattle I would only have two days to fix any problems and submit Pew Pew to the Store. At that point I really didn’t want to mess up again. I had to start my work in Mexico City.


Bandwidth Problems

My wife and I left Oaxaca  in the morning of 2/14  and arrived in the late afternoon in Mexico City. Before I unpacked my luggage I checked my email and sure enough there was the announcement for the new Windows 8 version. I logged into my account and clicked on the link for the Windows 8 images. The progress bar was crawling. The ETA for those two images was 15 hours.

That didn’t worry me, because I could just let the browser download over night. The next morning I realized that the process got interrupted after downloading about 10%. The new ETA had been reset to 12 hours. We had to be at the airport in 7 hours.

If you ever run into a similar bandwidth problem abroad try what I did: I went to the reception and asked whether the hotel had a land line (they did not), or whether they had different routers (they did). Then I tried every router until I found one that was faster. I eventually picked a router that downloaded my images in 4 hours.


Airplane Mode

I got my Windows 8 images  just in time before we entered the plane. But if your laptop’s battery only holds about 3-4 hours of juice, how do you make use of the precious power so it would last a long flight?

Here are my tips for saving laptop energy:

  1. Turn off wireless and bluetooth.
  2. Pull down the shades and lower the screen brightness so you can still see the letters on the screen.
  3. Quit every app that you don’t use.
  4. Try to avoid compiling. Reading and writing is cheap, compiling costs more energy.
  5. Try to avoid running VMware. It’s a powerful tool that requires lots of energy.

In my case I didn’t have much choice and had to use VMware in order to install the new Windows 8 version.

Fortunately everything went well. No problems, Pew Pew only needed to be recompiled.


The Video Shoot

We arrived in Seattle on 2/15 at 2:00 AM and I got up 5 hours later at 7:00 AM in order to prepare the house for a video shoot for  Microsoft’s website. Microsoft told me that they would like to shoot a little video for their blog, which would introduce the finalists. In hindsight I suspect that by then they had already selected the winners and they wanted to have a video about the winners and not all of the finalists. I am saying that, because shooting a video is extremely expensive and labor intensive.

Microsoft hired Omelet, which is a video production company from L.A., and their friendly crew of about 8 showed up at 9:00 AM in the morning at our house. I also met three folks from Microsoft’s PR department. The whole video shoot took about 4 hours and in the final video you only see about 4 seconds.

If you have never been part of a video shoot, I can tell you it’s very interesting. The equipment they used was all high-tech. What to me looked like high-end photo cameras were fully functioning video recording devices. They had a sound guy that heard everything. From time to time he raised his hand and said “plane”, or “fridge” and only then I would notice that a plane was flying over Seattle or the fridge was doing whatever fridges need to do periodically in order to keep the chamber cold.

Adam, the director, told me that this shoot would be like an interview, except for they would never see him. That’s why it would be important that I incorporated the questions in my answers. It sounds easier said than done! At one point Adam asked me: So how do you like Windows 8? I answered: “Oh, it’s great” before I realized that I had to incorporate the question in something like “What I like so much about Windows 8 is …”. I apologized and offered a corrected version. Adam told me that that happens all the time and they can edit everything later. What I found funny is that one of the few sound-bites they used from our 4 hour interview was “Oh, it’s great.” and “I like competition”.

Another funny trivia I learned later: This whole video cannot be shown in Singapore, because my dog Joe walks towards me in one scene and naturally turned his behind to the camera. Apparently showing a dog’s butt in a video is considered extremely rude in Singapore.

I was pretty tired when the video shoot was over. But I would do it again in a heartbeat. The Omlet crew and the Microsoft PR folks couldn’t have been nicer. It was an interesting experience and a pleasure working with them.


The Windows Store Opens

On 2/29/2012 Microsoft revealed their Windows Consumer Preview (which is pretty much the Windows 8 beta) as well as the new Windows Store. As part of their announcement Microsoft also introduced the winners of the First App Contest.

Pew Pew made it.

It was a lot of work but it was also a lot of fun. What started as a Metro learning project ended with a nomination for Microsoft’s First App Contest. I never expected that back in December 2011. Now, what’s next? Where do I go from here?

I’ll tell you next week in the final part of the Pew Pew Chronicles.


Pew Pew Chronicles: Submitting to the App Store

This is part six of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha in December 2011 I learned about Metro and got immediately hooked.  After installing Windows 8 Developer Preview and playing with Metro I discovered that I could even cross-compile Pew Pew to Metro. But there was a problem: this game was “crappy”, not “charmingly crummy” and unsuitable for submission to the Windows 8 First App Contest. My Death March Plan boiled down to improving Pew Pew first before implementing Metro features. Everything seem to be on track until my friend Christina made a video that recorded her first attempts to play the game. I clearly needed to to redesign a new joy stick and there were still a few features missing. According to my original plan I had nine hours left.


Nine Hours?

Forget it. That was impossible. It was Tuesday and the deadline was on Sunday, 11:59 PM. I decided to postpone testing and app store submission into Sunday. In addition I increased the capacity form 3 to 6 hours for the remaining work days from Tuesday to Friday. Saturday would be a 12 hour work day – “coma hacking” as we used to call it back in the days when I was working for Star Division (which got absorbed by Sun, which got absorbed by Oracle). With my creative accounting I increased my overall capacity from 9 to 36 hours. That’s almost a full work week!


A New Joystick

After searching around for a little bit I found an ActionScript sample with source code that emulates joystick controlled movements. The sample code looked terrible, because it used hazardous with statements and had to be cleaned up first. But the joystick logic seem to be working. It took me about 6 hours to integrate that joystick into Pew Pew including “crummifying” the artwork.


Crummifying Images

Pew Pew’s style guide could be summarized as: “make it charmingly crummy”. Images should look hand-drawn and the font for any text should look hand-written. But what do you do if you have a piece of perfect artwork? For example the artwork of the joystick from the ActionScript sample with source code that I found was clean and even had 3D effects for the knob. Whenever I had to add new artwork to Pew Pew like in this case the new joystick I had to make it crummy looking – a process that I named “crummifying”.

This is how it worked:

  1. Create a new document in Photoshop.
  2. Create a new layer and import the original artwork (here a screenshot of the sample’s joystick).
  3. Dim that layer by setting the layer’s alpha channel to 0.5 to 0.75.
  4. Create a new layer on top of the first layer that contains the original artwork.
  5. Use a fine brush and manually draw the artwork by following the contours exposed by the dimmed layers.
  6. Remove the first layer with the original artwork.

That left me with a crummified version of the original artwork. Over time my artistic skills naturally improved and I had to force myself to not draw as well as I was capable of doing. In some cases I had to start over and make everything crummier.


Metro Features

The joystick was going the right direction and the game was finally looking like a real game. All that was left was finishing up the Metro features and fine tuning the game. As you might recall I derived these eight Metro Commandments from Jensen Harris’s 8 traits of great Metro style apps:


Metro Style Trait Commandment
1. Metro style design “Align to the grid.”
2. Fast and fluid “Optimize with the Closure Compiler.”
3. Snap and scale beautifully “Honor the View States.”
4. Use the right Contracts “Implement Settings and Share Source.”
5. Invest in a great Tile “Provide wide and small Tiles.”
6. Feel connected and alive “Be interruptible: pause and resume.”
7. Roam to the cloud “Store app settings into the cloud.”
8. Embrace Metro principles “Do all of the above!”


I boiled those Metro Commandments further down to these Metro features that I wanted Pew Pew to support:

  • Tiles (wide, small, live).
  • View States (snap view, landscape, portrait).
  • Settings Charm.
  • Share Source.
  • Roaming Data Storage.
  • Pause and Resume

I’ll walk you through each of those features and tell you (roughly) how I implemented them.



In Metro every application is represented by a Tile. One of Jensen Harris’s recommendations is therefore “Invest in a great Tile”. It is important to note that there are three different Tile sizes. But Tiles could also be implemented as targets for push notifications for, i.e. stock ticker apps or weather apps, which allowed the apps to change their Tiles dynamically. Time was running out so I only provided the three tile sizes, which was super easy.

If you launch Visual Studio 11 and open your project’s package.appxmanifest you can simply add PNG files for the three tile sizes. All you have to do as a developer, really, is drawing those PNGs.


View States

“Snap and scale beautifully” meant to me “Honor the View States”. In order to observe view state changes I added an event listener to ApplicationView:

var appLayout : ApplicationView = Windows.UI.ViewManagement.ApplicationView;
appLayout = appLayout.getForCurrentView();
appLayout.addEventListener("viewstatechanged",  onViewStateChanged, false);


In onViewStateChanged I implemented the logic that changed the game area’s size and notified the game objects. (For more details about observing view state changes in Metro see the documentation for Application View Class and Snap Sample.)


Settings Flyout

For the first release I just wanted to have one Pew Pew setting for adjusting the position of the joystick. If you are left-handed you probably want your joystick on the left side of the screen. My settings control was a simple switch for “left” and “right” joystick position.

In order to implement a Settings Flyout I added my event listener to the application’s “settings” event, which gets called when the user opens the Settings charm. My event listener then populates the Settings Charm using SettingsFlyout.populateSettings().

const app : Application = WinJS.Application;
app.addEventListener("settings", onAppSettings, false);
private function onAppSettings(e:SettingsPaneCommandsEvent) : void

  e.detail.applicationcommands = {
    { href: "SettingsUIFlyout.html", title: "Game Options" },
    "helpDiv": { href: "HelpSettingsFlyout.html", title: "Help" },
    "aboutDiv": { href: "AboutSettingsFlyout.html", title: "About" }


As you can see each Settings Charm (game options, help, about) has its own HTML file.

For more details about implementing a Settings Flyout please see the documentation for WinJS.UI.SettingsFlyout and SettingsFlyout.populateSetting.


Share Source

From Jensen Harris’s talk about 8 traits of great Metro style apps I learnt that every Metro style app should be a Share Source if possible. In more technical terms: every Metro app should implement the Share Source Contract. Contracts are callback interfaces, that Metro asks you to implement in order to support features like Share Source. The Share Source Contract is about sharing information with others through apps and services like Facebook, Twitter, and email. Those apps and services are Share Targets. But you can also make your app a Share Target if you implement the Share Target Contract.

For Pew Pew I decided that players should be allowed to share the great news of reaching a new high score with the world. If you don’t have a high score the text would say something like “Hey, check out Pew Pew. It’s fun!”.

In order to implement a Share Source Contract I added an event listener to the DataTransferManager’s “datarequested” event, which gets called when the user opens the Share charm. My event listener code then populates the DataPackage with information that the Share Charm will display.

var mgr : DataTransferManager =
mgr = mgr.getForCurrentView();
mgr.addEventListener("datarequested", onDataRequested, false);
private function onDataRequested(e:DataRequestedEventArgs) : void
  var txt : String = "Hey, check out Pew Pew. It's fun!"
  const request : DataRequest = e.request;
  const data : DataPackage =; = "Tell your fellow Earthlings:"; = "\"" + txt + "\"";


For more details about implementing the Share Source Contract please see the documentation for DataTransferManager and DataPackage.


Roaming Data Storage

Jensen Harris says: “Roam to the Cloud”. In the context of Pew Pew that meant that if I stored the app settings and the current game state (high score, current score, lives, and wave level) into the cloud I could in theory interrupt a game on one device and continue where I left off on a different device. That would be cool!

I added an event listener to the application’s “checkpoint” event, which gets periodically called and when the app is being quit or suspended. My event listener code then writes out the app’s settings using ApplicationData.roamingSettings.

const app : Application = WinJS.Application;
app.addEventListener("checkpoint", onCheckPoint, false);
private function onCheckPoint() : void


In order to access the roaming data storage in writeSettings I had to query the roaming settings from the ApplicationData

const applicationData : ApplicationData = Windows.Storage.ApplicationData.current;
const roamingSettings : ApplicationDataContainer = applicationData.roamingSettings;
propertySet = roamingSettings.values;
propertySet["highScore"] = highScore;
propertySet["leftHanded"] = leftHanded;
propertySet["score"] = score;
propertySet["lives"] = lives;
propertySet["wave"] = wave;


For more details about using roaming data storage please see the documentation for ApplicationData and ApplicationData.RoamingSettings.


Pause and Resume

I translated “Feel connected and alive” to “Be interruptible: pause and resume”. In other words, Pew Pew needed to pause if Metro brought up the App Bar, Charms, or suspended the app, or switched to a different one. It turned out that the best way of doing that was by adding an event listener to the window’s “blur” event, which gets called when the user opens a Charm or the App Bar – in general: when Metro interrupts your app. My event listener code simply pauses the game by displaying a (crummified) Pause button, which resumes if the user presses the button.

const domWindow : DOMWindow = adobe.globals;
domWindow.addEventListener("blur", pause, false);
private function pause() : void
  // pause the TickManager
  const tm : TickManager = TickManager.getInstance();

  // dim the game area
  const currentView : GameSprite = viewManager.getCurrentView();
  currentView.alpha = 0.4;

  // add the pause button to the view
  pauseButton = createPauseButton();
  pauseButton.addEventListener(MouseEvent.MOUSE_UP, onResume, false);


onResume() does the reverse (remove the pause button, undim the game area, and start the TickManager).

For more details about observing interrupt events please see the documentation for onblur .


Pew Pew, release candidate

Everything came finally together on Friday evening. This was my release candidate: I integrated a new, crummified joystick and all of my Metro features (Tiles, view states, settings, share, roaming data storage, and pause and resume) were in. It was time to let my friend Christina Storm have another look at this much improved version. Her first video that recorded her first attempts to play the game  was pretty devastating. This release candidate had to work for her, or I was doomed.

Fortunately everything worked out great as you can see in Christina’s second video. She even completed a wave!


Release the Kraken!

On Saturday I tested Pew Pew thoroughly and fine tuned a few minor things. On Sunday I submitted Pew Pew just in time and 6 hours before the deadline. The whole process of submitting a Metro app couldn’t be easier. I actually started the submission from within Visual Studio 11 via a menu item that said something like “Submit to the App Store”.

Once Pew Pew was in the App Store I could observe the different stages the app went through. The longest wait time was about 5 days for “Content Review”. Since my submission was part of the Windows 8 First App Contest I received a friendly email from Microsoft’s staff to let me know that the finalist would be announced a week later on Sunday, 1/15/2012.

I was fried. The last two weeks were pretty exhausting. I almost didn’t care about the outcome of the First App Contest. I was just glad it was over. Even though I just returned from Adobe’s 2 week holiday break (which I partially used for working on Pew Pew) I was ready for more vacation.

Fortunately my 15 year sabbatical of six weeks was coming up in February.



Pew Pew Chronicles: Ready, Steady, Go!

This is part five of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha in December 2011 I learned about Metro and got immediately hooked.  After installing Windows 8 Developer Preview and playing with Metro I discovered that I could even cross-compile Pew Pew to Metro. But there was a problem: this game was “crappy”, not “charmingly crummy” and unsuitable for submission to the Windows 8 First App Contest. My Death March Plan boiled down to improving Pew Pew first before implementing Metro features. This all had to be done in 10 days.


Improving Pew Pew

I started the morning of 12/26/2011 with drinking an almost poisonous amount of coffee to get my blood moving. I knew I had a lot of things to do before I could submit Pew Pew to the app store by 1/8/2012. These were the features I needed to get done by 1/1/2012:

A. Improving Pew Pew WAG 
1. Resizable Game Area 8h
2. Replace game controller with analogue joy stick 10h
3. Use hand-written looking font, rather than Helvetica 8h
4. Roll-overs on buttons 2h
5. Redesign start screen 3h
6. Add health bar 3h
Total: 34h

On 1/1/2012 I would then decide whether it would make sense to continue, or drop out of the contest.


Resizable Game Area

The original Pew Pew version was designed as a prototype game for mobile devices and used a fixed size of 320 x 480 pixels for the game area. If you resized the browser window the game area would still stay at that size. In order to fix this problem I added an event listener that attached to the document’s window and observed the onresize event. When my event listener got triggered I resized the game area and notified every game object (ship, enemies, UFO, chaser etc.) of the boundary changes. I made a note that the size of the game objects should also change depending on the size of the game area. If the game area was 320 x 420 or smaller I wanted to use small images, otherwise I wanted to use bigger images.


Hover Ball

In the original Pew Pew version the game controller was a circle with a line in it that indicated the direction of where the ship was heading. The game controller was mirroring mouse movements. As you moved the mouse the line in the game controller would spin around similar to a steering wheel. I decided that this game controller had to be replaced with something like a joy stick as Ian Lobb suggested in his code review of Pew Pew.

I thought, why not introducing a new kind of joy stick? A ball that hovers over a pad. Yes, that would be the joy stick of the future! You would control the Ship’s movements by moving a hovering ball in different directions. If you released the mouse the ball would snap back to the middle of the Hover Ball Pad. If you dragged the ball further away from the pad the ship would accelerate. Not being able to accelerate/decelerate the Ship was one of the main complaints Ian Lobb had about the game controller. The Hover Ball would solve all of those problems and it would look cool, too.

Fortunately switching the original Circle game controller over to the Hover Ball  turned out to be easier than I thought. So I moved on to other problems.



The original Pew Pew used flash.text.TextField controls for everything that had text on it: the start screen, the score bar in the game area, and the screen between level changes that said “Wave completed!”. Every button was a flash.display.SimpleButton, which internally uses a TextField.

TextField’s default font is Helvetica and I wanted to change that and use hand-written fonts throughout the game (which Ian Lobb had also suggested). Now, you can set any font you like via TextField.defaultTextFormat and flash.text.TextFormat . But the problem is that not every platform has every font. In order to avoid this dependency I used Photoshop: First I created a new text box, then I set the font to a font I found named “Handwriting Dakota” and wrote the text I wanted to display. Finally I exported my text as a PNG image file.

In Pew Pew I then replaced TextField and SimpleButton with my own classes that loaded my handwritten text image snippets. This was very tedious work, which I usually did in the evenings while watching TV.



The original Pew Pew version used SimpleButton, which are rather ugly rectangles with Helvetica labels. I had to replace those with my own buttons with handwritten text image labels and round “crummy” corners. I also added support for roll-over states: over, down, and up. In other words I created three images for each button using Photoshop.


Start Screen

The original Start Screen was just hideous. I completely redesigned it using handwritten text images and added a line that gave credit to Mike Chambers with a link pointing to Pew Pew’s github depot. I made a note that if the URL should probably be implemented as a real link if there was time left.


Health Bar

Pew Pew’s original game area displayed some sort of score bar at the top showing the number of lives you had left and the points you had accumulated including the level (“wave”) you had reached. My plan was to replace that score bar with a crummy looking Health Bar with three sections: Ship symbols for the lives left plus two number wheels for the points and the current wave level.



When I reached the checkpoint on 1/1/2012 I was pleased. I had implemented most of the Pew Pew improvements I needed and I made great progress on my Metro features (more on Metro features in my next post).  Not everything was entirely done and my list with notes of things with what I should add if there was time left also grew disturbingly long. I hadn’t started with the Health Bar yet, and the button labels were all still in Helvetica. But the bottom line was encouraging. Pew Pew didn’t look crappy anymore. I liked the direction this was going. I decided: No need to drop out, everything was under control.

It was time to get some feedback from other folks. Just by coincidence I met my friend Christina Storm at a coffee shop to discuss a project we were working on and I told her that I wouldn’t have much time, because I had been working on this “stupid game”. After telling the whole story Christina generously offered her help. She said: “Don’t worry about our project. Why don’t you send your game over to me and I’ll play with it? You probably need some testers.” That was exactly what I needed.


Straight To Video

Knowing that Christina would test the game and give me feedback encouraged me to work even harder on Pew Pew. On 1/3/2012 I threw my first alpha version over the fence. It took Christina only a few hours to reply. She did something really wonderful by creating a video that recorded her first attempts to play the game. As she was describing what she was seeing and how she was thinking Pew Pew would work it became quickly clear that my Hover Ball turned out to be not such a brilliant idea. On video I could see that she was trying to move the Ship with the mouse. First she tried dragging the ship, which didn’t do anything. Then she suspected that that ball in the right corner might have something to do with steering the ship and fiddled with that. When she dragged the Hover Ball the ship suddenly moved. But the movements of the ship were jerky and seemed unrelated to the movements she applied to the ball. This was a disaster. Towards the end of her video recording Christina was very frustrated. Her Ship got destroyed numerous times, because she couldn’t figure out how to navigate it. She felt like a sitting duck. The game sucked.


Morituri Te Salutant

It was Monday and before watching Christina’s video I thought I was well on track for freezing Pew Pew on Friday, which would give me enough time to test the game on Saturday before submitting it to the app store on Sunday, the dead line for the Windows 8 First App Contest. In this week I was planning on implementing all of those Metro features.

But now I had to redesign a new joy stick and there were still a few features missing. To make things worse this week was a very busy first work week in 2012. In my original plan I set my capacity for the first work week to 3 evening hours. I was looking at 9 hours for Tuesday to Friday in order to get Pew Pew back on track.

Implementing a joy stick plus the rest of the Metro features in 9 hours? That was perhaps a little bit too ambitious.







Pew Pew Chronicles: Planning A Death March

This is part four of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha in December 2011 I learned about Metro and got immediately hooked.  After installing Windows 8 Developer Preview and playing with Metro I discovered that I could even cross-compile Pew Pew to Metro. But there was a problem: this game looked crappy.


Reality Check

On 12/25/2011 my wife and I were returning to Seattle after a restful week in Omaha, which ended with a harsh wake-up call. Pew Pew for Metro in its current form was “crappy”, not “charmingly crummy” and unsuitable for submission to the Windows 8 First App Contest. The deadline for submitting apps for the contest was on 1/8/2012 and only two weeks away with one of those two weeks being my first work week in the new year. I realized I had to be very disciplined and focused in order to turn Pew Pew into a game worth submitting to the contest.

As we were entering the airplane I am laying out the plan for my Death March in my head:

  1. Damage report
  2. Research & extracting features
  3. WAGs
  4. Prioritizing features
  5. Implementation!
  6. Debugging & testing
  7. Release Candidate
  8. Contest Submission.

Most developers feel tempted to immediately start with #5 and then see where everything is going. But I knew that given my tight schedule starting with implementing small improvements would have been the safest way to end up with an even crappier version of Pew Pew. Over time I learned (often the hard way) that one has to follow those steps no matter how little time is left. First I needed to understand what was exactly wrong with Pew Pew.


Damage Report

Ian Lobb wrote a great code review of Pew Pew, which gave me some good pointers for improving Pew Pew:

  • Use hand-written looking font, rather than Helvetica
  • Joystick doesn’t allow you to set speed, only direction. A simulated analogue stick would have been nicer.
  • Movement of the ship is not very graceful
  • Speed of the bullets is way too slow
  • Collision detection between the bullets and enemies is inconsistent
  • There are no roll-overs on any buttons
  • There aren’t any transitions between screens
  • The enemies bounce around the screen like asteroids, but they are UFOs.
  • Use a health bar rather than instant death.
  • Create a scrolling world.
  • Add basic physics like momentum
  • Allow pausing the game
  • Add particle effects for trails and explosions

Ian’s list was already depressingly long. But I had to add one very important missing feature:

  • The game area needs to be flexible and adjust to orientation and size changes.

I could have just taken that list and started fixing those problems until the deadline arrived. But as I mentioned before it is worth stepping back and spending a few extra cycles on what exactly needs to be done.


Research and extracting features

This second step is about finding ways to fix what is wrong. In my case: How do I get from “crappy” to “crummy”?

It was clear to me that I  had to dramatically improve the game in order to avoid being kicked out in the first round of the First App Contest. But I also had to add as many Metro features as possible, because the fine print of the First App Contest rules clearly said that every app would be judged by how much it embraced the Metro Style guidelines. I hoped that even a borderline crappy Pew Pew game could make it into the next round, if it supported a lot of Metro features, because that’s what the contest was all about.

It was time to revisit Jensen Harris’s session about 8 traits of great Metro style apps. After all Jensen was one of the three First App Contest judges – I better listened to what this guy had to say about Metro apps. But even after watching Jensen’s talk a second time I felt that everything was a little bit too high-level and philosophical. I needed something closer to my daunting task at hand. So I came up with this table, in which I tried to translate Jensen’s “fluffy” Metro Style Trait definitions to 8 Commandments I was determined to follow in order to avoid eternal condemnation in Metro hell:


Metro Style Trait Commandment
1. Metro style design “Align to the grid.”
2. Fast and fluid “Optimize with the Closure Compiler.”
3. Snap and scale beautifully “Honor the View States.”
4. Use the right Contracts “Implement Settings and Share Source.”
5. Invest in a great Tile “Provide wide and small Tiles.”
6. Feel connected and alive “Be interruptible: pause and resume.”
7. Roam to the cloud “Store app settings into the cloud.”
8. Embrace Metro principles “Do all of the above!”


I reduced those Metro Commandments even further down to these Metro features that I wanted to add to Pew Pew:

  • Tiles (wide, small, live).
  • View States (snap view, landscape, portrait).
  • Settings Charm.
  • Share Source.
  • Roaming Data Storage.
  • Pause and Resume

Now that I boiled everything down to a list of six Metro features I could start thinking about pricing those features.



After identifying features for improving Pew Pew it was time to put some price tags on those features. Here at Adobe this process is often referred to as “wagging”. What does WAG stand for? Well, most people here at Adobe (including this author) think that WAG is an abbreviation of “wild a** guess”. Truth is, that during project planning nobody expects developers to generate precise estimates for tasks involving problems they don’t know yet how to solve. I often hear this joke where WAGs delivered by developers should be adjusted by increasing the time unit. “It takes 1 hour” becomes “it will take 1 day“, “it takes 1 day” becomes “it will take 1 week“, and so forth. Estimating tasks precisely is very difficult. My personal goal is trying to deliver within 10% of my WAGs. Do I hear some PMs laughing? – At least I am trying!


Prioritizing features

I decided to separate two distinct phases:

A. Improving Pew Pew WAG 
1. Resizable Game Area 8h
2. Replace game controller with analogue joy stick 10h
3. Use hand-written looking font, rather than Helvetica 8h
4. Roll-overs on buttons 2h
5. Redesign start screen 3h
6. Add health bar 3h
Total: 34h


The second phase would be all about implementing Metro features:

B. Adding Metro Features WAG 
1. View States  (snap view, landscape, portrait) 8h
2. Tiles (wide, small) 1h
3. Settings Charm 8h
4. Share Source 8h
5. Roaming Data Storage 4h
6. Pause and Resume 4h
Total: 33h


By having two separate phases and starting with just improving the game I was hoping to save time, because improving the game didn’t require me to work in Windows 8 and Metro. Picking a development environment consisting of ActionScript, Flash Builder, my cross-compiler, and the browser allowed me to implement features very quickly at a low bug regression rate. Flash Builder caught syntax errors and debugging was easy in the browser. I would argue that one cannot implement large projects under massive time constraints in JavaScript alone. It would be like implementing Photoshop in Assembler in, say, six weeks . Not that implementing Photoshop in six weeks would be possible in any language. But if you really had to try, you wouldn’t pick Assembler. Being able to cross-compile from a high-level language to JavaScript was a crucial element of my plan.

In addition to having two separate phases I also decided to set a check point after the first phase. If I were too far behind I would cut my losses and drop out of this crazy race. In my opinion you have to know your own limits which includes that you know when you are beaten.


La Quenta, Por Favor

I was finally ready to add up all the numbers: it was 12/25/2011 and the Fist App Contest deadline had been set to 1/8/2012. I was travelling on 12/25 and I reserved 2 days at the end of that period to wrap up things, test, and submit Pew Pew to the store. That left me with 10 days, or 80 hours assuming a regular work week (Mon-Fri, 8 hours per day). But this wasn’t a regular project and the first week at work in the new year is never a regular work week. So I added the weekends back in (+4 days=32) but reduced my capacity for the first week at work in 2012 from 8 hours to 3 evening hours per day. That gave me roughly 76 hours (12/26 to 1/2: 8 days at 8 hours; 1/3 to 1/6: 4 at 3 hours). My WAGs totaled 67 hours. That was awfully tight. After Adobe program manager adjustments (“increase WAGs by one time unit”) the ETA for this project was 67 days and not 12.

My checkpoint after the first phase, which I wagged at 34 hours, would be in roughly 4 days. In other words at around New Year’s Eve 2011 I would know whether Pew Pew would see the light of the Metro Store, or not.

There was only one way to find out whether this was an insane plan…




Pew Pew Chronicles: From Flash To Flex

This is part three of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha in December 2011 I learned about Metro and got immediately hooked.  After installing Windows 8 Developer Preview and playing with Metro I was surprised to see a simple cross-compiled app running in Metro without any problems. Would it be possible to get even more complicated apps like Pew Pew up and running in Metro?


Digging out an old prototype

It only took me a few minutes to find that old prototype I wrote in February 2011 to convince skeptics within Adobe that you can  cross-compile a game from ActionScript to JavaScript. There it was: Pew Pew, a cute space shooter game originally written by a Mike Chambers, a colleague of mine. The version that Mike open sourced  Pew Pew in 2011 at github was pretty much the same I had used for my prototype. But I had to do a few important adjustments back then before I could cross-compile Pew Pew to JavaScript.


Converting from Flash to Flex

In Pew Pew’s github depot you will notice a file called Main.fla, which is a Flash IDE project file. If you open Main.fla with the Flash IDE you might be surprised to see that there is really nothing going on in this project. There is only one key frame, which kicks off the game through adding an instance of Main to the stage. Somewhere in Main.fla there is also one transition for animating explosions. Most of the logic is in a cluster of ActionScript files that contains code which gets attached to Symbols defined in Main.fla. (For more details about Pew Pew’s project I recommend reading Ian Lobb’s code review of PewPew.)

Later I learned that many games are written that way: one frame, a few transitions, a bunch symbols, and the rest is all ActionScript code. I can see why many developers prefer this kind of Flash Pro setup, because using Symbols in combination with ActionScript code is very convenient. You would have to do a lot more extra work in order get the same game running in Flex. Herein lies the problem, though. From a Flex developer’s point of view ActionScript code from Flash projects often appears incoherent and messy. The part that Flash Pro is adding to SWFs may seem convenient. But to me (and I suspect many other developers coming from the Flex world would agree) all that “magic” that Flash adds is just opaque. In many cases ActionScript code recovered from Flash project doesn’t even compile.

Back in January 2011 it quickly became clear to me that before I could cross-compile Pew Pew from ActionScript to JavaScript I had to convert the original Pew Pew Flash project into a coherent Flex project. In other words, first I needed to be able to create a Pew Pew SWF from a Flex project. You simply can’t compile incoherent code. Your compiler will (and should) throw compile errors if it detects inconsistencies. I realized, my job was adding that missing “Flash Magic”, that hidden extra code that game developers are fond of not having to worry about.


Implementing Flash Magic

You might think that you can easily convert a Flash project to a Flex project just by importing those ActionScript files and compiling everything. That’s unfortunately not the case. There are a few weird things I call “Flash Magic”, which Flash Pro adds to the SWF in order to make everything work. The two most important oddities every Flex developer needs to know about Flash projects are automatic instantiation of symbol members, and automatic promotions of local variables to members. Both concepts seem utterly counterintuitive and unnecessary to me. But that doesn’t matter. It’s part of reality and one has to deal with it. Fortunately automatic promotions of local variables to members didn’t seem to be a problem in Pew Pew. So let’s focus on automatic instantiation of symbol members and have a quick look at :

public class Main extends MovieClip
  //instantiated within FLA
  private var gameArea:GameArea;

  //main game menu view
  private var gameMenu:GameMenu;
  public var background:MovieClip;
  //main entry point for applications
  public function Main()
    //note stage quality is always set to best in Adobe AIR. Have it
    //set to HIGH here in case we are running in browser
    stage.quality = StageQuality.HIGH;
    stage.align = StageAlign.TOP_LEFT;
    stage.scaleMode = StageScaleMode.NO_SCALE;

    //listen for when we are added to the stage
    addEventListener(Event.ADDED_TO_STAGE, onStageAdded, false, 0, true);

    //cache bitmap so it can be accelerated
    background.cacheAsBitmap = true;

    //dont need mouse events on background, so disable for performance
    background.mouseEnabled = false;
    background.mouseChildren = false;



You will probably agree with me that the code above as it has been checked into github looks very suspicious. Our Main class declares a background member of type MovieClip. Then Main’s constructor code uses background before it has been created. Where is the code that does “new MovieClip()” ? You won’t find it, because it is part of the “Flash Magic”. If you open Windows/Library in the Flash IDE you will find an entry for Background. As far as I know Flash automatically instantiates class members if they are listed in the Library.


Adding a SymbolManager

In order to convert the code in Main’s constructor to proper, coherent ActionScript I had to add these two lines:

  //main entry point for applications
  public function Main()
    if( !background )
      background = SymbolManager.instance().createBackground();


By doing so I could use the same ActionScript code in Flash and in Flex. In the Flash version the background member would be automatically instantiated but in the Flex version we would instantiate background manually. I could have initialized background with just “new MovieClip()”. But I decided early on to encapsulated all the work for emulating “Flash Magic” into one class, which I named SymbolManager.


Lost in space

Some symbols like Ship have an initial transform, that SymbolManager also has to emulate. For example if you select GameItems/graphics/ship_graphic in Flash IDE’s Window/Library and observe the Transform panel you’ll notice that Ship is rotated by 90 degrees and also scales x and y axis by about 51.8%. The Info panel tells us that the initial x/y positions are set to 0.0/0.0.

Unfortunately I didn’t find the values that the Flash IDE gave me very reliable. In order to get correct values I had to export my symbols to FXG (File/Export/Export Selection, format=FXG). The exported Ship.fxg for GameItems/graphics/ship_graphic was just an XML file and looked like this:

// Ship.fxg:
<?xml version="1.0" encoding="utf-8" ?>
<Graphic version="2.0" viewHeight="800" viewWidth="480"
 ATE:version="1.0.0" flm:version="1.0.0" d:using=""
    <Definition name="GameItems_graphics_ship_graphic"
      <Group pd:symbolType="1">
        <Group d:type="layer" d:userLabel="Layer 1">
           rotation="90" scaleX="0.51818848" scaleY="0.51817322" 
           source="@Embed('Ship.assets/images/ship_bmp.png')" fillMode="clip"/>
 <Group d:type="layer" d:userLabel="Selected Items">
   <GameItems_graphics_ship_graphic x="-12" y="-15.35"/>


As you can see rotation and scale values are listed as attributes of the BitmapImage tag. The interesting part is in the GameItems_graphics_ship_graphic tag, which is the container of the ship image. That container tag sets x and y to -12 and 15.35. You will never find those values in the Flash IDE. But they are very important in order to correctly set up the initial transform.

With the FXG information I was able to implement SymbolManager.createShip() and onShipLoaded, which gets called when the ship bitmap has been loaded:

private function onShipLoaded(e:Event):void
  const bitmap : DisplayObject = getBitmapFromEvent(e);
  if( bitmap )
    bitmap.scaleX = 0.51818848;
    bitmap.scaleY = 0.51817322;
    bitmap.rotation = 90;
    bitmap.x = -12; bitmap.y = -15.35;
    bitmap.width = SHIP_WIDTH;
    bitmap.height = SHIP_HEIGHT;
    _removeEventListenerFromTarget(e, onShipLoaded);


There were a few other minor things I had to adjust in the Pew Pew. But I was eventually able to create a Pew Pew SWF from Flex. Once I had a coherent Flex project it was pretty easy to cross-compile Pew Pew to JavaScript.


A fine line

In the end it took me about three days to reanimate the old Pew Pew prototype with the latest version of my cross-compiler. Along the bumpy way I fixed a bunch of regression bugs and a few new ones as well. It was quite a moment of victory when I hit the debug button in Visual Studio 11 and Pew Pew finally worked in Metro. I thought, if I put in a little bit of work I might be even able to submit this game to the Windows 8 First App Contest I had just read about.

Being able to cross-compile that old Pew Pew prototype to Metro was a big accomplishment for me, which I wanted to share with my wife, who was sitting right next to me. The conversation that followed went like this:

Me: Hey, I got Pew Pew up and running in Metro!
She: That’s great, let me see.
Me: Here it is. It needs a little bit of work, though. I am thinking of submitting it to the contest.
She: You will never win the contest with something like that.
Me: What do you mean? The graphics? It’s supposed to look crummy. It’s charming.
She: There is a fine line between “crummy” and “crappy”.

I knew I was in trouble. Cross-compiling ActionScript to JavaScript was one thing, developing a cool game that is not crappy is a completely different beast I would have to tame.




Pew Pew Chronicles: Hello, Metro!

This is part two of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha I learned about Metro and got hooked. I decided to dive into Metro at around 12/20/2011.


Setting up Metro on a Mac

After a few relaxing days of catching up with my in-laws and eating way too much good food it was time to get my hands dirty with Metro. I only brought my MacPro laptop to Omaha. So how does one install Microsoft’s Windows 8 Developer Preview on a Mac? This is how I did it:

  1. I downloaded the Windows 8 Developer Preview ISO file (which is not available anymore, instead just use Windows 8 Consumer Preview).
  2. I created an empty vmware image and installed Windows 8 from the ISO file through vmware’s CD drive emulator.
  3. I took a snapshot called “Windows 8 Developer Preview”

This may surprise you, but I would have done the same on my Windows machine at work. I highly recommend sandboxing new operating system versions that are under development with virtualization software like VMware or VirtualBox. This method just saves you many troubles. Take many snapshots and just roll-back if things get too messy (as things tend to during software development).


Launching Metro

Then I launched Windows 8 in my sanitized vmware sandbox and made myself familiar with my new environment. Metro reminded me of Windows 7 for phones. It was all very “touchy.” I have to admit, at first I didn’t like the Tile metaphor. Tiles remind me of bathrooms and hospitals. They break into shards when they hit the ground and they are cold unless you have heated floors. I know, UI design is more difficult than one thinks it is, but I wondered, why didn’t they choose something organic like Leaves instead? Perhaps even Pillows?


Developer Tools

As far as I can remember Windows 8 Developer Preview from September 2011 came with Visual Studio 11 Express pre-installed. In case you run the latest Windows 8 Consumer Preview you need to install the Developer Tools and SDK with Visual Studio 11 Express Beta in a separate step. VS 11 looks pretty much like the previous versions except for a few new options like creating Metro Style JavaScript App projects. This all looked pretty encouraging. I was eager to write my first Metro Style App, Hello World.


Hello, Metro

Of course, I had no idea how to write a simple Hello World Metro Style app. So I downloaded the Windows 8 Sample Pack and looked for a Hello World sample. There was one example called “DirectWrite hello world sample.” But that didn’t look  simple at all. I believe I ended up picking the “App tiles and badges sample” and built it. When I hit the debug button VS linked the app, deployed it to Metro and launched it without problems. That was easy.

Just for fun I decided to create a blank Metro Style JavaScript App Project and sniff around a little bit. VS 11 created a bunch of files, one of them was named default.html, which included default.js . That had to be the entry point! Sure enough, when I opened default.js I saw that WinJS.Application.start() brings the app to life, which would eventually trigger the call to WinJS.Application.onactivated – a function that I could, for my convenience, override:

// default.js
(function () {
  "use strict";
   var app = WinJS.Application;
   app.onactivated = function (eventObject) {
     if (eventObject.detail.kind ===
         Windows.ApplicationModel.Activation.ActivationKind.launch) {
       if (eventObject.detail.previousExecutionState !==
           Windows.ApplicationModel.Activation.ApplicationExecutionState.terminated) {
         // TODO: This application has been newly launched. // Initialize your application here.
       } else {
         // TODO: This application has been reactivated from suspension.
         // Restore application state here.

   app.oncheckpoint = function (eventObject) {
     // TODO: This application is about to be suspended. Save any state
     // that needs to persist across suspensions here. You might use the
     // WinJS.Application.sessionState object, which is automatically
     // saved and restored across suspension. If you need to complete an
     // asynchronous operation before your application is suspended, call
     // eventObject.setPromise().


In order to test my theory that onactivated() would be eventually called towards the end of the launch sequence I added a trace statement to WinJS.Application.onactivated:

   app.onactivated = function (eventObject) {
     if (eventObject.detail.kind ===
         Windows.ApplicationModel.Activation.ActivationKind.launch) {
       WinJS.UI.processAll(); "Hello, Metro" );

There it was in my debug console: Hello, Metro.



For an hour or so I just browsed through the samples until implementation patterns seemed to emerge then I decided to get serious about studying the Windows Runtime API. Fortunately Microsoft’s online API reference for Windows Runtime and Windows Library for JavaScript documentation for Metro was (and still is) excellent.

I noticed two namespaces: Windows.* and WinJS.* . Apparently, the Windows.* namespace corresponds to Windows Runtime, which “is designed for use with JavaScript, C#, Visual Basic, and C++”. The WinJS.* namespace on the other hand refers to “the Windows Library for JavaScript is a set of JavaScript and CSS files that make it easier to create Metro style apps using JavaScript”.

I was feeling ready to try running a simple cross-compiled app. Why not SpriteExample?


SpriteExample for Metro

One of the first ActionScript apps (if not the first one) I ever cross-compiled to JavaScript was . I simply imported my cross-compiled SpriteExample.js into the empty “Hello, Metro” project and made a small change:

// Original SpriteExample.js
 (function(__global) {
// Modified SpriteExample.js
function loadSpriteExample(__global) {

This change allowed me to defer the load sequence of my SpriteExample. I wanted to load SpriteExample at the end of app.onactivated, where I had put my trace statement:

  app.onactivated = function (eventObject) {
     if (eventObject.detail.kind ===
         Windows.ApplicationModel.Activation.ActivationKind.launch) {

The only step left was adding a script tag to default.html, which loads SpriteExample.js:

<script src="/js/SpriteExample.js"></script>

Frankly, I was shocked when I saw SpriteExample running in Metro without problems.

This all was way too easy. Could it be that it was in fact super easy to develop Metro Style apps using ActionScript and my cross-compiler? I had to try a more complicated project. I was convinced, at one point reality would stop me from doing what I was doing. So I chose Pew Pew as my next project…




Pew Pew Chronicles, December 2011

This is part one of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. It all began in December, 2011…


Attention Earthlings!

If you download and install Microsoft’s Windows Consumer Preview of their upcoming Windows 8 operating system and click on the Store button you will find a rapidly growing number of apps. One of them is a game called Pew Pew, which I submitted for the First App Contest. The description reads:

Attention Earthlings! This fun, retro space shooter game allows you to destroy enemy ships and UFOs from the safety and convenience of your home planet. Rack up points while protecting your planet from invasion.

Pew Pew was originally written by Mike Chambers, who is currently the Directory of Developer Advocacy for web platforms here at Adobe. In 2010 Mike published Pew Pew’s source code under the MIT license at github. The original Pew Pew version was written in ActionScript and in order to turn Pew Pew into a Metro app I had to solve three problems. First I downloaded the latest Pew Pew source code from github and cross-compiled Pew Pew’s ActionScript code to JavaScript. Then I improved the game and added Metro features before submitting Pew Pew to Microsoft’s App Store. This all happened in 9 weeks between 12/17/2011 and 2/17/2012.


Restless Developer Syndrome

Vacation! On 12/17/11 my wife and I hopped on an airplane in Seattle to visit her parents in Omaha. Those, who know me better, have accepted that I am one of those developers that always work – even on their vacations and honeymoon. I call it Rest Developer Syndrome while my wife thinks I am just a workaholic.

As in most cases, my wife is probably right, but still, in my opinion there is a difference between work and “work”. When I am on vacation I can finally catch up with all the new stuff that had come out in the past few months. That’s not work for me, that’s even more fun than my regular work! There was that //build conference that I missed in September 2011, when Microsoft revealed its new Windows 8 operating system with something completely new called Metro. Fortunately Microsoft made recordings of the keynotes and many talks publicly available. So I downloaded five or six of those videos and watched most of them during the long flight from Seattle to Omaha on my slow iPad.


Learning about Metro

I started with the keynotes, which seemed a little bit hectic as most keynotes usually are (only few deliver brilliant keynotes as Steve Jobs did). I did learn from those keynotes that Windows 8 would introduce a new user interface called Metro in addition to the “traditional” desktop. Only Metro style apps would run in Metro, they said, and developers would be able to write entire apps in JavaScript, because Metro’s JavaScript API would allow developers to access the operating system through a new, unified Windows Runtime layer. In Windows 8 you could only install Metro apps through Microsoft’s new App Store. That’s how developers would make money (and Microsoft would make a few pennies, too).

I didn’t mind seeing Microsoft try to catch up with Apple and Google by opening their own App Store. I love competition, I love Freedom of Choice! What really intrigued me was that I could access the operating system through Metro’s JavaScript API. I had been cross-compiling a lot of complex ActionScript projects for almost a year and by December 2011 I had become a fearless gladiator. The biggest limitation when cross-compiling ActionScript to JavaScript was the browser and its DOM. For example, there was (still isn’t) any way to access the camera from JavaScript unless you used something like PhoneGap. If it were really true (as Microsoft promised in the keynotes) then Metro would open a gigantic candy store right in my own neighborhood: access to the OS layer. I definitely wanted to learn more about Metro.


Eight traits of Metro style apps

Still on the plane to Omaha I next picked Jensen Harris’s talk about 8 traits of great Metro style apps. Those eight traits are:

  1. Metro style design
  2. Fast and fluid
  3. Snap and scale beautifully
  4. Use the right Contracts
  5. Invest in a great Tile
  6. Feel connected and alive
  7. Roam to the cloud
  8. Embrace Metro principles

Jensen’s talk walks you through each of those traits and frankly, I was surprised. Something was really different with this guy and Metro itself also seemed different from what I had expected. I had to watch another talk about Metro.


Designing Metro style: principles and personality

The next talk I picked was Samuel Moreau’s talk about Designing Metro style: principles and personality and this one just blew me away. Sam, who is a director at UX Design and Research at Microsoft, explains the background and inspirations for Metro style design. He identifies three key influences:

  1. Modern design (Bauhaus)
  2. International Typographic Style (Swiss Design)
  3. Motion Design (Cinematography)

Sam’s talk really opened my eyes. I realized, that Metro is not some flashy technology tacked on to a mature operating system (the lipstick on the pig if you will). Instead I had to look at Metro as a new paradigm.  The gladiator in me knew that cross-compiling ActionScript projects to Metro wouldn’t be as easy as I thought it would be. Bringing some cross-compiled JavaScript up and running in a new environment alone won’t do it for Metro. Metro is a different beast.


A New Microsoft?

Jensen Harris and Samuel Moreau really surprised me in many ways and it took me a while to put my finger on what it was. Their talks were interesting and I didn’t feel lectured to at all. Instead of past attitude, I sensed a human side that I found refreshing. Those guys seem to be normal people and their reasoning resonated with my way of thinking and cultural values.  I wondered, is there maybe a new breed of developers and managers like Jensen and Sam emerging within Microsoft? Perhaps there is a New Microsoft forming within the Old Microsoft? One can only wait and see.


Ground Rules

By the end of our flight to Omaha I have already decided to dive into Metro. But I also wanted to spend the holidays with my wife, who I love very much, and her wonderful family. So I came up with these ground rules for my new Holiday project: I should not work more than 3-4 hours a day on this, or any project that involved me being emerged with my laptop.