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.
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.
|Web Component Type||File type|
|Static web pages||HTML|
|Dynamic web pages||JSP or PHP|
|Images||PNG, JPG or GIF|
|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.
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.
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.
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.
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.
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.
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.
Cascading Style Sheets
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.
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.