The Joy of Flex

Suppose you’re a small startup with a shipping product based on a substantial ActionScript codebase. Suppose your app is not just a bunch of list views with a few graphical assets, but it’s a really rich interactive tool. For example’s sake we’ll say it’s a sailboat designing app with visual water-simulating features: call it BoatWright. And suppose you’re trying to figure out your mobile strategy, which is a fancy way of asking “how do I get BoatWright on at least iPhone and Android, plus Windows Mobile, Symbian, Blackberry, and WebOS for good measure?”

As a startup with a shipping product, you’ve got a lot of constraints. The biggest is that you are already trying to do too much with not enough people, and forward momentum of the product is critical. You have to keep shipping new features to build the product out, so you can’t afford to go dark while you port your ActionScript to Objective C, Java, C++, and so on in order to make native apps. Wasn’t the Flash Player supposed to be a neutral platform?

At the same time, you’re worried about the new guy on the block who is just starting up in your space. Sure, you’re way ahead of him now, but if he starts from scratch maybe he can leapfrog you on the mobile platforms before you can figure out how to get there. Or, put another way, someone’s going to build a great sailboat designing app that runs on the iPhone, and especially on the iPad where it can take advantage of all that extra screen real estate.

What are your options? Well, you could go out and hire a mobile team. Oh, wait, you can’t do that – you’re trying to do less with more, remember? So porting or reimplementing your app on somewhere between two and six additional native platforms is a non-starter. It seems like an exciting prospect – “hey, we’re a cool mobile company now!” – but you’re not a mobile company, you’re a sailboat design software company, and there will be somewhere between two and six steep learning curves, and momentum on the shipping product will fall, and then at the end of it all you’ll have seven separate codebases to maintain, and you’ll grind to a halt. Don’t do this.

Another, more reasonable choice might be to read the tea leaves about which mobile platform is the best choice for your app, and port to just that one. This is really a big decision about what kind of company you’re going to be. Do you want to enter the wild west of Android where the most popular app is a process killer, but at least you can ship whatever you want? Or the safe warm fuzzy confines of the App Store where shipping a new version can be delayed by months while Apple repeatedly rejects your app for minor violations? And are you going to maintain two codebases, ActionScript for your browser app and Objective C or Java for your mobile app? (I’m taking the conservative route and assuming Apple is never going to permit Adobe to ship a version of Flash Player for MobileSafari.) Even maintaining two codebases is going to double the effort for each new feature, so are you going to bet it all on mobile and leave the ActionScript codebase behind? This line of thought seems scary. You want to postpone big decisions like this if you can.

But maybe porting your codebase just once would be acceptable, if the end result could run in desktop browsers and on all mobile platforms. Not to mention that porting the codebase would give you a good opportunity to refactor and generally clean up the code in the process. Suppose you could convince yourself that your app could run well in WebKit using as much of HTML5 as is generally available on both desktop and mobile browsers in the time frame of your port. Now that’s starting to sound like a strategy. You’d end up with just one codebase to maintain, it would run everywhere, and you’d no longer be constrained by the limitations of Flash. ActionScript and JavaScript are similar enough that maybe the port wouldn’t even be terribly hard. This approach seems attractive. It’s not without risk, though: you still have to go dark while you do that port, and more importantly, you have to convince yourself that you can get to the same level of performance in HTML5 with Canvas that you already have in the Flash Player. For some apps this is going to be more challenging than others. For some apps it’s not going to be feasible this year or next.

Then there’s doubling down on Flash: don’t port your code at all. On the mobile platforms where Flash Player 10.1 is coming out, redesign your app for the small screen but leave it in Flash and ActionScript. And on the iPhone and iPad, use the Packager for iPhone technology that’s coming in CS5, again redesigning your app to take advantage of the platform. This approach is not without risk either: the full Flash Player on mobile platforms is a new beast and it’s going to take a while to shake out. The Packager for iPhone is also unproven. In both scenarios it’s going to take a while before everyone is convinced that apps on those platforms will perform adequately while preserving battery life.

But the great thing about doubling down on Flash is that it postpones major life-changing decisions like porting an entire codebase, and the investment of redesigning your app for Player 10.1 on mobile and Packager for iPhone is relatively small by comparison. Even if it doesn’t work out, you’re not much worse off than you are now, and you can still try one of the more expensive and riskier strategies.

What are you waiting for?

P.S. I was a little surprised to come to the above conclusion. I don’t work for Adobe any more and even though this blog is called The Joy of Flex, I’d rather make a good strategic decision than stick blindly with Flash Player forever. So I’m happy to convince myself that with FP 10.1 and Packager for iPhone, Adobe is about to start offering a potentially great choice for developers like me.

At the end of January I’ll be leaving Adobe Systems and joining the team at Noteflight! I have wanted to work on music software at least since college, and I have wanted to work with Joe Berkovitz since I met him at Adobe MAX a few years ago, and now it’s going to happen.  Wow.

Noteflight, in case you haven’t heard about it, is an online music writing application that lets you create, view, print and hear music notation with professional quality. You can work on a score from any computer on the Internet, share it with other users, and embed it in your own pages. It’s written from the ground up in ActionScript, and it’s awesome. I’d call it the “Buzzword” of music notation, though perhaps by next month I’ll be calling Buzzword the “Noteflight” of word processors.

