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:
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.)
...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.
...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 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:
(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.)
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:
Learn more about automatic menu-building tools here.
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; }