Serial Entrepreneur & Enterprise RIA Pioneer

Jeff Haynie

Subscribe to Jeff Haynie: eMailAlertsEmail Alerts
Get Jeff Haynie: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: RIA Developer's Journal, Appcelerator RIA Journal

RIA & Ajax: Article

Right Side Up Development

Introducing interactive use cases

Traditional Web development frameworks tightly couple the user interface (UI) and the server. This characteristic has two significant implications:

  • Prototyping is difficult
  • Development is server-focused

Traditional Web frameworks make it extremely difficult, if not impossible, to create prototypes. The tight coupling between the UI and the server dictates that you must write and run server code to do anything. This leaves you with two options: build prototypes using a different set of technologies or don't prototype at all. In the first case, your prototype will be thrown away, which is obviously expensive, but there are certainly cases where it's less expensive than forgoing a prototype all together.

Server-Focused Development
Starting development with traditional Web frameworks equates to writing server code. The problem with this is that you are forced to build your UI and your server simultaneously. Inevitably, there will be changes to your application. This approach makes changing applications expensive, because you have to modify both the UI and the server; in some cases, you may have to undergo major structural changes if a new requirement dictates it. The negative effects of this type of development are not insignificant. Best case, you simply incur a small additional cost to make the change, but the cost of several small changes adds up quickly. Worst case, the cost is significant, which leaves you with three suboptimal options: absorb the cost, don't absorb the cost and deliver an application that doesn't meet business needs, or scrap the application.

A second side effect of server-focused development is you typically have server programmers writing UI code. This is bad for two obvious reasons:

  • Server programmers don't typically have good UI design skills
  • You're using an expensive resource to perform a lower-cost activity

The net result is that you spend more money creating an application that has inferior usability.

Introducing Interactive Use Cases
The emergence and widespread adoption of AJAX has triggered a foundational change in Web application development. The Appcelerator Platform is an example of this change. The platform is based on a message-oriented architecture, which enables some interesting capabilities related to this discussion. First, it enables an almost full decoupling of the UI from its services. In Appcelerator, UIs and services are linked only by a lightweight message interface. Second, it enables you to create "mock services" in the UI. Mock services handle remote service requests and responses, but they reside in the browser; the application has no knowledge of the location of the services it consumes. These two capabilities are the driving force behind what we call Interactive Use Cases. Interactive Use Cases are fully functional UI prototypes that are 100% reusable.

Fully Functional UI Prototypes
"Fully functional" means that your prototype behaves as if it were a real application. For example, when you do a search, you see a progress indicator for a second or two before seeing the search results. Experiencing the actual behavior is important because it's necessary to evaluate usability. In traditional application development, this is impossible to do without actually building the entire application, which is why there are so many applications in production with poor usability.

"UI prototypes" means no server code. This is important for two reasons. First, it lets you build and improve the UI until it meets your business and usability requirements without writing a single line of server code. The result is that you can build a much better product in less time and for less money. Second, no server code means no server is needed to run the prototype. This makes it easy to share and demo the prototype with both internal and external audiences to get feedback before building out the service tier.

100% Reusable
Once you've completed the prototype, you're ready to build out the services tier. The really good news is that your prototype will now serve as the final UI with no changes. Well, there's one change - you have to remove the reference to the file that contains your "mock services," which is one line of code. Your mock services also provide an additional and powerful benefit - they contain the messaging interface that the actual services must implement. The result is faster service development because developers have two important artifacts before starting to implement: the final UI and the messaging interface they need to implement.

Resource Alignment
As mentioned earlier, the Appcelerator Platform cleanly separates the UI from its services. A positive side effect of this is that you can now use designers and HTML developers to fully and independently build the UI - no more UIs written by server programmers. This is a great example of how a well-designed technology can enable natural efficiencies in the development process.

At Appcelerator, we use Interactive Use Cases for all of our software development projects. It has fundamentally improved the way we, and our customers, develop software, both in terms of speed and quality - we like to call it technology-enabled agile development. Instead of adopting a formal process, our technology enables a behavior that is agile in nature. The results have been phenomenal. We built our new developer network in eight weeks using this approach. We also used Interactive Use Cases with one of our biggest customers, Premiere Global. We have published a full case study on their experience at

More Stories By Jeff Haynie

Jeff Haynie is co-founder and CEO of Appcelerator. He started Appcelerator to provide a true open-source solution to enterprise RIA and SOA-based services development, after growing frustrated by the limited options and complexity in other solutions through his own development work. Prior to starting Appcelerator, Haynie served as co-founder and CTO of Vocalocity and CTO of eHatchery, an extension of Bill Gross? ideaLab. Haynie is an expert software developer and entrepreneur. Haynie has been active in standards development, as well as a contributor to open-source projects, including early work on JBoss. For more on Jeff Haynie, visit his blog at

More Stories By Nolan Wright

Nolan Wright is co-founder and CTO of Appcelerator, leading the company's product and services organizations. Prior to starting Appcelerator, he led engineering and product management at Vocalocity. He has also held several senior technology, product management and consulting positions with Accenture, Netscape Communications and Vertical One. Wright is a graduate of Vanderbilt University, where he earned his BEEE in Electrical Engineering. For more information, please visit

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.