Over time, your enterprise customer facing sites can become a hodge-podge of content hosted by various web and application servers. Due to lack of infrastructure and a plan, you can find the components used to define your common enterprise look-and-feel duplicated in various places, including inside your web applications. In order to change your look-and-feel, you might need to perform the same change in multiple places, including building and testing your web applications. The question becomes, how do you separate look-and-feel from applications and provide a central place where it can be changed?
Before we answer this important question, let’s define enterprise look-and-feel and the components used to create it.
What Is Enterprise Look-and-Feel?
Recently, I installed WordPress on one of my servers and created multiple instances of it for a team working on a project. It has a nice feature called “themes“. You can search among many themes to choose from, even using criteria in your searches such as “blue” or “holiday”. You can install as many themes as you want. While you can only activate one at a time for one WordPress instance, you can, with the click of the mouse, change which theme is active on your site at any moment. When you change it, poof, your website’s appearance, or “look-and-feel”, can completely change. Your content does not change, with the possible exception of your menus (e.g., not all themes use sub-menus.) Clearly, WordPress has achieved an ideal separation between look-and-feel and content.
What is WordPress, you ask? According to their About page:
WordPress started as just a blogging system, but has evolved to be used as full content management system and so much more through the thousands of plugins, widgets, and themes, WordPress is limited only by your imagination.
The key here is to understand that WordPress has become a Content Management System (CMS). To be sure, while WordPress presents limited application capability through its plugins, it is not the complete enterprise solution you probably need. Yet, despite is simplicity and lack of enterprise capabilities, it does provide a clear lesson on look-and-feel through its 1,457+ themes.
If you are interested in WordPress, you can quickly begin using themes. Try opening a free WordPress hosting account at wordpress.com, and play there to see what your options are. Because I hosted my own from the software provided at wordpress.org, I cannot personally testify to the options available via a wordpress.com hosting account. Yet, I imagine you will have no problem searching, installing and activating themes. Let us know via comments what your experience is.
Optionally, you can learn how to develop themes, where you’ll become involved in site design and layout. This is where you transition from choosing a look-and-feel to creating a look-and-feel. At this point, let’s move on from WordPress to avoid digressing into specifics to that platform required for creating themes, such as writing code with PHP, and just highlight the concepts of what these themes embody.
Each theme comes with its own header and footer, which can contain various elements, such locations where pictures can appear. A theme can also come with a sidebar, which could permit you to drag widgets to it. Themes will define how your menus appear, but don’t define the options you have on your menus. Creating the menus, or list of options a user sees, is part of the content side of content management. But, the themes will often decide where the menus appear, how they look, and whether or not they support sub-menus. Some are “javascript” menus that use animation to create the sub-menus when you hover over them. Others are just a row of links.
In general, your menus appear in your heading. If they appear in the footer, they are usually of the simpler text link variety. Your layout may or may not have a sidebar. This is all part of your site’s look-and-feel.
Between your header and footer is usually a body where content or application components go. Look-and-feel is usually not responsible for what appears in this section of the page. It simply reserves a placeholder for content and application components.
There is one “hidden” part of the look-and-feel. The default fonts and possibly other attributes for how things appear can belong to your standard look-and-feel. Thus, while look-and-feel does not control the content that appears in the body of the page between the header and the footer, it can impact the font styles of the text, color of links or default spacing between images and text of the content that appears in there for both user created content and applications.
Look-and-Feel Components
What components are used to create look-and-feel? These components can consist of static web pages, dynamic web pages, images, JavaScript and cascading style sheets.
| Web Component Type | File type |
|---|---|
| Static web pages | HTML |
| Dynamic web pages | JSP or PHP |
| Images | PNG, JPG or GIF |
| JavaScript | JS |
| Cascading Style Sheets | CSS |
All of these types of components can be produced as part of content and application, in addition to your common look-and-feel. The difference is that in a website theme, these components are playing a role in creating that theme for the site.
Headers, footers a
nd sidebars
These begin by being web pages. Your header should be a page, your footer should be another page. If you have a sidebar, that would be a page, too. While the user sees the end result as one composite page, the page they see can be constructed from multiple sub-pages. How these pages appear together is what we refer to as the site layout. A common header, with the body below it, and the footer below that, is probably the most common type of layout. The question becomes how you create these common layout component pages.
Static option
The simplest method is static HTML. With this method, you have an HTML file that a web designer proficient at HTML maintains, and changes as needed. You can even use a graphical tool to create one. The layout includes just this static HTML.
The cons to static is that your web designer needs to make any changes you want, including to text. Plus, you cannot easily insert context-sensitive data. To be sure, this can be partially addressed with JavaScript, which ultimately becomes an important part of your website design as you use it to address not only obvious look-and-feel elements, such as menu animation, but also in how you include dynamic content, such as the name of the user currently logged in. One way or another, you’ll want to be sure you think through your dynamic needs across your enterprise web use cases, from a basic site, to one requiring user log-in, to customer self-service. Static HTML, with its high maintenance and lack of features, is more of a 1990s path that has given way to increasingly dynamic presentation capabilities.
Dynamic option
You can create a very dynamic header. In this case, which is how it works with WordPress, it is created with a server-side language. Because WordPress is developed with the web programming language called PHP, your header in a new WordPress theme will be a PHP file. This permits you to have server-side scripting that can access a database to produce dynamic content, resulting in your HTML being a combination of embedded in the PHP and generated from the server-side programming logic. If you are hosting on a Java application server such as WebSphere, Web Logic, JBoss or Tomcat, then you’d likely create your header as a Java Server Page (JSP) page, where Java is the server-side language.
Hybrid options
There is a middle-of-the-road option for creating the header. You could create it as a page in a content management system (CMS). This has the advantage of permitting a user of the CMS to be able to edit it. However, due to the complexity required to achieve dynamic inserts and context-aware transformations, you’re still likely to need a web designer, at a minimum, to integrate Javascript and complex HTML into it. Its biggest limitation, though, is that like static, it cannot leverage the dynamic capabilities of a server-side language like a PHP or JSP page could. Nevertheless, because there are many changes that a non-web designer can do in a CMS, it is often preferred over the static option.
Comparing options
Contrasting the options available with the complex topology that an enterprise site can have which can include applications such as web order entry integrated into them, you’ll probably choose a solution that permits you to have the robust server-side integration of a JSP page, while handing as much capability as possible to non-technical personnel, such as your corporate marketing and communications departments. Consider creating a look-and-feel application framework that permits application developers to create the overall theme, with configuration options that permit these business users to be able to configure your theme. You’ll want to define and implement standards that permit new applications and CMS content to be created that does not duplicate these theme elements such as the header and footer. They should be able to easily integrate into them to become part of one seamless user experience for your customers.
Menus
How do you define your menu options? With WordPress, you create menus with your web browser independent of themes. You define each menu option as a URL (link to anywhere on the web), page (content you create), a category (list of content) or a sub-menu. Considering that any user, including non-technical people, can create content using its visual HTML editor, this ability for any user to easily create a menu option puts the power of extending the site menus in the hands of the content owners. In an enterprise, this empowers the business to own the content on the site instead of requiring IT for changes.
These easy to create menus are stored in a database that is ultimately used by the header and possibly other layout pages to create the HTML and Javascript menus. This means that this method of maintaining menus is a form of application, which may or may not be part of the CMS part of your solution. WordPress can handle that role, providing a way for theme developers to “plug in” the menus that are defined by users like content. Even if you handle your header via server-side language application components such as a JSP page, you’ll probably want to store your menu options in a database, and have a web maintenance front-end permitting both technical and non-technical users to change these options. Your CMS may provide the ability to build menus. If it doesn’t, then you’ll want to create one re-usable application component that can be integrated into your layout sub-pages such as your header.
To be sure, this does not prevent applications from having their own application specific menu. Applications can have their own menus, such as order entry having navigation options, that can perhaps be located just below the site menu. Your primary goal in defining your common look-and-feel and menu navigation options is to define navigation that is uniform across your site and independent of any specific application or content. You can have a link on your site menu to order entry, while order entry has its own menu for navigating to product search or viewing the shopping cart.
If you want to include application components in your top level site header, that can be tricky. While do-able, you’ll need to plan for a method for applications to provide the information the header needs to generate or include it.
Images (and other media)
WordPress has a nice media feature permitting you to upload images, videos, PDFs and other static content into a media library. You can then easily insert it into your content, hosting the same piece of media in multiple locations. The nice thing about this approach is that you can see all the places where the media is used.
You’ll want to use your CMS to the fullest extent possible to host your media. There will still be a need for application specific images to be contained within applications. You’ll also continue to have other sources, such as your public web server, which could include content that is uploaded by users using tools such as FTP. Yet, having the option of hosting media in a CMS increases your flexibility and the ability of your non-technical staff to change your look-and-feel as needed.
Javascript
While not absolutely necessary, your look-and-feel could have Javascript to create your menu appearance, insertion of dynamic content, visual effects and perhaps a re-usable library accessible by your applications and content. Like most of these things, you’ll probably use a lot more Javascript within your applications. Yet, even if just used to create your drop-down menus, Javascript can play an important part of your site’s look-and-feel.
Cascading Style Sheets
This is one of the most subtle yet important components of your look-and-feel. This is usually stored in its own file ending with the “css” extension. Directed by HTML, browsers load this file and apply the settings to change the appearance of the page that it renders. It is a bit subtle because users don’t directly interact with it like they do with the HTML that creates the text and items site visitors interact with on the page, Javascript creating drop-down menus, or images. Yet, because it has so much impact on how all these things appear, it is one of your most important weapons in your consistent web site theme arsenal. The wikipedia describes the purpose of CSS in one nice sentence:
CSS is designed primarily to enable the separation of document content (written in HTML or a similar markup language) from document presentation, including elements such as the layout, colors, and fonts.
For the article you are currently reading, the fonts you see and the colors of links are determined by a CSS file that your browser was instructed to load when it loaded this page. Unlike other look-and-feel components, this impacts not only how the header and footer looks, but also the body which may be created by users in your CMS or your applications. Thus, using CSS, you can ensure that all the links on your site have a standard default color, regardless of where the links are contained.
Using CSS to implement layout is a bit tricky and challenging. To be sure, while sites commonly use CSS for formatting, many do not use it to determine layout. Sites commonly use a hybrid of methods, only partially using CSS. Part of the reason is that while CSS can define how a common HTML tag such as a level 2 heading looks, requiring nothing on the part of applications or content that uses level 2 headings, using CSS for layout usually requires detailed coordination with your application developers to provide names that map elements to the styles defined in the CSS files. For instance, if you define a style for the sub-headings of images called “image-sub-heading” that applies a standard alignment and font, your application developers will need to include the “image-sub-heading” name in tags that wrap this text.
CSS also has both advantages and limitations in layout capabilities when contrasted with other methods. You’ll balance these capabilities, using common CSS to impact higher level layout such as your header and footer, default elements like page titles and spacing between things like lines and images, while providing common re-usable conventions that application developers can use to place their applications. Developers will continue to handle layout within their applications independent of overall site look-and-feel, using a combination of application specific CSS in addition to the styles defined in the site’s common CSS, utilizing the benefits of your common look-and-feel, while ensuring the best customer experience in your applications.
Choices
Nearly all of your content can typically fall into 3 categories: static, dynamic via content management systems (CMS), and dynamic web applications. The challenge for an enterprise is to provide a seamless experience for visitors to your site as they navigate from one type of content to another, while ensuring they have a consistent look-and-feel throughout their visit. At the same time, you want the management of this look-and-feel to be as easy as possible, permitting agile changes directed by the business owners of potential and current customers and business partners.
We touched on the various options we have in creating the components that together create the consistent look-and-feel. In our next post, let’s look at various holistic solutions to achieve our primary objectives.
