The Joy of Flex

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.

If you missed the beta version of my talk on Architecting a Shared Codebase for Flex and AIR on Tuesday night, and you’ll be at Adobe MAX 2008 in San Francisco next week, you have another chance to see the 1.0 version of the talk.  It’s on Wednesday at 11 am in Moscone West 2006.  Sign up here.

Here are my slides from last night’s talk on architecting a shared codebase for both Flex and AIR.