Mark Anders' Blog

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

September 12, 2006

Sneak Peeks at Flashforward

During Kevin Lynch’s keynote at Flashforward in Austin, TX today, I had the opportunity to demo both Flex Builder and Apollo One of the things that Kevin wanted to do was to have each demo be a sneak peek of something, so everyone who presented had to have something new to show.

Flex Builder 2.0 for Mac

The first part of my demo was to introduce Flex concepts and I built the Flickr browsing app, which a number of us have done before, so that wasn’t new. What was new was that I built it using Flex Builder on my MacBook Pro! This was the first time that we’ve shown the Mac version publicly, and it went great. Often when you demo pre-beta software, you have problems, but Flex Builder worked like a charm.

Now my whole presentation had to be between 10-15 minutes, including slides and witty banter, so the Flex part was probably under 10 minutes, but I was able to show off design view, and MXML and embedded ActionScript coding features. The performance is great and it’s been very stable.

Building Apollo Apps

There were a couple of new things in this demo. To start with, this was the first time that we’ve demoed actually building an app for Apollo. Previously we have shown apps running on Apollo, but haven’t ever shown what’s involved in getting them to do so.

What I did was to take the Flickr app that I developed in the first part of the presentation and converted it into an Apollo app that ran outside the browser. To do this, there were just a couple of tweaks that I had to make, most notably switching the Panel to an ApplicationWindow so that it would get Maximize/Minimize/Close controls and to configure Flex Builder to use the Apollo launcher instead of the browser.

Another interesting thing about the demo was that I again did it on the Mac. Previously we hadn’t even shown Apollo apps on the Mac and so it was really cool to be able to not only show it running on the Mac, but building it there, too.

Finally, I showed an example of an Apollo installed my system like any other desktop app. For that, I had a version of the Flickr app in the Doc of my Mac and ran it from there. One thing that I did not mention during the demo and nobody would have been able to figure out is that I actually built the installed app on Windows and just copied the app package over to the Mac where it installed itself.

Originally, I had planned to demo the installed app on Windows running in Parallels on my Mac and show how it could be just copied over to the Mac and run. However, the networking at the hotel where the conference is taking place had been very flakey and I was having throughput problems, so I wanted to simplify the setup and so that part was dropped.

Looking Forward to MAX

There were lots of other great demos given during the keynote. Big Spaceship showed their Nike Air site, which is really cutting edge, running on Flash Player 9 for Linux, which was the first time we’ve shown that. Mike Downey and Justin Everett-Church followed me with lots of great features from the upcoming Flash 9, including the new Photoshop import wizard, which looks fantastic, as well as my personal favorite, being able to save timeline motion as XML is really MXML, so you can paste it into a Flex app and it works!

Overall, the next few months should be really exciting as things get polished up for MAX. Don’t miss it!

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

June 29, 2006

Flash Player 9 for Intel Macs Beta Available Now!

I wrote yesterday that we were really close to having a Beta of Flash Player 9 for Intel Macs available, and the code Gods did not let me down! It's available right now, less than 24 hours after my original post. You can download it from http://www.adobe.com/products/flashplayer/public_beta/. Check it out!

Posted by Mark Anders at 11:38 AM | Comments (3)

June 28, 2006

Flash Player 9 for Intel Macs

Emmy Huang has a great post about Flash Player 9 that you should check out here. One of the key things she mentions is that a Beta version of Flash Player 9 for Intel Macs will be available in the next couple of days. Emmy's wording on this was a bit confusing, so I went to talk with her for clarification. The team is really close and hoping to get it out this week. However, things do come up and so we don't have an exact date, but it is really soon.

Ironically, as I was driving to work this morning, I saw Paul Betlem, who is the head of Flash Player Engineering, walking up Townsend St, so I gave him a ride. We started talking about what's next for the player, and when he told me how close they are to Beta for the Intel Macs, I nearly did a back flip…except for the fact that I was driving and had my seatbelt on! The reason is that over the past couple of months, I have shifted over to a MacBook Pro for my main machine. It allows me to run both Windows and Mac and I love it. However, I was bummed that the only way I could run Flex 2 content was in Windows.

So, when I got to work, I got a link from Paul to the most recent build, installed it, and gave it a whirl. It rocks!!! Despite what Emmy says about it not being completely optimized, which is probably true, I'm really impressed with the performance. So if you're an Intel Mac user like me, it should be here really soon. I promise!

Posted by Mark Anders at 03:54 PM | Comments (2)