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.

As a simple UX exercise I decided to recreate the Google Talk install process in Flex and then apply some morphing transitions. In this example I’ve used the recently released Yahoo! Flex Skin to approximate a desktop look and feel. Thanks to the guys at Yahoo! Flash Dev for getting this out.

In this first example you’ll see a sequence dialogs very similar to the Google Talk install process.

In the second I’ve added a morph effect similar to the effect that Toast uses. In my opinion using a subtle effect like this drastically improves the user experience (UX).

Let me know what you think, drop a comment…