 | Level: Introductory Mike Padilla (mikepadilla@hotmail.com), User Experience Design Director, Radian Guaranty
19 Sep 2006 Enterprise application integration (EAI) is the elusive Holy Grail of any large IT department. The value of integrating multiple disparate applications so they can share business data and business processes is well established. From information architecture to branding, applications that are integrated across a multifaceted user experience to share a unified user experience (UUE) are easier to learn and offer productivity gains. The standards, paradigms, and patterns that define the UUE can also help to accelerate design and development through the use of reusable components. Integrating the user experience (UX) does have its share of challenges and drawbacks, but when done correctly, it can provide the enterprise with a homogeneous, familiar, efficient comfort when users interact with its application while it shortens development cycles.
If you're at all like me, you have at least three remotes: one for the TV, one for the DVD player, and one for the VCR. Sure, you can buy some fancy universal remote to control everything, but you don't have the money or the three months of training required to learn how to operate the thing. Wouldn't it be nice if the three remotes at least shared a common user experience? How much easier would they be to operate if buttons of comparable operations were located at similar locations, looked the same, and felt the same? It would also be nice if they all took the same size batteries, making maintenance a breeze. Then the day comes when finally you get that TiVo you've had your eye on. If its remote belongs to the same user experience family as your other three remotes, life will be good.
Life can be good in the cubicle too, with applications that share a UUE. When you switch from Microsoft® Word® to Excel® to PowerPoint®, you experience the Microsoft Office® UUE. Each application hosts unique functionality, but common actions and behaviors are executed in the same way. Within all Office applications, you access functions from the top menu of File | Edit | View| Insert | Format | Tools | Window | Help. Once you learn one application, you acquire an interaction foundation that you can apply to the other applications. With each new application that you access, you spend less time learning how to interact with it and more time learning about its unique functionality.
One big happy family
Applications all belong to one large global family defined by the physical user experience that they share. The general UX is defined by a set of common characteristics that enable users to interact with different applications using the same set of fundamental concepts. Users access applications through a computer, using a mouse and keyboard as input elements, and a monitor as feedback. Once users have learned these fundamental interactions, they can more easily interact with other applications.
Within this global family are multiple, progressively tighter-knit families -- sets of applications that have more and more in common. Web applications, specifically, can be unified across one or more of their many UX facets, including site structure, page structure, element structure, and skin (see Figure 1).
- Site structure: The application's information architecture, which defines page flow
- Page structure: The application's page layout, which defines sections of the page and the information and functionality that correspond to each section
- Element structure: User interface elements such as tabs, headers, and tables, which define the interactions, design, and structure of the site
- Skin: The branding of the application, including logos, font families, and color palettes
Figure 1. Unify Web apps through common UX characteristics
The IBM Web site is a good example of a UUE across an enormous set of information. The site features a global information architecture, with the top banner effectively serving as the grounded origin. Regardless of how deep you are in the site, that top banner is always there. Throughout the site, all pages share a common structure: global banner, section-specific left navigation, section-specific content area, and footer. Elements such as links, headings, input elements, tabs, and sidebars are designed and behave in a consistent fashion. Finally, all pages are branded consistently. Regardless of where you are within the IBM site, you at least know that you're in the site -- a seemingly trivial statement but of the utmost importance to the branding stewards in the marketing department.
So what does the UUE across the IBM Web site afford you as a user? You're able to use the entire site with greater ease, because once you've become familiar with one page, you've become familiar with all 10,000 pages. You know how to navigate, where to best look for specific information, and what types of information are likely to be available. Since it all looks consistent, you can subconsciously infer that interactions that you learned in one section will apply throughout.
In essence, the cognitive load to use the Web site is reduced, thereby leaving you with additional cognitive resources to apply to the task at hand. Instead of your brain having to load balance 1) how to use the IBM Web site with 2) learn more about Rational® Methodology, the UUE of the Web site allows you to focus on the latter.
The math of net usability
When evaluating the benefits of a UUE, the usability of one application relative to another can be equally, if not more, important as the absolute usability of each application independently. Two applications that must be used in context of each other might both have excellent, though individually unique, user experiences, but the combined usability across both suffers with the lack of a UUE.
The overall net usability across multiple systems relative to their individual usability might surprise you. Table 1 shows the possible scenarios on a scale of 1 to 10, with 10 being the best.
Table 1. Net usability
| Two applications have wholly unique user experiences | Two applications share a common user experience |
|---|
| Application 1: Individual usability: 10 | Application 1: Individual usability: 10 | | Application 2: Individual usability: 10 | Application 2: Individual usability: 6 | | Net usability across both applications: 7 | Net usability across both applications: 9 |
For example, say an insurance claims representative has to access Web App 1 for customer information. She also has to access Web App 2 for claims information. To process a claim, she must first use Web App 1 to find a customer and generate a claim number, and then she must use Web App 2 to access the generated claim number, enter claim information, and submit the claim. If the two applications have a UUE, the claims representative will be able to go back and forth between the two much easier than if they do not. While she must work with two different applications, they don't have to feel like two different applications.
UUE prudence
Not all applications should necessarily be integrated into a UUE. A UUE is defined by a set of standards. As with any standards, they must be reasonably applied. Blindly forcing all applications into a UUE does not work. Standards apply to the majority, and you'll nearly always find exceptions. You need to determine the degree to which the user experiences across multiple applications is unified. In some instances, merely applying the consistent corporate branding might be best.
In some instances, differences between applications' user experiences are appropriate. For example, a company that has an intranet, an extranet, and a public Web site targets different audiences with particular sets of information. An employee who has access to all three should be able to easily identify which site he is in so that he can easily infer the confidentiality of the information he is reading. If all three sites are blurred under one UUE, the employee might accidentally divulge information that he read on the intranet, believing that it was already public information.
By adopting common standards across multiple applications, you effectively create a singular dependency. That's fine as long as those standards are well established. But what happens when you realize that one standard is inappropriately defined? You must effectively change every application to which that standard is applied. There are effective ways to develop applications so that you can roll out some changes easily, including Cascading Style Sheets (CSS) and modular code snippets. However, you can't deploy a change such as redesigning the information architecture at the push of a button. It's important to define well-prescribed UUE standards, because you can embed them throughout many applications.
Evaluating the level to which you should incorporate a new application into an existing UUE is relatively straightforward. The picture gets a bit murky when deciding the same with an existing application. An application with an existing user base has static inertia. The users are familiar with the system regardless of how convoluted it actually is. However, because they've built experience working with the system over time, the users have synchronized themselves to the application. Adaptability and, ironically, resistance to change are strong forces in human nature.
A new UX should offer long-term benefits to justify the initial upfront hit of reacclimating to the application. Regardless of how much better a new UX might be, you have to expect some pain in the transition. The improved UX should ultimately enable better efficiency of use and shorter learning curves to bring new users up to speed.
Unified but modular
Having a UUE across many applications can be like placing all your eggs in one basket. How can you easily swap your basket without breaking the eggs? Modular design is the answer. You can effectively separate your content (eggs) from its presentation (basket) and control the presentation independently through the combination of linked templates, snippets, CSS, and JavaScript files. Modular design lets you alter the entire look, structure, and even aspects of interaction behavior by changing a few linked files.
By abstracting common patterns across a Web application, you can uncover those parts of an application that you can modularize. A common set of patterns across most Web applications relates to create, read, update, delete (CRUD) functionality. For example, your Web application might provide access to many entities, such as customers, bills, products, and reviews. For each entity, a common pattern emerges -- users perform a search, select an entity, view a detail page, and CRUD the entity.
The flow of these pages defines the site structure. While you cannot easily modularize and reuse the site structure, you can leverage a single page template across any type of entity for each common screen related to CRUD activity. You can define templates for the search page, results page, entity detail page, create entity page, and edit entity page. You can apply each template to multiple instances, thereby affording you a single point of maintenance and uniformity.
Page templates define the skeletal structure of the page. You might also see common patterns of information display within the page. For example, many pages might have a header title, a breadcrumb, a search box, and a horizontal divider. You can save this element structure once and reuse it across the site.
You have to find a balance between what should and should not be converted to a template. The criteria are the product of how often a component is reused and its complexity. The letter a might be reused across the application, but that doesn't mean you should make a template for it. A unique data layout might be used in two places, but you probably should not make a template for that either. Templates introduce a dimension of complexity, but when they are properly prescribed, they can result in net simplification.
|
Templating engines
Templating engines help development teams create Web applications that separate data from presentation. Some of the commonly used templating engines include:
TeaServlet:
TeaServlet is a framework that sits on top of the Servlet API and works with the Tea template language. It requires a servlet container to run in.
WebMacro:
WebMacro is a templating system written in Java with an effective, lightweight scripting language. In reference to the separation of data and presentation, the WebMacro folks like to say, "Things you don't care about should get out of your face."
FreeMarker:
FreeMarker is not a Web application framework but is suitable as a component in a Web application framework. It simply generates text (HTML or any other text output) based on templates.
Velocity:
Velocity allows you to reference objects defined in Java code. It is part of the Apache Jakarta Project.
|
|
The Java™ programming language features many open source templating engines, including TeaServlet, WebMacro, FreeMarker, and Velocity (see Resources). An added benefit of using a template approach with such tools is that you can achieve a division of labor between the über and less technical staff with the separation of content and presentation.
Take a closer look at Velocity, for example, to see how you can modularize design and separate content from structural presentation. Using the Velocity Template Language (VTL), you can create references for accessing objects in context. They access data. You can use the same set of references across multiple templates. Using directives, which are used for control and action, you can use one template and conditionally render specific references.
For example, with a user profile screen, you can use a single template to view your own private profile, another member's profile, or a product profile. Directives figure out which data to display by the references based on the context of the session. The page structure remains the same, while the content changes.
You can achieve highly modular design with Velocity if you conditionally render entire sections of a page rather than just bits of data. These page sections in turn can conditionally pull data. By using a layout template file, separate page component files, and a configuration file that connects the two, you can pull various modules together to make one cohesive page. You can use the page component files across multiple templates, and you can change the templates to modify the layout without affecting the data.
Finally, Velocity has Velocimacros, which let you designate a chunk of VTL code and pass parameters to it. You can think of them as mini templates. For example, you can define a table structure Velocimacro and pass a CSS class, ID, and data source to it:
#macro( dataTable1 $cssClass $id $memberlist )
<table class=$cssClass id=$id >
#foreach( $member in $memberlist)
<tr><td>
$member
</td></tr>
#end
</table>
#end
|
When a designer needs to include a table in a Velocity template page, he can simply enter the following syntax with the proper parameters:
#dataTable1 ( "gridLayout" "fanbaseInfo" $fanclub )
|
Suppose that one month from now, all such tables must end with a blank row. You only need to change the Velocimacro definition, and the change will ripple through all instances:
#macro( dataTable1 $cssClass $id $memberlist)
<table class=$cssClass id=$id >
#foreach( $member in $memberlist)
<tr><td>
$choice
</td></tr>
#end
<tr><td> </td></tr>
</table>
#end
|
Templates tackle higher-level page-structure patterns, while CSS can address atomic presentation issues in a modular fashion. You can define styles for anything from the font of a page to the bordering of a table. By defining a CSS class in a linked file and applying the class in HTML to an element, you can further decouple the presentation and content. In a completely CSS-driven layout, you can simply swap stylesheets and change the presentation from one suitable for a traditional PC to one suitable for a cell phone. Likewise, it is possible to change the entire branding of a Web application. Check out CSS Zen Garden to see this at work (see Resources).
Finally, you cannot only modularize how information is presented but also interactive behaviors. Interactive elements and behaviors such as sliders, calendars, autocomplete, and drag and drop are available for use from many resources, including Yahoo!, Google, Dojo, Rico, and script.aculo.us (see Resources). With the proliferation of Asynchronous JavaScript with XML (Ajax), you can make many of these utilities interact with data independently without having to refresh the entire page.
To see the true power of modularized behaviors in developing a UUE, look at the familiar functionality of browsing through multiple records. Most applications accomplish this by presenting a fixed set of records per page, along with a list of page numbers that link to each respective page. You can certainly accomplish this with a template for the result page and a snippet for the paging mechanism. But across different applications, questions might arise. How many results should you display per page? Should you have page numbers and forward/backward links? Should you have a text field so users can jump to a page number? If so, should you have a Go button or just assume the users will click Enter?
An Ajax widget can take care of all of this. By displaying all results in a fixed area, users can navigate through all the records by simply scrolling. The Ajax functionality pulls only the records in view so that it doesn't have to pull down everything locally. You can easily use this widget across many applications. Because the applications can all use the same source code through a link to the JavaScript source file, you can easily manage any adjustments to its behavior. You can see this in action at Rico (see Resources).
Summary
We live in a world governed by standards. A red light means stop; a green one, go. An address has a number, street, city, state, and zip code. Standards provide a contextual framework that allows you to process information more easily. They can do the same across Web applications. But because standards serve as a core source that is distributed across many instances, you might face challenges when you need to update a standard. Fortunately, with Web applications, you can readily accommodate such global changes with the proper planning and implementation of templates, CSS, JavaScript, and Ajax behaviors.
Resources Learn
- The Design section in the IBM Ease of Use Web site: Check out this good starting point for developing user interface guidelines.
- Client and server-side templating with Velocity (Sing Li, developerWorks, February 2004): Learn more about templating with Velocity and how to integrate its template-processing capabilities into your own client-side standalone application, server-side Web application, or Web services
- Build apps using Asynchronous JavaScript with XML (Ajax)(Naveen Balani and Rajeev Hathi, developerWorks, November 2005): Create a dynamic, asynchronous Web experience with AJAX-based Web apps -- complete with real time validation and without page refreshes in this tutorial.
- Zen Garden: Walk through and learn about the beauty of CSS design.
- Velocity: Learn more on The Apache Jakarta Project Web site.
- TeaServlet: Read about a template engine that works with the Tea template language.
- WebMacro: Learn more about a templating system written in Java.
- FreeMarker: Read about this template engine.
- Dojo: Find out about an open source JavaScript toolkit.
- Rico: Learn more about the open source JavaScript library.
- script.aculo.us: Find out about cross-browser user-interface JavaScript libraries.
- developerWorks' Web zone: Improve your work with info that specializes in Web architecture and development, featuring downloads and products, open source projects, a technical library, training, and events notices.
- developerWorks technical events and webcasts: Stay current with jam-packed technical sessions that shorten your learning curve, and improve the quality and results of your most difficult software projects.
Get products and technologies
Discuss
About the author | 
| | Mike Padilla is a user experience design director for Web applications at Radian Guaranty (RDN), where he oversees everything from information architecture to branding integration to rich client UI architecture. Mike has led front-end development efforts for such companies as Fleet Credit Cards, Mellon Private Asset Management, The Bank of New York, and Bessemer Trust. Macromedia has featured his usability designs. He received a B.S. in mechanical engineering, focusing on ergonomics, from Cornell University. You can contact Mike at mikepadilla@hotmail.com. |
Rate this page
| |
