Does your software solution include a Web-based graphical user interface? If so, then chances are one of your customers has previously asked you whether or not you could rebrand the GUI. Whether they simply want to display their corporate logo alongside yours or require that the application be completely adapted to their corporate look and feel, large enterprises typically want interfaces to meet certain graphical requirements.

Most developers tasked with rebranding a GUI grossly underestimate how much effort is required. While you don't need to be a genius to modify the look and feel of an application, the task should not be trivialized.

Like any other software quality attribute or "ility", brandability is easier to achieve if it's designed in your application. The following principles and guidelines should be considered whenever you are white-boarding a Web-based graphical user interface.

A basic principle of software development is to separate the presentation layer from the business layer. Source files (e.g. JSP, ASP or CFM) that contain font tags aren't only hard to read; they're hard to manage! Imagine how much more difficult it becomes when every customer wants to modify these font tags to change simple attributes such as colors and size.

External cascading style sheets (CSS) allow you to apply a style or "class" to any section of your application while defining the actual look and feel of this class in a separate text file. This offers many advantages over embedded font tags, most notably the ability to modify the look and feel of the entire application by editing one (1) text file. In other words, instead of having to modify 200 JSP pages in order to change the font from Arial to Helvetica, you'll only need to modify one text file.

Organize your images. Don't store those jpgs and gifs all over the place in your application's hierarchy. Create an images directory at the root level and add all of your images in that directory. If you have more than 20 images, organize the main images folder with sub-directories. This will greatly simplify your ability to replace your default images with branded ones.

Some larger enterprises will ask you to go beyond changing images, fonts and colors, and require you to display specific text. This is very likely for strings that represent a trademark, corporate slogan or legalities. Furthermore, they may want to improve usability and replace some of the generic label with words that are better understood by their users.

Store all of your text strings--including error messages, button labels and HTML alternate/title tags--in a resource bundle. In the event that the customer decides to change a string throughout the application, you won't have to do a "find and replace" across 200 source files. You'll simply need to change one text entry in a resource bundle, which is generally a simple text file or database record.

Whether you're using ANT or any other build script/tool, make sure it accepts parameters that can help you brand an application at build time. You know you've achieved brandability when you can pass a parameter to a build script specifying which customer to build the application for (e.g. "ant -Dbrand=blockbuster") and the script automagically grabs the custom images and stylesheets.

If you decide that rebranding should occur at deployment time instead of build time, develop tools and utilities to easily deploy custom artifacts on a running instance of your application. Deployment guides certainly help, but don't assume your customers will follow written instructions to the letter. Nine times out of ten, even the most technical customers will have a difficult time following your methods and procedures. If rebranding is intrusive and can potentially break the application, provide tools to simplify the job.

An application is only "brandable" if the people in charge of branding it understand how the infrastructure works. If your ANT script accepts branding parameters, explain how someone can call it. Give command-line examples as to how one would brand the application for "Blockbuster." Explain where the custom images, stylesheets and resource bundles must be stored in your source code repository in order for the build script to automagically grab them. Provide an example that illustrates how a developer can create a customized GUI for another customer such as "Netflix."

The procedure for rebranding an application must be idiot-proof. Don't assume that the person in charge of customizing your GUI will be familiar with your course of action. The tools and utilities provided should, among other things, validate stylesheets and resource bundles to ensure they are properly formatted. They should verify broken image links in case someone replaces a .jpg to a jpeg. More importantly, they should guarantee that someone doesn't mistakenly replace or delete a source file that is critical to the application. (Many a time I have witnessed developers delete source files and entire directories when all they wanted to do is delete an image.)

Rebranding an application takes weeks, if not months. If you had to guess where you will spend 80 percent of your effort, what would you put your money on?

The answer is most definitely E. The majority of your time will be spent waiting! Waiting for your customer to send you hexadecimal color codes, corporate logos, and text strings; waiting for your customer to review the first prototype of the rebranded GUI; and waiting for their legal department to approve the new look and feel as well as the custom trademarks, slogans and legalities.

Luc Richard is professional speaker and author with over 10 years of experience managing the development of software applications. He can be reached via www.betterprojects.com.

Brandability