… Could have been the title of this post 3 months ago. Given the recent layoffs and announcements in the past few weeks, it may seem short sighted to be overly excited faced with this news today. This was, however, a part of the announcements recently by Adobe regarding Flex. They are committed to contributing Flex (and several complimentary projects) to the Apache Software Foundation (ASF). I personally witnessed the commitment and plan for this at their San Francisco office. Many leaders of the Flex community gathered at Adobe SF by request of group product managers Deepa Subramaniam and Andrew Shorten this week. We heard from senior management on their new strategic vision for Adobe around digital marketing and digital media. We heard apologies for the accelerated and miscommunicated nature of the messaging of the past few weeks. And, we, most importantly, heard about the future of Flex as it may likely live in the ASF.

There has been a lot of focus lately on the poor messaging to the community around the announcements of late. I don’t disagree about how destructive and misguided this messaging was, but I do think it’s important to see it as the past and move on. Many in the community may criticize this idea. It would be easy to say this is one of many moves towards under valuing the community. Again, I wouldn’t totally disagree, but I do think this particular moment in history is different than in the past. Here’s a bit of an explanation…

The ASF model for development is much different than how a product is developed by a corporate software vendor. On an Apache project there are no project managers, product managers, senior vice presidents, presidents, CEOs, CTOs, development managers, senior engineers, or any other title of a role that you can think of; other than “commitor”. A commitor has the right to commit code to and vote on a project. You can read a lot more about the ASF process on their site. So, what’s the big deal? Why is this different than a time in the past that Adobe (or any company) did wrong by it’s community, said “we’re sorry”, and kept moving right along? – This time they’re actually handing over the reigns of the project to us; to the community.

Adobe will not have contributors on the Apache Flex project. Neither will Spoon, Roundarch or any other corporation or group. This is (technically) true because contributors are individuals. So, there will be some individuals who are contributors on Apache Flex that will also be Adobe employees, but they will not have any higher status or privilege than any other contributors on the project. This is by design. The design of the ASF. The process of Adobe contributing Flex to Apache is in the form of a proposal. That proposal states the intention of all initial commitors to create an Apache Flex project, among other details. Up until Apache Flex is realized as a full project there will be a phase of incubation. During this time Apache will work with the proposal submitters to help arrive at a proposal that fits the Apache model. This is to ensure the best possible arrangement for a successful Apache Flex. That’s why this moment is different than similar times in the past. By this model, Adobe gives up the sole control and direction of Flex and enters into a partnership with the community to drive the future of the framework, with the guidance of Apache. Without that partnership Apache will not accept this contribution. So, for those claiming Adobe is “giving Flex to Apache to die” or “dumping off Flex with Apache”, this is simply not true. It also shows a severe lack of understanding and respect for what the ASF does and has done.

We have not heard this before. This is a new approach with a high potential for excellent collaboration of all the individuals and entities that depend on Flex for critical business needs. These individuals and enterprises need a path to a future that enables their teams and businesses to deliver the high quality solutions they (and their customers) are accustomed to. For many enterprises developing highly complex applications with millions of lines of code, large development teams, and high expectations for success, Flex was and still is an extremely valid technology, for others it is a requirement. There are enterprises that are so vested in using Flex to build (or maintain) a platform for their businesses that a short term migration is simply not possible. This is not an understatement. Individuals from enterprises like what I’m describing were present and vocal at this recent Flex Summit.

So, what else did we hear as it’s relevant to Flex?

A paraphrased quotation, as I can’t remember the exact wording:

Adobe will not continue to develop Flex as a “stand alone” business.

It was also stated that Adobe does not currently have plans to develop any product targeted at enterprise scale user interface development. That’s not to say they aren’t developing tools for HTML5 development, just not a platform like Flex based on HTML5. They are committed to their runtimes for what seems like a minimum of 3-5 years. All of the current runtimes (less Flash Player for mobile browsers): Flash Player for desktop browsers, AIR for mobile (iOS, Android), and AIR for desktop (Windows, Mac OS).  However, it does seem clear that this runtime development will be focused in line with their new strategy of digital marketing and digital media. For Flash that means game development and video. There are certainly concerns around this regarding Flex. Game development is very different from enterprise class development. They have also stated that they will commit to backwards compatibility to meet all the dependencies that exist today in Flex 4.6.

My thoughts on the future of Apache Flex…

