Mark Anders' Blog

May 08, 2009

Thoughts on FXG Design and Motivation

Rick Jelliffe wrote about FXG on his blog where he both equates it to OOXML and asserts that it was designed as a replacement for the Adobe Photoshop PSD file format. You can read his post here. Since he references an earlier posting of mine about FXG, I thought I’d respond. Also, since his writeup was focused on Photoshop, I'm not going to assume knowledge of Flex or Flash

First, FXG was not designed to be the document format for any of our apps, and so was not meant to be “to PSD what OOXML is to .DOC: a re-factoring of a middle-aged binary format in XML with a focus on fidelity rather than elegance.” In fact its focus is not PSD or Photoshop or Illustrator at all. Likewise our main goal was not to create an XML based graphics interchange format like SVG.

The thing we set out to design, first and foremost, was “componentized graphics” for Flex, which is an open source framework for creating Flash-based content. This goal was responsible for most of the constraints we had to contend with. FXG is a well documented subset of this, so that tools could read and write these componentized graphics descriptions without having to understand Flex, Flash or ActionScript, which is the programming language supported by the Flash Player.

So the origins and goals of what we did are not really comparable with how Microsoft approached OOXML. What follows will also explain why it’s conceptually different than SVG. Here is some background as to how we approached the problem.

Flex is an ActionScript-based framework for building applications. It provides a set of ActionScript components that are used to create user interface, and it is easy to add new ones. Historically, Flex gives you things like Buttons and Datagrids for building UI. Flex also has a nice XML-based language called MXML that defines simple rules for how an ActionScript object maps into XML and is useful for defining how objects are to be instantiated and parented. The rules are really simple. If you have an object, its name becomes the name of the tag. Properties on the object become attributes on the tag. Metadata applied to a object defines how it can contain other objects. Everything is case sensitive.

So if you have an Application object that has a Button , rather than writing a bunch of procedural code to say:

var app: Application = new Application();
app.minWidth = 1024;
app.minHeight = 768;
var button: Button = new Button();
button.x = 31;
button.y = 27;
button.label = "Hello";
app.addElement(button);

You can more easily write:

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://ns.adobe.com/mxml/2009" minWidth="1024" minHeight="768">
    <Button x="31" y="27" label="Hello!"/>
</Application>

This has lots of benefits but it’s important to note that the code is equivalent. You could write it either way. Using XML as the basis for the language has the nice property that it makes it much easier to provide graphical design tools to author and edit the files since the code is declarative rather than procedural.

In looking at what we had accomplished with Flex, one thing we realized is that, while it was easy to build apps out of buttons and textinputs and datagrids, if you wanted to use a line or an ellipse, it was much harder. Flex had no defined way of using graphics as building blocks. You HAD to write procedural code.

Since Flash is, after all, all about graphics, we wanted to extend Flex to make it as easy to build things using graphics as it is to do so using datagrids and buttons. So what we did was to create a set of ActionScript objects that represented all of the graphics that Flash could do, and to design them so that, when they got mapped into an XML format, they looked nice.

It is important to emphasize that the design process for Flex and its XML format is different from how one typically creates XML based formats. With XML, you typically lead by thinking about schema and the semantics of how it should be interpreted. Flex does not have a schema. It has ActionScript objects that imply a schema but everyone can and does create new ones. So here, you think about ActionScript objects AND how they map into XML using the rules of MXML.

To design our Flex graphics, we followed the same guidelines that we follow for all of our additions to the Flex Framework. This is what the prototype I described here, and that Rick references was about. Our design guidelines, like with Java and other systems, have conventions that say, for example, that class names begin with an uppercase letter, and methods start with lowercase. In my prototype, my classes were inconsistent. I did have things like:

public class LinearGradient

Which are fine according to our guidelines, but I also had things like:

public class g
public class svg

Which were not. Likewise, we specify that property names are to be descriptive. Therefore:

LinearGradient.gradientUnits

Was just fine, while:

path.d

Was just wrong. So we thought it would be bad to have the graphics classes be completely inconsistent with everything else in the system. Consistency and elegance was important to us. So in the design of our objects, we followed our established standards.

Once we designed the graphics objects, the XML format was, in essence, designed for us, by the rules of how MXML maps objects to XML. Having graphics as part of Flex and MXML gave us a number of nice benefits. MXML has syntax (like HTML) for adding event handlers to objects. So, for example, if you wanted to take an Ellipse and handle click events, you could easily do it like this:

<Ellipse x=”10” y=”10” width=”100” height=”50” click=”onEllipseClick()” />

You can also do things like have databinding expressions to programmatically bind one variable to another, such as:

<Ellipse x=”{mouseX}” y=”{mouseY}” width=”100” height=”50” />

After doing this work to extend Flex with graphics objects and the resulting XML format, we realized 2 things:

