Executive Summary
You have a company site that the public visits and your customers come to regularly for self-service options such as order entry or checking on the status of a claim. In addition to hosting these on-line customer applications, you have content on the site, such as product specifications created by your marketing and other non-IT departments. When a customer logs into your applications to use self-service, you want the experience to be holistic and customer-centric, so the customer feels they are at one site completely focused on their needs. Your objectives include having a common customer-centric look-and-feel throughout the customer visit to your site that empowers your business to quickly change your branding and content to optimize to changing business needs.
Behind the scenes, there are various information systems integrated together to create the complete visitor experience. You’d like to add more capabilities, such as a Content Management System (CMS) to permit your business to quickly author and publish new content to your site. The question becomes, how do you manage the header, footer, company logo, your navigation menus and other components of your site’s look-and-feel?
The business empowerment and agility benefits of a CMS lead you to consider putting your look-and-feel in there. However, the CMS is not able to supply the customer-centric capabilities that an application can provide, capabilities needed to tie your customer self-service into the content portions of your site.
Putting your look-and-feel into an application with a web front-end for managing its components creates the customer-centric capabilities you need, such as a link to the customer’s shopping cart that they might click after viewing a product specification published by marketing. Because of the compelling value of the CMS for quick and easy content publishing, and its ability to help make management of the look-and-feel components easier and quicker for the business to update, your best approach is to have an application where you can manage your look-and-feel components and integrate them with your customer self-service applications and your business owned CMS content. This leaves you with one look-and-feel creating a unified holistic customer-centric site seamlessly integrating your business published content with your customer applications.
The Enterprise Website Design Strategy Challenge
Having an enterprise website composed of content created by your marketing and communications departments, customer self-service components such as order entry, and various types of other applications such as calculators or tools that draw interest to your site result in your site being composed behind the scenes from various sources like a patchwork quilt. If you’ve managed to have a common look-and-feel despite years of unplanned transition, you’re likely to find it difficult to change to support the brand marketing you’d like to have, let alone be able to handle the complete re-imaging required by a corporate merger.
In the previous post on Unified Look-and-Feel on Enterprise Websites, we discussed what look-and-feel is and the components that are used to create it. This website look-and-feel primer touched on the components that make up look-and-feel and the various options you have with these components.
Now we’ll delve into overall options you can use to help build a consistent look-and-feel you can quickly and easily transform to achieve improved brand image and better customer experience as your business needs change.
Before discussing options, let’s go over objectives you’ll want to consider.
Objectives
Before you compare options, you’ll need to understand your objectives so you can measure the pros and cons of options, and look for techniques that can help you produce the ideal outcome.
- Common look-and-feel. Visitors to the site feel like they are visiting one company. Your high level menus are available and consistent no matter where visitors are on your site.
- Customer-centric. Customer logs in once to access the site. The customer can easily click to log in or out, view their cart, or change their profile or preferences.
- Quick optimization to changing business needs. Your look-and-feel and brand image must be able to quickly change with the strategy and goals of your business. You’ll need low maintenance cost, high flexibility, and as much of this change capability empowered to the primary stakeholders, the business departments responsible for marketing, communications and customer service.
- Longevity. Your solution continues to achieve these objectives years later.
Option 1: Content Management System (CMS) centric
In this scenario, you have a Content Management System (CMS) permitting business owners of content to create web content that can be edited using a graphics editor tool. The graphics tool creates HTML, the code sent to web browsers to represent the page to display. But, the content creators do not need to understand HTML or be web designers or developers. It could be autonomous, in that you could host your site using just a CMS server if you did not also have customer self-service applications. You create the header, footer, menu and other components in your CMS.
If your applications are hosted on a different server such as WebSphere Application Server (WAS) or JBoss, how do your applications integrate? Simplistically, they have uniform resource locators (URL) pointing to the layout components, such as a URL pointing to the header. (You see URLs when you surf the Internet in the address space near the top of your web browser pointing to the page you are viewing.) This means, of course, that the header in the CMS must be autonomously displayable like a web page. Ditto for the footer and any other displayable components. Applications have a choice. They can embed these URLs into their web layout pages, perhaps using IFRAMEs to position and load them. In this scenario, the visitor’s web browser directly retrieves these components from the CMS system because that is where the URLs point. Or the applications can, like a browser, obtain the HTML necessary to create the components from the CMS, and embed it within their own pages. With this latter approach the visitor’s browser is receiving the header directly from the application, not from the CMS server.
The pros to this approach are clear, centering around the benefits of a CMS. The CMS gives you one place where your look-and-feel components are maintained. Because your CMS permits business users such as marketing personnel to update content, your look-and-feel is easily maintained and highly accessible, permitting a broader ownership over the content used to create your look-and-feel components. This is a nice boost to your ability to be agile to business change.
The limitations to this approach center highly around application integration. Thus, for sites that do not require applications such as customer self-service, this is often the best approach. A blogging site, for instance, can be completely deployed with WordPress.
If your site includes customer self-service applications or tools, however, you’ll find this model to be difficult to support. How do you include common application capabilities in your header, such as the ability log in, log out, or view the shopping cart? Many sites with e-commerce capabilities have a “view cart” link in the header. How do you handle one customer’s login session across the site when your CMS is not likely to be geared to provide the ability for your customers to log into your applications or provide individual customer-centric options?
Clearly, we want the benefits of a CMS while also having the benefits of our customer-facing applications. This option delivers the CMS benefits, but comes up lacking application capabilities.
Option 2: Look-and-feel as an application
Your applications may currently have the headers and footers defined within them, probably with dynamic web pages such as Java Server Pages (JSP). One issue you have is that they are duplicated across your various applications even though they appear the same to your customers.
To resolve this duplication, you can isolate your look-and-feel components into their own application, and then just have your applications include them. Because they are in the application realm, they can handle your dynamic requirements, such as providing common links for your customers including the ability to log in, log out, view profile or view cart. Your imagination is the only limit when your look-and-feel is handled as an application.
Because this is an application, your web developers can change whatever you need. How do you empower the business to change the look-and-feel and branding of the site? While not as easy as using a CMS, you can create an easy to use maintenance front-end to permit common changes, such as menu items, images and colors. Applications can store anything in a database, and can create any front-end for maintaining that data, and then use that data to create any dynamic content or components for your website’s look-and-feel.
In this option, you achieve a complete separation between your site’s look-and-feel and your other customer self-service applications.
What about non-application content, though? Clearly, while you can go far without a CMS, and achieve quite a lot on the look-and-feel front, your business agility is likely to be optimized through the use of a CMS. The question then, becomes, what role the CMS can play in this? For this, we consider option 3…
Option 3: Look-and-feel application and CMS hybrid
Can we have the best of both a CMS and a look-and-feel application? Can we provide the business with a high degree of control over both content and look-and-feel through the CMS and application maintenance capabilities, while ensuring the highest degree of application capability and integration to provide the best possible experience for customers who log in and public tools users?
Presuming you have look-and-feel defined primarily as an application, you can integrate content the way you integrate the applications. You can provide a convention that provides the consistency components, such as your header and menu, while inserting the customer application or CMS content in the center portion of the page designated for this purpose. Both your CMS content authors and your application developers would use this convention to insert their pages into the layout.
This solves the issue of CMS integration for the purposes of providing business authored content such as product specifications and other marketing content into your site while also providing this benefit to your customer facing applications. You can change your look-and-feel independent of content or applications, avoiding duplicate maintenance. You can change your header, footer, or layout or virtually any other component of your look-and-feel in one place.
Can you go further and use the CMS to help create at least part of the components that paint your look-and-feel? You can define certain parts of it to originate from the CMS, and create conventions for pulling them into the look-and-feel application. For instance, you might want the CMS to maintain the footer since it doesn’t usually have dynamic personalized customer-centric content. While you might keep the header in the application due to the integration requirements for a customer-centric experience, you could include static components of it in the CMS, such as your company logo or the CSS that defines your site’s standard fonts, spacing and colors.
This option optimizes and balances the use of your infrastructure to create the best possible experience for visitors to your site while achieving your objectives, including your capability to quickly adapt to new business demands.
Option 4: Duplicate everywhere
With this approach, you have a standard set of components of your look-and-feel, and you disseminate it to the various content and application creators, asking them to integrate them into the applications and CMS’s. You duplicate these files, such as the HTML for the heading and footer, your menus, your CSS and Javascript, in all the places to create a common look-and-feel no matter where the user is at.
To be sure, this works. Once complete, your customers will enjoy a consistent look-and-feel. The biggest con, however, is cost and lack of agility. This is, in part, because change requires not only changing all your applications, but regression testing them as well. Because this cost is high, there is a high risk that you will only change portions of your site as the business needs change, resulting in a broken and dis-joined website, losing your common look-and-feel.
This is, at best, a temporary solution… a band-aid. Why mention it if it is such a clearly poor option? Because barring a clear strategic plan to architect your web sites internally to obtain all your objectives, this is the likely option you’ll unwittingly choose. In the absence of a concerted effort to choose otherwise, this is your default option.
Option 5: Web Portal Server
A web portal, conceptually, is a site that is dedicated to providing links to locations on the web that usually fall under a common theme. You could have a golf web portal that provides links to various golf sites and news.
Out of this concept came the web portal server, a web server designed to provide a face to your organization by hosting the components you include in a page as “portlets”. It is similar to a CMS in that you can create content for it, and it can become an entire site, including the look-and-feel.
Open standards organizations such as the Java Community Process define specifications for creating and hosting portlets. The Portlet Specification (JSR-168) and its 2.0 successor (JSR-286) are implemented in products created by IT vendors IBM, Red Hat and countless others.
With a robust enterprise portal server, you can construct an entire website, including your header, footer, menus, and content. It is like a CMS, although it typically lacks features of a CMS that isn’t essential for building a website, such as document management and work-flow.
Unlike a CMS, however, this provides a standardized way to integrate application components as portlets. In fact, you can think of portlets as application widgets that can be placed anywhere within a portal server independent of the creation of the portlet itself, like the tiles in a moving square puzzle. A portlet is, for all intents and purposes, a movable tile containing a web application or content.
The portal server is likely to come with all the maintenance for building and defining all the various pieces, including simple HTML portlets where you just create content, much as you would with a CMS.
What are its downsides then? While it is very good at integrating everything, it is not ideal at any one thing. On the content side, it is not as robust with content as a CMS which tends to have better publishing work-flow and controls. On the application side, a portlet can be a bit restrictive, or cramped, inside of a little portlet with limited control over pages.
To be sure, there are popular sites built using this option. 53.com is built using WebSphere Portal Server (WPS). The NCAA even combines WPS with IBM Web Content Manager (WCM), which IBM describes as being “Tightly integrated with IBM WebSphere Portal.”
The largest limitation is on the application side, however. For instance, if you are using WebSphere Commerce Server (WCS) to create your online customer purchasing capability, you are not likely to be able to put it in a portlet. WCS does not come with a portlet sample store to help you create one. If you try to create one, you are very likely to hit road blocks. Ditto for other customer applications you may obtain off-the-shelf (OTS) or create.
One approach you can use to overcome this is to have a multi-tiered approach to your site, where the portal server is the first front-facing portion of your site where you can take advantage of its simplified extensibility, and create portlets hosting lite versions of your applications, or content from your applications, such as a graph. You could choose a CMS that integrates well with your portal server. However, for applications, such as those built using WebSphere Commerce Server, where a portlet is not a realistic option, you can have the customer move to the second tier, ideally one closely representing option 3.
We digress, though, because at this point by introducing the option of a portal server we are discussing your web architecture and capabilities beyond just look-and-feel. To bring us back to our original discussion, you can integrate your portal server in the way you integrate your CMS in option 3. Using a multi-tiered holistic approach you can prevent duplicating look-and-feel components, defining them using the hybrid model that include both application and CMS components, while using the portal integration capability to present it in your portal server. In an enterprise solution with a CMS and applications, your use of the portal server doesn’t provide a look-and-feel option. You are using it for other benefits, increasing the case for option 3 (hybrid) to have one centralized look-and-feel application for all your presentation options.
Conclusion
Clearly, you’re trying to avoid option 4 of having the components of look-and-feel duplicated in your CMS, applications, and possibly your portal server. Without a plan or concerted effort to choose a better option, duplication is your default option.
Option 1, using a CMS, looks very good from a content perspective, but leaves out the application side of things. Likewise, option 2, creating a look-and-feel application, solves the application side of things, but does not empower the business (non-web developers) to be able to quickly create content if it is not integrated with the CMS. While implementing both of these options independently is better than option 4, it results in duplicate components for your look-and-feel and can result in a disjointed experience for your customers who are likely to jump back and forth from your content and your applications. A customer might, while searching for products to add to their shopping cart, view the product specification of one, landing them in your CMS. If doing this removes their shopping cart options normally in the header, it can be confusing and requires additional clicks to return them back to their cart.
Option 3 solves this by creating a hybrid model for your CMS and your customer applications. By sharing the look-and-feel application, and perhaps having the CMS contribute to parts of it, you eliminate duplication. This permits a truly holistic experience for your customers, who can now enjoy both your CMS and your applications while feeling like they are at one united site completely dedicated to their needs.
With the centralized look-and-feel application and a CMS integrated, you can introduce new web capabilities such as a portal server to the mix, while still having one isolated look-and-feel and an integrated experience for your customers.