Apache is the the future for enterprise class Flex. For those highly skeptical and critical of Adobe, my message to you is this: The move to Apache is a big one and categorically different from anything we’ve seen in the past. Is Apache perfect? I doubt it. What it’s not is proprietary or corporate. It also answers in no way to a group of public share holders. It is not driven by senior management who are making business decisions to please those public share holders. It has no “layoffs”. It is not driven by the sales of an IDE. Further more, it has no goals of making profit – at all.  It was founded and is governed by folks that really understand open source development. It is one of the most respected software foundations in the world. What Apache Flex can be is a powerful force for the community to drive the future development of Flex and deliver in a way that holds true with the most important needs of the community – governed and guided by the Apache model for open source development.

I also believe that development is just one factor in the future success of Flex. Now that Adobe is stepping back from Flex there will be gaps in the future in the areas of: education, community (user groups, conferences, etc), quality assurance, support, tooling and potentially others. The Spoon Project may likely provide an appropriate group to support in these areas. There are already of mass of talented folks rallied around problems similar to these gaps in Spoon.

So, down to brass tacks:

What’s the reality of HTML5 as it relates to Flex at this moment in time?

HTML5 and open standards for the web will play a dominant role in the future of technology. What I believe is that this future is farther off and a bit more uncertain than many that make this statement. Let’s consider some recent figures by IDC. IDC predicts that 90% of smartphones and tablets will have HTML5-ready browsers by 2013. This means that 90% of consumers will be able to access your HTML5 application on their smartphone or tablet by end of 2013 (still 12 months away). However, the Gartner prediction of 81% smartphone penetration/adoption for 2012 was off by 50%. That stat is actually 44%. Even looking at the past month, smart phone purchases are only at 56%, well below that 81% prediction. The staggering number is 2015. 90% browser adoption of HTML5 is estimated for 2015. The Flash Player has historically had 90-99% adoption in desktop browsers. Additionally, there is no complete HTML5 specification. Notice: “Draft”.

In that respect an even more staggering number is 0. 0 is, technically, the current browsers that support an open standards based implementation of HTML5. Without a complete open standard it’s impossible to have compliance around that standard.

As Google, Microsoft, Apple, now Adobe and others seem to have consensus around the support for HTML5 in the future, none of these companies seem to do a great job at messaging when, exactly, this future is. Along with that I think many analysts are also doing a poor job of analyzing and messaging the capabilities of current web technologies. Part of that problem is the term HTML5 is now being used for anything related to HTML. Current support for HTML, JavaScript and CSS is a lot better than it was years ago, but comparatively (both to what HTML5 will be and what Flex and the like are now) it has many drawbacks. There is still a considerable amount of browser fragmentation to deal with, there are considerable challenges with styling for some experiences, there is a severe limit to the amount of performance of any browser’s JavaScript “runtime”, and there is still a lacking of support for mature approaches to software engineering when it comes to JavaScript. That doesn’t mean I hate JavaScript or think it isn’t a great tool for solving a lot of problems. It is my opinion on the comparison of the available choices for developing software on the web today – not the how that may or may not look in the future.

In the future that is next week and next year, Flex still has a place.. and that future is considerably more relevant than speculation on what is 3 years away… but back to the topic at hand: Apache doesn’t hedge on those futures. It supports a thriving community interested in building software. This is another huge reason that I see so much potential for Apache Flex. So, you won’t be hearing me making blanket statements like HTML5 is the future and you shouldn’t be building Flex apps. Or, Flex will be around for decades and HTML5 is completely overrated. Anyone who makes makes these kinds of huge generalizations is in one (or all) of these categories:

• A person who is trying to sell you something
• A company man (or woman)
• A technology zealot

If you’re an engineer or part of management driving the technological future of your organization, it’s probably not a good idea to listen to these kinds of people as your only source of information (or maybe at all). The sales person is driven by profits. The company man is driven by a career towing the company line. The technology zealot holds to their particular technology views without necessarily analyzing the reality of the tech landscape. These are all risky people to put your faith in. The technologist that can analyze trade offs, discuss options, strategize to meet business goals effectively; that is a person who I trust. That is a person who I want on my team, working with my customers, and solving critical technology problems with me.

More to come on Apache Flex as it develops…

Google+ comments.

The Good.

