User Interface

• HTML delivery via templates: an overview
  • HTML templates
  • Processing instructions
  • Collection templates and class fallback
• TextClass
  • General Page Layout
  • Specifying Individual Collection Characteristics
    • CSS files
    • Graphics
    • Header characteristics
      • Background colors and graphics
      • Title name or graphic
      • Navigation tabs and fonts
      • Navigation sub menus
  • Templates
  • Processing Instructions
• ImageClass
  • Specifying Individual Collection Characteristics
    • CSS files
    • Graphics
    • Header characteristics
      • Background colors and graphics
      • Title name or graphic
      • Navigation tabs and fonts
  • Templates
  • Processing Instructions

HTML delivery via templates: an overview

The user interface in the DLXS middleware is manifested by a combination of interrelated techniques:

• HTML Templates
• Processing Instructions
• ProcIns Module

HTML Templates

HTML templates are used to deliver dynamic content from the CGI within a prescribed HTML structure. In general, there are as many templates per class as there are distinct page types in the overall functional architecture of the class. A collection implemented with the TextClass middleware, for example, can include up to 33 template files for delivering, among other pages, multiple search forms, results displays, bibliographic headers and tables of contents, search histories and full text displays. Each HTML template is a combination of static HTML code for areas of content that are unchanging from page to page, and processing instructions that are either replaced by content provided by the CGI or used to remove content or code from the template before delivery. Processing instructions can deliver simple strings, or large combinations of text and HTML code, depending on the circumstance, but the practice has been to minimize the amount of HTML code replaced via a PI because this allows for easier maintenance of graphical interface at the template level. Otherwise, the only rule governing template planning is that, when parsed, it should deliver valid or acceptable HTML to the browser.

Processing Instructions

HTML templates are combined with processing instruction tags that are parsed and replaced by the middleware. Processing instruction tags are of the form

<?PI_IDENTIFIER_NAME [modifiername="value"]*>

where all identifier names are preceded by a question mark and are represented in all capital letters with underscore characters. Zero or more modifier name/value pairs can be included to provide additional parameters. Here are two example PI tags:

<?TITLE>	Appears witin <TITLE></TITLE> tags and supplies a collection title string.
<?DOC_ROOT mode="single">	Can appear within the href or src attribute values in individual collection templates to return the appropriate local root path of that collection.

Processing instruction tags are not, in all cases, a standardized API mechanism to collection information, though they share some of those characteristics. In general, the PIs are more likened to a customized API to the middleware itself. In this regard, PIs perform two general types of functionality:

PIs may act as simple variable names: As in <?TITLE> above, replaced by simple strings or even large blocks of HTML code and text;

PIs may act as include/exclude instructions: A pair of PI tags may instruct the middleware to include or exclude code contained in the template, depending on specific context.

<?INCLUDE_COLL_SPECIFIC_CONTENT id="navbarbrowselink">

<td id="browsetab" width="90" height="23" align="center" nowrap>
  <span class="navlinks">
   <a id="browselink"     href="<?COLL_SPECIFIC_CONTENT id="navbarbrowselink" cginame="text-idx">"     class="nav" onMouseOver="P7_autoLayers(0)">Browse</a>
  </span>
</td>
<td id="sep3" width="1">
 <img src="/t/text/graphics/plug.gif" width="1" height="1" border="0" alt="design   graphic">
</td>

<?INCLUDE_COLL_SPECIFIC_CONTENT id="navbarbrowselink">

The code example above is from the table that contains cells navigation bar tabs and tab divisions. The HTML wrapped within the <?INCLUDE_COLL_SPECIFIC_CONTENT> PI tags is for a browse feature that is not supported by all collections. The PIs are used to remove the code in the case of collections that do not need this HTML, and to provide the appropriate url for the browse feature for collections that do have browse features.

Collection templates and class fallback

Each of the class-specific sections below describes the techniques that are applied within the class architecture to effect changes to overall class look and feel as it is expressed through the templates. It is important to note, however, that the class middleware supports the implementation of customized, collection-specific templates and associated stylesheets. That is, when attempting to render a particular page utilizing a specific template, the middleware will first look for the required template in the collection-specific path, using a customized template if it exists. If there is no such customized version of the required template in the collection path, the middleware will utilize the default class template. The sections below, thus, apply to the techniques that can be applied to any templates, class defaults as well as optional individual versions.

