Intranet Journal
The online resource for intranet professionals

When Less Is More: User Interface Reusability, Part 1

Robert Bogue

5/5/2006

With increasing pressure on software development teams to deliver more, better, faster, it is no wonder that finding ways to capitalize on reusability are more important today than ever before. We all need to do more with less and reuse is the panacea of doing more with less. Once the initial investment has been made, little or no effort must be consumed to use the work again.

While software development as an industry has focused on reuse through structured programming, object oriented programming, service oriented architecture, and several other techniques little thought or effort has been applied to the process of finding opportunities for reuse in the user interface. More often than not each application's interface is seen as completely independent, having no need to be reused for any reason.

However, organizations of all sizes are finding needs to develop and reuse small components of applications in an effort to minimize costs, increase reliability, and allow for rapid changes to the platforms their technology lives on. This is why there is a need to create reusable user interface components. In this article, the first of two parts, we'll explore why user interface reusability is important, how it's been overlooked, and challenge you to develop a strategy for dealing with the need to make user interfaces reusable to reduce costs.

The Problem

With each new platform a new interface emerges. An old mainframe application designed for a dumb terminal is given a new skin via a skinning application to make it work in a client-server PC world. (This is perhaps best described as a terminal server world today.) When the Internet hits in full force the same application has a new Web interface added to its surface and security added on. The internal users eventually demand a Web-based version for their use which works differently than the Web interface that the customers use. Finally, the mobile workers beg for a mobile device version to allow them to work remotely.

From a single legacy application, five user interfaces have emerged. That doesn't even address any duplication between the same data needing to be leveraged by different applications — that's just getting all the support for all of the platforms. Each interface does, without a doubt, have its nuances, the things that it needs to do that no other interface can support. However, many of the things about the interface must remain the same. The same fields are needed and the same validation checks must be performed.

Most organizations are beginning to awaken to the fact that recreating interfaces with each platform for an application is consuming a great deal of their software development resources — precious resources that are needed to solve true business problems.

And yet, replatforming UI work continues daily as does the kind of work which produces a separate user interface for each application — even when that application consumes the same data that every other application in the organization consumes. There may be dozens of interfaces which display customer data from the central customer database. There may be even more ways to look at the sales data — even if the rows and columns are the same.

We're stuck in a mode of rebuilding the same basic user interface over and over again in the vain hope that this interface will be better or simply because there's no framework for how to reuse an interface.

Reuse Defined

Reuse is the Holy Grail of the software development industry. And in some ways it seems just as difficult to find as the Grail. Reuse is simply trying to get more energy out of the development effort than was put in. In a larger sense, it's the same transformation that the civilized world went through with the Industrial revolution.

All of a sudden we were creating more complex tools which allowed work to be done with fewer or no humans. We were beginning to become a society which made a relatively small investment in machinery which paid back dividends in time savings over many years. This is the same kind of performance improvement that we seek from reusing software components.

But for every step we take forward in this quest it seems like we also slip back one. Few organizations are getting any reusability in their applications and fewer still are happy with the level of reuse they are achieving. Reusability is easy to desire and hard to produce.

Creating reusability happens one of the three basic ways:

• Architected Reuse — Reuse is one of the original design goals of the component or application. Time and effort is invested in creating a component that is inherently reusable. This is the type of reuse that is focused around frameworks, libraries, and development infrastructure.

• Accidental Reuse — This type of reuse is defined by serendipity — it's a happy accident. Someone in the project team magically knows about work done in another project that can be used without any modifications. This kind of random accident is great but not as prevalent as expected.

• Reengineered reuse — Similar to accidental reuse, reengineered reuse relies upon someone knowing that code exists within another project which can be helpful to the current endeavor. However, unlike accidental reuse, reengineered reuse does not require that the original component be able to be instantly placed into the current problem. Reengineered reuse reworks the original piece to support both its original project and the current one. Because there is some effort involved this kind of reuse, it doesn't have the same return that other types of reuse do.

Architected reuse is the most repeatable way of creating reuse, but it has an upfront cost in it to design a reusable interface, to construct a more flexible solution, and to perform the additional testing necessary. These costs can be contained but do represent a real impact on whatever project is being used to create the components which are architected for reuse.

The real challenge with architected reuse is that there is no guarantee that the components will ever be reused. So while in theory the architected reuse approach will result in a savings it is possible that an architected reuse approach will cost more — if the effort is put into creating reusable components that no one ever uses.

Reengineered reuse solves the potential issues with not reusing the component by having a built-in reuse, but it suffers from a higher cost to implement as things must be redesigned and retested. So the cost is slightly higher with reengineered reuse, but there is little chance that the effort put into reuse will be lost.

Accidental reuse is, obviously, the "best" kind of reuse from a cost perspective because it incurs no cost, there was no initial investment to offset. However, as a practical matter accidental reuse almost never happens. Occasionally the needs and existing code will just happen to align to allow direct reuse of code that was not initially intended for reuse, however, this happens so infrequently that it can not be counted upon as a reuse strategy.

Reuse in the User Interface

Reuse in the user interface is a lofty goal. Providing different views based on a single code set may seem easy at first but it has its own challenges. Not the least of which is that it is nearly always architected reusability. There are few happy accidents in user interface reuse. As a result the investments in making a reusable user interface should have a reasonable expectation of actually being used again. Some situations that favor user interface reuse are:

• Multiple Platforms to support — There are several platforms on which you must support the same application. For instance, mainframe terminal, client-server, and Web.

• Multiple Interfaces to the same data — Multiple applications work with the same section of data and therefore you need the same display and/or edit screens in multiple applications.

• Volume of user interface screens — Even without the need to replatform user interfaces or to create the same user interface for multiple applications, a development group that spends a substantial portion of its time building user interfaces has a heightened need to seek out opportunities for reuse.

In addition to the desired benefit of lower development time to produce, reuse of user interfaces has the hidden benefit of reducing the amount of time necessary to train new applications. Because the user interfaces are the same across applications and platforms less time must be spent in training the user interface.

Conclusion

Now that you understand the problem and the goal of user interface reusability, you're ready to develop a strategy for how you're going to approach it. In the next article, I'll share some of the tools that you can put in your toolbox for accomplishing reusability.

If you're interested in seeing a Webcast covering both the problem definition and tools for creating solutions to user interface reusability, go to http://www.developer.com/webcast/article.php/3590576.

email this page

Tutorials XML Basics and Benefits Removing Spyware Build a PHP CMS Microsoft's SharePoint and more at: Intranet Journal's Tutorials

Intranet Journal Favorites Creating a PHP-Based Content Management System The Spyware Guide Introduction to Microsoft SharePoint Portal

Intranet Journal Part of the EarthWeb Network Managing Editor Intranet Journal Tom Dunlap EarthWeb Home Page Jupitermedia Home Page Media Kit