Support > Documentation > Templating & Design > Graphic Design Best Practices

Graphic Design Best Practices

Page Structure

A page is typically broken into several regions, each holding a block of content that is independent of the others. For example, a common page structure uses a 3-column layout, with a header and footer:

Header
Left Sidebar





Body Right Sidebar
Footer

You can set up any page structure you like (but we will refer to this example in the discussion below). Note that you can use any version of HTML, or any HTML design philosophy (eg. table-based layout, DIVs with CSS, etc.) you prefer. ExSite does not impose any special requirements on you.

The first thing to consider is how each of these different "blocks" will be maintained by the regular site editors, bearing in mind that the editors may not be experts in web layout or navigating the more advanced corners of the ExSite CMS.

Content blocks typically fit into one of the following categories:

  1. Primary content - this is the material that a normal site editor is most likely to need to edit on a particular page. It usually has the most prominent placement on the page (for example, the "body" in the above example). Simplified CMS tools may assume that there is only one primary content block on a page (by convention, this is the "body"), and provide the editor with the option to edit that one block only.
  2. Secondary content - this is sidebar information, or links/teasers to other content on the site, and is typically downplayed in its presentation (eg. smaller fonts, placement off to the side, etc.). Site editors may need to update this information from time to time, or it might be updated automatically by the CMS. You may need to use a more advanced CMS interface to access the secondary content blocks, since the easy-to-use tools only give you the option to edit primary content. In the above example, the right sidebar might contain secondary content, such as headlines and shortcuts to other site content, a login box, breaking news, etc.
  3. Template content - this is generic style and graphical "dressing" that is shared with other pages on the site. Typically this includes logos, masthead graphics, and menus. In the above example, the header might hold the website logo/masthead, the left sidebar might contain the main site menu, and the footer might hold some standard copyright message and links to site policies. All of these can be template content, since they don't change from page to page. Site editors generally do not touch the template content; this is the domain of the site's designer(s).

High-vs-Low Design

High Design pages have received the attention of a professional graphic designer in all respects. Even the basic text in the primary content blocks has been carefully edited and positioned to ensure it meshes well with the templated elements around it. The primary content may include CSS classes and IDs to fine-tune the design of particular elements of the page. There may be specialized images and backgrounds in the primary content, configured to work tightly with certain elements or sections of text. The content works closely with the design, and cannot be swapped into another graphic design without some additional work from the designer. These content manipulations require a high level of technical knowledge.

Low Design pages may have been templated by a professional graphic designer, but the primary content comes from a non-technical editor. In this case, the primary content is plain-old HTML markup, with no special style classes. The content is quite separate from the templated design wrapper, and could be swapped into another template by a non-designer with no loss in quality of presentation.

Mixed Design uses a combination of high- and low-design pages to obtain the benefits of both. High-design pages can look terrific, but require a lot of professional work to produce and edit. Low-design pages tend to look more utilitarian (but can still look fairly decent with a good template), but are easy to produce, even by non-technical people. A common mixed-design approach is to build a high-design entry page to give maximum visual impact to new visitors, but resort to low-design interior pages to maximise maintainability, flexibility, and efficiency. (The two examples shown here come from the same web site.)

If your maintainers are not web design experts...

...Then you want to make heavy use of low-design pages, at least where you expect your site maintainers to be making most of their changes.

Your page structure should emphasize a single block of primary content (the "body"). This is because your site editors may not be fluent in the advanced CMS tools that allow them to selectively update various blocks of secondary content. It is much easier to present them with an interface that basically says "Edit this page", which in turn allows them to edit the "body" only. (This is what the MySite CMS tool does, for example.)

You may also find it worthwhile to give your page an elastic design so the body will expand width-wise as necessary; or equivalently, ensure that your fixed-width design doesn't break if it is forced into a larger width than intended. This is because you have little control over what the editors may try to force-fit into the site pages. They can (will!) try to insert graphics that are too wide for a fixed-width body, which may end up breaking a template that has not taken this into account.

You will also want the page "body" to be simple in shape; a basic rectangle works best. Fancier designs can implement irregular shapes, in which the body text flows around floating images. However, editors could stick anything into these pages (images of unknown dimensions, long or wide tables, more floating images, lists, etc.) and the particulars of where the content breaks to flow around a design element will effectively be random, which means it can end up being ill-matched to the design. The unsatisfactory layouts that result may in turn inspire your content editors to experiment with various random edits to "make it fit", which can leave you with occasional messes to clean up.