TextClass

General Page Layout and Color

Default page delivery in Text Class is done via class-level templates that are shared by all instances of the class, though the middleware also supports collection-specific templates for any or all page-based behavior within the class. All default Text Class page templates are based on the same layout approach, which relies on tables (along with transparent spacer gifs) for all positioning and general color or graphic appearance. General layout is shown in Figure 1, which shows top-level tables with borders showing, and using the color scheme for the Voltaire électronique collection. All table cells for header and navigation bar content at this level have default values for the bgcolor attribute for browsers that are not CSS-capable. Each header and navigation cell also has a default CSS class value and default background image specified in the background attribute. The background colors created by class and gif allow for flexibility to change appearances for different collections based on the same template. For more on specifiying individual collection appearance, see Specifying individual collection characteristics.

Figure 1: top-level table structure of a typical page.

Figure 2 shows the simple search page for The American Verse collection as it appears normally. Navigation bar labels, page text header markup (not header text content, e.g., "Basic Search"), instruction text and footer text are hard coded, and thus identical across all collections. All other content is specified per collection by processing instructions.

Figure 2: Basic search page for American Verse.

Specifying Individual Collection Characteristics

CSS files

Text class templates utilize two CSS files for controlling most font and color characteristics: textclass.css and textclass-specific.css. textclass.css is stored in at the <root>/t/text/ path and contains all the default style declarations. textclass-specific.css is created for each individual collection and stored at the <root>/c/coll/ path. References to both stylesheets are as follows:

<link rel="stylesheet" href="<?DOC_ROOT>textclass.css" type="text/css">
<link rel="stylesheet" href="<?DOC_ROOT mode="single">textclass-specific.css" type="text/css">

The <?DOC_ROOT> processing instruction resolves to the relevant path for each stylesheet. Because textclass-specific.css is referenced after textclass.css, any style declarations that appear in textclass-specific.css will effectively overwrite matching declarations in textclass.css. This is how fonts and background colors are varied for each collection. (full text of textclass.css)

See a comparison of textclass.css and a collection specific CSS file.

Graphics

Default text class templates employ a variety of relatively generic graphics that can be referenced by all collection instances. A table of shared files shows those files that are stored in the <root>/t/text/graphics/ directory. Any alternative graphics by identical names may be stored in individual collection graphics directories to replace the default class graphics for that particular collection. Any files not stored in collection graphics directories, but referenced in the templates, will be referenced from the class graphics directory as a fallback mechanism. Graphics files that are likely to be unique to each collections are discussed in the section on header background colors and graphics.

Header characteristics

The header of each page template includes that area in the top 75 pixels of the page containing those elements associated with unique collection identity: main collection title, global links, if any, and the main navigation bar. The templates accomodate inclusion of background colors or graphics to provide some flexibility in creating unique appearances for different collections.

Background color and graphics

Main background color for template headers is provided at three different levels: default background colors for table cells specified in the bgcolor attribute, style declarations in the textclass-specific.css stylesheet, and table cell background graphics referenced by the background attribute. Figure 3 illustrates how these characteristics are specified in td opening tags in the Voltaire électronique collection.

Figure 3: Header cell color and graphics.

The two top cells each have CSS class associations and background graphic references to files in the local collection graphics directory. The hdrcolor style is set locally in the textclass-specific.css style sheet as

