Building an Object-Oriented User Interface with ColdFusion MX
What is an object-oriented user interface (UI)?
Building a user-interface design (UI) with an object-oriented (OO) approach helps you achieve flexibility, simplicity, and return on investment (ROI). By creating building blocks for both the user screens and the back-end functionality, you can develop web applications quickly and also change them easily as the business needs expand. ColdFusion MX is a powerful tool that can help you build an object-oriented UI by breaking functionality down into visual and structural components that you can easily rearrange.
Optimizing real estate and design layout. To focus on the user, I'll explain the front-end design and then the back-end functionality. This section uses a screen that displays user account information.
Visualize a design that has boxes that you arrange, much like building blocks. In this article, I'll call each block a widget. Each widget contains certain groups of data (the data fields are green in figure 1). One widget displays user details, such as name, e-mail address, and phone number; another widget contains a list of groups that the user belongs to; and another contains a user's security roles.
Figure 1. Object-oriented UI with widgets.
Figure 1 illustrates the widget model. The boxes with black outlines represent widgets (each widget is an included file). Each widget can contain any number of tables (blue) and fields (green). Each widget is independent, so that you can include it on any screen that needs it. For example, you could list a user's security roles on a widget on an "account information" screen, and also list them on a different "security roles" screen without customizing the code again.
One major advantage in making an object-oriented UI is that instead of using a page-to-page workflow, typical in many websites, you can present information in visual blocks for the user. It also empowers the developer to create new screens and choose which widgets he/she needs quickly, without having to customize code for data fields specific to each screen.
Reusing code libraries allows faster, stronger development. The widgets become a reusable code library you can call and assemble anywhere you need them. Every application changes as its business needs grow and change. By building user screens that are modular widgets, you can implement changes faster and cleaner. One of the most costly factors (in time and money resources) in application development arises from having to quickly redirect application functionality. If you custom code a web application, making one major change in workflow or functionality can mean that developers spend weeks or months customizing programming to fit the new business needs. With an object-oriented UI, however, you can make major workflow changes much faster, in a more structured way, saving time and money.
For example, suppose a fictional company created a web application that builds automated e-mail campaigns. In their workflow, a block of text fits into a message, many messages become part of a larger category called a campaign. The system sends groups of messages based on the campaigns. On top of this, the company creates customized UI screens for each campaign and each category level (customized screens). This is a typical web design: "custom build what you need when you need it". But this process can be inefficient.
Now suppose the same company decides to expand the product to new markets and find customers who aren't interested in the campaign idea, but who would like to send individual e-mails with built-in surveys. Because the code isn't intended for this purpose, the company must customize the code and each screen again to handle the different customer types. This change requires developers to customize programming and duplicate data to display in different ways, depending on the customer type. For instance, the developer might put the same data fields on many different web forms or create custom workflows.
Duplicating code inflates the system and weakens its structure more than necessary. This is especially true in user interfaces. Sometimes it's just easier to copy existing code, at least initially. For example, suppose a developer was building a new screen in a page-to-page design. If he/she were under a time constraint, and the new screen was very similar to an existing screen, it may tempt the developer into just copying the existing screen and altering it. The problem with this process is that it depends on how much the new screen differs from the original screen. If 95% of the screen is the same, then the developer duplicated almost all of the code. Later, when the developer needs to change the interface elements again, he/she has to change the duplicated code in all of the screens where he/she copied the interface. For instance, if the developer copied a screen header to 50 files, he/she would have to remember all the files where he/she copied the code and update each one. Additionally, for each of those files, he/she must adjust the file for any alterations that he/she made after the initial duplication. This tedious and time consuming process can engulf a great deal of the interface development cycle as a product grows.
In this situation, reusable widgets become highly valuable. If you need to copy 95% of the screen, maybe 75-80% of the screen uses the same widgets, you could call each of them individually. Customizing the new screen becomes a small task. If you must change one part of the interface, you can alter the widgets individually, and the changes reflect through the entire application; this takes far less time and allows you to be far more organized. In a product lifecycle, this is very important because new products can shift directions rather dramatically in the early stages. Using the traditional custom screen-to-screen methodology over the life of the product is much more extensive. At some point, you would need to completely rewrite the entire system based on the changing business. This is costly in development time and in budget.
By building the UI from reusable widgets, or using an object-oriented design, you simplify the development process. Instead rewriting entire parts of the system, you add widgets to screens that already contain data, reorganize them based on workflow, and add form fields to widgets instead of to a particular screen. In short, instead of customizing the code, you rearrange, add, modify, or delete widgets to achieve the design layout you want.
Is there a down side? Application architects can more easily apply an OO development process than web page publishers or designers. Although some developers and designers assume that a web application is the same as a website, this is typically not so. You develop a website like a book-it has pages and images that you arrange to tell a story. An application delivers dynamically-generated data and follows a specific workflow.
A web publisher or graphic artist must expect a learning curve in understanding the differences between a website workflow and application workflow. Software programmers understand the benefits of creating a component-based application. Designers and web publishers must also understand how the high-level benefits of using an OO-design, even if it means a more complicated process in initial planning stages; otherwise, they may unintentionally return to customizing programming for each screen-a process they are accustomed to.
Early in a project, it can be very tempting to build screens that are needed as they are planned, very quickly. After all, it is much faster to prototype and demo individually-built user screens than it is to plan out and coordinate a component-based interface. But for a more scalable application, you should plan to build the widget/component architecture early in the project life cycle instead.
Early in the project life cycle, management should make the time to plan the user interface design, decide on a look and feel, and build the infrastructure to support the widgets and components. This is a both "top-down" and "bottom-up" strategy. The product managers deciding what the product does and how it looks should build a visual design from the top going down. The application architect works with the product managers during the process to build the back end so it can support functionality that the product managers define. This is not an obvious process early on, but becomes critical later in the product life cycle. By that point, it's really too late to rebuild the architecture to adapt to new product requirements. This is why some companies rewrite products from scratch. By working from the top-down and bottom-up from the beginning of the user interface design stage, rewriting won't be necessary. The developers can build the app based on the architecture so that it scales to support the range of possibilities for the particular app and business.
Using ColdFusion MX to Build a Widget-Based Application
ColdFusion provides several key features that allow for an objected-oriented approach. By combining custom tags, server-side includes, and ColdFusion components (CFCs), you can build and arrange the building blocks of the application easily.
Making logical blocks of information into visible widgets. Starting with the front-end visual design, the process of making widgets in ColdFusion is fairly straightforward. Using CFML and HTML, make the widget visual boxes by using HTML tables. The table provides a way to put colors and styles on the widget and to arrange fields inside the widget. Save the widget into a separate CFML file. You can put all the widgets in one folder as a library. Now for any screens that you need, you can simply call an arrangement of widgets for the screen's overall function. For example, if you needed to build a "User Administration" screen, you could call a widget that provides a "list of accounts" and a widget that allows a user to "edit user information". There may be other screens where you want to include the list of accounts, for instance. By making the widget reusable, you use the widget on this screen and you can call it elsewhere in the application.
Using ColdFusion components to deliver the data to each widget. In the past, a developer used CFQUERY to write a custom query within each widget to get data. This forced developers to group data exactly as it appeared in the UI widget, tying data to the UI too tightly. Wouldn't it be better if each widget could call a data module, which was also an independent code block from a library?
ColdFusion MX Components (CFCs) solve this problem by separating the data from the user interface. Now, not only can you assemble the UI widgets and call each onto the screen, but you can separate the data called within those widgets and use it
in different widgets. In all, there are multiple levels of separation of screen to widget to data (CFC). This means you can rearrange them like building blocks. As the product grows larger through its life cycle, this simplifies and
speeds up the process of changing the interface. Just as widgets are a library of objects that you can call to on a user screen, the data is also a library of CFC objects. You can build each CFC so that it contains the functions necessary for
each widget you build. To create functionality, widgets call CFCs with the cfinvoke tag. Therefore, a developer selects a widget from the UI library and also selects ColdFusion components from the CFC library. Each widget can call
one or more CFCs to get necessary data. Ben Forta also reinforces this methodology in his article, Using ColdFusion Components-Properly.
The cfinvoke tag is where the UI designer and CFC programmer meet. This is the real advantage to the widget/CFC development methodology. The UI designer can work with a product manager to develop what the product does and build the
visual screens by calling different widgets. Meanwhile, the CFC programmer builds the ColdFusion components, which deliver the data to one or more of the visual widgets. This process is a much simpler, faster, and stronger place to "meet in the
middle" than a language like Java can natively provide. It is also more encapsulated and flexible for changes than binding CFQUERY tags directly to the UI as ColdFusion developers did in traditional page-by-page development.
Why is meeting in the middle so important for software developers? There are basically two different approaches for developing a web-based application. In one approach, a developer uses development tools optimized for high-level designers (such as ColdFusion, ASP, or PHP). In the other approach, a developer uses low-level software engineering (such as Java or .NET).
Different companies use different approaches. Some choose to use simple ColdFusion or ASP applications because they are extremely fast and simple to use. When you need a new screen, you can quickly program and implement it. The disadvantage to this approach is that the applications become "stove-piped" into separate small systems that you must individually maintain. This increases costs; with a number of small applications sprouting everywhere, the number of people that must maintain them also grows.
In the other approach, you build applications in a framework at a deep level, using Java or more recently, .NET. This way, each application fits into a framework of larger systems. The downside to this approach is that the development cycle is much longer and changing direction is very difficult and costly.
ColdFusion MX makes it possible for these two requirements to meet in the middle and allows you to make libraries of reusable code. Designers will be right at home with CFML and the UI design tools they use. Meanwhile, Java programmers will be accustomed to developing components and using objects within a framework.
Figure 2. Meeting in the middle.
By combining components and CFML, web developers can break the application functionality into parts that they can reuse anywhere in the system. An application's optimal usability starts with the user. Looking at the widgets from the user's point of view should always be your primary focus during the design phase. Ask yourself these key questions:
- What data will the user need?
- What logical blocks can you put the information in?
- How will you group together the blocks?
Once you know this information, you can develop the logical blocks coming from both directions: one from the information source (the database), and the other from the user experience (the UI). The approaches must always meet in the middle to provide the user with the data they need in a simple, usable way.
The overall application purpose determines how you develop from the top-down (UI-centric design) and from the bottom-up (data-centric design). You must plan and prototype data models, database tables, XML schemas, internationalization, and the workflow engine as early as possible. This is another reason that a widget/component-based design benefits you; it helps keep the presentation layer and data layer separate but makes it easy to reconfigure as the design process evolves.
You really don't want to hastily build customized UI and data structures for the purpose of prototyping, which you keep in the app for the product's lifecycle. It is critical to take time early on to forecast and plan for the future, spending time designing and planning what the future of the product could be. This takes more time in the early stages but planning it out correctly yields a UI that's easier to reconfigure and a more flexible database structure-all long term benefits. If you carefully plan your user interface, workflow, and database so that they are adaptable and modular, changing direction may take less than half the time it would with hastily coded, customized screens and database tables.
Results
At Concentric Spheres, we built our flagship product, Carrier Wave, using this method. We took six weeks to program the application to a usable state. We estimate it took less than half the time that a Java/HTML development effort would have taken to provide the functionality we wanted, while maintaining an object-oriented design that is very structured and flexible.
Separate people created the UI and CFC libraries, but they met in the middle. The UI developer built the screens using the desktop/widget model, and the component developer simultaneously built the CFCs to deliver the data and functionality.
Figure 3. Display of the widget-based user interface in the Carrier Wave product from Concentric Spheres.
The exact technical meeting point occurred where we used the cfinvoke tag. (You use the ColdFusion tag, cfinvoke to call ColdFusion components. Read Ben Forta's Introduction to ColdFusion Components for CFC basics.) The UI developer put the HTML fields in place on the widgets, while the CFC developer placed the cfinvoke calls to the
components to deliver the data into the UI. Our main workflow used cfscript to create objects to dynamically load metadata from the components as well. Finally, we were ready to test and use the product.
This methodology maximized our ability create functionality and modular screens, while enforcing the standards that we set for the architecture and encouraging a component-based, object-oriented approach to developing the application. We dramatically reduced our development time and created an application that was far more flexible and standardized than we expected with ColdFusion. By using ColdFusion MX, our company got the best of both worlds by combining rapid-application development with an OO framework-helping us produce a solid, flexible product very quickly. We expect a significant return on investment (ROI) for taking this approach over traditional paths of development, especially as we add new features and quickly respond to our customers' changing needs.
