I’ve seen a few people complaining about and/or questioning the lack of mature tools to develop content for the modern web (aka HTML5), and it got me thinking about the evolution of these tools, and how challenges are solved for technology platforms in general.

In my (albeit limited) experience, there is a natural progression for a maturing technology stack, particularly one without a single master (ex. Flash and iOS development differ somewhat because the tools and platform are directed/developed by the same entity).

First, you will see the development of a lot of frameworks, starting with micro-libraries that address a single challenge, and evolving to macro-frameworks like JQuery that tackle an entire workflow. Developing frameworks has a very low barrier to entry, and provides an ideal way for developers to explore and share a variety of potential solutions for challenges. Because the libraries are written in the domain language, it also means that any developer encountering a problem can address it directly with a language they are familiar with.

As problems become better defined, and specific solutions begin to emerge as more dominant, you start to see single purpose tools created, often as command-line utilities. These have an increased investment compared to frameworks, and require that the developer has knowledge of both the problem domain, and basic desktop development.

Next, you will see partial workflow tools, which aggregate and leverage the single purpose tools (either directly, or by borrowing approaches). These put a UI on top of a number of solutions to make them more accessible to users. Again, these involve increased investment, and require additional capability (UX/UI design, more advanced desktop development).

Finally, you will see the emergence of full-scale workflow tools. These represent a major investment, generally require a team of specialists to create, and are built over the course of months or years. As such, they need to build on top of standards, approaches, and frameworks that have been well vetted by real-world use. Even then, their early releases will be limited, and will require a huge amount of community feedback and multiple revisions to “get it right”. With this in mind, early release with rapid iteration is a critical practice for any tool that aims to be successful in this space.

As an aside, code editors tend to follow an accelerated path, simply because the problems they are solving are less tied to a specific technology platform, and have been thoroughly explored for other languages.

Of course, none of these steps happen in isolation. In the JS world, you can see all of these underway simultaneously. There is an unending stream of new frameworks, as developers explore challenges, with a number of more mature ones gaining traction. There are a number of popular single-purpose tools (ex. LESS, Closure Compiler, Zoë). There are a few partial workflow tools (ex. CodeKit). And finally, there are a number of early entries in the more robust tool category (Edge, Sencha Animator, Flash Pro’s Wallaby, etc).

Further, this evolution is massively complicated and slowed in the HTML/JS world by the constant flux of the technology, the non-trivial issue of supporting multiple browsers/platforms, and the question of legacy support. Tool makers need to wait for a standard (or more frequently, a collection of standards) to stabilize and be broadly adopted/accepted before they can risk the investment to build on top of it.

This is obviously a simplified look at the problem, but hopefully helps illustrate where things are today, and why we don’t have access to fully mature tools for HTML5 development yet. They are coming, but it’s going to be an incremental process.

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

I’m very happy to announce that I’ve pushed major updates to a number of our javascript tools and libraries for developing rich content with HTML5. It’s very exciting for me to see these starting to realize some of the vision I’ve had for them over the past year, both as individual pieces and as a suite of tools to make great interactive content using web standards.

Here’s a quick breakdown of what was released:

EaselJS v0.4.0
The latest release of EaselJS (our HTML5 display library) has a completely reengineered sprite sheet engine, which includes a host of new features: multi-image sprite sheets, variable frame dimensions, frame reuse, image preloading, and a new data format. Note that this change will require some minor updates to existing content using sprite sheets in EaselJS.

We’ve added filter effects, and a few sample filters, including a box blur filter by Mario Klingemann, who has agreed to write a number of other filters for the library.

There’s also a fantastic new build system, built on top of Node.js by Adobe’s own Mike Chambers. And, of course, a whole pile of other feature additions, optimizations and bug fixes. Check the VERSIONS file for full details.

Zoë v1.5.0
We’ve released a major update to Zoë, our tool for exporting sprite sheets from SWF animations. It supports EaselJS’s new data format, and adds some great new features like variable frame dimensions with more optimal rect packing, and intelligent frame reuse. The latter allows you to set a threshold for how similar frames can be, and Zoë will automatically remove similar frames and reuse them in animations. Testing on some old content, we saved 20-50% on file size with this feature, with virtually no decrease in animation quality.

This release was a bit more rushed than we would have liked, so you should expect to see a v1.5.1 release before too long that polishes things up and adds additional features such as multi-image export.

TweenJS v0.1.0
This is the first “official” release of TweenJS. TweenJS uses a simple API of chained commands to sequence tweens and actions to create complex animations and timed events. For example:

Tween.get(ball).to({x:200},500).wait(750).to({alpha:0,visible:false}).call(onComplete);