.hdrcolor { background-color: #FFFFF1 }

The background graphics files, hdr-bg1.gif and hdr-bg2.gif, are, in fact, laying "over" the background color specified by the CSS style--the order of precedence for CSS capable browsers is background, class, bgcolor--but you see the CSS style colors because the gifs are transparent. The lower cell has a bgcolor value and a CSS style, navcolor, set again in the local textclass-specific.css as

.navcolor { background-color: #F3E098 }

Figure 4 illustrates the appearance of another header based on the same template using non-transparent background gifs that integrate with the collection title gif and the CSS style for navcolor.

collection title gif hdr-bg1.gif and hdr-bg2.gif provide background.

Figure 4: component files for a header portion of UM Technical Reports templates.

Title name or graphic

Collection title name is provided in the templates via the <?TITLE mode="complex"> processing instruction. The PI will resolve to a text string or a graphic file as specified in the colldb. When rendered as text, titles are wrapped in H3 tags with CSS style topheadlink so that collection title font can be specified.

Navigation fonts and tabs

Color for navitation tabs is controlled by CSS styles, as are the border colors that surround and underline the tabs. Tab color is, in the "backgrounded" state, set by the navcolor style. The tab "foreground" state color is specified with the navhicolor style. Border and underline colors are set with navdivision and navhrcolor styles respectively.

Font settings for tabs are also CSS controlled. Relative style declarations for fonts are as below:

/* nav bar fonts */
.navlinks { font-family: Arial, Helvetica, sans-serif;
font-size: 12px;
font-weight: bold;
color: #666666;
text-decoration: none
}

/* nav link characteristics */
A:hover { text-decoration: underline }
A.nav { color: #FFFFFF;
text-decoration: none
}

A.nav:hover { color : #FFCC33;
text-decoration: underline
}

These styles set the default, "closed" tab state for all navigation fonts. In previous releases of the class, each navigation state (e.g., basic search, proximity search, browse, etc) has been represented by a separate template file containing specific HTML markup: in that scheme, styles for the "open" state characteristics were declared in the style sheet and simply applied to different HTML elements as required.

In release 10, the navigation menu is contained in a single, separate template file, navheader.chnk, that is inserted into all templates. Instead of changing the various CSS class associations for relevant HTML elements to effect state, the HTML elements in navheader have permanent ID associations, and the template file referencing the nav header markup inserts necessary CSS declarations to effect the preferred state. Figure 5 shows a "close-up" of the navigation bar HTML, with table borders showing, and illustrates the placement of ID values on table cells that will serve as CSS selectors.

Figure 5: "Close-up" of the navigation bar with "ID=" values indicated. Additionally, the text of the "Search" and "Browse" tabs also have ID values ("searchlink" and "browselink," respectively).

When navheader.chnk is inserted into search.tpl, requiring that the search tab be shown in an "up" state, the cgi also inserts the contents of searchtabstyles.css into the page (shown below).

#searchtab { background-color: #ffffff } /* background color of the search tab proper */
#sttopborder { background-color: #333333 } /* search tab top border background color */
#sep1 { background-color: #333333 } /* separator 1 background color */
#sep2 { background-color: #333333 } /* separator 2 background color */
#stbotborder { background-color: #ffffff } /* search tab bottom border background color */
#searchlink { color: #000000 } /* search link color - attaches to the immediate anchor element */

The result is as is shown in Figure 2 above.

Navigation sub menus

In a previous release of the DLXS Text Class design, multiple search options were grouped under a single "Search" tab as a static sub-menu. Figure 6 illustrates this design as implemented by the ACLS History E-book collection.

Figure 6: The ACLS navigation bar showing static search sub-menu.

In an effort to conserve vertical space, release 10 will implement, by default, a "pull-down" menu that triggers by Javascript onmouseover events. This menu is shown in Figure 7.

Figure 7: The American Verse navigation bar showing the "pull-down" menu.

The pull-down technique an implementation of the Project Seven positioned dropped down menus design, utilizing Project Seven extensions to Macromedia Dreamweaver. The Project Seven implementation is very reliable, working effectively for Netscape 4.7 and up, and for Internet Explorer 5 and up (and most other browsers) for the PC and Mac platforms. Even so, the search page design offers static link alternatives for all menu options.

(Note: The implementation of the pull-down menu, however, is not tied to the cgi since the cgi only provides the HREF values for the various links in the menu. Alternative markup for the earlier design is available, and will be supplied in the distribution.)

Modifying the appearance of the pull-down menu background colors and font characteristics is accessible through CSS class declarations, shown below.

A.menunav { color: #000000; text-decoration: none }
A.menunav:hover { color : #FF6633; text-decoration: underline }

/* the color of popup menu cells in the up state - #BABCEA */
.mencellup { background-color: #E5E5E5; }

/* the color of the bground table cell for the menu nav i.e., the border color for nav cells */
.menucellground { background-color: #666666; }

The font style of the menu labels themselves is controlled by the smallformfont class.

Modifying the dimensions and/or behavior of the menu is best accomplished by opening the navheader.chnk template file in Dreamweaver, with the accompanying extensions installed, and editing it in that environment. The extensions are available for free from the Macromedia Exchange site (select the "DHTML Layers" category), and the tutorial at Project Seven (which also provides access to the necessary extensions) gives a clear, step by step instruction of how the menu is assembled.

Alternatively, view this brief tutorial, which illustrates editing the DLXS search pages in Dreamweaver.

Text Class Templates

The table below gives a brief description of all templates included in the Text Class distribution. As a companion, you may also want to view the list of processing instructions also supported in text class.

Text Class Processing Instructions

The following table includes descriptions of all the processing instructions that appear in TextClass templates, as well as links to descriptions of the relevant template files in which they appear.

ImageClass

Specifying Individual Collection Characteristics

CSS files

ImageClass templates, much like TextClass templates, utilize two CSS files for controlling most font and color characteristics. ImageClass templates differ, however, in that they do not include a default reference to a collection-specific CSS file, but only build a reference to a collections CSS file if one exists. This obviates the need to include a collection CSS file for every new collection.

The reference to the class CSS file is also different form the TextClass templates in the <LINK> element pointing to the file is written dynamically using Javascript code. This allows the template to refer to one of any number of separate CSS files to best suite the specific characteristics of a particular combination of browser and platform. A portion of the code, creating the <LINK> reference is shown below:

if (ie)
{
  document.writeln('
<link rel="stylesheet" type="text/css"
href="<?PATH type="web">css/imageclass-ie- '+platform+'.css\">\n');
<?CSSURL type="ie">

}
else
{

document.writeln('
<link rel="stylesheet" type="text/css"
href="<?PATH type="web">css/imageclass-ns-'+platform+'.css\">\n');
<?CSSURL type="ns">

The <?PATH type="web"> processing instruction resolves to the relevant path for each stylesheet. The <?CSSURL> processing instruction will create a link to a collection-specific CSS file if it exists. Because the collection-specific CSS is referenced after the class CSS, any style declarations that appear in latter file will effectively overwrite matching declarations in the former. This is how fonts and background colors are varied for each collection.

Graphics

Default ImageClass templates employ a variety of relatively generic graphics that can be referenced by all collection instances. A table of shared files shows those files that are stored in the <root>/i/image/graphics/ directory. Any alternative graphics by identical names may be stored in individual collection graphics directories to replace the default class graphics for that particular collection. Any files not stored in collection graphics directories, but referenced in the templates, will be referenced from the class graphics directory as a fallback mechanism.

Header characteristics

The header of each page template includes that area at the top of the page containing those elements associated with unique collection identity: main collection or group title global links, if any, and the main navigation bar. ImageClass templates work very similaryly to TextClass templates to accomodate inclusion of background colors to provide some flexibility in creating unique appearances for different collections.

Background color and graphics

Main background color for template headers is provided by style declarations in the class CSS styleshee. Figure 8 illustrates how these characteristics are specified in td opening tags in the class template.

Figure 8: Header cell color and graphics.

The three top cells each have CSS class associations inherited from the hdr1 style attached to the parent table row. Likewise, the two bottom cells inherit styles from their parent table row.. The hdr1 and hdr2 styles are set locally in the class CSS style sheet as

tr.hdr1 {background: black;}
tr.hdr2 {background: #E7E5D6;}

Any of the table cells involved can also include values for the bgcolor attribute as a backup to the style declarations. The order of precedence for CSS capable browsers is to render style first over bgcolor attribute value.

Title name or graphic

Collection title name is provided in the templates via the <?BANNER> processing instruction. The PI will, in the case of an individual collection, resolve to a text string or a graphic file as specified in the colldb. In cross-collection made, the content is specified in the imageclass.cfg file. When rendered as text, titles are wrapped in H3 tags with CSS style topheadlink so that collection title font can be specified.

Navigation fonts and tabs

Navigation tabs in ImageClass are implemented as an imagemap with a series of graphics files. The tabs graphics files represent the entire tab set in a particular state, showing all the relevant tabs in their relative state, and all against a background color that matches that of the table row containing the imagemap. Thus, in the header layout shown above, the navigation tabs are contained within the table row class attribute set as class="hdr2" where hdr2 is defined as the background color #E7E5D6. The tab set uses an identical background color so that it blends in cleanly in the display ...

ImageClass Templates

The table bellow gives a brief description of all templates included in the Image Class distribution.

ImageClass Processing Instructions

The following table includes descriptions of all the processing instructions that appear in ImageClass templates, as well as links to descriptions of the relevant template files in which they appear.