Avoid requiring any CSS-dependent HTML elements (ie. elements that must have particular class or ID attributes) in the primary content. That is because your editors are not likely to understand how CSS works, and the WYSIWYG tools do not insert CSS class/ID attributes by default.

If your page structure has secondary content blocks, then it may be useful to preconfigure these blocks to display some useful but generic content (eg. headlines, teaser links). You do this by defining those blocks in the template; that templated definition will be inherited by all pages that do not explicitly define their own version of the secondary content.

If your maintainers *are* web design experts...

...Then you can freely make use of high-design pages where needed. However, even if you are a professional who is not intimidated by high design, you should consider that it is still much faster and more efficient to update a low-design page. If you value your time and want to use ExSite's CMS features to maximize your productivity, a low-design approach to commonly-edited pages will make your life easier. If a particular page is not expected to require regular maintenance, then it may not matter, and a high-design approach will not cost extra effort in the long run.

Multimedia

Multimedia elements such as Flash may be used to "liven up" a page. All-flash pages are discouraged, for reasons of accessibility and search engine friendliness, but you can employ flash elements much like images to improve the graphical impact of your page.

It is important to remember that the ExSite CMS cannot edit the contents of a Flash movie, so if changes are required you must go back to your Flash software, regenerate the movie, and upload it as a new revision. It is best to avoid using Flash for content elements that may require ongoing maintenance.

Otherwise, handling Flash is straight forward - upload your SWF file into a suitable library, and then insert your Flash wrapper HTML into your page, for example:

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" height="150" width="500">


pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash"
height="150" width="500">

(Note the CMS notation for the SWF file.) This HTML snippet could in principle be placed in a library as well; in principle that would simplify things, since an editor merely has to reference the snippet to insert a fully configured Flash movie. (Note that interactive flash movies may require additional Javascript to make them work easily in IE; this is beyond the scope of this document.)

Menus

If you are using a plug-in to auto-generate your site menus, then your menus must be designed in a regular and consistent fashion. Essentially, this means every menu item must be templated. This is what allows ExSite to automatically extend your menus when you add new pages to the site.

A menu link is typically output by auto-generated menu plug-ins as something like this:

My Page

The anchor tag may be given an ID of "thispage" (meaning that this link corresponds to the page currently being viewed) or "toppage" (meaning that this link corresponds to the highest-level ancestor page of the page being viewed). In some menus, submenus will automatically be exploded, and those links may be given a class of "submenu". These CSS attributes can be used to restyle menus to highlight your current position in the site.

These links are then ganged together with some kind of separator HTML. For example, in the default horizontal (menu-bar) menus, the separator HTML is a simple "|" character; in vertical menus, it is a "
" character.

You can get arbitrarily fancy with your separator HTML, by specifying custom snippets of HTML that should be placed between each of your menu links. You can also specify HTML snippets to be placed before and after the whole block of menu links (for example, to put them all in a table or other wrapper).

The important things to remember when designing for extensible menus are:

  1. each menu link follows the same basic format as all of the others
  2. the template should allow enough space to accommodate the expected number of links in the menu

Learn more about automatic menu-building tools here.

Graphical Menu Buttons

Some sites use graphic (image) buttons for menu links. While this allows for a very customizable menu appearance, it causes a serious drop in maintainability. That is because new graphics must be created by a graphic designer before new pages can be added to the menus. For this reason, we recommend always using text menu links.

Auto-generated menu links will use normal text anchors to ensure that the CMS can easily generate new menu links automatically. This also ensures that your site navigation remains accessible and search-engine-friendly. You can create nice-looking semi-graphical menu buttons simply by adding background images to your menu links. For example:

a.menu { display:block; width:100%; background-image:url(menubg.gif); }

Using the :hover pseudoclass, you can provide rollover effects. For example:

a.menu { display:block; width:100%; background:url(menubg.gif); }
a.menu:hover { background-position:0px 30px; }

Topics

google (5 items)
RSS (3 items)
SEO (3 items)
plug-in modules (28 items)
IT (9 items)
best practices (5 items)
visual tutorial (29 items)
security (3 items)
data handling (7 items)
fundamentals (3 items)
graphic design (19 items)
web protocols (9 items)
programming (48 items)
html formatting (7 items)
POD (32 items)
events (8 items)