Flex came to us at a time where there was a shift in the way we were using technology to build software for the web. AJAX was just a baby, even though many (including myself) had been doing AJAX like HTML development on the web, long before the term was coined. AJAX and HTML were a decent solution for many problems, but browser fragmentation was worse than ever, and the languages of HTML, CSS, and JavaScript were supported by browsers and tools in an arcane way. It didn’t add up to tools that made sense from a software engineering perspective. So, a lot of us turned to ActionScript. A language that was part of a platform better suited for engineering with almost none of the fragmentation problems that plagued HTML/CSS/JS. These fragmentation issues were, of course, solved by a runtime called the Flash Player.

When I first came into Flash I didn’t have a high opinion of it. I thought it was that timeline tool that designers used to make fancy ads that annoyed me. When I really dug into the language and the platform though, I saw potential. So, at the time just before Flex, like many others in the community, I was building Flex-like apps based on purely ActionScript and the Flash Player. As a young developer who had worked in more classical desktop user interface frameworks like Swing, Visual Basic, etc, ActionScript and the Flash Player gave amazing freedom from the limitations of the way browsers were constructed to deliver markup content via HTML. Markup is not a particularly desirable framework for engineering user interfaces – Flash was better.

Then came Flex. Macromedia saw a trend in the market: building applications on the web. They also saw that a lot of folks were using their runtime to do this. Possibly in a way Macromedia had never intended. Flex came as a solution to this problem. The main benefits of Flex in it’s prime:

• A standard user interface component set
• Remoting (the ability to interface with web services via transferring typed objects)
• A better skinning and styling workflow (than HTML/CSS at the time)
• Efficient vector graphics for data visualization (charts, graphs, etc)

These add up to an excellent offerring for organizations developing custom, business critical software to run their enterprises. Previously we had seen tools like Visual Basic and Java’s Swing and SWT frameworks occupy this space. Among others, a main downfall with these options was the requirement of IT professionals to support pushing out new builds of desktop applications across enterprises. Flex came as enterprise IT organizations grew tired solving this problem. At the same time the web was maturing to a point where these kinds of applications could actually be served from a browser. It allowed a single web deployment of an application that could be updated and serve many users to solve the business critical problems so crucial to the success of the operations.

This is what I loved about Flex, and still love about it. It was a tool that could be used to solve these problems for enterprises in a manner that was so much more effective and engaging than what I had previously seen in tech. It also opened the door to engage with user experience practitioners in a way like we hadn’t really seen before. When I started working with colleagues in user experience roles it changed the way I thought about software. We weren’t building something to fulfill a boring requirements document, we were engaging users to create an experience that was different than what they were used to getting from software. The goal wasn’t just to make a better widget, it was to redefine what a widget was. We’re still doing that today and it’s still exciting.

Flex is still one of the greatest UI toolkits I’ve used to build rich UIs. I am proud to have been part of community that shared this opinion and pushed the technology so much of the last few years. I have met so many brilliant engineers, user experience practitioners, and visual designers; all folks who embraced and defined what we know now as rich internet applications. I’ve learned a lot from all of you, and it’s been a great ride. To those of you at Adobe that contributed to the progress of the product; thank you. No product is perfect and your contributions to the field of user interface engineering are commendable.

The Bad.

Over the past few years it has been clear that the product development of Flex has shifted from an user interface engineering tool as pioneered by Macromedia to a tool more inline with Adobe’s offerings for designers. From a user interface engineering perspective, this was bad. There are clear examples of platforms, both present and past, that are designed for software engineers to solve complex problems. Tools for; testing (unit, integration, functional), profiling, continuos integration builds, code coverage, etc have been largely left behind in Adobe’s product development concerning Flex. I say this is bad, but I also understand that from a company who’s made most of their stake on PDF, Fonts, and Photoshop sales, it’s understandable. From a business perspective I’m sure Adobe was interested in having repeatable success with Flex as they had with Photoshop and their other creative tools. The problem is, Flex is not Photoshop and the theory that it could be has been clearly disproven.

