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

Prototyping
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.

Conclusion
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 http://www.appcelerator.com/premiere.html.