These materials were prepared when we were regularly teaching people to use CommonSpot by conducting small-group seminars. Although those small-group seminars are not now being conducted, these reference materials are still of some value, and so have been maintained online.
The two-part seminars, "Intermediate CommonSpot Pagemasters" and "CommonSpot Content Contributors" are presented as a combination of lecture, demonstration, and hands-on learning. We intend to teach pagemasters and content contributors what they need to know in order to migrate an existing site into the CommonSpot environment; to build a new site in CommonSpot; or to maintain an existing site in CommonSpot.
The entire first session is prerequisite for the second session.
The intended audience for "Intermediate CommonSpot Pagemasters" includes two groups of people:
those who are already maintaining a Web site in some other server environment; and
those who have studied the New Pagemasters material, linked from the Full Contents in the secondary navigation block to the left.
As such, this seminar does not include extended discussions of the trade-offs involved in page and site design, nor extended discussions of the range of information gathering and work approval processes that may be appropriate for new or radically re-designed sites.
The "CommonSpot Content Contributors" seminar has no pre-requisites. We assume that content contributors will be working under the oversight of their subsite's pagemaster, who will be responsible for the basic design trade-off decisions.
These seminars will not cover everything there is to know about using CommonSpot. What we do aim to do is to bring you up to a reasonable level of comfort with the essentials, and to expose you to a wide enough range of CommonSpot features that you can develop a useful level of intuition as to how the authors of this software approach the whole Web site content management business. That will serve as a foundation for your own exploration, which will be aided by these on-line tutorials.
The sequence of exercises presented here is not the best sequence for the activities involved in building a new subsite, or in migrating an existing subsite into CommonSpot. Planning and template design should precede page creation, as discussed below.
For many people, we believe that one or more of the following areas will prove to be significant advantages of CommonSpot:
Pagemasters can delegate responsibility for specific pages or page elements to one or more content contributors.
Pagemasters and content contributors can create pages and update content without directly confronting the HTML.
CommonSpot includes workflow features to address situations where multiple people should approve any changes before they are public. The approval process will be documented as part of the Advanced Pagemasters materials.
CommonSpot pages are built on templates. Templates make it easier to build and update a site with consistent page design while avoiding repetitious work when creating multiple pages that share design features. When revising those shared features at a later date, a change in a template immediately propagates to all pages built upon it.
Pagemasters can create their own templates, by adding page elements either to one of the system base templates or to a derived template built upon a base template by themselves or others.
The current version of CommonSpot is designed to create pages that can be viewed with a wide range of modern graphical browsers, on Windows, Macintosh, and other platforms. Viewing the sites with text-based or older graphical browsers is likely to have some problems.
Site creation and updating require the use of Microsoft Internet Explorer, version 7 or later, on Windows, or Firefox, version 3 or later, on Windows, Linux, or Macintosh, but in all cases, with cookies and scripting enabled (this includes de-activating any pop-up-window blockers). To reduce the risk of compromising your personal computer's security that would result from having cookies and scripting generally enabled in order to work with CommonSpot, we suggest that you follow the separate instructions for configuring Internet Explorer, or for configuring Firefox. If you have a pop-up blocker that can be configured to trust certain servers, then the list of servers that the pop-up blocker must trust is the same as that given for IE or Firefox to trust in the above-linked pages.
Authoring with Firefox is a comparatively new feature of CommonSpot, so you may find that a few things do not work as expected. Please let us know if you encounter any such problems, so that we can bring them to the attention of PaperThin's developers.
The current version of the Rich Text Editor is not able to preserve some common HTML constructs, even if you enter them correctly by hand in the HTML view. For example:
A "Definition List" structure (involving the tags, <DL>, <DT>, <DD>, and </DL>) will not survive the Rich Text Editor if the <DT> parts have header tags (e.g., <DT><H2>text</H2>).
A <UL> ... </UL> structure, used without <LI> tags for the list items, in order to create an indented section, will be transformed into MARGIN commands that only some graphical browsers will honor.
CommonSpot cannot be used to create pages using HTML <FRAME> tags. Because it is impossible to refer someone to a particular resource in a framed environment, except by providing the frame home page, and then a sequence of clicks to bring up the particular information, this is no great loss. Most of the advantages of frames (e.g., having one file to update for a uniform set of navigational links) are achieved in CommonSpot by using templates.
There is a maximum size of about 3 MBytes for uploaded files, including graphic images and binary documents such as Word's ".doc" and Acrobat's ".pdf" files.
Since the introduction of CommonSpot in mid-July, 2003, the Ohio University Front Door has been a combination of a "Static-Page" server (using the raw HTML and graphics files model of site preparation) and a CommonSpot server (using a content management system model of site preparation). With some exceptions, the pages, images, and documents in each subsite or sub-subsite are served from the same server. There are a number of subsites that have some sub-subsites served by the Static-Page Front Door server and also some sub-subsites served by the CommonSpot Front Door server.
As illustrated below, the Ohio University home page and the Bicentennial subsite are served from the CommonSpot Front Door server ("www.ohio.edu"), while the Policy and Athens subsites are served from the Static-Page Front Door server. When a browser asks for any of these pages from www.ohio.edu, the load balancer gets the files from the appropriate server, whether the CommonSpot Read-Only Public Server ("ROPS") or the Static-Page Front Door Server.
Any attempt to get a page from the old, now-retired, VMS Front Door server ("www.ohiou.edu") results in an HTTP protocol "redirect," telling the browser to ask for that page from www.ohio.edu, instead.
The Static-Page Front Door server continues to serve many subsites, including (at the time the graphic was drawn) the Policy and Procedure Manual and the Athens Campus Map and Tour.
The authoring server, "author.oit.ohio.edu," is a separate server from the ("read-only") public server, "www.ohio.edu," as shown above. The pages viewed from the two CommonSpot servers will be identical, because both the authoring and the public server use the same "back-end" database; the only difference will be that redirection happens for the public server, but not for the authoring server.
You build the new subsite in CommonSpot by accessing the pages with URLs that look like:
When your subsite is ready to go live in CommonSpot, please contact OIT by E-mail to firstname.lastname@example.org or by phone to 593-1222, to let us know that you are ready for us to re-configure the load balancer to stop serving your pages from the old server.
Once your subsite is live, make a final test run through the pages (looking particularly to confirm that all links among your pages stay on "www.ohio.edu" and that none go to "author.oit.ohio.edu"), and then tell your new URL to those responsible for pages from which your subsite should be linked (or from which a prior version is already linked). In the case of a previously existing site that has been migrated into CommonSpot, there are other issues, discussed below, that need to be addressed from the planning stage onward.
Once you are live and in production as http://www.ohio.edu/subsite/, you will continue to access your subsite for revision using the "author.oit.ohio.edu" URL. Once you are satisfied with a new page, or with a change to an existing page, you will instruct CommonSpot to "publish" that update, and it will be visible from both domain names.
As discussed below, it is also possible to bring your subsite into production one sub-subsite at a time.
Many terms will be introduced as they are used, but there are a few that should be presented right away (some of which we have already been using). We will try to be consistent throughout this seminar in using these words as described here:
site refers to the entire collection of pages found on a single server; for example, the older, VMS Front Door site is all those pages whose URLs start with "http://www.ohiou.edu/" and the new, CommonSpot Front Door site is all those pages whose URLs start with "http://www.ohio.edu/".
subsite refers to all those pages that share a first-level URL within a site; for example, the first subsite to be published from the CommonSpot server was the bicentennial subsite, all of the pages whose URLs start with "http://www.ohio.edu/bicentennial/".
sub-subsite refers to a group of pages within a subsite whose URLs all match through at least one more "extra" slash (a sub-subsite is achieved on most servers by placing those files into their own folder or subdirectory); for example,
are both part of the "webservices" sub-subsite of the "oit" subsite. Subsite pagemasters are responsible for creating sub-subsites. Some CommonSpot screens refer to sub-subsites as "child subsites."
page element refers to an item within a page that has its own access controls, identifying the people and groups who are allowed to create, read, revise, or remove that item. This may be a single graphic image, a paragraph, or the entire main section of a page. Page elements can be shared among more than one page, with updates done once and being reflected immediately on all pages where the shared element appears.
content contributors are people who are responsible for one or more parts of a subsite. Their responsibility may extend to one or more entire pages, or may be restricted to a single page element that appears on one page.
subsite pagemasters are people who are responsible, as individuals or as a group, for an entire subsite. Often the "subsite" prefix will be left off, and "pagemaster" by itself will be used with this meaning. Some of the CommonSpot screens and documentation use the phrase "subsite administrator" with this meaning. Subsite pagemasters can do everything that a content contributor can do, and more besides. In addition to creating sub-subsites, subsite pagemasters are also responsible for controlling membership in the groups of users who are pagemasters or content contributors for their subsite.
templates are the starting point for constructing pages in CommonSpot. The two types of templates are "base templates" (which are hand-coded by programming staff) and "derived templates" (which any CommonSpot subsite pagemaster or content contributor can create by adding elements to an existing base template or derived template). Unlike some other Web publishing tools, CommonSpot templates include only items that will be identical on all pages derived from that template; they also include content-free placeholders where page-specific content will be built.
render options refers to one of CommonSpot's mechanisms for choosing among the standardized design variations that have been explicitly coded into a base template. For example, the "official_pages0" base template (on which the "official_pages1" derived template is built) is coded to permit the page author to choose (by the render options mechanism) whether or not to display the "Sitewide Navigation Bar" immediately below the header.
blank page refers to a page that is used to create other pages by copying the blank page and then changing one or more of the elements in the copy. "Primary blank pages" are built on templates, with no changes. Primary blank pages are useful for confirming that a template is properly locked-down, and sometimes also when multiple authors will be building new pages on the same template. "Secondary blank pages" are built on templates, and then modified by adding elements that will need to be further modified for use on each of the pages that will be built by copying the secondary blank page. Secondary blank pages are useful when multiple pages have similar but not identical content.
mock-up refers to a "page" that is used during the design process to help visualize the proposed appearance of one or more pages. As such, a mock-up will include more or less complete "example" content. That content may be created by building a page with the usual mixture of text and graphic elements, or the entire mock-up could be created as a giant graphic, or any mixture of those approaches. A mock-up constructed with text and graphic elements could serve (after the design decisions were made) as a secondary blank page, but usually a more efficient approach would have less content than a full mock-up in the secondary blank page, in order to reduce the work of removal or replacement.
inheritance is the mechanism by which updates to a template are propagated into the templates and pages built on (or "derived from") that template. Some revisions to a page can break the inheritance, so that updates to the underlying template may no longer be propagated to the page, or so that updates to the underlying template will destroy page content when they do propagate to the page. The current version of CommonSpot provides no warning dialog when a page or template revision would break inheritance from an underlying template. Fortunately, it is possible to set "inheritance security" while in Author mode on the template so as to prevent breaking inheritance, but that will also prevent some kinds of revisions to the pages and templates built on the template.
refresh refers to an HTML construct, within a META tag inside the HEAD section of an HTML file, that instructs the browser, after a controlled delay, to jump to a different, specified URL. The page containing this refresh will be, briefly, visible on the browser's display, until the specified delay time has elapsed and the browser jumps to the new URL. With most browsers, the refresh page will also be visible, briefly, if the user later clicks on the browser's "back" tool repeatedly to return through that page to the prior one; see, for example, the page
If you do choose to use a refresh page, be sure to avoid using a zero-second delay: that would be user-hostile, because, with most browsers, it would prevent your reader from using the browser's "back" button to return to the page that brought them to your site.
redirect refers to an HTTP protocol level interaction in which the server responds to a request for a page, not by sending an HTML file, but by sending a small data "packet" to inform the browser that it should instead be asking for a different URL. This is established by appropriate configuration of the server. Because no HTML page is transferred from the server, no intervening page is displayed by the browser when the user follows the link to the re-directed page, nor later if the user clicks on the browser's "back" tool to return to the prior page; see, for example, the result of clicking on the page
The owner of each page, and the administrator of each subsite, can control who has the ability to modify each page, or each page element. In order to simplify the transitions between people in various jobs, and to more easily maintain the subsite during vacations or illness of the primary people, we urge you to take advantage of CommonSpot's "Group" capabilities. Access to the page or page element should usually be granted to the appropriate group, not to individuals, even if there is only one person in the group. Then, individuals can be added to or removed from the group, as their temporary or permanent responsibilities change, without each and every page and page element needing to have its security re-set.
Creating groups and changing their membership is one of the functions of the subsite pagemaster. The owner of each page can then grant access at the appropriate level to each group.
Once the subsite pagemaster has migrated the subsite into CommonSpot, it will be time to recruit content contributors, sign up for the Advanced Pagemasters' training (to learn how to grant the content contributors access), and sign the content contributors up for the Content Contributors training (where they will learn how to maintain pages and page elements).
In addition to the controls for permission to modify pages and page elements, CommonSpot pages can be visible to the world at large, or they can be restricted to be visible only to the specific individuals and groups you authorize. This seminar includes instructions for creating subsites that are visible to the world. The Advanced Pagemasters seminar includes instructions for restricting access to specific individuals and groups. If you need to have an entire subsite or sub-subsite password-protected, so that it will not be included in any public search engines, for example, but do want to have all of the pages be visible to all Ohio University users, then use the techniques documented as part of the Advanced Pagemasters seminar. If you need to restrict access to part of a sub-subite, e.g., to restrict access to a particular page, please contact OIT by E-mail to email@example.com for instructions.
New pages and changes to page elements are not visible to anyone except the page author until they are approved. That approval process can be a single step taken by the page author ("submit for publication"), or it can involve an entire workflow sequence of approvals initiated by the page author. Earlier versions of CommonSpot suffered from a misfeature in this workflow approval process that created a risk of losing page content irretrievably. That has been fixed now, so we are planning an extended discussion of the approval process to be part of the Advanced Pagemasters seminar, "real soon now."
If you have an immediate requirement to have someone else approve your work before it is visible to the public, please contact OIT (by E-mail to firstname.lastname@example.org, or by phone to 593-1222).
Go to http://author.oit.ohio.edu/secure.cfm.
In class, enter your demo OAK login ID and Password (not your own personal OAK login ID or password). When working on your real subsite, you will use your own personal OAK login ID and password.
Observe the "Pending Actions" dialog box. It will be displayed every time you login, listing any pages on which you have work-in-progress, any of your pages on which CommonSpot is aware of broken links, any pages that have been submitted for publication by others that require your approval, and any pages that have been changed recently that you asked CommonSpot to tell you about. For now, close the "Pending Actions" dialog box; you can bring it back up later.
Navigate to your demo subsite's home page and observe the three tool ("shortcut") icons at the top center. In the next section we will begin our exploration of the tools available through these icons for modifying this page or creating a new one.
If, during your session, your authentication expires (most likely as a result of what appears to CommonSpot to be inactivity), then the shortcut icons will disappear and their tools will not be available. If you then attempt to access
or the equivalent page in your real subsite or sub-subsite, your browser will automatically re-submit your password on your behalf, and when you return to the page you were working on, the shortcut icons will be re-displayed.
Observe the tabs at the top right of the page. Clicking on each of these tabs brings up a menu of choices that depend upon the context. To take a choice, move the mouse (keeping it within the menu box) until it is over that choice, then click as usual. If you move the mouse outside of the gray menu box, that menu will collapse with no choice being made.
The "Tools & Information" tab contains primarily features that assist users in locating content within the site. The choices that are available will depend on whether you are in "Read," "Author," or "Edit" mode. The "Document Information," "Image Gallery," "Referring Pages," and "Validate Links" choices are of more general use.
The "Page View" tab contains options for users to toggle between "Read", "Author", "Edit", and "Preview" modes. Users can also view previous versions of a page. The choices that are available will depend on whether you are in "Read," "Author," or "Edit" mode. Because of the way Ohio University's installation of CommonSpot uses Ohio login ID and password for authentication, the "Logout..." choice will accomplish some housekeeping, but will not prevent the next user of the computer from using your access rights. When you are done using CommonSpot, close all browser windows (on Macintosh, choose "Quit" from the browser's menu).
The "Properties & Actions" tab contains options for creating new pages and templates, and for setting content expiration. The choices that are available will depend on whether you are in "Read," "Author," or "Edit" mode. The "My Pages..." and "Standard Metadata..." choices are of particular use.
While you are modifying a page, CommonSpot will routinely create one or more windows to function as dialog boxes and forms to obtain your input. Often it will initially create these windows off-screen, and then when they are complete, re-position them onto the visible part of the display. If the final repositioning fails to occur, you can right-click on the taskbar segment for that window and choose "maximize" to get it visible.
Return to your demo subsite's home page, if you are not still there. In "Read" mode you are seeing only those changes that have been completed and published.
Click on the "Page View" tab and in class select "Author" from the menu. In "Author" mode, you will see the completed and published version that was visible in "Read" mode, as modified by any changes that are your own work-in-progress. In "Edit" mode, you will be able to see and work with not only your own work-in-progress, but also work-in-progress by all other CommonSpot pagemasters or content contributors who have been authorized to work on that page.
After the page has been re-drawn in "Author" mode, observe that your page now includes various small CommonSpot tool icons, in addition to the three primary tool icons at the top center. Clicking on these icons will bring out menus of various actions. Each CommonSpot element will have at least one tool icon above it.
Examine the lower left of the page, just above the gray footer bar. You will see a block of "boilerplate" identifying the person who most recently modified the page, and immediately above the boilerplate, on the left margin, four CommonSpot tool icons. Click on the name of the person in the boilerplate.
This will bring up the Rich Text Editor ("RTE"); we will return for a more detailed exploration of the RTE later. For now, change the name to your own, and change the date to the current date.
Click on the "Finish" button when you have made those two changes.
Observe that the changed boilerplate now has five CommonSpot tool icons; the new one is a yellow "work-in-progress" icon, which should look similar to one of the following:
, , or .
Such changed or new material is visible only when in "Author", "Edit", or "Preview" mode (and to those who are part of the formal approval process for that change, if there is one). "Preview" mode displays the page as your audience would see it if all work-in-progress items were submitted for publication in their current state. "Edit" mode permits you to see, to further revise, and to discard or to submit for publication, work in progress that was initiated by someone else. Other people's work in progress is not visible to you when you are in "Author" mode.
Click on the yellow work-in-progress icon and select "Submit entire page for publication..."; be very careful to avoid selecting "Discard Change," which is adjacent on the menu!
If you had multiple page elements with changes that were still work-in-progress, you could choose to submit any one element's changes for publication at any time, by clicking on the appropriate yellow work-in-progress icon, and choosing "Submit Change for Publication..." from the menu. That will leave the other elements' changes still as work-in-progress, visible only while in "Author" or "Edit" mode. If you have only one change to submit, the system is likely to be quicker in responding to the "Submit Change..." choice than it can be for the "Submit entire page..." choice. If CommonSpot has gotten confused about some aspect of the page, it is more likely to recover during a "Submit entire page..." procedure than during a "Submit Change..." procedure.
While you are first building your subsite, it is appropriate to activate new pages, and to publish changes in revised pages, as you go along. Once your subsite is in production, however, you may well choose to get a new page entirely ready before activating it, or choose to complete an entire set of revisions to the content of an existing page before publishing them all together.
In the resulting publication dialog box, you will find the opportunity to provide comments. Please make a habit of doing so -- they will prove quite useful when you need to use the Version History feature, among other times. Do consider that the times when you need to use Version History are times when the world is already seeing something that is wrong, so any help that will speed your selection of the correct prior version is a very good thing!
In the publication dialog box you will also find a check-box, immediately after the comment section, to display the page in "Read" mode after publishing the changes. Often it is best to check that box.
In class, be sure to wait your turn to click on the "OK" button.
Observe that the page is displayed in "Read" mode, and that your changes have taken effect.
Click on the "Page View" tab and select "Author" from the menu.
Direct your attention just above the boilerplate section. Near the left margin you will see a collection of four CommonSpot tool icons (the fifth, yellow work-in-progress icon will be gone). Above them, you will see a short, wide box, inside of which is a "phantom" or "ghost" link, saying, "Click here to define the layout."
Click there to define the layout. You will see a dialog window that provides control of all the usual HTML table attributes. We will return to explore this dialog later.
Click on the "OK" button to accept the defaults, creating a one-column by one-row table, with no borders or cell padding.
Observe the yellow work-in-progress icon and the new "Click to insert new element" choice.
Click on the "Click to insert new element" just above the boilerplate's tool icons, and observe the Element Gallery.
Click on the boldface header, "Text Elements" (or the orange triangle to its right), to expand that part of the list.
Click on the boldface header, "Simple Text Block (without header)." We will cover the Simple Text Block element in more detail later.
Observe the new item, "Click here to define the text block." Click on it to bring up the dialog box for data entry.
Type something "short and sweet" in the text block. By definition a "Simple Text Block" has no special formatting. We will presently explore also the "Formatted Text Block" element, using the "Rich Text Editor."
Click on Finish.
Observe that the new material is flagged with a yellow "work-in-progress" icon.
Click on either yellow work-in-progress icon and select "Submit entire page for publication..."; be very careful to avoid selecting "Discard Change," which is adjacent on the menu!
In class, check the box to display the page in "Read" mode after publishing the changes.
In class, be sure to wait your turn to click on the "OK" button.
If you didn't check the box, then manually change back to "Read" mode.
In class, click on the "Page View" tab and then select "Version History" from the menu. You can see your comments and any previous comments.
The key things to remember about changing a CommonSpot page are that you should go to the page in question, scroll up to the top, and select "Author" or "Edit" mode, and then either
add something, by clicking on "Click to insert new element" or
change something that is already there, by clicking on the gear-wheel icon at its upper-left corner.
This section is intended for subsite pagemasters, not for content contributors. Content contributors are welcome to read it, but in the Content Contributors' seminar we will skip forward to Creating New Pages.
If you are responsible for an existing site or subsite, and decide to migrate it into CommonSpot, you will need to consider several issues that do not arise for people who are building entirely new subsites.
After the new subsite is live from CommonSpot, and you have tested your pages one last time, you will tell the new URL to the pagemasters of pages that you know have links to your old site. There are bound to be personal bookmarks and search engine databases that will continue to lead people to the old site. Therefore, the server that was publishing your old site should be re-configured to send anyone who comes looking for any of the old pages, over to the new ones. If the old site was on the VMS Front Door server, with URLs that look like:
then you need only include that old URL in your E-mail message to email@example.com asking for activation of the CommonSpot subsite. If your old site was on some other server, then you will need to contact the system administrator of that server directly.
There are three approaches to re-configuration of the old server, all of which are useful for as long as the old server continues to operate:
having any attempt to get any page from the old server bring up a specific replacement page from the old server that has a refresh meta tag and a text link to take the reader to the appropriate new page;
having any attempt to get any page from the old server result in a redirection to the new home page;
having any attempt to get any page from the old server result in a redirection to the corresponding page in the new subsite.
Let's consider each of these three aproaches in more detail:
The replacement page approach is always possible. This alternative is appropriate when the subsite has been reorganized, so that information that used to be on one page is now split among multiple pages, or information that used to be on multiple pages is now combined onto one page, or information that used to be published is no longer published. This alternative is more work for the pagemaster, who has to manually create a replacement page for each of the existing HTML pages, but it is less frustrating for the reader than the home page approach, because the browser is taken directly to the information on the appropriate page of the new subsite. One approach to the creation of the replacement pages is presented on-line at:
(the final period is part of the URL).
The home page approach is usually possible. This alternative is also appropriate when the subsite has been reorganized. This alternative is less work for the pagemaster than the first alternative, but is frustrating for the reader, because he or she must explore the new subsite to find the information that used to be immediately available at that link.
The corresponding page approach is possible for some servers, including any subsites that were already on the older Front Door server. This alternative is easy for the pagemaster and satisfying for the reader, but does require planning by the pagemaster, and may not be possible for some subsites.
This alternative is appropriate only if every URL on the old site has a corresponding page with the "same" URL (in terms of sub-subsite names and file names) on the new subsite, and the information content of the pages matches, so that anyone following a link will get to the information they were expecting to find. The new subsite can have additional pages, and need not have the same navigational linkage among the pages: the subsite can be conceptually re-designed and re-organized, and still use the corresponding page approach, provided that the same information can be found on pages with the "same" URLs.
The file type of the old site may have used ".htm", ".html", ".asp", ".php", or some other type for the page files. Ohio University's CommonSpot installation has been customized so that if a browser requests an HTML file that does not exist, but for which there is a ".cfm" equivalent (as all CommonSpot pages will be), then a refresh page leading directly to that equivalent page will be constructed "on-the-fly" by the software, automatically, and presented to the reader.
CommonSpot provides for you to manually construct a redirect for any single page, by using the Content Expiration dialog. This is discussed among the Advanced Topics.
For these reasons, we strongly suggest that you seriously consider preserving your site's file and sub-subsite names unchanged (except for changing ".htm" and ".html" into the ".cfm" that CommonSpot automatically provides), when you migrate an existing site from another server into CommonSpot, so that you and your readers can take advantage of the corresponding page redirect approach.
In order to simplify programming, documentation, and training, we have decided to configure the CommonSpot server so that the only default page name will be index.cfm. Thus, a URL of the form
will bring up the page
if that page exists, and a "file-not-found" error if index.cfm does not exist. In order to permit "corresponding page redirects" to work as described above, even for subsites migrating into CommonSpot that had been on servers using other default page names, CommonSpot's custom "file-not-found" code includes detection of requests for the most common other default filenames, and brings up the index.cfm page instead, just as it does for "index.html" changing into "index.cfm". At this time we provide this service for pages named "welcome.*", "default.*", and "homepage.*" (where the ".*" can be ".htm", ".html", ".htmlx", ".asp", ".php", etc.).
If your subsite has been using a default page name other than index, welcome, default, or homepage, please let the Web Team know, so that we can consider whether to add it to the list.
Please build all CommonSpot subsites using "index.cfm" for your home page (and for each sub-subsite's home page). If your former site had been using a default home page name other than index, please be sure to tell the Web Team the details when it is time to put your CommonSpot subsite into production.
A final complication to the corresponding page redirect approach will occur for some subsites: those for which an existing file or sub-subsite name happens to collide with one of the various files and folders that CommonSpot creates on the server "behind the scenes," on your behalf.
The list of files and folders that CommonSpot will create as part of its infrastructure includes:
template-*.cfm for your local templates (the * will be replaced by the name you specify for the template)
the following folders will be created in each subsite and sub-subsite:
cachecustomcf (not in V6)
customcf (new in V6)
pageindex (not in V6)
files with the following names, with one ending or another, will be created in each subsite and sub-subsite:
force-login (not in V6)
restricted (not in V6)
Do not attempt to create pages using any of the above listed file names, nor to create sub-subsites using any of the above listed folder names!
If you are migrating an existing site that uses any of the folder names or file names that are listed above (including any files of the same name with any ending), please contact OIT (by E-mail to firstname.lastname@example.org or by phone to 593-1222) early in the planning process, before you start creating any pages or sub-subsites in CommonSpot.
Planning -- assemble the answers to the following questions (your answers to some of the later questions may require that you reconsider your answers to earlier questions):
Should the overall site and page design be preserved or re-worked? If re-worked, should the changes be cosmetic only, or should the navigational paths, or allocation of content among the pages also be changed? Constructing mock-ups of the home page, any other navigational pages, and representative content pages may well prove to be a useful exercise in answering these questions.
Will folder (sub-subsite) and file names be preserved? If not, how will your subsite be organized, what will the new file and sub-subsite names be, and what will their contents be?
Which of the three approaches will you use to help people find your new pages: replacement pages with refresh, home page redirect, or corresponding page redirect?
What pages will share one or more identical page elements? What templates will you use? What page elements will each have? Which templates will be derived from which? (Consider having at least two sets of templates: for navigation-intensive pages and for content-intensive pages.)
What secondary blank pages will you construct, on which templates, to speed the process of building which pages?
Which, if any, groups of pages should become CommonSpot "page sets?" (They should probably share their own derived template, which will include some of the page set navigational structures, and may also be easier to build by starting from a copy of a secondary blank page.)
Should any page elements not included in templates be shared among two or more pages?
Contact OIT by E-mail to email@example.com, or by phone to 593-1222, informing us of your readiness to build your subsite. Please provide the URL of the existing site, if there is one.
We will create and configure the new subsite in CommonSpot; we will create an initial, content-free "index.cfm" home page, using the "official_pages1" or the "unofficial_pages1" template, as appropriate; we will create a password-protected sub-subsite for preparation off-line of content that should not be visible to the world until it is completely ready; and we will establish redirects from www.ohio.edu to your existing site.
Login through http://author.oit.ohio.edu/secure.cfm, and then navigate to your subsite.
Create, in your password-protected sub-subsite, the templates you plan to use.
Lock down those templates, so that element inheritance will not be broken by page revisions.
Create, in your password-protected sub-subsite, a primary blank page using each template, and confirm that no CommonSpot tool icons are displayed when in "Author" mode, on items that should be locked down.
Create, in your password-protected sub-subsite, any secondary blank pages that you plan to use, adding the elements that will be similar on the pages you will be building from each secondary blank page (e.g., place the graphic images for "back" and "next" buttons, which cannot be in the template, because they will be linked to different destinations in each page).
Build your subsite home page, either using the content-free page we created initially, or by making a new page from scratch using the template of your choice, with a name such as "new-index," and then: renaming the placeholder page we created to be "old-index"; renaming your new page to be "index"; using the "Referring pages" dialog on old-index to mend any links so that they now go to the new index page; and finally, deleting the old-index page.
Create the sub-subsite structure, starting each sub-subsite's home page -- with a name of "index" -- on the appropriate template.
Create additional navigational and content pages on the appropriate templates, with additional links from the navigational pages to the content pages, and among the content pages, as appropriate.
If you have chosen the replacement pages approach, prepare each of those, so that you will be ready to upload them to your old server promptly after the CommonSpot site is in production.
Contact OIT by E-mail to firstname.lastname@example.org, or by phone to 593-1222, informing us of your readiness to go live from http://www.ohio.edu/subsite/.
If your former site had been using a default home page name other than index, please be sure to tell the Web Team the details at this time, even if you have previously mentioned them to us.
We will turn off the redirection that we established in step 2, above.
Double-check that all is working as expected when you view the subsite from http://www.ohio.edu/subsite/. In particular, follow all links among your pages, to confirm that none of them takes you to http://author.admsrv.ohio.edu/subsite/whatever. Once you are satisfied, then either inform the system manager of the old site that it is time to set up redirection from the old site, or upload the replacement pages, if you have chosen that approach.
Maintain subsite content using expiration and freshness reminders.
Take the Advanced Pagemasters seminar (once we start offering it -- study the online resources in the meantime), and sign your content contributors up for their training.
Authorize others to maintain particular content, with appropriate workflow approval processes.
Using sub-subsites to organize your Web pages can help your reader to understand and remember the URL, because it can be parsed out into smaller pieces. There is no requirement that your sub-subsite organization correspond exactly to the navigational sequence of links that you expect people to follow to get from your subsite home page to the specific content pages, but that often provides a good basis for choosing a sub-subsite organization.
Sub-subsites must be created before any pages can be placed into them. Only subsite pagemasters are permitted to create sub-subsites. Other content contributors may be permitted to create new pages within a sub-subsite that the subsite administrator has already created.
It is possible to configure our CommonSpot server so that your subsite is live and visible as http://www.ohio.edu/subsite/, but one or more sub-subsites are still being redirected to your old server, while you complete those sub-subsites, accessing the pages through http://author.oit.ohio.edu/subsite/sub-subsite/. If you want to bring your subsite live in stages this way, please contact OIT (by E-mail to email@example.com or by phone to 593-1222).
In the following example we write "subsite" where it is the label that CommonSpot uses in the forms and dialog boxes for your new sub-subsite.
Go to your subsite's admin page: http://author.oit.ohio.edu/demoX/admin.cfm (where "X" is the appropriate digit for your training subsite). When you do this for real, of course, you will replace "demoX" with your subsite's name.
Observe that your subsite is selected in the upper right hand corner; if not, then choose it. Your "Subsite Administration" page will appear.
Click on the plus [+] sign next to the "Subsites" heading to expand it.
Select the link "Click here to create a new child subsite".
The subsite name that you assign will be that part of the visible URL of all the pages in that sub-subsite.
Fill in the subsite name, description, and display name, and click "OK".
Click on "Create first page," then click on "Create New Page."
Select the appropriate template from the Template Gallery, by expanding the category and then clicking on the boldface template name. For now, choose the "official_pages1" or "unofficial_pages1" template, as appropriate for your subsite.
Complete the "Create New Page" form: specify a category of "Ohio University Website," or "Unofficial Ohio University page," respectively. Give the first page in the sub-subsite a name of "index" (without the quotes), even if you are replacing an existing site that used "welcome," "default," or "homepage" for its default home page. You can use either orange circle with the black down-arrow to propagate that field's text to later fields. Be sure that the title you specify is different from any other CommonSpot page's title -- include the subsite in the title, either as it shows in the URL or by a conventional name, and then make sure it is distinguishable from any of your other pages.
Click on the "Next" button.
Decide whether or not to activate the sub-subsite home page immediately. If your entire subsite, or this particular sub-subsite, is still being redirected to the old server, you should activate the page right away, since it will not be visible on www.ohio.edu anyway, and the redirection process is more reliable with a default home page in place for the sub-subsite.
Select "Read" mode before leaving the page.
Sub-subsite security settings may need to be adjusted if you are going to have others work on those pages. That can be done later, and is a topic for the Advanced Pagemasters seminar.