Obviously, these are my opinions on choices made over the last several years as they apply to Flex as an user interface engineering tool. It’s also my opinion, that Adobe hasn’t really been set on the path to make Flex the best tool for this as they seemed to be up until around 2008-2009. That’s not to say Flex isn’t still a great tool for these problems, it’s just that it hasn’t made the progress it could have in terms of an engineering tool. This “bad” really adds up to lost potential to be the de facto tool for enterprises building web based applications. What’s really disappointing is that, before last week, Flex still had the opportunity to be this tool, with little competition. I personally know folks who have created proofs of concept around patching the Flex compiler to compile a Flex application to run in a JavaScript environment – and it works. Not to say this is a trivial effort, but it is something that can be accomplished. So, instead of Adobe evolving their own platform and tools around the trending towards HTML5 they’ve, more or less, decided to start over.

Starting over is actually not that bad of an idea, but the side effect of dropping commitment to the Flex platform is estranging a development community that has been passionately committed to the platform over the years. These developers are reasonably disappointed and angry to have been left out in the cold. I think it will extremely difficult to earn back that commitment in the future.

The Future.

So, Flex Developers, what’s next? Flex filled a need. A need we all were looking for and many helped shape, but it was a reaction to what the industry needed and how technology was trending at the time. It was not a proactive stab to solve a problem that was known. We all worked through this together to get to a place where we had something pretty great to solve the problems in our industries. So, the point is, we did that, and we’ll continue to do it again. The industry is trending again in another direction, and it will trend again and again and likely never settle. This is another thing I love about technology – it is constantly in a state of reformation.

Does that mean Flex is dead? Not necessarily. To quote Jesse Warden from a thread we had on Google+, “Sun fubarred Java, and it’s still straight pimpin’”. The community now has the opportunity to redefine Flex once again. Maybe a plan of compiling Flex to JavaScript isn’t far fetched for the community. Anything is possible. At the same time, this moment provides a good opportunity to sit back and look at the land scape in technology. A proper engineering mindset should arrive at decisions pragmatically, not emotionally. We have a new era in front of us that continues to show the importance of user experience but also clearly points to the importance of apps.

Forrester coined this new wave as the “App Internet”. We’ve seen the revolution of desktop applications converging on the web. In this next wave we will see mobile as a defining factor in the internet technology of tomorrow.

What we’ve all learned by using Flex is greater than Flex itself. We’ve learned and evolved the way we solve problems in technology more efficiently and serve our users more effectively. Adobe cannot layoff these skills and we can use them to continue to evolve software and the way we build it.

I am fortunate to be surrounded with technologists, user experience practitioners, visual designers, and strategists at Roundarch who combined represent expertise in almost all things relevant to modern software development. It’s a lucky spot to be in and I’m confident in our proficiency to adapt both reactively and proactively to trends like this in the industry.

So, learn JavaScript / HTML5, contribute to Spoon.as, or write the next new amazing UI framework. Just don’t stop writing great software because of the change in direction of one tech company.

The conference, held at the 3LD (3-Legged Dog) Art & Technology Center, will feature tracks for Technology and Inspiration, along with the City track for exploring local landmarks. The Technology track will focus on coding and wiring for application architecture while the Inspiration track will center on design and user experience. The venue, which is a gallery for new media and experimental artwork, is meant to mirror the tone of the conference in the way it joins art and technology.

As part of the Inspiration track, I’ll be giving my talk entitled “Building RIAs with Style,” which I premiered at Flash Camp Chicago in February and have continued to refine since then. The talk starts with an introduction of lower level concepts about web graphics for developers, continues with exploring how some popular RIA frameworks handle styling, and wraps up by comparing two important workflow tools—Adobe Flash Catalyst and Microsoft Expression Blend—to demonstrate how the different platforms operate.

My goal with this talk is to provide rookies with a basis for understanding graphic assets, how to apply styles in RIA development, and the importance of styling as well as provide more advanced tricks of the trade for senior developers.

Check back to hear how it went, but first, watch my interview with Elad Elrom, Flash and the City conference organizer. Elad is a technical writer and senior Flash engineer, and he will also be leading a session entitled “Flex Data Binding Pitfalls: 10 Common Misuse Mistakes.”

Flash and the City is May 14-16 in New York, New York.

Vector Graphics – http://en.wikipedia.org/wiki/Vector_graphics
Raster Graphics – http://en.wikipedia.org/wiki/Raster_graphics

F*CSS

Site – http://fcss.flashartofwar.com
Source – http://github.com/theflashbum/fcss
Quick start – http://fcss.flashartofwar.com/quick-start-guide

Jesse Freeman – @theflashbum
http://flashartofwar.com/

FlexFormatter