1. It would be great if graphical tools such as Photoshop, Illustrator and 3rd party tools could read and write the XML format so that you could create graphics in those tools and easily bring them into Flex.
2. A lot of the things that are legal in Flex MXML and that a developer might do, such as adding databinding expressions or event handlers to a graphics element or (gasp) intermixing a button, datagrid or some other component with the graphics markup, would make it impossible for tools that don’t understand Flash, Flex or ActionScript to reliably work with this markup.

As a result, we decided to create the FXG format, which is a subset of MXML that includes only graphics tags. It removes all of the developer-oriented syntax such as databinding and event handlers, and it is also rigorously defined as an interchange format, so that the behavior of the graphical elements is defined as is the rendering model. We did this by focusing on schema and semantics as the first priority, but most importantly, keeping in mind the corresponding runtime objects in Flex.

So unlike SVG, our goal was not that FXG would be an interchange format to be sent to a client machine for runtime interpretation, even though this is possible and sometimes even desirable to do. Rather, FXG was designed as an exchange format between tools that understand graphics, like Photoshop, Illustrator, or other 3rd party ones, and tools that understand Flex and MXML.

I hope this puts a bit more context on what we did and why.

Posted by Mark Anders at 04:51 PM | Comments (4)

November 28, 2008

MAX Milan and Interesting Article in The Register

I'm heading off to MAX Milan today where I'll be delivering the keynote on Monday. I'll be covering pretty much the same ground as Kevin Lynch did when he did it in San Francisco, though we have a couple of new things that we'll be showing, as well.

I'll also be doing a bunch of press interviews. Last year at MAX in Barcelona I met with a variety of journalists including Tim Anderson of The Register, who I'm meeting with again this year. Tim just posted an interesting article on how Scott Guthrie and I showed AJAX support in ASP.NET as far back as 2000, which we called "incremental page refresh" at the time, but that it didn't actually get released until 2006! Actually, I think our earliest prototypes of ASP.NET (then called XSP) had AJAX support in it, so that would put it around 1998. It's an interesting article and I'm looking forward to talking with Tim again next week!

Looking forward to seeing everyone in Milan, and please say hi if you're there. I'll be around all week!

Posted by Mark Anders at 09:22 AM

November 17, 2008

Thermo (Flash Catalyst) Unleased at MAX!

One of the big pieces of news coming out of MAX is that we've released a preview version (pre-Beta) of Flash Catalyst, which is the official name of the product previously code-named "Thermo". While it's going to be featured in tomorrow's Day 2 General Session, there is also a session this afternoon that starts in 5 minutes where Ryan Stewart will be presenting it in depth.

We will also be giving away copies of the preview version to MAX attendees. I was lucky enough to steal a copy BEFORE the session, while Steven Heintz wasn't looking, and so here's the first peak as to what it looks like!

Enjoy!

Posted by Mark Anders at 03:00 PM | Comments (1)

September 30, 2008

Flash on the Beach, FXG & SVG

Yesterday I gave a session at Flash on the Beach 2008 in Brighton, England on Flex 4 and Thermo. Overall, it went really well and generated some positive mentions, such as this one from the Yahoo Developer Network Blog and this from David Arno.

David’s review was really enthusiastic and he concludes by saying “All in all, the session was amazing. To say I’m now excited by Flex 4 is probably the understatement of the year.” What made this so satisfying to me is that he is a hardcore C#/.NET developer which is a group that I've felt is important for Adobe to reach.

On the Yahoo Blog, Steve Webster liked the talk but also had a question that I thought would be good to answer. The question was:

“I can't help but wonder why Adobe created FXG and retrofitted all their creative tools to read and write the new format, when SVG is already here and supported by all those tools and more.”

The First Flex Graphics Prototype

The effort to add graphic tags to Flex actually began over 2 years ago when I created a series of prototypes to demonstrate how it could work and what it would look like. The goals of what became the initial prototype were to change people’s perceptions as to what Flex could be, to demonstrate that we could make it into a framework for both design and development, and to try to convince Adobe upper management that there was a need for a new tool for designers working on RIA that leveraged the Flex framework. This is what became Thermo.

The first prototype for the graphics tags was in fact a partial implementation of SVG in Flex. I showed this off at a 360 Flex conference in March 2007 and blogged about it here. The way it was built was that I created a set of Actionscript objects whose class names and properties were such that when they were mapped into MXML, they looked like SVG.

I based it on SVG for a number of reasons. First and most importantly, it was a standard that was supported by a variety of tools and by using it as a spec, I could focus on implementation rather than having to dream up a new object model.

Problems Using SVG

In the course of building the first prototype, I ran into a number of issues, some small, some large.

The most serious were those things things that were impossible to do, given the approach I was taking. For example, on all shapes and containers, SVG defines a “transform” property that is a string. However, on DisplayObjects, Flash already defines a "transform" property, and it's not a String. As a result, I had to rename my svg property to be "transformer", because I could not override a property with one of the same name but different type.

A number of properties and objects required implementations that were unlike other things in Flex and Flash and inefficient. For example the SVG transform is a string that is an expression such as:

<g transform="skewX(30)">

