For many decades user experience was a generally low priority; up until the mid-2000s the term barely existed. It wasn’t taught in software engineering university programs, and businesses weren’t cognizant of user experience and design (also known as UXD).

Over the years, however, UXD has become a first-class citizen and a top priority, particularly for public-facing web applications. Supporting that are some awesome web-based technologies that allow developers to create these rich internet applications.

But it wasn’t always so awesome. Back in the day (early 2000s) I’d been searching for a way to provide users with a better online experience. It took time before Google wowed everyone with the innovative Google Maps site, so for a long time users didn’t know how much better things could be.

Through the years of using the web for document distribution, users’ expectations devolved from the power of native desktop applications to the anemic ability of HTML applications. That’s not a knock against HTML and the web; the web is perfect for what it does, which is deliver platform-neutral documents. Developers and companies focused on the web’s ability to give them time-to-market rapid application development, and users accepted whatever was in front of them because, hey, that’s how web applications are, right?

It bothered me that with every click, a backend system executed a lot of code to result in minimal UI changes. Even worse was the constant bombardment of database servers. For a technologist, the quick remedy to this is simple: Slap in more memory, load up on virtual machines, scale out horizontally with low-cost commodity servers, and call it a day. But I’m talking about the cost to the users. On their end, they were experiencing that annoying click-and-wait feeling that was common for web applications. In addition, UIs were limited. Sure, you could use JavaScript, but you could only go so far before you needed advanced skills. From an ROI perspective, it generally wasn’t worth it.

At the time, Java applets and Flash were available, and they seemed to offer the potential to achieve what I was looking for. But applets failed as a solution; they were bloated, slow, and inconsistent across platforms. Flash was promising, but trying to produce enterprise business applications in a designer’s environment proved to be more challenging than it was worth.

During my time in the Knowledge Management department at eBay, this challenge came up again. I needed a way to abstract the complexity of the data and make it simple for users to work in a visual environment.

Along came Flex in 2004 (V1 initially and V1.5 shortly after that). I was able to make a business case for using it, and our team delivered experiences at an entirely new level. At this point, I knew Flex would be big. It delivered the desktop power users needed while maintaining the development velocity that software teams required to survive.

As a believer in Flex, I made it a personal mission to help grow the Flex community. I created CFLEX.Net (www.cflex.net), believing that the bigger the community, the more it will reinvest in itself through knowledge and code sharing and in this way continue to boost the technology’s adoption rate. If there’s a strong support network, you take less of a risk in bringing a new technology into your organization.

For the early adopters of Flex, the learning curve was rough because only a limited number of books and other reading material were available. That changed with the release of Flex 2, when the number of resources dramatically increased.

I left eBay in late 2005 to join Amcom Technology and build and manage a team of developers. As with any new technology, experts in the field are hard to come by, so your best bet is to grow the skill. While training developers on Flex, I found that the current set of books didn’t map to how they think and that obvious challenges were never addressed.

In continuing my mission of growing the community, I set out to write Flex 3 in Action, hoping it would help solve the learning challenges that everyday developers face. Instead of grouping topics based on feature categories, the book is structured according to the natural progression of creating an application. I focused on maximum simplicity by not introducing anything you don’t need to know until it was needed and by using small code examples that are easy to absorb. I also found that people learn best when they’re able to relate new things to things they already know, so whenever possible, I use analogies to how you’d do things in another technology.

With this Flex 4 version of the book, I brought on some industry heavy hitters (Dan Orlando, John C. Bland II, and Joel Hooks) to help take it to a higher level in order to provide you with a solid foundation of understanding. My hope is that by teaching you the keys to success, the Flex community will expand as a result, because you too will be able to share your knowledge and experience with those around you.

Now is the time to get into Flex. The community continues to grow, more and more third-party vendors are coming out with Flex-related technologies, and Flex user groups are popping up all over the place.

The RIA space is red hot with technologies and competition, but Adobe continues to prove it’s a few steps ahead. We’re in for some exciting times! HTML web applications will always have a place, but it’s time to take your skills to another level, because the industry is moving forward with or without you.

Sit down, buckle up, and strap in for the ride!

TARIQ AHMED