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.

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.

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.

Now come give it a spin!

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?

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.

Noteflight – Moccasin

We’re looking for a summer intern developer on the Buzzword team in Newton, Mass for 2009. If you are interested, start with the official Adobe job position, click “apply now” to get yourself into the system, and feel free to email our recruiter Cindy Vink Loggins, cvink at adobe dot com with any questions. Or, if you know someone who might be interested, please forward them this post or the link to the job. Also, if you’re a blogger, please do me a favor and repost!

Here’s the gist of the job:

Position Overview

What is the Buzzword team up to?

Buzzword, the first real word processor for the web, is a breakthrough in collaborative authoring for documents that matter. The Buzzword team joined Adobe Systems Incorporated in 2007 in order to take Buzzword to the next level, building new features, integrating with the Acrobat.com product suite, and scaling up to hundreds of thousands of users.

The Buzzword application is built on the Adobe Flash/Flex platform, written primarily in ActionScript 3.0, an object-oriented language familiar to people who know Java and C#. Additionally, Buzzword incorporates a server that is written in C# using Microsoft .NET and SQL Server 2005.

Responsibilities

What are we looking for?

The Buzzword team is looking for a software development intern to join us for the summer. You should be a computer science major (or equivalent) going into your junior or senior year, with a passion for writing great code, learning new technologies, and discovering just what it takes to build commercial software. You’ll receive mentoring from Buzzword team members, and you’ll see every part of the software lifecycle: requirements, design, coding, testing, and release.

What would you work on?

Here is a small sampling of the projects you might work on as an intern on the Buzzword development team:

• New features: if you’re a strong contributor, you’ll get to work on important new product features right along side the rest of the development team.
• Bug fixing: there’s no better way to learn your way around a big code base than by fixing some bugs.
• Prototyping additional browser support: Buzzword relies on some small but critical bits of JavaScript to support keyboard control and system clipboard access, so we are currently limited to IE, Firefox, and Safari. You would prototype versions of this code for other browsers.
• Load and/or performance testing: In order to gauge future hardware needs, you would write a load simulator for our server, execute it, and analyze the results.
• Writing tests: Buzzword has a built-in automated test framework, with hundreds of existing tests that exercise product functionality and check for bug regression. You would write new tests, and analyze existing tests to remove duplicate functionality and improve coverage.
• Experimenting with Buzzword mashups: there are many unexplored possibilities for mashing Buzzword with other applications on both the client side (in the browser) and the server side.
• Site statistics analysis tools: both the Buzzword server and Google Analytics gather ongoing server usage statistics; you would improve on them and build new ways to look at how our users use the product.
• Secret projects: we’ve got new products coming down the pike that we can’t tell you about in this ad.

Again, next step is to see the official Adobe job position, and feel free to email Cindy Vink Loggins, cvink at adobe dot com with any questions. (This position is located in Newton, MA.) ]]> http://www.colettas.org/?feed=rss2&p=294 2 http://www.colettas.org/?p=294 http://feedproxy.google.com/~r/TheJoyOfFlex/~3/L-5PJFzuBK8/ http://www.colettas.org/?p=286#comments Fri, 05 Dec 2008 16:46:52 +0000 David Coletta http://www.colettas.org/?p=286 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.