Interview with Jack Doyle, Founder of GreenSock

Jack Doyle, founder of GreenSock and creator of TweenLite, spends some time talking to ActiveTuts+ about how he got started, the future of TweenLite/Max, and what he has learned about code optimization & licensing.

Hi Jack, tell us a bit about how you began with Flash. Were you a self taught developer or did you come from another language? If applicable, how did your past experience help you as a Flash Developer?

All my formal training was in graphic design actually. I went to college on a design scholarship and I never imagined I’d end up writing code like this. Never took a computer science or programming class in my life. I was always pretty good at math and drawing. I worked at an advertising firm early in my career and got interested in designing web sites, so I went to the owners and pitched the idea of me running a “digital” division. To my surprise, they agreed and gave me a shot. I’d do the design and hire other companies to write that gobbledy-gook called “HTML” and server-side scripts that made it all work. I was disappointed by what the vendors delivered and it was a big hassle to keep going back and forth, so I bought a couple books and learned HTML and ColdFusion. I couldn’t believe it was so much fun. I started seeing all sorts of possibilities. Then came Flash. Wow. It could deliver visually rich experiences (the designer in me liked that) as well as complex interactivity (the budding developer in me got sucked in immediately). I was hooked.

Virtually all my learning came from trial and error, Google searches, and making a ton of mistakes. I’m a very stubborn guy, so I’ll try and try and try until I figure out how to make an idea work. I’ll lie on the floor face-down for hours sometimes, just thinking. Then I’ll jump up and try an idea. And promptly fail. Then I’ll pace back and forth, get another idea, and try, fail, and so on until I figure it out. We’ve all experienced those “aha!” moments when we finally get it right – that feeling is rather addictive for me I guess.

As far as my past experience helping me, I think design was a tremendous help for two reasons. First, it taught me to think of things from the viewer’s perspective. Ask yourself this question: if you could design a car any way you wanted, what would it be like? What annoys you about most cars today? The same concept applies to creating an API for an ActionScript class. As a user, how would you want it to work? Too many developers get caught up in technical details and fail to put much thought into creating an elegant, intuitive API. I frequently hear from developers who say they love working with TweenLite/Max because it’s so easy; it just makes sense. That means a lot to me.

The other thing graphic design helped me with was being able to communicate. I’m surprised by how terrible much of the communication is from developers out there who release their code. It could be amazing code, but if nobody understands its value or how to use it, it’s a failure.

TweenLite is one of the most popular tween libraries out there. What do you think are some of the keys to your success with it and why people choose it over the competition?

I owe much of the success to the user base – they have been so kind and loyal and they brag about it to their friends. And I think people brag about it because it has a rather unique mix of power, ease of use, speed, and reliability packed into a small package. Most other engines I know of have lingering bugs, they’re missing important features, the syntax is just plain ugly and cumbersome, performance is sluggish or they’re way too bloated. I’ve tried hard to avoid those issues. The bug thing is a pretty big deal to professional developers because a tweening engine is so foundational in most projects these days – you don’t want to build on a shaky foundation that has lingering bugs or an author who isn’t committed to promptly squashing them when they pop up. The GreenSock platform seems to have earned a reputation for reliability and quick bug fixes which developers appreciate. Plus I try to continually improve it, add features, optimize, refine, etc. It has really matured over the years while many open source alternatives stagnated. There’s a lot of stuff you can do with the GreenSock platform that you just can’t do with any other engine. But ultimately it’s probably the ease of use that gets people hooked. I hear from developers all the time who say things like “every time I stumble across something else I need the engine to do, I discover that you’ve already thought of it and the tools are right at my fingertips.”

Now that you have released version 11 of the Tween platform what are some of the new features you are most proud of in this release? What do you see in store for version 12?