I’m enormously grateful to my colleagues at Virtual Ubiquity, with whom I helped create Buzzword. It was a singular experience.  Likewise, I’m grateful to Adobe Systems Incorporated, for the opportunities they have given me over to grow in many different directions since we joined them. Finally, I thank the incredibly talented engineers with whom we have worked at Adobe over the last two years to bring together Buzzword and the other applications into a single Acrobat.com suite.

The conventional wisdom about why Google built Chrome is that Google wanted to be able to deliver a better browser experience, both for search and for its apps, than was possible in other browsers. Similarly, it’s understood that Google is betting heavily on HTML5 as the platform of the future for applications on the web, and the best way for them to influence that future is to create it.

What I just realized today, however, is that since Chrome is built on Webkit, Google can build and deploy HTML5 functionality, contribute it back to the Webkit open source project, and watch it propogate virally into every other browser built on Webkit.

I think Google is building Chrome as a real-world demonstration platform on which to prove the features of HTML5 and create the future.

A couple of years ago I said we’d look back at June 2007 as the time that Safari turned a corner. But now I realize that it’s really Webkit that’s the important technology. If I’m right about Google’s strategy, then over the next two years we’ll see many of the technologies that constitute HTML5 appear in the Webkit open source code base and start to appear in other browsers.

We just took the wraps off of a new site called labs.acrobat.com where we are showing previews of what is coming to acrobat.com in the near future. Today you can check out a preview of the app that does for presentations what Buzzword does for word processing documents.

Now come give it a spin!

Right now it’s hard to find out when people have made changes to Buzzword documents that you care about. Say you’re working with a couple of other people on a project plan, and you’ve just written a first draft and sent it out for comment. When your collaborators leave comments in the document, or rewrite some of the document, the best way you can find out about that right now is to leave the document open and watch for changes. Alternatively, you can check for an unread mark in the document organizer. Either way, you have to remember to look. That’s not right.

In a past life, I worked on a collaboration product called eRoom. The main way eRoom sent out notifications was that inside its server there was a giant spam machine that could generate nightly or immediate emails when documents changed. Each user could specify their own notification preferences at various levels of the hierarchy (documents, folders, or entire rooms), but the net result was a metric buttload of email. With the right set of email rules on the receiving end, this can work, but it’s not pretty.

What if a document could tweet? Set aside the mechanics — for example, don’t worry about what Twitter account it’s using, or how people go about following the documents — and just ponder for a second what it would be like if the documents you cared about talked to you from time to time in your Twitter client. If you followed a document, from time to time you’d see a tweet saying something like David Coletta left a comment on 2010 Project plan: “it would be awesome to hit this date!” or Bill McFill edited the document 2010 Project Plan.

Key to this idea is that no one would have to press a button to make the document tweet. Instead, authors would specify some criteria about which documents should tweet, what they should tweet about, how often, and so on. Maybe it would also be important for people on the receiving end to specify these same things, but I’m not sure. And I’m not ruling out a manual process too, but the point is that you wouldn’t have to think about individual tweets if you didn’t want to.

So given the ideas above, would this be a useful approach to getting notified about the documents you care about? Should authors get to specify the criteria, or should followers? Could it be really simple, or would it only work if there were lots of fine-grained controls? Could this be the only way you get notified, or would there have to be email notifications, toast-style popup notifications, and so on as well?

For reasons unknown, over the weekend Flex Builder 3.0.2 for Mac OS X stopped being able to launch. It would show the splash screen, then the beachball would start spinning, and it would never actually open the previously opened workspace.

I got it working again as follows.  I renamed the top level directory of the previously opened workspace, launched Flex Builder, and this time it started up just fine. Then I quit, renamed the top level directory back, and relaunched. That worked fine, and subsequently quitting and relaunch worked fine too. 

Hope it doesn’t happen again.

Last night at the Boston Flex Users Group monthly meeting, Joe Berkovitz presented Noteflight and Moccasin.  Noteflight is his Flex-based online music editor, and Moccasin is an open-source framework that supports direct-manipulation editing in Noteflight and apps like it. This was a great talk, and I particularly liked the way Joe used his music application as a example to demonstrate the Moccasin code. Moccasin comes with a sample AIR app that demonstrates its features, with some simple direct-manipulation editing, undo, and more.

Noteflight – Moccasin

Looks like we’re about to start a search for a couple of developers on the Acrobat.com team in Newton, MA.  If you are smart and get things done, plus you know some ActionScript 3, Flex, C#, .NET, and/or SQL Server, please drop me a line at dcoletta at adobe dot com. On-site full-time candidates only.

In case you’re wondering, the new college grad developer position on the Buzzword team at Adobe Systems Incorporated is still open! If you are a recent grad, or will be graduating soon, from a BS/CS or MS/CS program in the U.S., and you fit this job description, I’d really like to talk to you.  You can email me directly at dcoletta at adobe dot com, or call our recruiter, Erin Fife, at 408.536.5382, efife at adobe dot com.