TweenJS makes a great companion to EaselJS, and also has some basic support for working with CSS properties, which will be extended in future versions.

SoundJS v0.1.0
This is also the first official release of SoundJS, our library for working with the HTML5 Audio tag. Sound in HTML5 is a complete mess to work with, and this library aims to make it a bit easier. It handles preloading, allows you to assign a fixed number of tags to a specific sound, provides volume control, and manages sound interruption.

This library is still a little rough, but we’re planning to continue to clean it up and add functionality (ex. WebAudio support) as time permits.

in summary
All of these projects are free and open source, released under the highly permissive MIT license, and are hosted on GitHub. I’d like to thank everyone who contributed to these releases, even if just by providing feedback or encouragement. Hopefully people find these useful in their own quests to build amazing content for the web!

As an aside, now that these releases are out of the way, I’m considering doing a series of posts or videos on getting started with some of these libraries. I think it would be particularly relevant as Flash developers start looking to create content in HTML5, and web developers look to create more interactive content.

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

By now, you’ve likely heard that Adobe has ceased development of the Flash Player for mobile browsers. It’s hard to miss – it has whipped the usual rabble of ill-informed techno-zealots into a screaming mass of vindictive idiocy. Sadly, this frenzy is being led by sensational headlines in the media, and snarky, self-congratulatory posts by leading tech pundits.

I don’t think I will ever understand the joy that apparently comes from dancing on the grave of a dead technology. One less technology means one less choice, and one less branch from which new innovation can spring.

And let’s be honest. A LOT of innovation has sprung from Flash. It opened a whole new class of web experience, birthed online casual gaming, defined rich UI, and heavily influenced many of the features that comprise HTML5.

Yes, Flash is proprietary, but that allows it to be agile. Yes, there’s an abundance of truly horrible Flash content out there, but that’s more a testament to its ease of use than its failings as a technology. I guarantee that if creating HTML5 content ever becomes as simple as with Flash, you will see a plethora of horrible HTML5 content (though hopefully some lessons will not be forgotten – RIP Skip Intro).

Flash is deeply flawed, but so is every technology. Hating it is popular, but seems to be based less on any rational analysis, and more on a self-sustaining anti-fanboism, and the sheep-like re-bleating of Jobs’ proclamations.

See, Steve Jobs was right. But then he was wrong. Very wrong.

As an iPhone user, I was initially in full agreement that Flash had no place on my phone. Flash Lite was crap, and there was no evidence that the full player could be made to run well on a device. I also didn’t have a burning need to view Flash content on my phone.

Then two things happened that shifted my thinking.

First, Adobe (eventually) proved that the Player could be viable on mobile with the Android plugin. They also made it optional. In my mind, that was ideal. It gave people a choice. I could choose not to enable Flash, or I could choose to only enable SWFs that I wanted to view. It seemed like the perfect compromise, and made me wish I had the same choice in iOS.

Unfortunately, Steve wasn’t known for compromise, so rather than either embrace this proven approach or simply maintain the status quo, he chose to lash out. His famous open letter on Flash was a mix of half-truths, hypocritical misdirection, and outright lies. I lost a lot of respect for Mr. Jobs that day. Withholding a choice from users to maintain a “perfect vision” is classic Jobs, but engaging in FUD wasn’t.

His biography indicates that this act was driven not by evaluating what was best for users, but rather by a personal vendetta against Adobe for past slights.

Regardless of his motive, it worked incredibly well. Companies cancelled or froze Flash projects while they waited for the dust to settle. Flash lost a ton of momentum, despite there being no viable replacement yet. Without iOS, Flash’s “write once, deploy anywhere” story became a lot weaker.

Given this climate, I think Adobe made the right choice in killing off mobile Flash. The mobile player requires a huge ongoing investment to support new devices and OSes, an investment that has no (obvious) financial benefit for Adobe.

Further, the type of content that Flash enables doesn’t make a ton of sense on the mobile web. People use their browsers for quick look-ups and fall back to apps for rich content. This will change over time, but the reality is that virtually no one is creating mobile version of Flash content for the web, there simply wasn’t enough demand to justify the expense, especially without iOS support.

If this decision allows Adobe to focus on increasing innovation in the desktop player, significantly improving their app packagers, and investing heavily in HTML5 tooling, it’s got my vote.

Jobs was right, but he was right for the wrong reasons.

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

I am proud to announce the winner of this year’s pumpkin contest!

“Kill All Pumpkins”, Ryan and Lanny’s homage to Futurama brings home the gold, narrowly edging out Grant and Wes’ “2001, a Squash Odyssey”, and “The Angry Pumpkin” by Sebastian and Chris, which kept up until the last few days of the race. There were some great entries this year, and I think it was one of the best contests yet.