This required parsing at runtime, is not efficient and makes integration with other Flex features such as databinding, states and transitoins more difficult.

The style property on a number of objects defines another of these "micro langauges" that requires runtime parsing. For example it's common to see something like this:

style="font-family: 'Super Sans'; font-weight:normal; font-style: italic"

SVG also exposes a way to essentially bind one object to another such as:

<rect fill="url(#XMLID_8_)"/>

While this had to be parsed at runtime, what was worse is that Flex doesn't provide a DOM of the MXML document so there's no way to look up an object with a specific ID. As a result, I had to build a lookup table of these at runtime. Flex has a different method of doing this same thing, which is to use databinding, so I also supported it in a more Flex native way like this:

<rect fill="{myFill}"/>

Of course, doing this was non-standard and made those graphics incompatible with SVG.

Another class of issues around was around consistency. The Flex and Flash teams have done a ton of work to make all of the API consistent. I myself spent days reviewing every Flash Player and AIR API, looking for any violations of the myriad of design rules we have established.

The first thing you notice when you start looking at some even as basic as SVG names is that there is absolutely no consistency. Here are some SVG tags:

<svg>, <g>, <defs>, <ellipse>, <linearGradient>

Because in MXML each tag maps directly to a class name, I had a classes named "svg", "g", "defs" etc. This violated a number of design rules for Flash and Flex. For example, we have tried to name all classes with complete, descriptive names, and classes such as "g" don't meet that criteria. Of course, the most basic rule of class naming is that all ActionScript class names begin with an uppercase letter and every SVG class begins with a lowercase one.

Attributes are also named inconsistenly. For example, the main property of a path that people use is named "d" while gradients have a property called "gradientTransform". There is a property on gradient stop called "stop-color", which would be an illegal name in ActionScript.

Probably the biggest challenge I had was when the imaging models were just completely different. For example, Flash objects support a "filters" property, as do SVG ones, but the models are not even close. SVG has very low level filters for things like "ConvolveMatrix" and "SpecularLighting". These can be composited together to create higher level effects. Flash on the other hand has high level filters such as DropShadow and Glow and what I implemented was based on the Flash model.

In the end, what I had was nowhere near complete. There were so many issues with supporting even the limited amount of SVG that I implemented that it wasn't worth finishing. While a number of the more advanced features were never implemented, the prototype could display the type of SVG that you get out of a tool like Adobe Illustrator, and you could modify everything at runtime, including control points, fills, strokes, and filter paramenters, so it served its purpose.

From Initial Prototype to Implementation

After I was done, I reviewed the results with a number of people, including Ely Greenfield and Glenn Ruehle from the Flex team and NJ & Sho Kuwamoto from the Flex Builder Team. What we concluded was that being compatible with SVG would be impossible if we maintained consistency with Flex and the rules of MXML, and that that there was a lot we could do to provide a better, more consistent, and higher fidelity format for Flash that also solved real problems for designers, developers and us in our role of building tools for Flex.

We also realized that, given what was going to be coming down the pike with Flash Player 10, with features like 3D, the Vellum text components and Pixel Bender, that getting locked into SVG would make it more difficult to support these new capabilities.

With that knowledge, I created 2 other prototypes. Both cleaned up large portions of the object model to be more consistent with Flex and the Flash imaging model. But they also diverged from SVG in other functional areas.

For example, one thing I ran into is that rotating objects programmatically is actually kind of diffcult. While SVG has a rotation transform convenience method, this rotates the objects around the origin of the shape, which is often not what is desired. To get a shape to rotate around a given point you actually need to do 2 matrix operations which SVG doesn't make easy to do.

So what I did was to add a transformX and transformY proprerty to the shapes. That way, you could easily rotate an object around a given point without having to do math with multiple matrices. This also more closely matches how Flash presents graphics at design time.

With the prototypes done, I turned the work over to Ely, Glenn, and Deepa Subramaniam, who did the actual design of what became FXG and Flex Graphics. While I don't think any of my actual code survived, a number of the names, designs, concepts, as the lessons we learned by experimenting with SVG did.

I should also note that as word of what we were doing with Flex Graphics and FXG circulated around Adobe, we were asked about why this wasn't just SVG on a number of occasions. At that point, however, we had a lot of data as to why we made the design choices we did, and so we were able to do what we had concluded was the right thing to do.

Posted by Mark Anders at 11:13 AM

July 01, 2008

A New Approach to Searching Flash

It’s been a while since I’ve posted, but it’s not because I haven’t had anything new to write about. We’ve been working hard on Thermo and I had the pleasure of showing off a recent build at Flashbelt in Minneapolis a few weeks ago. One of the challenges I’ve had with blogging is that many of my projects can’t be talked about while they’re under development. Fortunately, these things don’t stay hidden forever!

One of the projects I worked on a while ago that I can now talk about is a new approach to more effectively search Flash based applications and content. We developed it in collaboration with Google and Yahoo. Google is in the process of rolling it out and Yahoo is committed to doing so in the near future.

