Back Intermediate Pagemasters Home CommonSpot Tutorials Home Next
There are two methods for creating new pages in CommonSpot:
As you can see from the table of contents, above, we will discuss the creation of pages from scratch, then the creation of your own derived templates, and then the use of a blank page to create a new page by copying an existing page.
A template is the starting point for constructing a page in CommonSpot. Using templates provides a way to more easily build a site with consistent page design, and to maintain that consistency over time. The system provides a choice of templates, and you can also create your own templates, by starting with one of the system templates and adding page elements.
The CommonSpot software design works with two kinds of templates: "base templates," and "derived templates." Base templates are hand-coded by programming staff. Derived templates are layered on base templates or other derived templates, and use CommonSpot page elements and other features to add content.
A useful mental model for templates is a multi-layer overhead transparency: you start with a base layer, then add more and more items on top of it. What you and your audience see at any time is all the layers together. The figure below illustrates the relationship between base templates, derived templates, and pages built on them:
The illustration above is simplified by having only one derived template in the stack. You are likely to find it useful to have multiple derived templates, one built upon another, as the starting point for many of your pages.
At Ohio University, we are configuring CommonSpot with several different templates that are available for use by pagemasters and content contributors. The templates that are presented to you as available choices when creating a new page may include templates whose use is required, permitted, or forbidden, for that particular page. It is the pagemaster's and content contributor's responsibility to choose an appropriate template.
All official Ohio University Web pages, on any server, are required to meet specific design guidelines (including the placement of the new logo graphic mark in the upper left corner and the copyright statement at the bottom), regardless of the server they are published on. Templates are available in CommonSpot that facilitate meeting those guidelines, for use by pagemasters and content contributors building official sites. Those templates must not be used for unofficial sites.
All unofficial Web pages (student organizations, personal pages, etc.), on any server, are forbidden to use official Ohio University graphic logos (any variation of the Cutler Hall woodcut, the Intercollegiate Athletics "Attack Cat" logo, the University Seal, etc.), and must not say that they are copyright by Ohio University. Separate templates are available in CommonSpot that facilitate meeting those guidelines, for use by pagemasters and content contributors building unofficial sites. Those templates must not be used for official sites.
The "official_pages1" template is coded initially to facilitate the building of sites that are closely modeled on the Front Door design. As soon as the formal university policy on Web page design is finalized, additional render options or templates will be created as needed and made available through CommonSpot, in order to provide the full range of flexibility to CommonSpot users that is permitted under that policy to users of other servers.
The base template for use on unofficial sites includes a render option to display a link to the Front Door. Such a link is required for use on unofficial subsite home pages, and is permitted, but not required, for use on all other unofficial pages.
Because some people will be responsible for both official and unofficial subsites, you may have access to templates that must not be used for a particular page. Similarly, templates may be created and made available to you that are coded such that it is possible to change a page from official form to unofficial form by changing "render options" (discussed below). These technical possibilities do not mean that those choices are permitted.
The system programmers can revise the base template your page is built on, or you can edit a derived template, as discussed below, changing the CommonSpot elements on that particular template. In either case, the updates made to any template are reflected immediately in the display of all the pages built on top of that template, without losing the specific work on any of the pages built on that template (provided that inheritance has been preserved).
What should you do if you realize that you want to have a page that is already under construction or in production be built on a different template than the one you chose when you first created it? The following sequence of steps will be required:
As you can see, you will not lose all your work done on the template you chose first, but the process of switching a page from one template to another is labor-intensive; CommonSpot rewards those who plan ahead carefully and select their templates thoughtfully.
. In class, and while first developing a subsite through author.admsrv.ohio.edu, activate it right away. Once a subsite is in production through www.ohio.edu, you will most often choose to activate the page only when it is fully ready for public viewing.
If you later need to "de-activate" an active page, use the document information tool.
Setting a width other than 100% for this table can result in different effects on different browsers, so we advise that you leave the width choice at "100%."
You can modify the choices you have made here later on in several ways that we will discuss.
, 
, or 
.
Although the page has been created, that is, it now exists, your work is only just begun! Be sure to promptly check, and if necessary change, the render options settings, as discussed in the next section, and the page background color, as discussed in the following section.
Depending on the template you have chosen, the page may have options that you can adjust.
Near the middle of the resulting Standard Metadata dialog box you will see the "Publication Date" section, which can be used to control the date and time when the page will become accessible (e.g., to embargo a press release).
In class, select the "Sitewide Navigation Bar" option (which will force the page to exceed the width achievable by many printers in portrait mode), the "Printer-Friendly Page Option," (which will make it easier for your users), and the "Remove Footer Text" option, which we will take advantage of in the next section.
Details of using the "printer-friendly version" are discussed later.
Observe that changes of render options take effect immediately, and are not recorded in the Version History. They can only be "un-done" by being re-done.
The "Remove Footer Text" render option removes the standard text from the left side of the footer bar and lets you put custom footer text in its place. This option is likely to be used with templates to provide a departmental address, phone number, and e-mail link, instead of the generic information built into the base template.
Depending on the template you have chosen, the page may be generated with no explicit body background color. Because different browsers have different default background colors (usually either white or gray), you should be sure that the page is generated with an explicit background color of your choice, so that your page will appear as intended for all viewers. When in doubt, use white, as shown below, for maximum contrast with dark text, to be most easily read.
You could also choose to specify a background image, instead of a backgound color. If you do, be sure to choose an image that will "tile" gracefully whenever the browser is using a window bigger than the image.
Derived templates make it easier for you to create and to revise a set of pages with common features. Likely candidates for elements to include in your derived templates are header graphics (just below the standard header and sitewide navigation bar), subsite or sub-subsite navigational links, contact information, and E-mail links, located, for example, either in the custom footer text or at the bottom of the page content area, just above the footer. We anticipate that most subsite pagemasters will choose to create several derived templates, for use with various categories of pages: sub-subsite home pages, other navigational pages, content pages, etc.
Any time you can identify a group of pages that share identical content, that situation presents a strong possibility for the creation and use of a template. It is rarely sensible to have a template on which only one page will be built.
As you build and work with your own derived templates, it is essential that you keep clear in your mind the distinctions between templates, blank pages, and mock-ups, as discussed earlier. As part of your design process, you may well have created a CommonSpot page that is a mock-up of your planned template design. If you have built a mock-up page, do not just save that mock-up page as a template. Instead, build your new derived template by starting from scratch or by copying a blank page, and then, for each element in the mock-up that will be identical in every page to be built on the new template, copy and paste one whole element at a time from the mock-up page into the new page. Be sure to insert content-free, undefined tabular layout elements as placeholders at each location where page-specific content will be included in the pages built on the new template.
Ordinarily, derived templates are available only to the person who saved them as a template. System administrators can permit derived templates to be accessible to other users. Therefore, if you are going to be working as part of a team, please send an e-mail to webteam@ohio.edu to let us know when your template is ready, so that we can confirm that it is properly locked-down, and provide access to your whole team to use it for creating new pages.
It is possible (but not always wise!) to turn any page into a derived template; this includes starting with a blank page, built on any existing template, and adding items, or starting with an existing page and removing or editing items. When you create a new derived template, you may find that you already have a page that includes some, many, or all of the elements that should be part of the new template. In that case there are several approaches you can take to using this starting page:
All the elements that were in the starting page survive as parts of the new derived template (e.g., in the illustration above, the irregular blob in the upper left corner). Thus, you have the same situation as if you had created a brand new page on the new template: when you look at the new page, all of the elements from any of the template layers are present, but there are no elements in the page layer itself, yet. If some of the elements that are in the new template layer should be specific to one page, not being part of the template (which would make those elements part of every page built on the template), they can be copied from the template, pasted into the page they belong in, and then deleted from the template. This should be done immediately, and then the template should be locked-down, to avoid problems with broken inheritance.
In general, you would first decide whether you will be starting from scratch, as we are in class, or using one of the three approaches outlined above:
Your template is in place, and CommonSpot will let you use it, but if you use it as-is, it will be easy to inadvertently break the inheritance from this template to the derived templates and pages built on it. That can result in the irretrievable loss of page content. The following sections describe this problem in more detail, and show the methods for preventing it.
Decisions you make about how to design your templates and pages can have significant impact on system performance in "Edit," "Author," and "Read" modes.
In "Author" mode, each CommonSpot element will have at least one and usually two tool icons (the "element properties" 
and "edit content" 
tools). Each tool icon has a menu; at least one un-cached database query by the CommonSpot server to its backend database machine is required in order to build each menu. Therefore, designing the template or page so as to minimize the number of CommonSpot tool icons will improve performance going into "Author" and "Edit" modes:
(for the whole table), plus a cell properties icon 
for each cell of the table, plus the tool icons for each element in each cell. When possible, use row or column spanning (controlled through the cell properties menu), rather than tables-within-tables. This simplification will improve not only "Edit" and "Author" modes but also "Read" mode performance, because the HTML is more compact, and because the browser will be able to parse that HTML more rapidly.
As a general rule, design choices for templates are especially significant in terms of reading and authoring performance, because multiple pages are likely to be built on each template. A modest change in system load per view for a template will be multiplied by however many pages are built on that template.
When a page is first built on a derived template, it is created with copies of every element in that derived template, and at that time any update to the template (either changing any of those existing elements, or adding a new element) will be promptly propagated to the new page built on that template. This is referred to as "inheriting" the changes. Some revisions to a page can break the inheritance, so that updates to the underlying template will no longer be propagated to that page.
The current version of CommonSpot provides no warning dialog when a page or template revision will break inheritance from an underlying template.
Fortunately, while in "Author" or "Edit" mode on a template, it is possible to "lock down" the template (using "element inheritance security") so as to prevent such inheritance-breaking, but that will also prevent some kinds of revisions to the pages and to derived templates built on the template. Designing templates so that inheritance is properly preserved, while still permitting customized content on each page, requires careful consideration of the pages that will be built on the template, and the nature of the customizations anticipated. This is yet another aspect of CommonSpot where planning ahead will truly reduce your long-term effort.
While designing each template, identify places on the screen where different pages built on this template should be free to have different content. In those locations, create a tabular layout, but do not define it in the template, leave it as "click here to define the layout." You can perform this step before or after saving the page as a template, but must do so before building any pages on the new template. Later, while first editing the page built on the template, the content contributor will click there, define the layout with as many rows and columns as desired, and place elements in them to build the page-specific content. It is vital that once used on a page or derived template, this undefined tabular layout element never be deleted from the template, nor be clicked on and defined in the template, as that would risk destroying all the page-specific content; see the discussion in the next section. If you have a situation where you will have several layers of derived templates, please consult the Web Team (by e-mail to webteam@ohio.edu) before proceeding, because deeply nested tables-within-tables-within-tables will slow down the display of your pages. Often it will be easy to place all of the undefined tabular layouts in the first template, using them up one at a time as you build successive derived templates, and finally the pages.
If, at any time during the steps listed below for locking down elements or layouts, you are warned that some content may be lost, take that warning seriously, and cancel the operation: the warning will be displayed when one or more pages or derived templates built on this template already has broken inheritance for the item in question, and, if you proceed, the changed content on those pages will be lost, irretrievably, forcing you to re-create it. Copying the pages in question will not preserve the content, because those copies will also be derived from this template and will have broken inheritance for those elements, too.
If you encounter such a case of broken inheritance, the safest course of action is to build a new template, properly locked-down, as described here, and then build new versions of the derived templates and pages that are based on it. See the last paragraph before the step-by-step section on template-based page creation. As discussed in that paragraph, you will be able to save some time by copying and pasting elements from the existing templates and pages.
Those elements whose content should be the same on all pages built on the template should be "locked-down" so that changes can occur only while editing the template itself, never while editing a page or derived template (which would break inheritance). There are three stages: locking-down elements, layouts, and pop-up menus. The steps itemized below can be performed only after you have saved the page as a template:
, which is located to the left, just above the element.
, nor the "Edit Content" icon, . The pagemaster or content contributor is therefore not able to edit or change the
element while in the page or derived template, preserving inheritance.
In order to be able to add an element to the template in the future, and have it be inherited by all templates and pages derived from that template, the "Click to insert new element" that you use must not have been previously used to add an element to any of the derived templates or pages. In other words, the act of inserting a new element breaks inheritance for that whole cell. In order to prevent such "hijacking" of the "Click to insert new element" at the page or derived template level, all of the tabular layouts in the template should be locked-down also, so that the "Click to insert new element" is not displayed while in "Author" mode on the derived page or template:
, that appears on the top left corner of the table that includes the element that should be revised only from within the template. In general, you will need to do this for every layout element except for those that are undefined in order to contain page-specific content. In class, you will choose the layout for the page as a whole, using the icon that is immediately under the logo graphic in the header at the top-left corner of the page.
that you have identified.
If your template has pop-up menus defined, they can be used (by creating a hyperlink to them) either in the template or in any derived template or page built on that template. Unless the pop-up menus are locked down in the template, however, they can be revised in the derived templates and pages, thereby breaking inheritance.
Locking down pop-ups involves multiple stages: locking down each specific pop-up menu, and possibly also locking down the Page-level Menu Properties (see the paragraph after the list of steps):
for each specific pop-up menu, and possibly for the Page-level Menu Properties.
, nor the Edit Content icon, are presented for any of the locked-down menus. The pagemaster or content contributor is therefore not able to edit or change those pop-up menus while in the page or derived template, preserving inheritance.
If you lock the page-level menu properties, you will not be able to create any new pop-up menus in the derived templates and pages built on this template. If you decide not to lock down the page-level menu properties, then you will be able to create such menus, but you will also be able to break inheritance for any of the page-level menu properties (such as font face and size), so that future updates to those properties will not be propagated to the derived template or page. Therefore, be sure to immediately check, and if necessary set, the page-level menu properties' font and size, as described in steps 10 and 11 of the pop-up menu discussion.
When you edit a derived template and publish the changes, all pages built on that template are updated accordingly (they "inherit" the changes, providing that inheritance has not been broken). However, if one of your changes is to delete an element that was on the template, you will be confronted at the time that you make the deletion, before you use the yellow work-in-progress icon to submit the change for publication, with a dialog box asking whether you want to:
If you choose the former (which is the default with the current version of CommonSpot), then every instance of that element will be removed, irretrievably. If the element in question was identical everywhere, having been inherited from the template and not modified, then it can be replaced with a single update to the template. If the element in question had been modified differently on various pages, then each of those separate versions would have to be re-created, one at a time. This risk that you or a future pagemaster might accidentally destroy multiple content items is a strong motivation to design your template carefully and to keep it locked-down.
If you choose the latter, then those "orphaned" elements on each page will each have to be individually modified for any future updates, because there is no element in the template for them to inherit changes from, and the act of revising the element may break inheritance for the layout element containing it.
Warning
There are circumstances (involving already-broken inheritance) where even though the "delete from template only" choice is selected, the elements are in fact deleted irretrievably from the derived templates and pages built on the template being revised. It is wise to approach with caution any element deletion from a template. Be sure that you have the resources available to re-construct any content (on that template and any derived template or page built on it) that may be unexpectedly destroyed.
Therefore, we urge you to design your templates with complete elements and with phantom "Click here to define the layout" placeholder items, but do not build your templates with any other elements that are phantom "click to define..." or that are intended to be modified on individual pages. In other words, what belongs in the template are the things that will be the same on all pages built on that template. For example, the boilerplate should not be in the template, because its content is page-specific. You can reduce work by copying the boilerplate element from another page and pasting it into your new page, then revise it to show the correct URL and date. You may also choose to create your page by copying a secondary blank page that includes the boilerplate element, ready to be revised.
As soon as you have completed each template, you should create a new page based on that template and activate it without modifying it in any way. This primary blank page will be available to copy (using the methods discussed in the next section) for others working on your subsite to build pages on the new template, even though they may not have access to that template through their template gallery. We suggest that you choose a name for this primary blank page that is "-blank" appended to the name of the template, or "blank" substituted for "template" in the name of the template.
The first use of the primary blank page is to inspect it while in "Author" mode. There should be the standard three CommonSpot tool icons at the top center, and one Layout Properties tool icon for each placeholder, undefined table that is intended for page-specific content, and no other tool icons, at all. If there are any other tool icons, take note of them, return to "Read" mode, navigate to the template, go to "Author" mode, and complete the element inheritance security settings to fully lock down the template, as described above.
If you have a group of pages that will share page elements of the same kind but different contents, you may want to make a secondary blank page, built on the appropriate template, and with additional page elements added. Once that is done, you can copy that secondary blank page (as described in the next section) to start construction of each of the pages in the group. Some examples:
There are two variations: if the template appears in your Template Gallery, or if it does not appear there. The first case is simpler:
In the second case, you should contact the Web Team by e-mail to webteam@ohio.edu, so that we can sort the problem out for you. In the meantime, there are two work-arounds: you may be able to identify someone whose template gallery does include that template, and persuade them to follow the above steps, and then to change ownership of that new primary blank page to you. After that you can find it in your "My pages..." listing, go to it, and copy it to start each page you need to build on that template.
If that is not possible, however, you can still create your own blank page, but the process is a bit more complicated:
, that does not have a phanton link, "Click here to define layout," and choose "Restore Inherited Content/Properties."
Once you have created the blank page, you can use it as follows:
for the boilerplate element just above the footer.
This method of creating a new page is particularly attractive if there is a page with nearly the same content already on the server, or if the person doing the work does not have access to the appropriate template, but does have access to a blank page that was built on that template.
Warning
From July 19, 2005, through November 16, 2005, the version of CommonSpot that we were using was afflicted with a subtle bug that sometimes corrupted pages made by copying, as described here. Use the Document Information dialog, discussed in the next section, to learn whether the page you are starting from was created during that time period. If it was, please do not copy it. Instead, create a new page on the appropriate template, and copy and paste elements as needed to provide your new page with the correct content.
The same menu choice is also used to move a page, that is, to change the subsite or sub-subsite that it is located within. If instead, you want to change the name of a page, without creating a new page, use the Rename Page... choice.
This is an efficient tool that allows you to quickly find and view any of your pages, templates, and binary documents; it is especially useful when you are the owner of multiple pages within one or more subsites.
This tool will let you quickly find and view any page in a particular subsite or sub-subsite, including both your own and other pagemasters' or content contributors' pages.
When you are in "Read," "Edit," or "Author" mode, the Page and Template Managment menu includes the choice "Template Hierarchy...", which brings up a large dialog window that
You can navigate to any listed template or page by clicking on the appropriate linked text. By taking this menu choice in a sequence of pages and templates, you can navigate to any page related to the one you started with.
Copyright © 2006 Ohio University. All Rights Reserved.
Dick Piccard revised this file (http://www.ohio.edu/pagemasters/commonspot/pageint/newpages.html) on April 7, 2009.
Please E-Mail comments or suggestions to "webteam@ohio.edu".