Thanks to everyone that voted!

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

I’ve been doing a lot of work with JSFL the last little while, and was starting to get frustrated with the inability to define my classes and methods in separate files. I did some hunting around, and found a couple of solutions that worked by putting objects in an implicit global scope, but this doesn’t seem to work in CS5.

After some messing around, I came up with an approach that seems to be working:

In MyClass.jsfl

MyClass = function() {}
var p = MyClass.prototype;
 
p.run = function() {
	fl.trace("hello!");
}

in main.jsfl:

var JSFL_PATH = fl.configURI+"path/to/jsfls/";
var included = {};
function include(file) {
	if (included[file]) { return; }
	included[file] = true;
	eval(FLfile.read(JSFL_PATH+file+".jsfl"));
}
 
include("MyClass");
var foo = new MyClass();
foo.run();

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

Maybe we are compensating for missing halloween last year, but 2011 is our greatest pumpkin contest yet! On Friday, fuelled by beer and pumpkin ale, we split into teams and commenced the hack-and-slash carve-fest.

This year has more entries than any previous year (seven), and as usual our most recent hires Alex and Mike built an app for voting (below)

Cast your vote, leave some comments, and go check out the previous years’ pumpkins!
2004, 2005, 2006, 2007, 2008, 2009

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

I recently bought a shiny new mechanical keyboard to use with my Mac. So far, I’m liking it, but I miss having media keys for controlling volume and music playback like on my Apple & Logitech keyboards.

To address this, I wrote a few simple Applescript services that you can bind keyboard shortcuts to, which enable media commands (volume up/down, mute, play/pause, and next/prev track) for any keyboard.

You can download them by clicking here. Once downloaded and unzipped, simply double click each workflow file to install it. Note that these are only tested in OSX 10.7 Lion.

To bind keyboard shortcuts to the scripts, go to System Preferences > Keyboard > Keyboard Shortcuts. Select Services in the left panel, then scroll down to the script you want to assign a shortcut to. Double click on the right side of the row to edit the shortcut. Now, just hit the key combination you want to use, and make sure the checkbox to the left is checked (it likes to uncheck when you edit the key combo).

I used the following shortcuts:
Command +:
F13 – Volume Down
F14 – Mute
F15 – Volume Up

Command + Option +:
F13 – iTunes Volume Down
F14 – iTunes Mute
F15 – iTunes Volume Up

Command + Control +:
F13 – iTunes Previous Track
F14 – iTunes Toggle Pause
F15 – iTunes Next Track

I chose these because they are conveniently grouped at the top right of my keyboard, and I don’t use them for anything else. Note that you seem to need to include a Command in your key combo for it to work everywhere.

Also note that I made the system volume control fairly granular (5% increments), and the iTunes control fairly coarse (20% increments) based on my personal preference. You can easily edit these values by opening the workflow files in Automator. The scripts can be found at ~/Library/Services/ once installed.

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

I was looking at the blog today, thinking how neglected it is, when I realized that its 8 year anniversary had recently passed. That got me scanning nostalgically through old posts, and wistfully pondering how much has changed since my very first post on Sept 1, 2003.

At the time, I was a spiky-haired, fresh-faced, freelance developer who had just recently won my first few awards, and had spoken at my first few conferences (a thoroughly nerve-racking experience). I was completely unsure of my place in the industry, had no idea how to promote myself (though I was starting to learn), and wasn’t sure what I wanted to be when I “grew up”. I just knew that I REALLY loved building cool things in Flash.

Eight years later, a lot has changed, but the important parts have stayed the same. I’m a grizzled veteran, with more than a few white hairs, and am no longer so fresh of face. I’ve spoken at hundreds of conferences and events around the world, but I still get completely stressed out before every single one. I lead a team of 14 absolutely amazing developers and designers, working on cutting-edge projects for some of the biggest brands in the world, but I’m still not sure what I want to be when I grow up. I just know that I still REALLY love building cool things and sharing them with the world.

There are a few reasons why I still love my work so much. Foremost, I love the continuous challenge and the sense of creation. I don’t think I’ve had a day in the past 8yrs when I haven’t either learned something new, or built something (however small) that I can be proud of. I also appreciate the diversity – I’m sure I’d be a much wealthier man if my company focused on building “enterprise blah blah blahs for the yadda yadda market vertical”, but I much prefer constantly tackling new challenges. We’ve worked on everything from intros & micro sites to frameworks & enterprise apps to games & installations to technical demos & art pieces.

