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)

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

March 01, 2006

Actionscript 3.0 Libraries and FlexUnit Released on Adobe Labs!

There is a great set of resources for Flex 2.0 and ActionScript 3.0 posted to Adobe Labs. You can access them here. There are a number of really useful ActionScript 3.0 libraries that allow you to interact with services such as Flickr, Mapper, Odeo and YouTube, as well as ones to deal with RSS and Atom. Additionally, there's a "core" library that has lots of useful stuff such as MD5 hashing, JSON serialization and more.

One of the most important things, from my perspective, is FlexUnit. Over the past year, a lot of people interested in Flex Builder have asked us if it included a unit test framework. Our response was that we would release one, and with the release of FlexUnit, we've delivered. Unit testing should be an important component of your development practice, and so I encourage everyone who's interested in Flex to download it.

Enjoy!

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