In the last article, “When Less Is More: User Interface Reusability, Part 1,” we explored user interface reuse including why it is important, how it is often overlooked, and some of the core challenges that organizations have with user interface reusability.

In this article we’ll explore the tools and techniques that you can use to build reusable user interfaces and the pitfalls you should avoid when using these tools.

The Tools

With the vital first step of understanding the concept of user interface reuse is born from s the obvious question of “how?” Reuse in the abstract is a good thing to do and the potential costs and benefits are understood but how does one go about creating user interfaces that are reusable. Like many things in Software Development there is no one golden standard for the way to achieve reuse. Instead there are techniques which can be used to create reuse. Some of the most valuable techniques for creating reuse are covered in the sections below.

The Shim
In carpentry, a shim is the little bit of material, usually wood, that goes between two pieces to fill a gap. Shims are used frequently to make two pieces fit better which don’t naturally fit the way the carpenter wants them to.

User interface shims work the same way. They connect a standard user interface to whatever the particulars of a specific implementation are. Their role is essential, because they allow for the creation of standardized user interface controls which can be connected to whatever platform as necessary.

A shim has one interface to the visual component which describes how it will provide the context that the user interface needs. Context might be the product number for which product to display, the customer number for the customer to display, or some other piece of data that the user interface needs to operate.

Similarly the shim connects to the interfaces of the underlying platform to bring up the necessary context and to connect the user interface seamlessly to the platform.

When a shim works well it isn’t visible to the user and it provides a rich interface to the user control for setting context and getting results. The shim code may change from platform to platform but the general services stay the same. This method allows you to concentrate the platform specific code into smaller, more easily maintained and enhanced modules. This facilitates the movement to newer platforms with great speed.

Shims are also sometimes tasked with the ability to composite multiple user interface components together. This compositing helps reduce the overall code size by keeping the components small so larger and more complex parts of the screen are actually built from smaller components of the system.

Shims are used in conjunction with all of the other types of solutions to make them fit better into the framework. They are never used alone since their entire function is to connect two different pieces — the infrastructure and the user interface.

IFRAME
The IFRAME, or more properly, inline frame, is the poor man’s approach to user interface reuse. It actually leverages the software on another system. IFRAMEs are used to encapsulate content from another Web server as a part of a page. IFRAMEs are derivatives of the old FRAME tages in HTML which framed-in various parts of a page.

The beauty of IFRAMEs is that there is very little that must be done to get an IFRAME-based method to work. You simply add the tag and point to the existing user interface. The existing user interface is displayed as a part of the page.

There are, however, negatives. It’s not possible to control the appearance of the content inside the IFRAME from the outside Web page. This can mean different colors and another set of menus. It is also possible that multiple scroll bars will result. One set for the contents of the IFRAME and another for the Web page in general.

It also means that the user must authenticate to the other system as well as the current system. For organizations using single-sign on, federated sign on, or HTTP/NTLM based authentication, this may not be an issue, but for others without a solution to authentication to multiple applications this may represent a significant challenge to being able to use this method.

User Controls
User Controls are a key component of .NET development. They are a way of encapsulating a small block of user interface functionality into one module which can be reused within an application and between applications.

The key advantage that the User Control technology has in .NET over say, Web Controls (or Web Server Controls), is that they are easy to create because there is still a visual designer in Visual Studio which can be used for the construction of user controls. The net effect of this is that user controls are nearly as easy to develop as a regular Web page.

In addition to the advantages of being able to design them visually, they are trivially easy to load into a page and are therefore easy to shim. This makes it easy to transport the user control from one application to another.

The one limitation that user controls have is that they are not the best performers. While performance isn’t bad, they cannot rival the performance that can be obtained by writing Web server controls by hand. In the grand scheme of things this is not as bad as it may seem. Most organizations do not need to focus on performance to the degree which they do.

Web Controls and Web Parts
The cousin of the User Control is the Web Control. A web control is similar to a user control in that it’s a fragment of the user interface which is added to a page. It is just as easy to add to a page as a user control, if not slightly easier. As such it makes a good platform on which to build a reusable user interface.

The Web control’s strength is that it’s capable of more tightly controlled user interfaces. Because there is no designer view for the Web control, everything the control does is done from code. This makes the Web control perform faster than its user control cousin but also substantially increases development time. Because of this, Web controls are occasionally used for high-performance or tightly controlled components of a visual interface but are not generally the bulk of the controls in use.

Web Parts are a derivative of the Web control which are designed specifically to be controlled from a user accessible interface. While the shim may be responsible for interfacing between the infrastructure and the reusable user interface code, the Web Part makes the interface easier for the customer by supporting the interfaces necessary to allow the user to control settings of the controls for themselves.

Web Parts are perhaps the most common idea of what a reusable user interface is. And yet in many cases they aren’t the best solution. The initial development costs and the maintenance issues that are created by Web Parts are typically not worth it for the marginal performance increase that is gained.