I also really appreciate the people. My own little team is made up of intelligent, creative, and fun people that I genuinely love working with. Our clients tend to be smart, savvy, and eager to do fantastic, progressive work. And, the communities I’ve been honoured to participate in have been hugely supportive and giving. Seriously, the Flash community is one of the coolest groups of like-minded folk I’ve ever had the pleasure to interact (and party) with. I’m still getting to know the HTML/JS community, but I’m hoping they will be equally cool.

I know it’s a bit sappy and cliché, but I have a deep passion and love for what I do, and a great deal of respect for the people I’ve been privileged to work with over the past decade. I’d like to think that’s helped make my work better, but if not, at least I’ve been having fun the whole time!

(and, yes, I will try to post more often – Twitter and G+ have made me lazy)

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, “Production“, and “Shadowing“.

At the end of shadowing, the trainee has been with us for 10-12 weeks, has received intensive classroom-style training, has planned and developed a small project from start to finish, and has worked on real commercial projects in parallel with a few of our most senior developers. Throughout this, we have been assessing and providing feedback on their productivity, code quality, communication skills, time management, and problem solving ability.

At this point we know for certain (hopefully) if they are going to be a great addition to the team.

As the 3 month mark approaches, we schedule a meeting with all of the senior staff who worked with the trainees. We compare notes, and discuss the strengths, weaknesses, and growth of the trainee, citing specific examples wherever possible. I take a lot of notes, and bring them into the review.

I like to keep reviews informal, usually over lunch or a beer. I talk to the trainee about what they are doing well, and how they could improve. Again, I try to use concrete examples where possible, so they can relate the input to real experiences. I give them lots of opportunity to ask questions or provide their own feedback on their performance and the training they’ve received.

If things didn’t work out, I make a point to provide them with honest feedback on what I think they need to work on if they want to continue in the industry, and where they could go next. I ask them how they’d be most comfortable with me announcing their departure to the team, and we generally have beers as a group to see them off amicably.

If things went well, I welcome them to the team, ask them a bit about their goals for the future, and start talking through possible projects we could put them on. From this point on we work aggressively to keep them busy on real projects, under the watchful eye of more senior staff who can ensure the quality of their output, and help to continue their growth in the company.

Of course, this whole process requires a large up-front investment which is wasted if we can’t retain our staff. I try my best to make gskinner.com a great place to work. We keep regular office hours, encourage our team to have a life outside work, pay fairly, have a good bonus model, offer praise and appreciation for accomplishments, foster continuous learning, promote a fun work environment, try to book interesting projects, and protect our staff from abusive clients. I would much rather lose a bad client than a good developer.

I have an amazingly fun and talented team that I love working with, and one of the things I’m most proud in my professional life of has been keeping them together over the years.

This concludes the Creating Great Developers series. Hopefully it helps inspire other dev groups to mould a new generation of creative, competent developers, and treat them with the respect they deserve. Interactive development is a creative pursuit, and I’m a strong believer that you can’t get exceptional results by treating developers as a commodity.

Note: I’m planning to revisit this series to do some editing (I’m not completely happy with the quality of writing), flesh out some details based on feedback, and add a persistent index.

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, and “Production“.

Once the new hire has successfully delivered their internal project, they are ready to move to the next phase of training: project shadowing.

We pair the new hire up with one of our senior developers, and have them work on the same project and tasks in parallel. At the start of each week, the senior developer will sit down with the new hire to outline the goals for the week, help prepare micro-deadlines (ie. production targets for each day), and provide some guidance on architecture and approach.

Throughout the week, the new hire works towards the assigned goals, and is free to ask their mentor for help or advice in an appropriate, organized manner. We schedule time for the senior developer to account for this, so that it does not create a burden on them.

At the end of the week, the trainee is provided with the mentor’s source code and given some time to compare it to their own efforts. They then sit down with their mentor to review their code quality, communication, and productivity. This also gives the trainee an opportunity to ask additional questions that arose during development or (more critically) while they were comparing their efforts to the senior developer’s work.

Besides being another great learning opportunity, it also provides the trainee and the senior staff with applied benchmarks as to how they are performing on a real project, without the risk associated with actually placing them on a client project. An important factor is that shadowing is treated as a serious project by both the trainee and the team, with a project manager, deadlines, and testing / quality control.

We repeat this process for 3-5 weeks, depending on the trainee’s performance. Most weeks we will switch mentors, so that the trainee is exposed to a variety of working / coding styles.

At the conclusion of shadowing, the trainee has been with us for between eight to twelve weeks, and is ready for their three month review, which will is the subject of the next article, available here.

gskinner.com | gBlog - News and views on Flash, Flex, ActionScript, and web technologies