To understand why a new approach is needed, let’s take a step back and examine how search engines work with basic web content today. During the indexing process, HTML and other well defined file formats are retrieved, parsed, and analyzed for content such as text, graphics, metadata, and most importantly links to other content. By traversing the set of links, the indexer can crawl the site and discover all of its content.

This works because HTML is a simple, declarative format that is easy to parse and understand. Or at least, that’s how HTML used to be! The declarative nature of HTML is important, because it means that you can look at a tag such as a link or heading and the format "declares" what it is. You don't have to run any code to understand it – you can tell just by looking at it.

The fact that SWF files are binary has led some people to conclude that this is why Flash is hard to index. However, this isn’t really the reason. Search engines can and index SWF files today.

What actually makes Flash hard to index is the same thing that makes AJAX applications hard to search, and that is that they don’t work like simple, easy to interpret HTML. You can't tell what they do just by looking at them. Rather, they are complex bodies of code that execute in the browser and do non-discoverable things such as calling out to web services and dynamically generating what the user sees.

In fact, this morning I was reading a report about what we’ve done on news.com, and some of the comments illustrated how pervasive the problem is even though they thought they were doing otherwise. The issue brought up was a simple one – how can Google and Yahoo even figure out what SWF file to load, since it's done with complex JavaScript? One commenter wrote: “Will Google and Yahoo parse everyone's different javascript technique to reveal where the .swf file (is)?”

This gets to the heart of the problem. Search engines can no longer figure out what’s happening simply by looking at the source code – they have to run it, whether it’s complex JavaScript to load a SWF, some XML, or other content, or the Flash application itself.

So what we’ve done is to enable the search engines to actually run the app just as an end user would. They can not only run it and see the information that’s displayed, including data dynamically loaded from the network, but can interact with it as well, pressing on buttons and links to interact with the app and explore all of is content.

To enable this we have created a special version of the Flash player that is designed to run on the server as part of the indexing process. As the code executes, there are special API that notify the search engine when something changes and that allow inspection of the textual and other data that would be displayed to the user.

There are other API that enumerate links and allow the indexer to instruct the player to simulate a “click” on various objects that are displayed. In this way, the indexer can navigate the running app.

What’s especially cool about this is that it doesn’t require any changes to the application code to enable it to be searched. It just works.

Of course, adding things such as deep-linking – exposing URL for distinct parts of a running app, will make searching content more effective, but it’s not required. This and other techniques will undoubtedly become important tools for optimizing how to most effectively expose Flash-based information to search engines.

Posted by Mark Anders at 09:05 AM | Comments (1)

January 17, 2008

Scoble Encounter and Thermo Interview

I, along with other members of the Thermo team went on a customer visit in downtown San Francisco yesterday to get feedback on new features. After each of these meetings we get together at a coffee shop to debrief and record what we learned.

Immediately after we came out of "Massimo", where I had a nice Cappuccino, Steve Heintz and I ran into Robert Scoble, who did a quick video interview with me about Thermo. We also talked a little about Silverlight, competition with Microsoft and a few other things. You can see the interview here.

Robert, who I believe is in San Francisco attending MacWorld, was with photographer Marc Silber, walking around town testing out a Nikon D3 which Nikon graciously loaned him. Marc took a picture of us that he posted to his site here. Robert and I are both ex-Microsofties, so it's always great to talk with him about what's going on.

Interestingly, Ethan Eismann, who is the product designer from Adobe's XD (Experience Design) Team working on Thermo also blogged about this. Ethan is a key part of the Thermo team and we work closely together.

Ethan and I even had a bit of a "bonding experience" when, while riding in a cab on a previous customer visit, we noticed the distinct smell of marijuana while stopped at a traffic light that got stronger after we asked the driver to close the windows. It was then, while driving at high speeds on the freeway that we realized that our driver was completely stoned! This was confirmed when we arrived at our destination and the driver giggled uncontrollably and referred to Ethan as "fancy pants"!

So, after all we've been through, I was suprised to see Ethan's post titled "Marc Anders, Scobelized". Ethan, it's Mark with "k"! Maybe that's his way of getting back at me for continuously reminding him of the "fancy pants" moniker!

Posted by Mark Anders at 06:16 PM

September 18, 2007

Thermo!

Well, the cat is out of the bag, so to speak... People are blogging about Thermo and Ted Patrick just posted a note about it being in the keynote at MAX. This is all according to plan. Or almost...

I haven't been blogging at all for the past few months and the reason is that I've been hard at work leading the team building Thermo. I am REALLY excited about it! We're going to be showing it as part of the MAX keynote in a few weeks and I think it's going to really be an important product and can't wait to show it off.

When Sam Robbins blogged about discovering a job description for an Engineering Manager Position on Thermo, it caught some people by surpise. In fact, here at Adobe, there was an email flurry and someone suggested that we need to make sure we scrub external job postings for codenames. This part was all part of my plan.