http://sourceforge.net/projects/flexformatter/
http://flexformatter.googlecode.com/svn/trunk/FlexFormatter/FlexPrettyPrintCommandUpdateSite/ (Eclipse software update URL)

Thanks to Flash Camp Chicago for having me present and to Roundarch for sponsoring my talk… it continues to be a exceptionally well-run conference and one of the highlights in my presenting year.

[ Update : Mike added this post that I was unaware of when I wrote mine.. also helpful to clarify what's going on ]

Disclosure

• I am a Flex Developer
• I use Adobe products daily
• I work for an Adobe partner: Universal Mind
• I am a fan of the Adobe platform
• I worked on the eBay Desktop project
• I was co-creator of the Artemis Project (similar to Mike’s CommandProxy)
• I’ve also worked as a java and Microsoft developer in the past.

Add all this up and I think my background gives a bit of relevance to the conversation.

I’d like do discuss some of the real issues here and do it in an attack-free manner. But first, since the previous conversations escalated to attacking some of the people I know and projects I’ve been close to, I’d like to give some shout outs:

Mike

I’ve heard Mike speak several times, had a couple conversations with him, and read his blog pretty regularly. My impression of Mike has always been that he’s an extremely capable technologist who cares a lot about his product (AIR). I’ve had extremely brief discussions with him about competing technologies. There was never a time in the course of any of these discussions where he has bashed another product or an employe of a competing company.

Alan / eBay Desktop

I had the pleasure of working on the eBay Desktop application before the Alpha release in 2006 and for a time after that. Alan is a great guy to work with. Again, like Mike he also cares a lot about his product. As Alan stated, the eBay Desktop application is in beta (as is AIR). It’s hardly fair or relevant to criticize the user acceptance of an application that is in beta. For me, eBay Desktop isn’t about offline it’s about a better experience, but more on that would be off topic.

Adobe’s Developer Relations

I’ve had quite a bit of interaction with the Adobe evangelists, probably the most with Ryan Stewart, but also; Ted Patrick, Mike Chambers, Mike Downey and Kevin Hoyt. Ryan went out of his way to help me out with Artemis and other Flex related stuff even before he was an Adobe employe. All of the other guys I have listed have been more than reasonable in answering all of my questions or concerns. Quite frankly, it’s their job and they’re good at it.

Another place Adobe shines in developer relations is through their engineering team. I’ve had e-mails answered by engineers and product managers from the Flex team that have saved me a lot of time, and I know that I’m far from the exception in this case. In my opinion, this is stuff that they really don’t have to do and it’s very much appreciated.

None of this is meant to be an attack on Microsoft. It’s been over 3 years since I did any Microsoft development, so I really don’t know what they’re developer relations are like. It’s also not to try and get Adobe to buy me a house (although I wouldn’t turn it down). It’s just a chance to highlight the good things going on at Adobe in light of the criticisms raised. Now on to the real issues…

Scott brought up two points that were interesting to me. One was regarding security and the other was on the relevance (ie “what is being solved here?”).

On Security

As I understand it, there are two concerns regarding security. The first is data protection. In Mike’s proof of concept, as well as in the Artemis framework, the data that is exchanged between AIR and .NET/java is sent through a socket that is not encrypted. It is possible for another process to monitor this data and intercept it in the same way a sniffer process that inspects packets on an internet connection can retrieve sensitive data that is sent across the internet. This is a concern for someone building an application that might send sensitive data between AIR and .NET/java.

The second security risk is that another process might hijack the proxy process. It would be possible to build a malware AIR application that could connect to the proxy process and cause it to do very nasty things to the underlying system (like search the hard disk for credit card numbers, or just reformat it). To me, this is the bigger risk. An important question here is: Why is this different from a .NET application that might to the same nasty things? It is different because AIR is a platform that has a security model associated with it. This type of bridging gives a false impression of security to the user. The result is an AIR application to .NET or java that has taken on all of the security risks of the bridged platform as well as the risk of data protection in the transport.

So, Scott is correct, these are big risks and should not be taken lightly, however, where I disagree is that is that Mike as an Adobe employe has no right to explore these ideas publicly. The fact that he (and others at Adobe) work on projects like this make me even more interested in their platform as a developer. That’s not a claim that any of their products are better than the competition, which is arguably subjective claim from either side. What I appreciate is the philosophy at Adobe that allows for and perceives the value of this work. It’s work like this that showed us Quake running in the Flash Player at MAX.

If these kinds of methods were something that Adobe was interested in supporting, rest assured the security issues would be addressed.

On Relevance (What is solved here?)

When I presented Artemis at 360 Flex in August David Coletta asked a question on Artemis that went something like: “Pphilosophically is this a way to improve AIR or extend the capabilities of java?” This is really a similar question. So, why? My answer for that is one that companies selling platforms might not like, and that is: Ubiquity. As a developer I want ubiquity between APIs, frameworks, languages, OSes, and definitely platforms.

The idea for Artemis came from the desire to make the benefits of java (countless open source projects and many great language features) available to a Flex developer creating AIR applications. At the same time, providing the powerful UI capabilities of Flex to java developers. I’d rather stop thinking in terms of the dichotomy that either Flex / AIR or Silverlight / WPFE is better as a platform or for a particular project, and be able to use the great features of both technologies ubiquitously. Unfortunately, I think the days of building a Silverlight module and loading it into a Flex app (or vice versa) are far away.

To sum up…

This work is definitely not the kind of stuff you validate a platform on. It’s not a solution for most (if any) enterprise or consumer applications, but it’s fun, cool stuff. That’s what I love about this technology. It’s fun to create solutions with it and I love the challenge of pushing what it’s designed to do.

Mike, thanks for working on CommandProxy. It’s a great idea to get .NET devs excited about Flex and push what AIR can do. Scott, thanks for bringing your concerns, the real issues underneath all of the unnecessary comments from both sides are relevant and important.

ADOBE MAX 2007, CHICAGO — October 3, 2007 — Adobe Systems Incorporated (Nasdaq:ADBE) today announced the winners of the 2007 MAX Awards. Now in its fifth year, the global awards program recognizes innovative applications of Adobe software for creating engaging experiences. Adobe received nearly 600 entries from 30 countries in seven categories. Finalists in these categories also competed for a People’s Choice Award selected by the MAX attendees.

“The MAX Awards recognize the incredibly innovative work our customers do with Adobe technologies,” said Kevin Lynch, senior vice president and chief software architect. “The awards not only highlight some of the best designers and developers around the world but their work also serves as inspiration for others in the community and teams here at Adobe, often pushing the edges of what’s possible in our software.”

Winners were announced last night at a ceremony at MAX 2007.

- The 2007 People’s Choice Award winner was eBay with EffectiveUI for eBay Desktop.

- In the Advertising and Branding category the winner was Interone Worldwide GmbH for Incredibly MINI The new MINI, and the finalist was Fuel Industries | Karbon Arc for The Passenger.

- In the Communication and Collaboration category the winner was MFG.com for its Online Marketplace for the Manufacturing Industry, and the finalist was Hong Kong Police Force for its Scenario-based Interactive Multi-player Simulation (SIMS).

- In the Enterprise category the winner was Wachovia Corporation with Cardinal Solutions Group, Inc. for Wachovia Corporation – Service Request Management (SRM) Workflow, and the finalist was GES Exposition Services with Four Point Solutions Ltd. for GES Intellikit(SM).

- In the Mobility and Devices category the winner was Shockwave & AddictingGames, a MTV Networks Company for Shockwave Minis, and the finalist was Dalrus Pte Ltd. for OwnTape.

- In the Public Sector category the winner was NASA for its International Space Station: An Interactive Reference Guide and the finalist was US Border Patrol, Department of Homeland Security for its OASISS – Operation Against Smugglers Initiative on Safety and Security.

- In the Rich Internet Applications category the winner was eBay with EffectiveUI for eBay Desktop, and the finalist was BMC Software for its BMC Dashboards for BSM.

- In the Video category the winner was Big Spaceship with BBDO for HBO Voyeur, and the finalist was DHAP Digital, Inc. for Industrial Light & Magic’s The Show – The Visual Effects of Pirates of the Caribbean II.

Winners and finalists for the 2007 MAX Awards were selected by a team of Adobe judges. Selection criteria included innovation, application of technology, brand building and business impact and benefits. The winner of the People’s Choice Award was selected by Adobe MAX conference attendees. For more information on 2007 MAX Awards winners and finalists, visit http://adobemax2007.com/awards/2007/finalists/ .

Adobe – Adobe Press Room: For immediate release.