Information Presentation. Moving down the hierarchy of Concepts, from the overall Sitemap, through Navigation (of Site Sections and SubSections), we now come to the Site Page, where the actual presentation of information to the site visitor takes place.
![[Note]](images/note.png) | Note |
|---|---|
In the next section, as we move further yet along the hierarchical descent to Modules (page fragments), we'll discuss how Presentation is actually (programmatically) managed and rendered at the Module-, not Page-, level, but for the purposes of the site visitor, presentation is experienced at the Page level. | |
Content Selection. Also found at the Page level is the editorial selection process of deciding "what goes on a Page," from a Content perspective. While arguably editorial decisions about Content are made at all levels of the site's hierarchy (the Site, the Site Section, the Page, the Module), it is at the Page level that the publication editor (site webmaster) is most concerned with the arrangement of potentially diverse components of information. Their selection and the overall page composition need to best match the intended audience's desires and expectations for information delivery, at that point in the site experience. (As just a very basic example of the thinking: Sometimes a briefer version of the content is more useful; at other points in the site the full text version of the information is what's sought, etc.)
An aid to the visitor experience that can be provided at the Page level is that there be a set of relatively consistent page "types" encountered throughout the site. In this way the visitor quickly becomes familiar with how to locate useful information on each page, and, in finding that this pattern is repeated, can save time and effort.
Page Types are often associated with certain "Levels" of the site, as we see in our Sitemap documentation, where the site has some five levels (0 - 4). Typically, the pages "across" one of these "horizontal" levels will share certain page design ideas (e.g. Level 1 pages have "Highlights"). The concept is simply that regardless of the content (e.g. the actual topic: "Research & Development" vs. "About Millennium"), the nature of the kinds of information you present at that Level in the site will share a certain consistency (e.g. "summary" info, or "cross-link related" info). And so, to support this information architecture requirement, the visual Page arrangement should be laid out to reflect these needs.
Examples of this "Page Typing" are seen in the "Page Visualizations" section of this documentation, in particular the "Representative Site Pages".
An interesting example of something of an exception to the rule is the "Representative Press Release Pages" set of page types. Visually, these vary only a little from the "Representative Site Pages" at a glance, but the end-user experience of encountering various presentations of the press release (summary version, brief listing version, full version), and of using a kind of "in-body navigation" (e.g. the "Year 2003" page), makes for a different experience in the Press Releases area of the site. Despite these differences, behind the scenes, we'll learn that the actual "bones" of these pages (the Page Layouts) are actually the same as for the Representative Site Pages. Interestingly, though, further behind the scenes we'll (further) learn that the Module processing for the Press Release pages differs a fair amount from that of the "regular" site pages—that's largely what makes for that "different" experience described above (various presentations; in-body navigation listing). And so, at three levels (at least): visual ("glance"), layout structure ("bones"), and module processing ("content"), we can consider factors that influence the determination of the need for new Page Types.
![[Tip]](images/tip.png) | Tip |
|---|---|
An additional "factor" that caused this project to require more Page Types was the realization (late in development) that on very short pages, the background image (a helix: /images/bg_image.jpg) (566px width, 345px height) was looking too large, and would be better suppressed. Now, to get this background image to the correct position (which crosses two divs), it was necessary to invoke it as part of the Page Layout, not from a Module placed into the Page Layout (like most every thing else on the page). So, to remove this "helix" bgimage based on the somewhat ad hoc requirement ("for the very short pages" (e.g. /careers/search/index.asp)), meant modification to the Page Layout. Creating a new variation was the best option, and so for this project we have a set of paired layouts (e.g. "Page Layout 5" (pl05.html) and "Page Layout 5 without BgImage" (pl05a.html)). The simple distinction is that pl05.html does contain the background image (by means of CSS class; HTML code snippet: "<div id="b_ma_co-re" class="bgImage">": CSS code snippet
.bgImage
{
background-image:url(/images/bg_image.jpg);
background-position:bottom left;
background-repeat:no-repeat;
}while the pl05a.html has only <div id="b_ma_co-re"> (no bgImage invocation). | |
The Page Layout is essentially the overall table structure that provides the page template. The table data cells (td) are established, nesting as necessary, to get down to the point in the structural hierarchy where content Modules are inserted. This is the point at which the Page Layout HTML stops (and the HTML of the Modules picks up). These "final" table data cells are referred to as "Module Zones"—page-level Zones that contain Modules.
In some cases, the Page Layout will be responsible for a visual effect (e.g. providing a narrow column for a "gutter"), but in most cases it is preferred to achieve such effects using CSS as applied to each Module that is positioned in that Layout zone. This approach can help reduce the number of distinct Page Layouts needed to support an entire website.
The relation of "Page Layouts" to Page Types is not necessarily 1:1. One Page Layout can accomodate more than one Page Type, though a single Page Type, pretty much by definition, ought to be using just one Page Layout.
Examples of the structural HTML tables for Page Layouts can be seen elsewhere in this documentation under "Page Visualizations: Page Layouts".
Page Layout "Zones" in Annotated Screenshots. The next dozen or so "figures" provide a walk-through of the nesting rectangles that constitute the set of building blocks for Page Layout '01'. The sample page selected is the "Research & Development" site section index page (/rd/index.asp).
Figure 3.18. Page Layout (01): Header, Body, Footer
The first in a series of Figures depicting the nesting "rectangles" (i.e. table cells (<td>s), and <div>s) that make up an overall Page Layout.
Shown with each rectangle is a text label showing an abbreviation of the name of the zone, or rectangle. As we'll see further along, each of these abbreviated names provides a single facet of information, which, when linked by underscores (_), combine to provide a hierarchical nomenclature descriptive of parts of the Page by location in the Page. As a simple example, " b_nt " is the ' B 'ody, ' N 'av ' T 'wo part of the page—it is the nested rectangle for 'Nav Two' ( nt ) inside the outer rectangle for 'Body' ( b ). ('Body' in turn is a rectangle inside the overall Page rectangle, but 'Page' does not form part of the established naming convention. Not needed—the fundamental page "triad" of 'h', 'b', and 'f' are significant enough.)
And so, in this screen capture (above) we see the initial breakdown of the page into three stacked divs, holding the Header, Body, and Footer.
Figure 3.19. Page Layout (01): Header: Site Header, Nav One
Here we have the first "breakout" from the overall page: the Header and inside it the two Module Zones that make it up: Site Header (h_sh), and Nav One (h_no). Each of these, being Module Zones, are "rectangles" inside of which you can place content Modules. (Contrast with the parent rectangle to these, "Header," which is not a Module Zone—it is not a low enough level of granularity, and houses other Zones, instead of Modules directly.)
Figure 3.20. Page Layout (01): Header: Site Header—Module Zone
Here we have the first actual "Module Zone" broken out on its own. The buildlist.xml assignment for this Zone is:
h_sh1_a = mlnm_site_header.html
Note that the naming convention includes two additional components:
an appended digit '1'
a final "underscore_letter": '_a'
The appearance of this appended digit is the signal in the naming convention that the Zone in question is being used to contain Modules directly: you have arrived at a "Module Zone" (as opposed to the higher level Zones, with no digit, that house only other Zones). To state it more explicitly: the naming convention uses letters only, until the use of this digit, which signifies that in this Zone, Modules can be directly placed.
The "underscore_letter" is used as the final token to indicate precisely which Position within the Zone a Module is to go. These simply stack up sequentially (_a, _b, _c etc.), and thereby follow the "flow" (straight down) of any given page zone. (So in fact to state it more precisely, the buildlist.xml assignment above (h_sh1_a = mlnm_site_header.html) is not to a Zone, but right to a Position within that Zone.)
As a brief digression from the review of page fragments making up our example ("Research & Development"—/rd/index.asp), a sample from another site page ("Recent Press Releases"—/media/news/index.asp) that has multiple Positions within one Module may be helpful to understanding the use of the "underscore_letter" naming for Positions.
Figure 3.21. Module Zone with Multiple Module Positions
Here we see simply that the Zone on the Page which holds Modules (b_ma_co1) in fact contains some three instances of stacked Modules, in Positions '_a', _b, and _c. (Our "Research & Development" example page has no such "multiple positions" zone.)
Figure 3.22. Page Layout (01): Header: Nav One—Module Zone
Here is the second broken out "Module Zone":
h_no1_a = Nav1_1rad_i.html
As above, note the addition of the appended digit 1 to signify this is a Module Zone, and the final _a for the Position: h_no1_a.
(Regarding the filename for this Navigation Module, see the discussion of naming conventions for Navigation, and please note that there the use of a digit 1 has a different significance.)
Figure 3.23. Page Layout (01): Body: Nav Two, "Matter"
Next, having (above) drilled down to the lowest level in the overall Header zone (to its component Module Zones), we now "bump back up" hierarchically to the overall Body zone. In this figure we see a basic breakout into two large Zones, the 'Nav Two' (which as we shall shortly see is in fact a "Module Zone"), and a second zone which gets called 'Matter,' as in what "matters" particularly to this page: its content, and its "related" information, as well as its page header.
| Tip |
|---|---|
This name 'Matter' may be less than perfect, but some label is needed to express a name for the location within the page for each zone, even when the contents of a particular zone could appear to consitute a somewhat contrived collection of pieces. We'll see this issue again shorly (below), with a Zone that doesn't really get a "name" but instead a concatenated list of abbreviations: 'Content + Related' = 'CO-RE'. In the end, all that's needed is a label that is sufficiently successful as a mnemonic. No harm done, using 'Matter,' 'CO-RE,' etc. | |
This may be the point at which to try to define the basic rules for identifying where zones are found. As can be seen, since zones nest, it can appear tricky to be certain about where one zone leaves off and another picks up. There can be more than one "right answer" to the way in which a page is broken down into zones, ultimately.
| Tip |
|---|---|
The basic rule for each of the three breakouts of zones and Module zones that we've seen in the figures above is this: In looking at any outer zone—a zone that contains zones (e.g., our whole Page, or after that, our Header, or the Body, or next, this 'Matter' zone)—the rule for any given breakout of zones inside is that all broken out zones will have rectangles with a side of equal length. What this means, simply, is that for any given rectangle (the outer zone we're discussing), the only permitted way to cut it up is with slices either all vertical or all horizontal, but slices all the way through the outer rectangle. In practical terms, this means you do can not create any direct breakouts of rectangles incorporated into any colspan (or rowspan) constructions. You must first breakout the entire rectangle that contains the colspan (or rowspan) and the spanned columns (or rows). | |
We see two examples of this on this page. First, the 'Body' has 'Nav Two' as a rowspan, with the 'Matter' rectangle containing two rows: the 'Page Header' row on top, with the 'Content + "Related"' ('CO-RE') row beneath. Then, the 'Matter' rectangle in turn has a colspan in 'Page Header,' with a single large rectangle beneath, 'Content + "Related"' ('CO-RE'), that in turn contains the two spanned columns: 'Content' and '"Related"'.
Both of these are broken down (as we shall see) according to the basic rules set out above.
Figure 3.24. Page Layout (01): Body: Nav Two—Module Zone
b_nt1_a = Nav2_1rad_i.html
This Zone houses Modules directly, at a fairly high hierarchical level, hence its brief page location name: b_nt1. The _a of course indicates that the single Module that goes in here appears in the first Position.
Figure 3.25. Page Layout (01): Body: "Matter": Page Header, "Content + Related"
Here, the breakout of the other Zone found within the overall 'Body' Zone, the 'Matter' Zone, is where we review in turn its component Zones: 'Page Header' and the "combination" Zone beneath that: 'Content + Related" (CO-RE)'.
| Note |
|---|---|
This Zone is an example of one that is not a Zone in which Modules are directly placed. | |
Again, as noted above in the "rules" for Zone breakout, the cut here is a slice (horizontal) across the whole width of the 'Matter' Zone.
Figure 3.26. Page Layout (01): Body: "Matter": Page Header—Module Zone
b_ma_ph1_a = pghdr_1rad_i.html
Again, the atomic breakout of a Module in its Zone. Like many Zones, this one holds but a single Module, in Position _a.
| Note |
|---|---|
Hypothetical Example: Like the 'Site Header' example discussion above, here we see another instance where plausibly one might divide this Zone into two (depending on various factors), yielding perhaps a Zone for the 'Page Header Name' (phn) and the 'Page Header Image' (phi). This would mean full Zone (and Position) naming conventions like: b_ma_ph_phn1_a and b_ma_ph_phi1_a. Then it follows that the ph Zone would then not get the 'digit 1' in its name. | |
Figure 3.27. Page Layout (01): Body: "Matter": "Content + Related": Content, "Related"
Here we are in the final Zone that holds other Zones. The combination of 'Content' and '"Related"' information doesn't lend itself to another invented label like 'Matter,' and being few in number (just two parts), the simple concatenation of abbreviations works well as label: "CO-RE". (With more than two, it can begin to get cumbersome: b_ph-co-re would have been required if b_ma wasn't instead invented.)
About this figure, observations of interest might include:
Module Granularity. Dependent upon a few factors (semantic values of the content; authoring requirements, management requirements; etc.), the stack of paragraphs in Modules like this one might be divided up into smaller Modules, instead of a single monolithic "CT01" ("general") Module.
Sourcing Inline Images. Implementation of the graphical "callout" ("Providing the right drugs...") as seen in this Module (and throughout the site) is achieved simply by an inline <img src=""> reference in the Module's HTML.
.
This single figure contains all the colored rectangles shown above, depicting Zones of both types: those that contain only other Zones, and those that contain Modules directly. The "Module Zones" have their full naming convention labels annotated as well.
Below the graphic is the text listing of all assignments of Modules to particular Positions in Zones (effectively the same information the buildlist.xml <page> entry contains).
Here are all seven "Module Zone" assignments (as seen above), assembled in one place, as they are in the buildlist.xml entry for the page.
h_sh1_a = mlnm_site_header.html
h_no1_a = Nav1_1rad_i.html
b_nt1_a = Nav2_1rad_i.html
b_ma_ph1_a = pghdr_1rad_i.html
b_ma_co-re_co1_a = ct01_rd-index.html
b_ma_co-re_re1_a = ct70_highlight_1rad_i.html
f1_a = mlnm_site_footer.html
SiteHTML/PgLayouts/pl*.html
devmachine (~/mlnmdev/SiteHTML/PgLayouts) > ls -l pl*.html pl01.html pl01a.html pl02.html pl03.html pl04.html pl05.html pl05a.html pl06.html pl06a.html pl07.html pl07a.html pl08a.html devmachine (~/mlnmdev/SiteHTML/PgLayouts) >