Web Services and XSLT
Of course, writing code for every Web part isn’t always the best case. With a generic component capable of consuming any Web service and a carefully crafted XML Style Sheet Transformation (XSLT) nearly any data from any source can be displayed. The ultimate in reusability, there is no code necessary to take the code and move it from one Web service to another. These skills can be taught fairly easily to developers with some experience.

However, the challenges with a Web service and XSLT-based solutions are numerous. First, few SharePoint consumers know how to construct XSLT statements to convert the results of the Web service into an HTML output. XSLT is still a very mysterious tool as far as most developers are concerned. It’s something that almost universally must be trained to be used.

Tools for manipulating XSLT still have a ways to go to make the process relatively painless. Their expensive price, limited documentation, and lack of cohesiveness makes working with them difficult but working without them nearly impossible. The other core limitation of this approach is that it works well for queries, it does not, however, work well for interactive questions, nor does it instill a sense of teamwork.

While Web services and XSLT have great potential, in today’s environment they are not practical yet. There are too many tools which need to be created to support the development of new solutions.

Web Services for Remote Portlets
New on the scene is an emerging standard for using Wb services to return HTML fragments for remote display. This emerging standard, Web Services for Remote Portlets (WSRP), is being pushed forward by Java enthusiasts and others as a way to distribute the processing of a portal page across multiple servers.

Although it’s a tool to watch, the standards are still emerging and have not yet addressed some of the core issues surrounding maintaining state and processing transactions. The initial specification, approved in 2003, was silent on complex issues such as these. The version 2.0 specification is in a committee draft state and is making progress toward addressing the gaps in the standard, but it’s unclear at this point precisely how effective WSRP can be.

Dynamic HTML, JavaScript, and Cascading Style Sheets
In a list of advanced technologies like Web services, it may seem odd to spend time on a tool with such widespread adoption. Web technologies including Dynamic HTML, JavaScript, and Cascading Style Sheets are in use throughout the Internet, but most organizations rarely, if ever, tap their full power. Cascading Style Sheets can be quickly replaced to change the entire appearance of a site. JavaScript and HTML and be used to programmatically show or hide content on a page, change its location, or change its behavior.

These tools become essential to nail down the seams between different parts of a portal. JavaScript might, for instance, resize an IFRAME so that it is precisely the size of the content inside the IFRAME. The net effect of which is eliminating one of the problems with IFRAMEs as a tool. By manipulating the Cascading Style Sheet, it’s possible to make even different web sites look and behave similar enough to be a believable part of a cohesive whole.

While the other tools mentioned are the mainstay members of the toolbox, the ability to leverage DHTML, JavaScript, and CSS should not be looked down upon in terms of its ability to be a part of world-class solutions.

The Pitfalls

While each method has its own limitations there are limitations which transcend individual management techniques. These limitations, if not properly managed, can make the difference between a workable system and a pile of junk. Let’s explore two of the key pitfalls of any system.

Patchwork Quilt
Perhaps the greatest risk to reusable interfaces is not being able to manage the patchwork quilt appearance that sometimes occurs because of different development teams, flexible standards, and the passage of time between the constructions of various elements.

In order to mitigate this pitfall you should:Develop user interface standards — Develop an overall set of standards on where controls will be placed. Don’t focus on colors and fonts — those can be changed with style sheets. Focus on how navigation will work and how the controls should operate internally.Fight changes to the standard – In order to deal with the issues related to the passage of time between construction of two components used on the same page, minimize changes to the design standard and encourage that each change should correspond to a project to fix the non-conforming interface components.Set tight CSS style names for various kinds of text and regions of the page. By defining good CSS style names you maintain a minimal set of classes in the CSS sheet which causes it to download faster to the client, render faster in the browser, and more importantly is easier to maintain.

The problem with the patchwork quilt pitfall is that you must always be on guard for it. It’s not something that can be eliminated as a pitfall. It can only be mitigated.

Poor Availability of Systems
Pulling information from many systems is a part of designing for user interface reusability. One system may support the customer records and be seven states away but it’s still a part of the local application from the perspective of the user. Any time you attempt to reuse components from other systems you inherit their limitations. When you are working with operational components that hit a variety of backend systems, you inherit a lot of limitations.

Reliability is one of those challenges that is unavoidable. Every new component that you use that has an operational aspect to it means another dependency for reliability. Because of this building reusable user interface components means being cognizant of operational dependencies and designing ways around them.

For instance, if the customer display needs the back end database (or web service) to get the data, make the data source configurable so a replicated copy of the data, or a shadow web service is used to fetch the data. If the user interface needs access to data that may frequently be unavailable, consider alternative or backup access strategies.

Paradigms and Culture
The true pitfall is underestimating the impact of paradigms and culture on the ability to implement a reusable user interface. Paradigms about how software is developed creep in like dirt creeps into your home between dustings. They are pervasive and impact every decision during the construction process. Failing to realize they are occurring and challenging them can be disastrous.

Putting it Together

Building a reusable user interface strategy isn’t about picking one single option that will meet your needs, nor is it about the one right answer for every situation. It is, instead, about learning what your options are and how they can be used to create a solution that fits your organization and your organizations needs. From the simple to the complex, there are an array of options that can be used to allow you to develop user interface reusability in your solutions.