Archive 1.x:Overview of Layouts and Design

Within the Open Semantic Framework, the term "layout" refers to a dedicated page display that has a fixed format and a fixed set of display widgets. Generally, layouts are associated with a Drupal content type, via which it is possible to enter specific parameter values for each page in order to "drive" (populate with data) its display.

This article overviews the purpose and use of layouts, as well as how to design and incorporate them into a given OSF (Drupal) installation. Should terminology get confusing, please refer to the Presentation Glossary. Also, please see A Zoology of Templates for an explanation of where layouts fit into the overall templating picture within an OSF stack.

Purposes and Uses of Layouts
Layouts are the preferred option when there are entire site branches or repeated sections for which display is desired to be fixed, but for which the actual data driving the display(s) may need to constantly vary. A common design approach is to have sub-menu links actually drive the queries that cause the data display to vary (say, by region, locale or topic, as set in the sub-menu).

Actually, any action that generates a query -- that is, an HTTP request (either Get or Post) -- may be sufficient to "drive" a layout display. Thus, layouts may be driven by menu-item links, standard Web links, uses of HTML forms such as dropdown lists or checkboxes, etc.

This action is because of the nature of a "layout" as defined in an OSF instance. An OSF layout combines:


 * 1) A more-or-less standard template page (as is shown for a   template page in Drupal); this is what sets the layout design and presentation framework
 * 2) One of more OSF-based OSF-Drupal tools or semantic component widgets, which themselves display data arising from
 * 3) A SPARQL query to the OSF Web Service Web services framework, which generates the actual data results set to be displayed.

The overall information flow of the process guiding a layout is shown by the animated figure in the Introduction to Semantic Components article.

Because of their highly repeated (duplicated) nature, layouts tend to be one of the more predominant displays types across an OSF installation.

Basic Layout Design and Specification
The premise of a repeated display framework that can be duplicated across multiple pages is the starting point for designing and specifying an OSF layout. The key to the premise is that there is some dimension of information -- be it geography, year, subject or other dimension characterizing one of more datasets -- that is useful to vary in order to show various views of the information contextually. It is also useful to have a good idea of how that information should be displayed and with what kind of widget. For example, numeric data might lend itself to charting; locational data to mapping; pictorial data to an image gallery; conceptual data in terms of relationships; and so forth.

Thus, before any coding or template designing or layout presentation is decided, it is necessary to think through what is the purpose of the layout, how it will be embedded into the existing OSF instance, and what other aids and Web page designs would be useful to the viewer and user of the data.

Some of the major kinds of choices that need to be made are shown by number in this example below. In this particular example, we are wanting to add information about "economic development" to a city-oriented portal:



Here are the various choices that need to be made, with some explanation keyed to each:


 * 1) Where do we want this layout to appear with respect to the overall structure of our portal site? In this case, we want it to appear on a main menu, so we first need to expand our menu structure and theme it appropriately (the case shown color-codes the various main menu options)
 * 2) What is the dimensional structure of our data that we wish to highlight? In this case, we are using sub-menu options to drive the various queries that highlight this structure (as noted, such queries could also result from links or HTML form actions). Some desirable menu options, however, may not adhere to this structure, which also needs to be determined. This step is one of the most critical, since it sets the context basis by which the structural dimensionality of the underlying data can be highlighted for display in the layout(s)
 * 3) Similarly, perhaps there are multiple actions that might be applied to these various dimensions. We may want to map some information, browse some information, and so forth, all in context to the same basic query driving the layout display. In this example, we actually have a layout page that references further layouts, all accessed via the contextual buttons at the top of the display
 * 4) We also may want to embellish the specific layout pages with other surrounding information. In this case, we are highlighting the addiiton of a so-called Drupal "block", but other embellishments could be footers, headers, etc. These embellishments are largely developed using standard Drupal options and modules
 * 5) For this option and
 * 6) This next one we then need to design the final layout displays. These displays (see next major section) are what actually get populated when we pick one of the multiple actions noted in Step #3 (if there are no multiple actions in Step 3, then the menu choice in Step #2 goes directly to the single layout).

Note that Steps #1, #2 and #4 are independent of any particular layout coding requirements (see next major section). These steps may be undertaken directly with Drupal and separately from actual layout coding.

Drupal Content Types (CCK) and Layouts
A layout has two major implementers: a site content administrator, who enters fields into a specific Drupal page type (content type) for configuring a specific display of a layout; and a developer, who actually creates the Drupal template file  for the particular layout.

Thus, in the design phase, prior (or, actually, in conjunction with) the actual layout page template coding, it is necessary to set up a new, corresponding content type (via the CCK, or Content Construction Kit module) within Drupal and to define its fields. That process and its rational are described in the Setting Up Content Types for Layouts document.

Coding the Layout
Layouts may be created either with the Smarty templating engine or directly in PHP + HTML coding. Layouts tend to block the display page into fixed display regions, in which a particular widget or record template may be displayed (and rendered).


 * Anatomy of a Page Template File

NOTE: additional documentation on layout coding in PHP is forthcoming.

Examples and References
Currently, here is the documentation on the set up and configuration of some of the more notable examples of layouts:


 * Configuration: Charts Layout
 * Configuration: Images Layout
 * Configuration: Stories Layout
 * Configuration: Topics Layout
 * Configuration: WebMaps Layout
 * Configuration: Multi-WebMaps Layout

Example Layout Templates
We also see here the actual code examples that drive the display aspects associated with these various layouts:


 * Sample Neighborhood Template

(This example is more oriented to a Smarty display framework; the next options are more related to embedded semantic components:


 * Sample Chart Template
 * Sample Image Template
 * Sample Topic Template
 * Sample WebMap Template
 * Sample Multi-WebMap Template.

Adding Contextual Help to a Layout
Because of its unique presentation and possible inclusion of specialty widgets, it is often helpful to add specific contextual help to a given layout. There are many ways to do so in Drupal. The method we follow is captured by the document, Adding Help to a Layout.

Theming and Testing the Layout
NOTE: additional documentation on theming and testing the layout is forthcoming.