… 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 New York Jets command center core was built using Adobe AIR, Adobe Flex and Java Spring.

Related:

• Jets Owner Leaves No Stone Unturned
  
• Jets Want to Know What You’re Buying
• New Meadowlands Stadium Features Revolutionary Fan-Friendly Technology
• New NFL Technology Brings Fans Closer to the Action

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.

This example was developed using Flex 4 and Merapi .NET in C#. You’ll need the Flash Builder 4 beta to build the Flex code and Visual Studio 2008 to play with the C# code. However, if you’d like to skip that part, you can download the binary for the C# portion from here and just run it from the command line.

Additional resources:

HTML view of the Flex code
HTML view of the C# code
The Google Code repo

Thanks to Bob and everyone involved with BFlex for having me speak and putting on a great event.

In early 2009 Roundarch and Tesla Motors partnered together to work on concepts for the Tesla Model S in-dash experience. The prototype used a framework that Adam co-created called Merapi. This framework enabled the dash user interface (an Adobe Flex/AIR application) to integrate with hardware in the car.

Adam helped implement the ideas Tesla and Roundarch conceptualized. This code was deployed into the working prototype car, which was showcased at many conferences featuring the early Model S. Adam worked with Dave Meeker, Zach DeBord and other colleagues at Roundarch on this project.

Related:

• Roundarch and Tesla Highlight Next-Generation Driving Experience at Adobe MAX 2009
• The Tesla Model S – Touch-Screen User Experience is Powered by Roundarch’s Merapi Project

Flex 3 with multiple selectors:

This example shows how powerful CSS can be with the ability to apply multiple selectors to each component. Each style is used generically and applied to a component regardless of the component’s type. So, we’re able to share a “redBorder” selector between button1, innerBox, and button2 without adding unique styles about the button’s text colors, padding, etc to the “redBorder” selector.

Degrafa skin with styled elements:

This example shows a simple Degrafa circle with it’s style properties (color, angle, alpha) abstracted into CSS. From a skinning perspective the lack of styles in Degrafa has always been just a little annoying for me. On large, enterprise applications it is essential to create conventional approaches to tasks performed throughout the app. Skinning is one of these tasks. Without the support of CSS, styling a Degrafa skin is much different than styling a halo skin, but now with the CSSPropertyInjector util a similar styling approach can be taken with both skins types.

Flex Chart with styled elements:

Another painful set of elements to style is the Flex Charting Framework. In this example you’ll see that the color and weight of stroke of the LineSeries is styled using CSS.

Flex 4 FXG with styled elements:

FXG is similar to Degrafa and easily styled using CSSPropertyInjector.

So, this is a start for CSSPropertyInjector. It’s checked into flexlib and ready for you to play with. I look forward to your feedback on making this a complete addition to flexlib. Please feel free to leave a comment on this post, e-mail me directly, or comment in the flexlib Google Code project.

We’ve released the first public beta on Google Code as well as opened a Google Group. There is also a repo for Merapi examples.

Here are the important links:

http://merapi.googlecode.com/
http://merapi-examples.googlecode.com/
http://groups.google.com/group/merapi-project

To find out more, keep an eye on our blogs. We’ll be releasing more tutorials and answering questions as they appear.

On March 9th I began a new position in the role of Technical Architect and Evangelist at Roundarch. As I stated in my previous post, this was a difficult decision to make.

Now that I’ve had a couple months of settling in, I’m happy to say I’m enjoying my new role and the team at Roundarch very much.

Roundarch is not just an RIA or technology shop. We are specialized in Information Architecture, Graphic Design, User Experience, Technology and SEO. Our work is in serving clients, and our process provides unique advantages to the fortune 100/500 enterprises we engage with.

Now that I’ve had some time to get to know many of the 175 people that make up Roundarch, I’ve learned to appreciate Roundarch‘s holistic approach towards solving problems. Although we do have experts that work within a discipline, we do not develop solutions in a vacuum. There is a belief at Roundarch that all disciplines (IA, UX, Design, Business, and Technology) should inform each other. This adds up to a group professionals who’s combined background includes graduate and post graduate level training in; HCI, Computer Science, Design/Art, Business Administration, etc… all working together as a team to create solutions for our clients. That process is exciting to be a part of.

There were many incentives that influenced my decision to join Roundarch. A few highlighted reasons are:

1. Leadership that believes in the success and direction of the company.
2. Working with my friend Dave Meeker on Merapi
3. Working with my new friend and mentor Gary Schwartzbard in the Roundarch RIA practice.

1. The Leadership

Roundarch‘s history comes from years of working under the Deloitte and WPP flags. Our owners saw a distinct value in the people that became the founding members of Roundarch and purchased the practice from Deloitte. It is a testimony to the leadership that many of the founding employees are currently managers, directors, and VPs even today. This is a leadership the has a clear vision of serving it’s clients and valuing it’s employes.

2. Dave and Merapi

Another part of my on-boarding to Roundarch was working with my friend Dave Meeker to develop Roundarch‘s capability’s to offer unique services leveraging Merapi. Most recently we’ve done this by assisting Tesla Motors in the release of their new Model S electric car. You can read more about our involvement with Tesla on the Roundarch blog and in this press release.

Shortly after the release hit the web, there was a bit of a surprise in the Merapi community about our positioning around Merapi. Pieces of the text were (validly) interpreted by some to read that Roundarch now owned / had purchased Merapi. This is not the message that Dave or I intended to publish. Roundarch has and will invest time and money in promoting and developing the Merapi technology, however, we view the open source effort as a key part in the success of Merapi.

Last week my friend Andrew Powell raised some concerns over the future of Merapi, and the position of the open source project. For those of you in the RIA community, you’ve probably seen Andrew give talks about Merapi over the last year. He’s been instrumental in helping develop the concepts of Merapi and has helped promote the technology in a great way. Moving forward, Andrew will sit with me as co-chair of the open source project and help to ensure that a community focused version of Merapi’s Flex/Java connectivity thrives.

This week Andy, Dave and I spoke about what might be the clearest, mutually beneficial way to position Merapi for the community and companies like Roundarch that want to invest in developing commercial solutions with it. Here’s what we came up with…

The open source / community effort will be known as:

The Roundarch commercial effort will be known as:

The open source effort will target developing a solid core for Flex/AIR and Java. Andy and I will be handling how to approve members of the community who would like to contribute on the project. We’ll likely be asking for individuals or corporate entities to contribute first by submitting patches and then elevate their status to full commitor rights. This effort will begin this summer.

3. Gary and the RIA practice

At Roundarch we don’t follow the typical manager / employee hierarchy. Instead, each employee has their own career counselor. I consider it a privilege to have Gary as a counselor and mentor. It’s been my pleasure to get to know and work with him on a few projects already. Even in the current economy, we’re in need of additional resources for this team and others. Contact me at adamflater [at] gmail [dot] com if you’re interested in finding out more about Roundarch.

So.. that’s a rather lengthy source-code-less post for me.

thanks for reading the update.. more to come on RIA development soon
-adam