Flex Article

Building RIAs from front to back – Part 1: Understanding the approach

Important note: Effective with the release of Adobe LiveCycle ES, the Adobe Flex Data Services 2 server product has been rebranded as a Solution Component of LiveCycle ES. This article was written based on Flex Data Services but will likely work as is with LiveCycle Data Services ES. Any articles referring to or using ColdFusion and Flex Data Services are not compatible with LiveCycle Data Services ES. To learn about the new capabilities of LiveCycle Data Services ES, see the tutorials in the LiveCycle Developer Center and read about Adobe LiveCycle Data Services ES.

No longer shackled by primitive interface controls and arcane request/response architectures, rich Internet applications are reshaping the way we take our businesses to the web. With the Adobe Flex 2 available in Labs, web developers can now build web applications with a level of richness never before possible.

With these advances in technology, however, arises a difficult challenge for the mindset of the traditional web developer. We see the problem often: web developers who are new to Flex attempt to build RIAs using a page-centric or request/response mindset. To take full advantage of RIAs, developers must instead begin to think in terms of RIAs focusing on the rich user experience they provide.

This article is the first in a series in the Developer Center that explore an innovative, proven approach for developing RIAs that focus on the user experience above all else. In this article we introduce the concept of "front to back" development, where the user experience is the primary driver for the development process, rather than an afterthought. We will discuss how to implement this approach with the Flex 2 , the features of which make this approach so successful. We will also offer real-world hints and advice on how you can use this approach to deliver the next generation of software over the web.

This series is not about theory and approaches. It is about how to build powerful RIAs using Flex 2 and the value of a "front to back" approach to that development. In the next four installments, you will learn how to do the following:

• Design and lay out your application
• Skin and customize your application with Flex, Flash, and HTML
• Use models to switch easily between multiple data sources
• Integrate your application into the enterprise

Turning the Tables

Let's begin with the oft-forgotten fact that our end users are our customers. They are the people who pay the bills—directly or indirectly—and who keep us gainfully employed. Strangely enough, traditional application development approaches do not focus on what the end user cares about—the user experience. Users don't care about design patterns or elegant code reuse. They care about how they interact with the applications you build for them. Yet development teams traditionally tend to focus on the back-end aspects of the system and leave the user interface as something of an afterthought. The perils of J2EE, CORBA, and other distributed development over the past 10 years highlight this disconnect painfully.

Think for a moment about the software industry compared to nearly every other product business. In the software industry, you approach the design process radically differently than you do with nearly any other product. You tend to work in what we would call a "back to front" approach. That is to say, most of us work through the process by focusing on the back-end engine and API first before knowing much, if anything, about the user interface that will connect to that API.

This way of thinking runs counter to the way that much more mature, established product businesses would build just about anything. For instance, if you were building a car, you would prototype the car's body in clay and then steel, working through the finest details of how the user would experience the car before you even began to think about the engine going inside it. Who knows the size of the engine you need if you don't know how large the engine area will be? The auto industry, like almost every other mature product vertical, approaches the development process "front to back." That is to say, they design the user experience first and use that to drive the features and functions that the end product needs.

The software industry has much to learn from traditional product development. The idea of designing and developing software using a "front to back" approach, although novel, is extremely powerful. It allows us to develop better, richer, and more powerful user experiences—in a fraction of the time.

Working from Front to Back

Time and time again, we've all sat through endless design sessions where we assemble each of the stakeholders into a room and drone on, day after day, trying to extract and document an application's requirements. Many of us have also noticed, time after time, that the requirements gathered this way invariably end up wrong.

This way of gathering requirements is tremendously difficulty for a variety of reasons. The most obvious reason is that the process does not truly engage the domain experts. Even the most passionate user's drive wanes after days of discussing requirements, eventually leading to stakeholders mechanically agreeing to anything in an attempt to bring the drudgery to an end. At the end of this process, a painfully long requirements document is created and sent back to the domain experts for signoff. Unfortunately, every one of these documents "looks" right, and it's not until the application is completed months later that it becomes clear that the requirements missed the mark.

Engaging Users through Live Mockups

