Templating & Design > How this site was designed in ExSite
posted on 5:42 PM, April 21, 2008
The redesign of the ExSite Support Site offers up a good real-world example of how to set up and install a new graphic design completely from scratch. This provides a good review of some universal web design issues, and how they are dealt with in the ExSite CMS framework.
The previous design of the support site was borrowed from the base design for exsitewebware.com. The base template for that site was simplified, the top menu removed, and a sidebar added for a vertically-oriented menu and some content previews. This design was functional, but uninspiring, since it was essentially a down-graded version of the exsitewebware.com template that we've all been using for some time. A design refresh seemed like it was in order.
Links to sources are provided at the end of this article, so you can inspect the HTML and CSS directly.
Now the designer had to create an HTML framework to hold these graphics. The first question here is: table-based layout, or CSS-based layout? CSS is more elegant, but can run into problems on browsers that do not properly support it. Tables are more of a brute-force approach, but in some cases can easily work around problems that CSS struggles with (such as vertical centering). The designer explored both options, and found a CSS solution that worked on all of the major browsers.
As part of working out the layout grid, the designer also had to decide whether the layout should be liquid or not. Liquid layouts expand and contract to fill the browser window, but create a few challenges in determining how background images should be defined to ensure they tile and stretch seamlessly. Making this layout liquid in the horizontal direction was fairly simple--because the blue gradients are horizontally symmetric, they are easily tiled to fill whatever horizontal space is available. Liquidity in the vertical direction was more problematic. The gradients fade in the vertical direction, so you cannot simply tile the background vertically (or else the gradient will reset at periodic intervals). But if you do not tile the background, then the small drop-shadow that separates the different "columns" of the page will simply stop in mid page. Creating a very tall background image that would probably be sufficient for most pages was not an elegant solution, because it creates an unnecessarily large download, and due to Murphy's Law, there would eventually be some pages that exceeded it.
The solution was to to use two nested divs. The outer div can be thought of as the "under" div. It carried a background image that had no gradient, just a constant background colour, with a drop-shadow along one edge. Because it has no gradient, it can be tiled vertically to any height. The inner ("over") div carried a background image with the full gradient that fades from blue to white, which does not tile at all. It sits "over" the tiled lower image, but aligned with the top of it. At the bottom, where it fades to white, it merges perfectly with the "under" div. As the page stretches vertically, the upper div stays fixed at the top of the page, while the lower div stretches and tiles to any height.
A further problem was encountered in setting up the footer graphics. For reasons that have to do with CSS's poor handling of vertical alignments, and the inability to easily use either absolute or relative positioning when trying to align footer elements with the main layout above, the designer fell back on a brute-force table layout for the footer. This seemed to do the trick, and since the inelegant table is at the end of the page and does not contain any very important content, this solution was judged adequate.
This image shows the different container elements used to set up the CSS for this page.
With the layout grid settled, the design image was cut up into pieces to match the respective CSS regions defined. The final layout grid was based on a fairly common CSS 3-column layout. The left column was to be fixed at 200 pixels width, to carry the logo and some sidebar text. The right column was to be fixed at a mere 27 pixels, for purely decorative effect. The main column was liquid, and would fill the available horizontal space in the browser.
After this step was complete, we had a prototype HTML file containing the layout grid, assorted images, and a stylesheet that specified the sizes, positions, and background images for each of the layout cells. It is at this point that most of the cross-browser debugging needs to be done, because the support for the CSS rules varies widely across browser platforms. IE6 in particular requires a few "hacks" to the CSS to support the equivalent of max-height and max-width.
To these we added two more content regions. A head element was placed in the dark blue region above the menu bar. A floating element was also added to the body; this would float to the right edge of the page, and only take 250 pixels of horizontal room. The idea was to optionally use this for content previews, quotations, or other sidebar-like content. It might be empty, in which case we want it to collapse down and not occupy any horizontal room.
We then filled in these regions with sample content in our HTML prototype:
To keep the main text scalable on older browsers with limited font scaling capabilities, we set the body text as size "small"; we also set it to be black for maximum contrast and legibility. Text in other regions (sidebar, head, foot, menu, and float) used less contrasting colours and were set at specific sizes (typically around 9pt), slightly smaller than the main text. This may not scale in some older browsers, but that was judged okay as it is secondary text and highly constrained by its container elements anyway.
Links were left using the generic blue link colours, which work well with our colour scheme, and are quickly recognized by all web surfers.
We defined a "button" class for some links, which we decorated with a gradient background, and 3-D border effect. These are used for some important links such as the login and register links in the sidebar.
The Import Template function automatically creates the page object to hold the layout, but it does not know how you intend to block out your content. So we edited the page object, and deleted each of our snippets of sample content, and replaced them with a CMS tag like this:
For those elements that were to hold some generic content, we created appropriate content objects for that purpose. For instance, the "foot" content object was created, and defined to hold a copyright notice and a few footer links. The sidebar was defined to contain a welcome message and some registration and login links.
The default decoration for a horizontal SimpleMenu is spare, so we added three content objects to our template to allow for more effective menu decoration:
SimpleMenuTopH - opening of a simple table
SimpleMenuMidH - divider between two table cells
SimpleMenuBotH - closing of a table
This has the effect of wrapping the horizontal menu elements in a table, with each menu item occupying its own cell. With the table cells to constrain the menu items, each menu anchor was set to display in block mode, with a height equal to the height of the menu bar (26 pixels). These anchors were then given a background image (the light blue menu bar), as well as a rollover ("hover") image, which was the same menu bar in a bright orange. We also added left- and right- borders to the menu anchors, to give a slight 3D effect. The result of these changes was to give the menubar a 3-D tab look; we decided to accentuated this by whiting-out the tab that corresponds to the current page, which helps to highlight out position in the site map.
We also made use of the SimpleMenu plug-in on some other pages, to generate site maps, path-menus, and submenus where appropriate. In the case of the submenus, we also added some CSS decorations to make them more button-like.
The Document plug-in uses generic markup, but wraps everything in a div of class "Document".
The Zine plugin makes heavy use of specialized container elements with a variety of class names. These are used for various purposes including indexes, articles, comments, icons, and reports. This article that you are reading is managed by the Zine subsystem, so you can view source to see the special CSS markup that the Zine plug-in adds to facilitate the styling of articles. There are many rules and combinations of rules that can be applied, allowing for a wide variety in presentation of your e-Zines. We elected to use a presentation style that is similar to the sample layout included in the Zine documentation, and copied much of that CSS into our stylesheet, with some minor modifications for background images (such as comment quotes). We also included some borders and padding for preformatted text, which helps to highlight sample code, as seen here:
Initially, we wanted to have two layouts to choose from. The first was simple, with the "body" content filling the page. The second had a floating "preview" element on the right side of the body, for the purpose of previewing or promoting other site content or services.
Because of the way we set up the page, we did not actually need to change the basic HTML to switch between these two layouts. Our floating "preview" block collapses when it contains no content, so the easy to way to switch between these layouts is just to leave "preview" defined or undefined. When defined, the "preview" block expands to hold its content; when undefined, it shrinks down as if it was never there.
We defined the base template to look for a preview element, without actually defining such an element in the template. That meant the preview would be empty by default, and would not occupy any space on the page. Any given page can define its own preview object, and the layout will automatically expand to incorporate it, without any need to switch templates.
However, we also thought it would be nice to have a default "preview", which could be used as desired. We configured a secondary template to define a preview object which highlighted recent postings into the Zine system (new articles and new comments). Pages that use this template will automatically get a new postings preview, without having to define it.
In the end, this meant we had two templates:
These tests revealed a few minor issues that need to be cleaned up, such as revising the site map to work better with our menus, and finding a few CSS settings that need to be tweaked.
Once that was done, we converted all pages in the site over to the new template using the Template -> Change for all pages function in the Website Editor. Then we custom-set a few pages to use our secondary template with the default preview. At this point, dynamic pages will already be rendering with the new templates, so after one quick pass to check the site over, we republished the whole site, and it all went live.
To view the complete set of CSS rules for both the general layout as well as special CSS rules for the Zine plugins, you can view the CSS file here.
The previous design of the support site was borrowed from the base design for exsitewebware.com. The base template for that site was simplified, the top menu removed, and a sidebar added for a vertically-oriented menu and some content previews. This design was functional, but uninspiring, since it was essentially a down-graded version of the exsitewebware.com template that we've all been using for some time. A design refresh seemed like it was in order.
Links to sources are provided at the end of this article, so you can inspect the HTML and CSS directly.
0. PLAN
The process of designing templates usually proceeds in the following steps:- sketch a graphic design
- convert the design to conventional HTML + CSS + image files
- import the design into ExSite
- derive new templates based on this base
1. GRAPHIC DESIGN
A basic design concept was sketched out in a graphic design package. The colour theme was based loosely on the blue-and-orange of the Exware and ExSite logos, with the addition of some colour gradients and small drop-shadows to give a feeling of depth. When complete, the result was a simple flat image file in PNG format. (Any web-ready format will do, but PNG gives the best quality of the widely-supported web image formats, at the expense of being slightly larger than JPG in most cases.)Now the designer had to create an HTML framework to hold these graphics. The first question here is: table-based layout, or CSS-based layout? CSS is more elegant, but can run into problems on browsers that do not properly support it. Tables are more of a brute-force approach, but in some cases can easily work around problems that CSS struggles with (such as vertical centering). The designer explored both options, and found a CSS solution that worked on all of the major browsers.
As part of working out the layout grid, the designer also had to decide whether the layout should be liquid or not. Liquid layouts expand and contract to fill the browser window, but create a few challenges in determining how background images should be defined to ensure they tile and stretch seamlessly. Making this layout liquid in the horizontal direction was fairly simple--because the blue gradients are horizontally symmetric, they are easily tiled to fill whatever horizontal space is available. Liquidity in the vertical direction was more problematic. The gradients fade in the vertical direction, so you cannot simply tile the background vertically (or else the gradient will reset at periodic intervals). But if you do not tile the background, then the small drop-shadow that separates the different "columns" of the page will simply stop in mid page. Creating a very tall background image that would probably be sufficient for most pages was not an elegant solution, because it creates an unnecessarily large download, and due to Murphy's Law, there would eventually be some pages that exceeded it.
The solution was to to use two nested divs. The outer div can be thought of as the "under" div. It carried a background image that had no gradient, just a constant background colour, with a drop-shadow along one edge. Because it has no gradient, it can be tiled vertically to any height. The inner ("over") div carried a background image with the full gradient that fades from blue to white, which does not tile at all. It sits "over" the tiled lower image, but aligned with the top of it. At the bottom, where it fades to white, it merges perfectly with the "under" div. As the page stretches vertically, the upper div stays fixed at the top of the page, while the lower div stretches and tiles to any height.
A further problem was encountered in setting up the footer graphics. For reasons that have to do with CSS's poor handling of vertical alignments, and the inability to easily use either absolute or relative positioning when trying to align footer elements with the main layout above, the designer fell back on a brute-force table layout for the footer. This seemed to do the trick, and since the inelegant table is at the end of the page and does not contain any very important content, this solution was judged adequate.
This image shows the different container elements used to set up the CSS for this page.
With the layout grid settled, the design image was cut up into pieces to match the respective CSS regions defined. The final layout grid was based on a fairly common CSS 3-column layout. The left column was to be fixed at 200 pixels width, to carry the logo and some sidebar text. The right column was to be fixed at a mere 27 pixels, for purely decorative effect. The main column was liquid, and would fill the available horizontal space in the browser.
After this step was complete, we had a prototype HTML file containing the layout grid, assorted images, and a stylesheet that specified the sizes, positions, and background images for each of the layout cells. It is at this point that most of the cross-browser debugging needs to be done, because the support for the CSS rules varies widely across browser platforms. IE6 in particular requires a few "hacks" to the CSS to support the equivalent of max-height and max-width.
2. CONTENT BLOCKING
Now we considered where our content elements of the page were going to be placed. The center of the page was obviously the body, and we had a small sidebar region on the left side for auxiliary content. The light blue bar across the top was going to hold the site menu, and opposing light blue bar on the bottom would carry some footer links.To these we added two more content regions. A head element was placed in the dark blue region above the menu bar. A floating element was also added to the body; this would float to the right edge of the page, and only take 250 pixels of horizontal room. The idea was to optionally use this for content previews, quotations, or other sidebar-like content. It might be empty, in which case we want it to collapse down and not occupy any horizontal room.
We then filled in these regions with sample content in our HTML prototype:
3. TEXT DESIGN
With sample text in each of our content regions, we could then start adding CSS rules for styling those text elements. We adopted a simple, conservative text style, with Helvetica/Arial/Sans-serif for our default font, and Monaco/Courier/monospace for our code font.To keep the main text scalable on older browsers with limited font scaling capabilities, we set the body text as size "small"; we also set it to be black for maximum contrast and legibility. Text in other regions (sidebar, head, foot, menu, and float) used less contrasting colours and were set at specific sizes (typically around 9pt), slightly smaller than the main text. This may not scale in some older browsers, but that was judged okay as it is secondary text and highly constrained by its container elements anyway.
Links were left using the generic blue link colours, which work well with our colour scheme, and are quickly recognized by all web surfers.
We defined a "button" class for some links, which we decorated with a gradient background, and 3-D border effect. These are used for some important links such as the login and register links in the sidebar.
4. IMPORT TEMPLATE
Now it was time to see what our pages and content would look like in the new layout. We went to the Website Manager, and used the Import Template function to load our HTML prototype into the CMS. Because it was a pure CSS layout, the HTML file only referenced one external file (the stylesheet), so we were only prompted to upload one additional file. The Import Template function does not scan stylesheets for additional files (as of v3.5, anyway), so we used the Bulk Import function to upload all of the special background images we made in part 1, above.The Import Template function automatically creates the page object to hold the layout, but it does not know how you intend to block out your content. So we edited the page object, and deleted each of our snippets of sample content, and replaced them with a CMS tag like this:
<!--content(body)-->where "body" was changed to "head", "sidebar", "float", "foot", etc. We also inserted some CMS meta tag substitutions for titles, keywords, etc.
For those elements that were to hold some generic content, we created appropriate content objects for that purpose. For instance, the "foot" content object was created, and defined to hold a copyright notice and a few footer links. The sidebar was defined to contain a welcome message and some registration and login links.
5. MENU DESIGN
We experimented with the DMenu plug-in, which generates dynamic drop-down menus. However, DMenu uses a set of DHTML tools from cross-browser.com that can get confused by CSS layouts. Often you have to use a table-based layout for DMenu to correctly calculate where its pop-up menus should appear. So rather than try to get that working, we switched to the reliable SimpleMenu plug-in, and inserted it into the menubar to generate a "horizontal"-style menu.The default decoration for a horizontal SimpleMenu is spare, so we added three content objects to our template to allow for more effective menu decoration:
SimpleMenuTopH - opening of a simple table
SimpleMenuMidH - divider between two table cells
SimpleMenuBotH - closing of a table
This has the effect of wrapping the horizontal menu elements in a table, with each menu item occupying its own cell. With the table cells to constrain the menu items, each menu anchor was set to display in block mode, with a height equal to the height of the menu bar (26 pixels). These anchors were then given a background image (the light blue menu bar), as well as a rollover ("hover") image, which was the same menu bar in a bright orange. We also added left- and right- borders to the menu anchors, to give a slight 3D effect. The result of these changes was to give the menubar a 3-D tab look; we decided to accentuated this by whiting-out the tab that corresponds to the current page, which helps to highlight out position in the site map.
We also made use of the SimpleMenu plug-in on some other pages, to generate site maps, path-menus, and submenus where appropriate. In the case of the submenus, we also added some CSS decorations to make them more button-like.
6. PLUGINS
We make regular use of the Document and Zine plugins, and so added some special CSS rules for decorating the output of those modules.The Document plug-in uses generic markup, but wraps everything in a div of class "Document".
The Zine plugin makes heavy use of specialized container elements with a variety of class names. These are used for various purposes including indexes, articles, comments, icons, and reports. This article that you are reading is managed by the Zine subsystem, so you can view source to see the special CSS markup that the Zine plug-in adds to facilitate the styling of articles. There are many rules and combinations of rules that can be applied, allowing for a wide variety in presentation of your e-Zines. We elected to use a presentation style that is similar to the sample layout included in the Zine documentation, and copied much of that CSS into our stylesheet, with some minor modifications for background images (such as comment quotes). We also included some borders and padding for preformatted text, which helps to highlight sample code, as seen here:
.ZineBody pre {
padding:10px;
border:1px dashed #99c;
background-color:#ddf;
}
7. SECONDARY TEMPLATES
Using our main design as a base, we could then derive some secondary templates. Derived templates share many files in common with the base template, so we didn't have to reimport them and set them up all over again. We simply needed to define the differences with the base.Initially, we wanted to have two layouts to choose from. The first was simple, with the "body" content filling the page. The second had a floating "preview" element on the right side of the body, for the purpose of previewing or promoting other site content or services.
Because of the way we set up the page, we did not actually need to change the basic HTML to switch between these two layouts. Our floating "preview" block collapses when it contains no content, so the easy to way to switch between these layouts is just to leave "preview" defined or undefined. When defined, the "preview" block expands to hold its content; when undefined, it shrinks down as if it was never there.
We defined the base template to look for a preview element, without actually defining such an element in the template. That meant the preview would be empty by default, and would not occupy any space on the page. Any given page can define its own preview object, and the layout will automatically expand to incorporate it, without any need to switch templates.
However, we also thought it would be nice to have a default "preview", which could be used as desired. We configured a secondary template to define a preview object which highlighted recent postings into the Zine system (new articles and new comments). Pages that use this template will automatically get a new postings preview, without having to define it.
In the end, this meant we had two templates:
- no default preview
- default preview highlighting recent posts
8. UPGRADE
The template development was now largely complete. To test/debug any unforeseen issues, we switched some pages over to use the new templates. We did this testing on static pages, since the public would continue view the published version and will not see our trials.These tests revealed a few minor issues that need to be cleaned up, such as revising the site map to work better with our menus, and finding a few CSS settings that need to be tweaked.
Once that was done, we converted all pages in the site over to the new template using the Template -> Change for all pages function in the Website Editor. Then we custom-set a few pages to use our secondary template with the default preview. At this point, dynamic pages will already be rendering with the new templates, so after one quick pass to check the site over, we republished the whole site, and it all went live.
9. SOURCE
To view the templated HTML, with content management tags, you can view the raw template here. Use your browser's "show source" function to see the HTML. The embedded CMS tags will appear as comments in the source.To view the complete set of CSS rules for both the general layout as well as special CSS rules for the Zine plugins, you can view the CSS file here.