When I wrote the job description, I wanted the Thermo codename to get out, and I carefully worded the job description to get people excited about it without giving away all of the details, which we would be revealing at MAX. My plan was that I would blog about the job description to do two things.

First, I wanted to get any great Engineering Manager who wants to work on an exciting 1.0 product that will have a huge impact to apply for the job. So if that's YOU, please click on the link and follow up with the Adobe recruiting team.

The second thing I wanted to do was get people excited about MAX. I think it's going to be a great show, and there is going to be a lot of really fantastic stuff shown. I think Thermo is really going to open some minds and so I definitely wanted to get people excited about MAX and to realize that if they thought that this was the year to skip it.. well think again!!!

What did not go according to my plan is that I was supposed to first one to blog about it! Argh!!!! What I hadn't exactly anticipated was that when the story broke somebody else from Adobe would reply, in this case Ted. But Ted captured a lot of the key stuff I wanted communicate about Thermo. It's really exciting, it's going to very important product and we're going to be showing it off in the keynote. So if you want to be up on where we're going with creating RIA, come to MAX!

I hope to see you in Chicago! (Or Barcelona or Tokyo!)

Posted by Mark Anders at 01:38 PM | Comments (12)

June 10, 2007

Flex 3, AIR and Flash Player Betas Now Available!

The first public beta release of Flex 3, AIR, and Flash Player 9 update 3 is now available on Adobe labs. This provides an early look at what will be a very important release. I'm sure there will be lots of coverage about this, but here are some of the things that I think are really important. You can get more info and the software itself at the following URLs:

http://labs.adobe.com/technologies/air/
http://labs.adobe.com/technologies/flex/
http://labs.adobe.com/technologies/flashplayer9/

Flex 3

The backdrop of Flex 3 is of course that it is going open source and that the community will be able to get much more involved with how it develops (pun intended)! As part of this movement, we've made the bugbase public, now. You can access it at http://bugs.adobe.com/flex. What are the important features that you can start filing bugs on? Though I can't say that there will be any bugs in the follow areas, here are some of my favorite new things in Flex 3.

We've created a way for a dramatic reduction in the size of SWF files by adding a way for Flex and some other libraries to dynamically linked and shared across applications, similar to DLL's on Windows or Shared Libraries on other systems. This means that end users will only have to download the Flex Framework library once.

For people who like to work with code, we've added in a number of refactoring operations that work across ActionScript and MXML. To aid in the creation of high performance apps we've added both memory and performance profilers to Flex Builder.

We've also really improved how one hooks up to data. There are data wizards that will generate both client and server code to hook up to existing database tables. On the server side we'll be supporting Cold Fusion, Java, PHP and my old love, ASP.NET.

For those of you consuming Web Services from your Flex apps, we've added web service introspection which will auto-generate client side proxy classes from WSDL signatures. This will handle complex types often returned from web services. The big benefit here is that it enables complete code hinting and compiler verification when working with web services.

Flex 3 has a number of features for making it easier to build great looking apps. There is integration with Adobe Creative Suite 3, so that you can easily import skins created in CS 3 apps by using a wizard that will generate the code to assign the assets to components. There is also the ability to create Flex components directly in Flash CS 3!

There is also a visual CSS editor that's really cool and number of enhancements to design view such as Pan and Zoom tools, and an improved constraints system and editor and much greater fidelity for fonts and item renderers.

Perhaps my favorite feature is the new Skin states feature, which was something I was pushing for. This really helps the Flex/Flash integration but will become even more important in the future!

Of course, there is also a lot of support in Apollo for building apps that run on AIR -- I love the way that sounds!

AIR

The Adobe Integrated Runtime, or AIR is the official name of what was codenamed Apollo and there are a lot of new features for Beta 1!

There is native OS drag and drop support as well as support for multi-windowed applications. We've also added complete rendering support for HTML content courtesy of the integrated WebKit HTML engine.

In addition to providing access to local file system, one of the big new features of AIR is that it integrates a local database engine so that you can store complex data locally.

Of course there is complete support in Flex and Flex Builder for creating AIR apps. We've added AIR specific components to Flex for things such as Windowing and HTML, and Flex Builder has an AIR project type. This will auto package everything up so that building apps is really easy.

Flash Player 9 Update 3

While this piece of technology has the most modest name of the bunch, it has a number of really compelling features.

There are enhancements to full-screen mode to use hardware scaling for improved video performance and quality. While his feature is not available on Linux in Beta 1, it will be available in a later release. What is there for Linux is full-screen mode, which is especially good news for people watching video on Linux.

There is also faster rendering of vector graphics on multi-core CPUs, which of course are becoming commonplace.

Finally, the ability to cache the Flex Framework as a common platform component is really enabled by the Flash Player. This is a really major feature that we'll be taking advantage of in exciting ways in the future!

All in all, this is an exciting release of a number of important technologies, so dig in and enjoy!

Posted by Mark Anders at 10:10 PM | Comments (1)

April 25, 2007

Flex To Go Open Source!