In "front to back" development, you instead use the development of the user interface to drive the functional requirements of the application. Traditionally, user interfaces—if prototyped at all—are normally designed using static wireframes in tools like Microsoft Visio. While Visio is a perfectly fine tool for diagrams, it lacks the interactive capabilities you really need when wireframing applications.

We have found that Flex itself is a much better tool for the job because it provides an unprecedented, productive environment that allows our developers to create engaging wireframes quickly that bring stakeholders intimately close to the end application from the beginning.

As we work through these live wireframes, an amazing thing occurs. The same domain experts who were falling asleep in previous meetings become animated and genuinely excited. Being able to see how they will use the application triggers real thinking about what exactly they need and how the individual pieces work together. The end result is a much more accurate picture of the application requirements.

Building the Data Model

Through this process, a rough data model begins to surface, providing insight into the key relationships and data points. As each screen comes to life, the development team maintains a matching data model triggering questions about relationships: Can a customer have more than one sales representative or does a customer always have only a single sales representative?

With "front to back" development, users provide more accurate requirements, triggering an astute development team to ask critical questions early on. We all know the pain of changing a database relationship from one-to-many to many-to-many at the last minute. The more engaged the users are from the beginning, the more accurate the data model will be from the start. This translates into shorter development cycles and happier customers.

Binding to Static Data

Once screens have been laid out, the next step is to bind the user interface controls to static data. Flex 2 makes it very easy to bind static or "mock" data in XML files to the RIA. Binding data makes the application appear to come alive, while allowing you to make sure your interface will properly support the required data.

For example, having bound, mock data helps ensure that fields are long enough and fit into the available space as needed. Your developers can enforce client-side validation rules in the RIA based on the developed mock data elements.

Finally, the screen flow is hooked together to create a functional, mock version of the application.

Providing an Accurate API

By this point you have designed, in essence, the API that the application will need. You now know the data fields that the application must read, the data fields that the application will post, and which portions of the business logic will reside in the server and client tiers. Data services are now developed, which are polymorphic with the static mock data. This ensures that the data being returned to the RIA is provided in a format that very closely mimics how the application displays the data.

We cannot overstate this incredibly important advantage. One of the biggest causes of performance issues in RIAs is when the application itself must massage and manipulate data returned from a data service into a format that suits the user experience.

This is one of the biggest drawbacks to a "back to front" design. When you develop the services and API before the user experience, it is impossible to ensure fidelity between the two. This also significantly reduces development time by avoiding over-development, where data services and APIs are created "just in case" the RIA needs them.

Binding Live Data to the User Interface

As each data service is developed, user interface bindings are then switched from the static data and connected to the live data services. Because we have already ensured compatibility between the two, the application comes to life.

Benefits of the "Front to Back" Approach

Developing applications in a "front to back" approach isn't just a theoretical exercise. It provides you and your users with serious value in three distinct ways:

• Better requirements gathering: Users don't know your developer's language. They don't know how you develop their applications and, frankly, they don't care either. Yet if they can watch you build a prototype of their application in front of them, they will very quickly begin to interact, and will tell you what the application should do and how it needs to work.
• Faster development and feedback: Users can't touch and interact with an engine. They can't demo an API. Yet if you start your development from the user interface with static data, users can show off and demo the application to stakeholders to gather feedback. This even allows your users to begin selling the product even before the development effort is finished.
• Users become advocates, not antagonists: Users might feel that you don't understand their needs, are always late, or that—in the end—you never build exactly what they want. Using a "front to back" approach, you can turn the tables on that relationship by keeping users involved in the actual development so that they feel the same emotional attachment to their work that you do as a developer. Very quickly, they will become your biggest advocate.

Where to Go from Here

How do you actually implement these ideas in building your own rich Internet applications? In each of the next four installments, we will review the approach and look in detail at how the Flex 2 makes RIA development, in general—and "front to back" development, specifically—powerful and productive for your application development. Read Building RIAs from front to back – Part 2: Layout beyond the standard container in Flex 2 to learn more.

You will learn these concepts through code examples and screen shots, which will help you adapt your development approach as simply as possible. In the end, you will have all the tools you need to turn the tables on your development with Flex 2.

About the authors