- Help & Support
- IDs & Accounts
- Tech Depot
- Networks / Telephones
- Academic Services
- Information Security
- Web Services
- OIT Projects
- About OIT
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.
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 one of a restricted set of browsers. For the past several years, CommonSpot authoring has routinely worked with recent prior versions of Microsoft Internet Explorer on Windows and of Firefox on Windows, Macintosh, or Linux, but has often not worked with the latest versions of those browsers. For current details, follow the "Authoring Browsers" link in the secondary navigation block at the left.
In all cases, CommonSpot authoring works only with 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.
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 somewhat less than 100 MBytes for uploaded files, including graphic images and binary documents such as Word's ".doc" and Acrobat's ".pdf" files. It is rarely humane treatment of your audience to include such large 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 was 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 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 working 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 (e.g., on your old site, after you have migrated into CommonSpot), 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.
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.
Enter your own personal OAK login ID and password.
Navigate to your subsite's home page and observe the pencil icon at the top right. In the next section we will begin our exploration of the tools available through this icon 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 some or all of the various shortcut icons will disappear and their tools will not be available. If you then attempt to access
your browser will automatically re-submit your password on your behalf, and when you return to the page you were working on, and re-load it, the shortcut icons will be re-displayed.
Click on the pencil icon at the top right; observe the menu of choices. 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 so that it leaves through the bottom boundary, the menu will collapse with no choice being made.
Choosing "View Page in CommonSpot" will bring up the page inside the CommonSpot Dashboard, in the equivalent of the old "Read" mode.
Choosing "Work on this Page" will bring up the page inside the CommonSpot Dashboard, in the equivalent of the old "Author" mode.
Choosing "Work on this Page (All Changes)" -- if that choice is present -- will bring up the page inside the CommonSpot Dashboard, in the equivalent of the old "Edit" mode.
After you select "View Page in CommonSpot," "Work on this page," or "Work on this page (All Changes)," the page will be re-displayed within the new "CommonSpot Dashboard," as shown here (for this graphic, we have added a blue overlay on the full-width toolbar, and a red overlay on the content-spanning toolbar):
(click on the image to see it full size).
While you are modifying a page, CommonSpot will routinely create one or more "lightboxes" to function as dialog boxes and forms to obtain your input. There may be a period of time with minimal or no visible result from your actions.
Return to your subsite's home page, if you are not still there. While viewing the page as published, you are seeing only those changes that have been completed and published.
Click on the "View" button in the content-spanning toolbar, and select "Work on this Page (My Changes)" or "Work on this Page (All Changes)." In the former case, you will see the completed and published version that was visible, as modified by any changes that are your own work-in-progress. In the latter case, 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, observe that your page now includes various small CommonSpot tool icons. Clicking on these icons will bring out menus of various actions. Each CommonSpot element will have at least one tool icon, a gear wheel at its top-left corner:
Clicking on that icon will evoke a menu; the choice closest to where the gear wheel was will be the primary content-modification tool -- for example, the Rich Text Editor for Formatted Text Block elements.
When you make changes, there will typically be a "Save" button to store them as work-in-progress.
The changed elements will have a yellow "work-in-progress" icon in place of the gear wheel, which should look similar to one of the following:
, , or .
Such changed or new material is visible only when working on the page (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.
When you click on the yellow work-in-progress icon and select "Submit page...", 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..." from the menu. That will leave the other elements' changes still as work-in-progress, visible only while working on the page. 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 page..." choice. If CommonSpot has gotten confused about some aspect of the page, it is more likely to recover during a "Submit 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.
The key things to remember about changing a CommonSpot page are that you will typically go to the page in question, scroll up to the top, and select "Work on this Page" or "Work on this Page (All Changes)," 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 static-page 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 static-page 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. The redirect should be coded, of course, to go to CommonSpot's ".cfm" page.
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 does exist, 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, it will be necessary for the redirect code to address that issue.
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, but may be left over from pre-V6)
customcf (new in V6)
pageindex (not in V6, but may be left over from pre-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, but may be left over from pre-V6)
restricted (not in V6, but may be left over from pre-V6)
Do not attempt to create pages using any of the above listed file names, except index, 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 the Web Team (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, if needed.
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: login and navigate to any CommonSpot page; click on the pencil; choose, "View Page in CommonSpot"; click on the "Admin" button in the full-width toolbar, and select "Subsite Administration..."; choose your subsite; click on the "Next" button.
Click on "New Subsite" at the lower right, and observe the Create Subsite lightbox.
Fill in the subsite name, description, and display name; choose a name that consists of letters, digits, hyphens, and underscores, but no spaces or other punctuation marks. Click the "Save" button at the lower right.
If an error message is displayed (e.g., about the request timing out or providing an empty response), close the error message's lightbox(es) and then close the subsite-creation lightbox. Click on the browser's "refresh" or "reload" button to re-display the CommonSpot Dashboard with the subsite administration page. The new subsite should be listed. If not, please contact OIT (by E-mail to firstname.lastname@example.org or by phone to 593-1222).
Click on the new subsite's name in the list of child subsites, at the lower left of the subsite administration page.
Click on "Create New Page" at the top of the block of text links on the right side, in the "Subsite Statistics" section in the middle of the page. A more-detailed, general description of the process for creating a new page on an existing template is included elsewhere; steps 6 through 10, immediately below, provide a quick summary.
Select a template from the Template Gallery: choose a category and then click on the "Next" button at the lower right; then click on the template name to highlight it (observe that the templates are listed in case-sensitive order, with the uppercase letters preceding the lowercase letters). For example, you might choose category, "Ohio University Templates," and then the "official_pages1" or "unofficial_pages1" template, as appropriate for your subsite. Once a template is highlighted, click on the "Next" button at the lower right.
Complete the "Create New Page" form:
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.
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.
You can use either of the orange circle with the black down-arrow to propagate that field's text to later fields.
Specify a category of "Ohio University Website," or "Unofficial Ohio University page," as appropriate.
You will be able to revise your entries later: the name, by choosing "Rename Page..." from the "Actions" menu; the others, by choosing "Standard..." from the "Properties" menu.
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.
Select "View page as published" before leaving the page.
Sub-subsite security settings may need to be adjusted if you are going to have others work on those pages, or if you want to restrict access when reading the pages. That can be done later, and is a separate topic.