Today Adobe has announced that it will be open sourcing Flex by making the source code for the Flex SDK available under the Mozilla Public License (MPL). This includes everything needed to build Flex applications, including the source to the ActionScript libraries in the SDK, the Java source code for the ActionScript and MXML compilers, and the ActionScript debugger.

In addition to the Open Source license, the Flex SDK will continue to be available under a commercial license to provide customers and partners flexibility in how they license the Flex SDK. We will also continue to offer other products that use the Flex SDK, such as Flex Builder, Flex Data Services, and ColdFusion under a commercial license.

Unlike what we did with the Tamarin project a little while ago, for Flex Adobe plans to sponsor and host the Flex SDK project infrastructure. This includes the open bug database, source repository and project planning forums. The initial committers will be the Adobe Flex engineering team. Members of the current Flex SDK development, QA, and product teams will become full-time contributors to this open source project. Adobe expects to add external committers to the project as we roll out the infrastructure and governance process for the Flex SDK project.

I am really happy about this. At Adobe, we have been working hard to improve how we work with developers. In many ways, our initial release of Flex 2 was the first major step in this direction, by creating a framework and tools that really appeal to developers. Open sourcing Flex is the next big step and I think will accomplish a number of important things. First, it should help us reach a new set of developers. More importantly, it will give the community a bigger voice in how we move Flex forward and allow them to directly contribute to its evolution.

We are also hoping that this encourages others to create tools targeting Flex. While I'm really proud of the job we've done on Flex Builder, we want there to be a diversity of tools at different price points and targeting different users. And though it will create competition for Flex Builder, it will ultimately help Flex and its users be more successful.

You can get all of the details at www.adobe.com/go/opensourceflex.

Posted by Mark Anders at 07:37 PM | Comments (3)

April 05, 2007

Great Article on Flash, Flex and Apollo in The Guardian

Charles Arthur wrote a great piece on Flash, Flex and Apollo in today's tech section of The Guardian, based on an interview I did with him when I visited the UK a little while ago. Overall, I was really happy with the contents and tone of the story. He really hit on the key points I was trying to get across about how Flash has evolved, how we are moving it forward with Flex and Apollo, and how it is enabling people to do new things on the web.

However, while reading Ryan Stewart's post about the story, he said "I’m a card-carrying member of the Mark Anders fan club, but saying that Flash is the new publishing tool of the century is a bit much" and two things confused me. First, members of my fan club have secret decoder rings, not member-ship cards, but more importantly, I had no idea what he was talking about with "the new publishing tool of the century" line. Where did that come from?

So I went back and re-read the article and it was then that I found out that it was actually the title of the story and that I supposedly said it! Now, I don't remember using those words, and interestingly, in the article they do not appear within quotes. However, in looking at the context of the statement, I think I understand what it means.

One of the things that I did talk to Charles about was that the type of content that people publish on the Internet has been changing and moving beyond text and images . YouTube of course has been a runaway success in web video and one of the key things on MySpace has been for bands to publish their music via embedded music players. In each of these cases, both of which are among the most popular sites on the internet, Flash has been the enabling technology.

Now, did Flash create web video? No, and neither did YouTube. But in the many articles I've read about YouTube's success, one of the key differentiators mentioned is that their video player "didn't require users to download and install software."

Of course, this isn't technically true. People did have to download the Flash Player. However, because we have always kept it small and made installation smooth and worked hard to get it on the vast majority of machines out there, the experience for almost everyone has been that they go to YouTube and it just works.

So while I don't recall saying that "Flash is the new publishing tool of the century", I do believe that as we've moved into the 21st century, the web has transformed to include more than just text and images, and that Flash has been an enabler of that shift to a richer web experience.

Posted by Mark Anders at 03:22 PM | Comments (6)

March 15, 2007

Make Flex Development More Like ASP.NET

...or like ColdFusion, PHP, JSP, etc. Tonight, one hour from now, at 7:00 PM PST we're releasing a new web tier compiler on Adobe labs. This allows you to simply copy the Flex files into a directory visible to your server and your app will be compiled automatically when you request the main application file using your web browser. The resulting model feels very similar to working with ASP.NET.

Who would be interested in this? My feeling is that it's best for people who don't want to or can't use Flex Builder, such as Linux developers, as it really streamlines working with the free SDK. However, it could be useful to Flex Builder users too.

It is available for both Apache and IIS, and runs on Windows, Mac, and Linux, and you can access it here after 7PM PST tonight.

All that's needed is a Java Runtime Environmnet (JRE). This has NOTHING to do with Flex Data Services and FDS applications will not run with it. It does NOT require J2EE. It's just a simple piece of software you can deploy to make Flex development more like standard web development. Enjoy!

Posted by Mark Anders at 06:00 PM | Comments (7)

March 05, 2007

Flex 360 Keynote

I gave the keynote at Flex 360 this morning and overall it went well. I showed a number of cool examples, including some that hadn't been seen before, that I think help illustrate what makes Flex magical.