I must admit that I’ve never been so excited about a release. Version 11 is a huge step forward in so many ways. Not only have TweenLite and TweenMax gained a bunch of features, but there are brand new sequencing tools (TimelineLite and TimelineMax) that have tremendous potential to change your animation workflow. I’ve heard from quite a few developers say things like “I had no idea how powerful the timeline classes are – I’m addicted!” Most people don’t quite realize the potential until they spend a little time kicking the tires. I created a video that goes over the basics at blog.greensock.com and I’ll post one that covers more advanced topics soon. Designers seem to like the new motionBlur plugin which automatically applies a directional motion blur based on a DisplayObject’s angle of movement and its velocity (yes, the blur can be diagonal). physics2D is a hit too – it allows you to tween things based on velocity, acceleration, friction, gravity, accelerationAngle, etc. TweenLite now gets full-blown controls like pause(), resume(), reverse(), play(), and restart(). If you haven’t seen it already, check out the 60-second promo swf on the home page at blog.greensock.com. There are big improvements in the structure of the code too and there’s full ASDoc documentation. As far as v12, I don’t have anything specific to share, but there are a few ideas bouncing around my head that I’ve been experimenting with. Right now, however, I’m still very much focused on v11 and helping people understand its potential.

GreenSock’s projects are rare in that they are not open source. What made you decide to go down that road and do you feel it has worked out better this way?

Absolutely. There’s no way the GreenSock Tweening Platform would be as robust, reliable, and optimized as it is today if it weren’t for the unique licensing model. I don’t think it’s appropriate for every type of project, but it is ideal for the tweening platform. And for those who aren’t familiar with it, the standard “no charge” license makes the code completely free for virtually all types of use including most commercial projects. There’s a very specific, rare type of usage (maybe 1% of the commercial use cases) that requires a special license which comes with corporate Club GreenSock memberships. And a few of the non-essential plugins are membership benefits of Club GreenSock (it’s a way I say “thanks” to those who support the project).

Club GreenSock serves a critical role by providing a cash flow mechanism that funds continued development and support. Everyone benefits from it even though an extremely small portion of the user base participates. A few developers have a hard time understanding it at first, turning up their nose as soon as they see any indication of a funding mechanism no matter how fair it may be, but most people understand its value and recognize how much it benefits everyone. In fact, many see the licensing model as a feature, not a liability because it demonstrates a certain level of commitment and staying power which gives them confidence that it will continue to be supported and enhanced. Look at the track record and you’ll see that no other engine is as actively developed and updated as the GreenSock one over time, and the licensing model is what makes that possible. I’d argue that it’s very short-sighted to believe that an MIT (or similar) license is always superior and I explain why in my “‘Free’ != Better” article at blog.greensock.com. I chose the unique model because I firmly believe it ultimately serves the community better, delivers a superior end product and protects against some common frailties of open source development.

A big shout out to the club members reading this – you make this all possible and I’m so thankful for your support.

Director had a thriving community based around selling plugins and code modules however, Flash has not been able to create the same market. Do you feel that developers can actually make money/profit by selling their code and if so do you have any tips to help get started?

Sure. I’m not familiar with the Director community of years ago, but I see lots of people selling their ActionScript code these days. I couldn’t speak to how profitable they all are, but the fact that there are so many tells me that something must be working. The difference with the Shockwave community years ago may have a lot to do with the nature of the internet at the time. Blogs and forums have become so pervasive these days and they show plenty of code examples and ideas for free. This is a wonderful thing, but it also makes it a bit more challenging for people who want to sell their code. They’re competing with free code and let’s face it – most of us developers like figuring stuff out and building our own solutions so it’s tempting to just look for free code and try to piece together what we need without plunking down any cash.

However, I think over time the landscape will mature as developers get burned by abandoned open source projects and bug-filled free code. There will be an increasing need for high-quality, refined solutions that developers can trust, especially for more complex things. TransformManager is an example of a niche product that is relatively complex which knowledgeable developers are happy to pay for because it saves them an immense amount of time and hassle. Would you rather burn weeks (or months) trying to figure out how to build a similar tool or pay a trusted source $299 and have it today complete with documentation, examples and a dedicated forum of fellow users?

Trust me – there’s a market out there. You just have to demonstrate clear value and earn their trust.

As for tips, here are a few:

• Make your API as intuitive, easy, and clear as possible. Imagine putting it in the hands of a complete moron – could they easily figure it out?
• If you can’t make it unique, don’t do it at all. If there are 300 slideshow solutions on the market already, don’t make it 301 unless your solution blows everything else out of the water. Look for a problem that nobody solved well. The more complex the problem, the better – make it easy.
• Prepare yourself for lots of questions. You may think something is obvious but you’d be surprised how many “silly” questions you get. Expect it. Don’t get frustrated. Serve your customers well and they’ll be loyal.
• Document your code. ASDocs are the standard – use ‘em. Provide examples too. Put yourself in your customers’ shoes – they need to be able to get up and running as quickly as possible.
• Don’t get too fancy with trying to protect your code. I’m generally a fan of giving customers the raw source code instead of swc files or mxp files, etc. As a customer, I want to be able to troubleshoot and dig into the code if I need to. Let me do that. When you put lots of hurdles in my way, you’re telling me you don’t trust me and you’re making it more difficult to use your product, so I’ll be less likely to buy from you again.
• If you can, set up a forum in which customers can post their questions. It not only cuts down on having to answer the same question again and again (since they can search the forum before posting), but it also invites customers to help each other, easing the burden on you. Just make sure you’re attentive and don’t rely too much on others to do your tech support.

Optimization is a hot topic now in the Flash community, especially with Flash on mobile in the horizon. What steps have you taken to insure your Tween engine is as efficient as possible? Do you have any tips for developer from what you have learned?

Wow, that’s a broad question (but a good one). I’ve learned quite a bit about optimization over the years, and if I listed it all here, well, the answer would get way too long. I’ll probably post something on my blog eventually with various tips, but here are a few:

Function calls are expensive. Avoid them if you can by performing operations inline instead. It’s possible to go overboard with this and make your code way too long, complex, and repetitive, so it’s a balancing act. Target the most frequently used chunks of code.

AS3 benefits from strict data typing, so do it wherever you can.

//slow:
var num:int = Math.round(n);

//4x faster:
var num:int = (n > 0) ? int(n + 0.5) : int(n - 0.5);

//slow:
for (var i:int = 0; i < myArray.length; i++) {

}

//faster:
var l:uint = myArray.length;
for (var i:int = 0; i < l; i++) {

}

//slow:
for (var i:int = myArray.length - 1; i > -1; i--) {

}

//faster:
var i:int = myArray.length;
while (i--) {

}

Accessing public properties is much faster than accessing getters/setters (because again, functions are slow).

//slow:
public function get myProp():Number {
    return _myProp;
}

//faster:
public var myProp:Number;

As far as optimizing the tweening engine, I’ve spent countless hours optimizing it, especially in the high-use areas. You can see how it stacks up against some other engines at blog.greensock.com

Can you talk a little about partnering up with Grant Skinner and what the collaboration was like? Are there plans on releasing more projects together based off the work you both have done with the Tween platform?

Grant is such a cool guy and a great developer. It was an honor to work with him. He comes from a much more traditional/structured background when it comes to writing code, so he gave me valuable pointers and explained how important it was to follow industry standards for things like the reverse domain package naming structure, losing the “$” in front of parameter names, etc. He was careful not to be dogmatic about anything and he wasn’t pushy in the least. Grant’s schedule is rigorous with all the flying around he does for conferences and he has a business to run as well, but he was kind enough to carve out time to chat with me which I greatly appreciated.

As far as future plans go, we hope to continue collaborating as schedules permit. I’m excited to see where things go from here.

If you could pick one thing, what would you consider your favorite part of ActionScript 3? Likewise, what would you change or want implemented?

There isn’t a particular part of AS3 that I’d consider my favorite – I just love how it gives me the power to create virtually anything I can imagine. It’s fast, flexible, and ridiculously capable. What would I change? Hm. Well, I’ve never been a fan of the built-in Flash components. They need a serious overhaul. And there are some really annoying bugs especially on the Mac that I hope Adobe fixes in short order. PixelBender has amazing potential, but seems like an afterthought and the language should be AS3-like. The way some of the security sandbox restrictions are implemented strikes me as just plain silly and cumbersome. But really, we’ve gotta give credit to the Adobe team for creating an amazing technology that has been responsible for some of the richest interactive experiences ever.

I continue to be amazed at what’s possible with Flash.