The first example I showed was something I wrote, which is a partial implementation of SVG as a set of Flex components. The way it works is different from actual SVG implementations, in that there is no interpretation of XML. Instead, I have a set of Flex components that, when you apply the rules of how MXML maps ActionScript objects to XML, look like SVG. So you can embed SVG into your Flex app and the Flex compiler turns it into a set of objects that render the SVG content.

I also showed a bunch of examples that are available on the web that illustrate what I think are important concepts in Flex. The examples are are really cool and look great. The first one illustrated the way Flex allows you to build new things via composition. The finished example was Doug McCune's very cool MXNA navigator. You can see it here. This was built from other components, such as Ely Greenfield's fisheye component and Josh Tynjala's treemap component, as well as the work of Alex Uhlmann and Ben Stucki. Doug talks about how he did it here.

I showed some other examples such as Ely's LightTable example, which you can find here as well as two applications that are stretching how one thinks about Flex apps.

The first is Picnik, which is very nice image editing program. What I think is interesting about it is that it looks like a standard web app, but is implemented in Flex. This might seem like a contradiction to some. After all, should one really create something that looks HTML-ish in Flex? To me, the answer is, if that's what you want to do, go for it, as long as you create a compelling user experience. I think Picnik has created something that's functional, responsive and easy to use.

The second example I showed was Virtual Ubiquity's word processing app, code-named Buzzword. They're still in stealth mode, but you can find the latest information at their site. This is a really amazing app and goes far beyond what you see in AJAX based word processors. For example, it does advanced text wrapping around images in ways that you can't do in HTML.

Mike Downey joined me on stage to demo Apollo and he showed Buzzword running as a desktop app. He also showed a bunch of other Apollo stuff, some of which I believe hasn't been seen before. Of course, people seem to be going crazy every time they see Apollo stuff, so I probably should have done the demo myself so that Mr. Downey wouldn't upstage me, but he does a great job and is a nice guy as well, so it was great to have him there.

Of course, since this was a keynote, there had to be a snafu, and there was. While cmd-tabbing between applications on my MacBook, the entire machine locked up! At the time, I thought that it could be because PowerPoint is a Rosetta based app. However, afterwards, someone told me their theory as to what happened. They said that they've had lockups on their Mac when cmd-tabbing after having added a secondary monitor as in a presentation scenario. His Mac was a G4 PowerBook, not an Intel Mac, so the Rosetta angle wouldn't apply. It's an interesting theory!

Anyway, I was able to reboot and everything else went well. There's a great buzz at the conference and I'm sure there will be lots of posts detailing more of what goes on at Flex 360!

Posted by Mark Anders at 10:25 AM | Comments (4)

March 04, 2007

Heading down to San Jose for Flex 360

I'm heading off to San Jose today for the Flex 360 conference and I'm really excited about it! This is my first Flex specific conference and the fact that it's sold out means that it should have a lot of energy. That it has been organized by EBay kind of blows me away!

In the past, when I've been involved in technology specific conferences, such as for ASP.NET, the conferences were always organized either by conference, training or consulting companies or by the company producing the technology. Having a company that uses the technology put on the conference is a new one for for me but I think reflects the type of excitement you see around Flex. That the company is one of the top internet companies around makes it pretty incredible.

There's a great line up of speakers, both from Adobe and from the community. At the office on Friday I saw Chafic Kazoun and Grant Skinner, both of whom are well known in the community and will do a great job presenting.

There is also a lot of excitement from Flex team members. David Zuckerman is practically bouncing off the walls and will give a kind of unique session on how to extend Flex Builder to do cool new things. He's also threatened to spill the beans on what goes on inside the Flex team, and though I'm no longer officially on the team and so probably won't be included, if he does say anything about me, please don't believe it!

Now, you might wonder why I'm heading down to San Jose today, since the conference starts tomorrow and I live in San Francisco, which is just a short drive away, and since I'm not listed as a speaker. Well, I'll be giving tomorrow's keynote presentation, with assistance from Mike Downey, and it starts at 8:30, so I need to be there bright and early. I'll actually be showing some cool stuff in the keynote including some things that I've never shown in public before, so I'm really looking forward to it.

Hope to see you there!

Posted by Mark Anders at 10:15 AM

February 27, 2007

Got Flex?

Well I'm back from FOWA and, despite the poor quality of the internet access, my talk went well. Afterwards, I spent a bunch time talking with people about Flex and Apollo, and just about everyone was really impressed by what we're doing. One of the things I did in my talk was to build a Flickr browser in a couple of minutes using Flex . While this wasn't a new demo, I included it because a lot of people still don't know what Flex is. Based on how many people came up to me to tell me how cool Flex looked, I think that it's a great way to show the power of Flex.

Of all the people I talked to, there was really only one who was not impressed with Flex, and his name is Yaniv Golan. We actually talked about it for quite a while. While I normally wouldn't write about something like this, Yaniv blogged about it over the weekend and even included a picture of me and so I thought I'd respond.

In his post, titled "Why I don’t get Adobe Flex", he admitted that "Actually, Flex looks great. Solid architecture, slick IDE, modern declarative markup language and scripting language" but goes on to question why anyone would use it when they could use a standards based approach based on HTML, CSS and JavaScript.

Having talked to lots of people who've chosen Flex, the key things I've heard is that it enables them to be more far productive in building their apps, has features not supported by HTML/AJAX, gets rid of the headaches of cross-browser implementation differences and is a more solid environment for large applications.

In his post, Yaniv speculated that:

Flex must have been a huge engineering effort. Could the same effort have been dedicated to delivering the same productivity and reliability advancements, but with the markup and the script "compiled" into XHTML + CSS + JavaScript instead of proprietary Flash runtime bytecodes?

One of the things that Yaniv might have missed at FOWA was that even people who are committed to and building with AJAX have issues with it. There was a great talk given by Jonathan Rochelle of Google who runs their Docs and Spreadsheets product where he talked about how poor AJAX is for large scale development. This is a complaint I've heard from many people building applications in AJAX.

Now, when someone like Jonathan says that AJAX is not a great foundation for robust applications, I don't think he means that it would be great if only he had better developers or if Adobe had spent their energy developing Flex for AJAX. The fact that you have multiple implementations of varying quality and that the browser infrastructure wasn't really designed for large applications means that no matter what you do on top of it, you can only go so far. We are trying to improve things for AJAX, however.

One of the things that I highlighted in my talk is that ActionScript 3 is based on the same standard as JavaScript, and we've been helping to move the standard forward to provide a better language for applications, whether they are using HTML or Flash. We've also donated the code to the ActionScript Virtual Machine to the Mozilla foundation to help improve the implementation in Firefox. The development team now consists of both Adobe and Mozilla engineers and the implementation will be the same across future Firefox and Flash Player versions.

Interestingly, Yaniv's blog entry was a bit different from the conversation we had. During our chat, his basic question was why would anyone use Flex when ASP.NET is just as easy to use and the result would be an HTML app which is standards based. However, in his post he phrases this as "I don't get it. Why would an architect choose to rely on a proprietary runtime, available only from a single vendor?"

What I found amusing about this is that if Yaniv is really so worried about vendor lock in, why on earth would he be using ASP.NET? ASP.NET, while a great technology, is single vendor lock in. And not only that, but it's expensive lock in. Flex, on the other hand, is a free framework, running on a free runtime. The free SDK even runs on Linux. Also, when you get the free SDK, you get all the source to the framework.

But to answer Yaniv's fundamental question, why would someone choose Flex? Hopefully because it solves real problems they have better than anything else. This could be because the runtime is richer and more expressive, after all, you have drawing API, video support and other things that just don't exist in HTML. It could be because it has a faster, more modern, more strongly typed language that enables better productivity tools to be created. It could be because Flex has a richer, more consistent architecture, allows you to easily bind to data and customize how it's presented. It could be a host of other reasons.

In the end, I was really glad that went to FOWA and got to meet so many people who really "got" what we are doing with Flex, ActionScript 3 and Apollo. I really DID enjoy meeting at talking with Yaniv, too. We had a nice, spirited debate. He might not "get Flex" yet, but maybe some day he will!

Posted by Mark Anders at 07:37 AM

February 20, 2007

Apollo Buzz at FoWA

I'm in London this week where I'll be speaking at the Future of Web Applications conference on Wed morning. My talk is going to be about some of the key things Adobe has been doing to improve the web application platform for apps running in the browser and how we're enabling developers to apply their existing skills to building desktop apps with Apollo.

I'll be highlighting our work on the EcmaScript committee to improve JavaScript, our collaboration with Mozilla on the Tamarin project to improve the virtual machine technology in both Firefox and the Flash Player, and of course what we've done with Flex to make Flash development comprehensible to developers coming from a client or web dev background.

Since I'm speaking on day 2, I was able to experience some of the Apollo buzz, and it's pretty huge. In his talk this morning, which opened the conference, Michael Arrington from TechCrunch said that Apollo is one of the great opportunities for those seeking to start new web businesses, and predicted that there would be a number of new companies founded based on Apollo! I was pretty blown away by how strongly he came out in favor of it.

I also hung around the Adobe booth and talked to a ton of people who were really interested in learning more about Apollo, so there's definitely a lot of excitement about what we're doing.

The only downer about the show for me is an erroneous assumption I seem to have made. When I present, I love to give demos, rather than just going through a set of slides. Since this was a conference about "Web Applications", I assumed that there would be internet access, at least for presenters! Well, I was wrong.

It turns out that British Telecom mistakenly disconnected the phone lines that were installed for the show a couple of days before it began and there's no way to turn them on again. Oooppsss! The publically available (and very expensive) BT wireless was unbelievably slow today, but I'm keeping my fingers crossed that it will work better tomorrow. We've have cobbled together a bit of a backup plan, but hopefully the wireless Gods will be on my side tomorrow so I can continue building the Apollo buzz with some great demos!

Posted by Mark Anders at 03:09 PM