Website Design
Detailed Design Document
2/12/2016
1Page 1 of 30
Table of Contents
TABLE OF CONTENTS ............................................................................................................................................2
DOCUMENT HISTORY ............................................................................................................................................3
OVERVIEW ................................................................................................................................................................4
CONTRIBUTION UI CHANGES .............................................................................................................................5
NAMING CONVENTIONS .......................................................................................................................................6
SITE HIERARCHY ....................................................................................................................................................7
LAYOUTS ....................................................................................................................................................................8
PERSISTENT AREAS ...................................................................................................................................................8
SPLASH PAGE .......................................................................................................................................................... 11
METADATA .............................................................................................................................................................. 16
SECURITY ................................................................................................................................................................ 16
WORKFLOW ............................................................................................................................................................ 16
CONTENT MIGRATION ........................................................................................................................................ 18
FRAGMENT INFORMATION ............................................................................................................................... 19
FRAGMENT LIBRARIES FOR <CLIENT> .................................................................................................................. 20
EXTENSIBLE ELEMENTS..................................................................................................................................... 20
<CLIENT> UNIQUE CUSTOMIZATIONS........................................................................................................... 20
NATIVE CONTENT, TEMPLATES, AND DYNAMIC CONVERTER ............................................................. 21
PUBLISHING ............................................................................................................................................................ 22
TECHNICAL APPENDIX ....................................................................................................................................... 23
TEAM BUILDING BEST PRACTICES........................................................................................................................... 23
Setting up a Workstation for Site Design ........................................................................................................... 23
Setting up a Workstation for Contribution ......................................................................................................... 23
Layout Design .................................................................................................................................................... 23
Fragment Creation and Modification ................................................................................................................ 23
Contribution ....................................................................................................................................................... 23
Primary and Secondary...................................................................................................................................... 24
DEFAULT METADATA FIELDS .................................................................................................................................. 24
SOURCE VIEW.......................................................................................................................................................... 25
URL NAMING AND PAGE BUILDING ......................................................................................................................... 25
LIST OF REGISTRY SETTINGS ................................................................................................................................... 26
ISSUES LOG ............................................................................................................................................................. 30
2Page 2 of 30
Document History
Contributor
Steven Sommer
Steven Sommer
Date
06/06/2005
06/14/2005
Steven Sommer
06/16/2005
Steven Sommer
06/16/2005
3Page 3 of 30
Comments
Initial Revision
Substantial updates including adding validation to
elements, upgrading to Site Studio 7.5, Dynamic
Converter information, etc.
Adjusted the fragment definitions based on POC
work.
Added a section on Contribution UI Changes.
Overview
This is the detailed design document for the <CLIENT> site redesign project.
The <client>’s external website is currently running as a static publish from Stellent’s Content
Publisher, version 6.2. See the scope document for additional details on the Current State. This
project’s goals are to improve the site and the web content management process in several areas:

A redesign of the look-and-feel. An outside agency, (<DESIGN FIRM>
http://www.<design firm>.com), has been retained to define the site look-and-feel and
navigational structure. The current site navigation can be improved to make the structure
flatter (or appear flatter) and to be more intuitive for the many audiences that are served
by the Department of Education. This includes teachers, parents, legislators, school
districts, the Department of Education itself, and others.

Improve the contribution model to allow direct edits. Currently content is sent to the
web team, which must process the contribution. In the new model, contributors will be
able to contribute content directly with controls in place to ensure the site consistency.

Provide an automated approval process. This will ensure that contributed content is
approved, in the context of the website, before it made public. This will be handled with
Stellent workflow.

Provide designers with tools to more affectively improve, manage, and maintain the
site.
The plan is to use the redesigned look-and-feel, code layouts, and the navigational structure
provided by <DESIGN FIRM>, and then to implement the site within new instances of Content
Server and Site Studio. Since the Stellent Consulting time allotted to this project may not be
sufficient to cover the entire site development from scope to deployment, this project will focus
on a few select vertical portions of the site. The intent is for the <client> staff to become
familiar with the Site Studio and Content Server tools so that they can complete the site
development on their own after the consulting engagement ends.
This project is dependent on the design and page layouts designed by <DESIGN FIRM>. The
design provided by <DESIGN FIRM> uses style sheets for positioning of items on pages (called
CSS Positioning). <DESIGN FIRM> is also designing pages that are W3C compliant, ADA
compliant, and include “screen reader” content.
The goal of this design document is to define the use of the design, images, layouts, style sheets,
and other artifacts provided by <DESIGN FIRM> to implement and deliver the site within the
Site Studio tool. This document focuses on the Site Studio tool and the construction of the site –
not on the design as provided by <DESIGN FIRM>.
4Page 4 of 30
Contribution UI Changes
The following changes are planned for the Contribution UI:
1) Use the <client> Logo in the Layout Editor. This is already completed, and provides a
light branding of the site.
2) Remove web site specific document types from the document type option list if the user
isn’t an admin. All site designers will be admin users, so they can access these types
during check in. This will accomplished with profiles.
3) Hide the Alternate File field. This is a configuration change. In the config.cfg file set
SupressAlternateFile=true
4) Hide the Website Object Type if the user is not an admin. The field should be defaulted
to “Native Document”. This will be accomplished with profiles.
5) Hide the “Inhibit Propagation” field unless the user is an admin. This will be
accomplished with profiles.
5Page 5 of 30
Naming Conventions
Naming conventions are critical to creating a Site Studio site that is consistent, where things can
be easily found, and maintenance is simple. The following table defines the naming conventions
within Site Studio that will be enforced for this project.
Content Type
Sections
Layouts
Fragment Libraries
Fragments
Contribution Regions
Elements
 WYSIWYG
 Plain Text
 Image
Data Files
Custom Elements
Title
Name determined by client. Should appear as user wishes it
to appear in any navigation fragments
SS_LO_<Unit>_<LayoutName> Where <LayoutName> is
the name of layout being used. See the layout section for
more details. Note: This name should also be used for the
content ID because this is what is shown in the designer
interface for sections.
SS_FL_<Unit>_<LibraryType> Where <LibraryType>
describes the types of fragments contained within (i.e.
navigation, static lists, etc.) See the Fragment information
section for more details. NOTE: This name should also be
used for the content ID because this is what is shown in the
designer interface for selection.
Fragment names appear in the toolbox. To group them
together for usability a qualifier of <Unit>_ should be
specified. The remainder of the name should be descriptive,
but are at the discretion of the creator. Fragments going into
the shared fragment libraries should use a qualifier of “Z_” so
that they are listed together and last in the toolbox.
This should be a meaningful name.
Use a descriptive name of the element field being defined.
SS_Datafile_<Meaningful Name> where MeaningfulName is
some descriptive name.
SS_Cust_<ElementType> Where <ElementType> describes
the type of Extensible Element being used (i.e. SourceForm,
ImageForm, etc).
Notes:
1. Whenever possible, all content should use an auto assigned Content ID. If the client
desires "friendly" layout names within Site Studio Designer, a unique "non-overlapping"
convention should be used. In Site Studio, ID's should generally match the content title.
2. All checked in content (framework and content) should have the website ID metadata
field set. This value will be used extensively during site migration.
6Page 6 of 30
Site Hierarchy
The site hierarchy defines the navigational structure that will be exposed to the end users of the
web site once it is delivered. This is also often referred to as the “tier structure” at <CLIENT>.
This will also be the basis for a site map page included within the site.
In addition to that, the site hierarchy also defines the categorization for site content. As
contributors add information to the site, they will be doing so in the context of a location within
the site. Therefore, it is critical that this hierarchy be completely defined and agreed upon prior
to any content migration or actual site development.
Area
Site Sections
Sub Sections
Primary Pages
Secondary Pages
Layouts
Description
Should contain primary page and secondary page. Name should be
the same as that desired in Navigation fragments. Areas which
should be included in the Navigation should be enabled.
Sub Sections should exist for all sub navigational links. Each Sub
Section should have a primary page and secondary page. Again,
areas which should be included in the Navigation should be enabled.
Required in each section and subsection
Optional in each section and subsection
Refer to the section on layouts.
<insert image of site hierarchy here>
7Page 7 of 30
Layouts
Persistent Areas
The design of the site is such that there are areas within the pages that will rarely change, but
may have some parameterized settings for some navigational feedback. These areas are
designated as persistent.
8Page 8 of 30
Page
Area
1
Courtesy Navigation
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Courtesy Navigation
<CLIENT> Courtesy Navigation
SS_Fragments_<CLIENT>_Navigation
None
1
Static List with a single column of WYSIWYG elements.
WEB_ASSETS
None
These are single page reference links, not dropdowns.
A single data file will be referenced by all instances of
this fragment so that the links are consistent across the
entire site.
Page
Area
Top Banner
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
2
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Page
Area
3
Top Banner
<CLIENT> Top Banner
SS_Fragments_<CLIENT>_Other
1-Logo(managed URL) – image from SCS
2-AltText (text) – Logo alt text
3-ParentTitle(text) – text in top right corner
0
NA
NA
NA
<DIV> tags in fragment or not?
Search Form
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
9Page 9 of 30
Search Form
<CLIENT> Search Form
SS_Fragments_<CLIENT>_Other
1-ButtonImage (image)
0
NA
NA
NA
Comments/Notes: Needs to be coded so it works on published site – might
not work on dynamic site. We should be able to borrow
the code from the existing site.
Page
Area
Program Groups
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Program Groups
<CLIENT> Program Groups
SS_Fragments_<CLIENT>_Navigation
None
0
NA
NA
NA
This code will be static. No contributor editing, not
dynamic.
4
This code will mostly be controlled by the style sheets,
down to the pixels. If special javascript is required for IE
(or any other special considerations) we may include that
code in the fragment.
This approach will require manual updates to the style
sheets if the navigation structure changes, but should be
fairly simple. Each style sheet that contains the code will
need to be modified.
Page
Area
5
Footer
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
10Page 10 of 30
Footer
<CLIENT> Footer
SS_Fragments_<CLIENT>_StaticList
None
1
Static list with single column of WYSIWYG elements
WEB_ASSETS
None
Comments/Notes: Includes the copyright and links to other footer-type
things.
A single data file will be referenced by all instances of
this fragment so that the links are consistent across the
entire site.
Splash Page
11Page 11 of 30
Page
Area
From the Commissioner
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
1
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Page
Area
2
From the Commissioner
<CLIENT> From the Commissioner
SS_Fragments_<CLIENT>_StaticList
1) Background Image (clear) 2) Text for tab heading,
defaults to “From the Commissioner”
TBD
Static List with four elements. 1) Image (image element)
2) Image Caption (text element) 3) Introduction Text
(text element) 4) email address (WYSIWYG element)
Communications
Image size, length of caption and introduction.
This particular fragment will only be used a single time
at this location on the splash page (most likely).
Associated Links
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Associated Links
<CLIENT> Associated Links
SS_Fragments_<CLIENT>_StaticList
None
TBD
Static List with one column WYSIWYG element.
Communications
None
Used only where links are required in the left navigation
area, but no tab heading is present. This may only be
used beneath the “From the Commissioner” fragment.
Page
Area
Current Topics Left
3
Current Topics Left
<CLIENT> Current Topics Left
SS_Fragments_<CLIENT>_StaticList
1) Background image (clear) 2) Title for tab, defaults to
“Current Topics”
Contribution Regions(s): TBD
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
12Page 12 of 30
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Page
Area
Legislation
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
4
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Page
Area
Legislation
<CLIENT> Legislation
SS_Fragments_<CLIENT>_StaticList
1) Background image (clear) 2) Title for tab, defaults to
“Legislation”
TBD
Static List with a single column of WYSIWYG elements.
Communications
None
Contributors can edit the list of links. Designer can
change the tab heading.
Resources For
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
5
Static List with a single column of WYSIWYG elements.
Communications
None
Contributors can edit the list of links. Designer can
change the tab heading.
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Resources For
<CLIENT> Resources For
SS_Fragments_<CLIENT>_StaticList
1) Background image (clear) 2) Title for tab, defaults to
“Resources for”
TBD
Static List with a single column of WYSIWYG elements.
WEB_ASSETS
None
Contributors can edit the list of links. Designer can
change the tab heading.
Page
Area
Celebrate Education
6
Celebrate Education
<CLIENT> Celebrate Education
SS_Fragments_<CLIENT>_StaticList
1) Background image (clear) 2) Title for tab, defaults to
“Celebrate Education”
Contribution Regions(s): TBD
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
13Page 13 of 30
Element(s): Static List with columns title (WYSIWGY), synopsis
(Text), and image (Image)
Security Group: Communications
Element Validation: None
Comments/Notes: Contributors can edit the list of events. Designers can
change the tab heading.
Page
Area
7
More Link
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Page
Area
News Center
Name:
Fragment Name:
Fragment Library:
Fragment Parameters
8
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
Page
Area
9
More Link
<CLIENT> More Link
SS_Fragments_<CLIENT>_StaticList
None
TBD
Static List with single column of links (WYSIWYG)
WEB_ASSETS
None
Restricted to designers. This is a generic piece of code
that can be used anyplace in the main body of content
where a “more <label>…” link is required.
News Center
<CLIENT> News Center
SS_Fragments_<CLIENT>_StaticList
1) Background image (clear) 2) Title for tab, defaults to
“News Center”
TBD
Static List with columns title (WYSIWGY), and synopsis
(Text)
Communications
None
Contributors can edit the list of news items. Designers
can change the tab heading.
Right Navigation Splash Page
Name: Right Navigation Splash Page
Fragment Name: <CLIENT> Right Navigation Splash Page (Fixed)
Fragment Library: SS_Fragments_<CLIENT>_Navigation
14Page 14 of 30
Fragment Parameters
Contribution Regions(s):
Element(s):
Security Group:
Element Validation:
Comments/Notes:
None
NA
NA
NA
NA
Static Navigation Component.
This will have the navigation values/links defined
statically in the fragment. In this way, it will require
editing if the first two levels of the site change (just the
same as the program group navigation.) The reason this
isn’t dynamic is that the entire navigation structure is not
desired here.
15Page 15 of 30
Metadata
Please refer to the metadata definition located on the Collaboration Server at:
http://collab.stellent.com/collab/groups/projects/@prj/<project>/documents/document/collab_011993.pdf
Security
Please refer to the security model definition located on the Collaboration Server at:
http://collab.stellent.com/collab/groups/projects/@prj/<project>/documents/document/collab_012097.pdf
Workflow
U of M will use sub-admins for workflow design and maintenance.
Content checked into production by contributors will be reviewed via workflow. Each
participant in a workflow step will be notified via email of work to be done, which will include a
link directly to the item to be reviewed. The workflow diagram below provides the design:
Contributor
Step
Check-in
Web
Team
Step
Reject
Approve
Proof
Readers
Step
Content
Released
And
Published
Approve
Reject
Doug
Step
Reject
16Page 16 of 30
Approve
Author
Notification
Step
Approve
The workflow will consist of the following steps:
1. Workflow step 1 - Web Team.
The web team will be the first to review the document. They will be reviewing it for
proper metadata, proper templates, proper conversion, etc. If it is not satisfactory it can
be rejected back to the original author with comments. This step will include the whole
team, but only a single person needs to approve it for it to advance in the workflow. The
web team will not be allowed to edit the document.
2. Workflow step 2 - Proof Readers.
The proof readers will be the next review step. The proof readers will be reviewing it for
spelling errors, grammar errors, run-on sentences, etc. If it is not satisfactory, it can be
rejected back to the original author with comments. This step will include the proof
reading team (may be a single person), but only a single person needs to approve it for it
to advance in the workflow. The proof readers will not be allowed to edit the document.
Escalation will occur at 2 hours and 4 hours. At 2 hours, <TBD> will be added to the
step and it will be repeated. At 4 hours the Web Team will be added to the step and it
will be repeated. Additional email notifications will be sent with a subject and message
that indicate the escalation. The Web Team is notified so that they can track down the
bottleneck.
3. Workflow step 3 – Doug.
The final reviewer will be Doug. Doug will be reviewing the document for compliance
with <CLIENT> policies for published content and related items. If it is not satisfactory,
it can be rejected back to the original author with comments. If Doug approves the
content, it will be released from the workflow. Doug will not be allowed to edit the
document.
Escalation will occur at 2 hours and 4 hours. At 2 hours, <TBD> will be added to the
step and it will be repeated. At 4 hours the Web Team will be added o the step and it will
be repeated. Additional email notifications will be sent with a subject and message that
indicate the escalation. The Web Team is notified so that they can track down the
bottleneck.
4. Workflow step 4 - Release Notification.
The original author will be notified via a step with zero approvers required. Content will
immediately be released and available for publishing.
17Page 17 of 30
Content Migration
See the Filenet migration documentation.
18Page 18 of 30
Fragment Information
Stellent Site Studio stores individual fragments in fragment libraries. You can store each
fragment in its own library or store related fragments together in the same library.
Fragment libraries are stored as managed objects in the content server in the following
way:
• Primary file: A zip file containing all of the assets required by each fragment in the
fragment library.
• Alternate file: A fragment definition file that defines the entire structure of each
fragment in the fragment library.
Notes
1. Stellent Content Server manages content items as either primary or alternate files, or both (see
Stellent Content Server Help). These files are unrelated to, and should not be confused with,
primary and secondary pages in Stellent Site Studio.
2. The fragment asset zip file that is checked in as the Primary file above should not be confused
with a fragment library zip file that contains both the fragment assets and the fragment definition
file. The fragment library zip file is what is used with the Designer’s Upload and Download
fragment library utilities and provides a simpler way to manage fragment libraries. You will only
need to manage fragment asset zip files if you are accessing the managed fragment libraries
directly in the content server instead of using the Designer’s fragment management utilities.
The fragment definition file contains the root element <fragments>, which includes one or more
<fragment> elements to define each fragment in the library. The exact syntax of the fragment
definition file is described in “The fragment definition file” on page 19 of the Reference Guide.
To add a fragment library to the content server, you won’t use the standard content server checkin page. Instead, you use the “Upload Fragment Library” feature in Designer. This feature checks
in the managed content items and ensures that a copy of the fragment asset zip file is extracted to
the appropriate run-time weblayout directory (where <stellent> is the name of your Content
Server):
<stellent>\weblayout\fragments
This path can then be referenced by server-side Idoc Script in a fragment by using one of
two Idoc variables:
• HttpFragmentsRoot: This is the full HTTP path to the fragments folder.
• HttpRelativeFragmentsRoot: This is the relative HTTP path to the fragments
folder.
19Page 19 of 30
Fragment Libraries for <CLIENT>
SS_Fragment_<CLIENT>_Navigation - All navigation based fragments
SS_Fragment_<CLIENT>_StaticList – Static List based fragments
SS_Fragment_<CLIENT>_DynamicList – Dynamic List based fragment
SS_Fragment_<CLIENT>_Other -Other fragments
Extensible Elements
No extensible elements are currently required.
Extensible Element Name
Description
<CLIENT> Unique Customizations
Customization Type
Short Names in Breadcrumb
20Page 20 of 30
Description
It is desirable to have the links that display in the
breadcrumb sometimes be shorter versions of the actual
section name – to conserve space on the page. This can be
accomplished by adding a custom section property
(cspBreadcrumbName). This property can be set by the
site designers when creating sections. The Breadcrumb
fragment will be modified to use this name if it is set
rather than the actual section name.
Native Content, Templates, and Dynamic Converter
A significant amount of content from contributors will be provided via Word documents, and
perhaps other formats. These documents will be converted to HTML for viewing on the website;
with the option of the consumer to see a PDF version1 of the document or the original native
document.
The ability to retrieve the other renditions from the web site is fairly straight forward and
involves constructing links to the web viewable and native versions of the documents via the
standard GET_FILE service call. The code to generate these links will need to exist in at least
two places:
1. In the Dynamic Converter template for showing at the top of an HTML page.
2. In the dynamic list fragment(s) that show search results.
One of the guidelines for producing respectable HTML is that the contributors use pre-approved
“templates” to begin with, containing styles that have been carefully crafted in Dynamic
Converter to convert in an expected manner. If the contributors “get creative” with new styles,
or modify styles, the result might be that the converted HTML is not as clean as desired. The
following table defines the templates <CLIENT> IT will provide to contributors:
Template Name
TBD
Description
TBD
The plan is to control, within the Dynamic Converter Templates, the generation of the HTML
fairly strictly. If any styles are encountered that are not defined by the Dynamic Converter
template, they will intentionally be displayed in a color/size that makes it obvious to reviewers.
1
UofM not using PDF Converter
21Page 21 of 30
Publishing
To be written.
22Page 22 of 30
Technical Appendix
Team Building Best Practices
Setting up a Workstation for Site Design
All “Designer” workstations should have Site Studio designer, Site Studio Contributor
application, and Dynamic Converter Template Editor installed. ActiveX and cookies should be
enabled. Designer users should have permissions that allow them read/write/delete access to
Document Types that are “WEB_ASSET” and “WEB_CONTENT” in a particular security
group.
Setting up a Workstation for Contribution
All “Contributor” workstations should have the Site Studio Contributor application, as well as
ActiveX and cookies enabled. Contributors should only have read/write access to Document
Types that are “Web_Content” in a particular security group.
Layout Design
1. Layouts can only be edited by the individual that has it currently open and checked out in
Designer. Layouts should be saved and closed after every update.
2. Layout reuse should be encouraged if at all possible. When creating a layout page three
options are available for design. Create a new page, create page from existing, or use
existing page. Within a layout, it is the contribution region content that is unique. The
Layout (i.e. the “Look and Feel”) should always be shared across individual sites. No
other users should be able to edit a Layout file if it is already opened by another user.
Fragment Creation and Modification
1. Fragment libraries should be created for similar groups of fragment code. For example,
all navigation fragments should be contained within a navigation fragment library.
2. Fragment editing can only be performed by Designers. Since fragments are contained
within a library, that library is checked out when editing a particular fragment contained
within. This disables any other user from being able to edit fragments within that library.
A user who has checked out a fragment library can edit all the fragments contained
within at once.
3. Fragment libraries are usually moved when Site Studio Replicator is utilized. When
uploading and downloading fragment libraries, the user should avoid performing the task
within the Content Server GUI, and instead use the File/Fragment/UploadDownload
function available in the Site Studio designer application. Custom fragments delivered
from Stellent should also be uploaded using this tool.
Contribution
1. Content contribution is a permission controlled environment determined by the Site
Designer. When a user contributes content, they should abide by use cases written
detailing the addition of content to a page.
23Page 23 of 30
2. Contribution regions are XML files contained within the Content Server. When viewing
a page in contribution mode, the XML contribution regions are checked out and opened
within the Contributor application. No other users should be able to edit a contribution
region when it is opened by another user.
Primary and Secondary
Primary pages are usually used as “landing” pages for each section created. Sections can only
contain one primary page. The primary page should be designed so that all links contained
within point to content in other sections/sites/or sub section pages. Primary pages also have the
ability to create links that point to “replaceable” secondary pages.
Secondary pages are layouts with “replaceable” contribution regions. A single section can only
have one secondary page; however, that secondary layout can be used for multiple contribution
regions. A designer should make the distinction of whether or not to allow contributors the
ability to add secondary content. By default, the existence of a secondary page allows a
contributor to add content linked from the primary; however, this can be disabled or limited with
the use of security and Dynamic List Navigation.
Ideally, when designing a site, a user should first identify a landing or “primary” page. If content
in a particular section pertains to that landing page, a secondary should be created to handle links
to section specific content. If content is part of a subsection of the site, a new section should be
created with a new primary page.
Default Metadata fields
Three custom metadata fields, created by the Stellent Site Studio component, are required by the
Stellent Site Studio product:
• xWebsiteObjectType
• xWebsites
• xDontShowInListsForWebsites
xWebsiteObjectType
The xWebsiteObjectType metadata field is used to indicate what type of web site–related item the
managed document is. The field is an option list containing the following values:
• Fragment: The managed document is a fragment library.
• Layout: The managed document is an HCSP layout page.
• Data File: The document file is an XML contributor data file.
• Native Document: The document file is a native document.
• Image: The document file is an image (unused).
• Script: The document file is a script (unused).
24Page 24 of 30
xWebsites
The xWebsites field is used to determine which web site (in the content server) the managed
document belongs to. Internally, it’s a comma-separated list of site identifiers, and the Stellent
Site Studio component overrides the standard content server pages to provide an easier-to-use list
of site names.
When an action is performed within either the Designer or Contributor application that involves
a managed document, the current site identifier is automatically appended to the xWebsites field
for that managed document, if it did not already exist. This means that when you use any
managed document within a site in the Designer or Contributor application -- that managed
document will automatically become part of the site.
It is important to realize that the site identifier will never be automatically removed from this
field once it has been added because it’s currently impossible for Stellent Site Studio to know all
of the places that a managed document might be referenced from. Designers can always use the
regular content server UI to remove a site ID from this field.
Note: This field replaces the xWebsiteID field used in earlier versions of Stellent Site Studio. If
xWebsiteID exists when Stellent Site Studio is installed, the new xWebsites field will be
initialized with the existing values from the xWebsiteID field. The xWebsiteID field will not be
removed and will still behave as it did before in order to maintain backward compatibility with
custom fragments created in earlier versions of Stellent Site Studio.
xDontShowInListsForWebsites
The xDontShowInListsForWebsites field is used to indicate the web sites that this managed
document has been identified with so that it will not show up in dynamic lists on that site. This
field allows the “Include / Exclude in Dynamic List” feature to work properly. See “A note about
including/excluding in dynamic lists” on page 32 for details.
Source View
The best setting is to set the checkbox into that intermediate “checked, but kind of grey” state so
that tidy is still on, indenting is still on, but it uses a smart “auto” mode to ensure <td> contents
are put on a single line . Note that there are still many other situations where a little bit of
whitespace can appear in a <td> preventing split images from butting up close together.
Url Naming and Page Building
1. Avoid named web roots and CGI paths. Instead, use the idoc variables of
<!--$HttpRelativeWebRoot--> and <!--$HttpCgiPath-->. This makes the site much more
portable.
25Page 25 of 30
1. Site Studio can handle other rendering technologies (JSP, ASP, ColdFusion, etc.) through
the use of Connection Server. Code developed in these languages will not be rendered on
the contribution side, but will be on the consumption side.
List of Registry Settings
All Site Studio DESIGNER configuration Registry keys are stored below:
[HKCU\Software\Stellent\Site Studio\SSClient\Config] (v6.5)
[HKCU\Software\Stellent\Site Studio\7.5\Designer\Config] (v7.5)
All Site Studio CONTRIBUTOR configuration Registry keys are stored below:
[HKCU\Software\Stellent\Site Studio\SSContributorClient\Config] (v6.5)
[HKCU\Software\Stellent\Site Studio\7.5\Contributor\Config] (v7.5)
Possible Values:
logfile
maintainstate
SZ
DWORD
logfileinterval
DWORD
tracelevel
DWORD
enableloggermanager
DWORD
disable3rdpartyplugins
DWORD
selectedcolor
SZ
tracesllidcclient
DWORD
26Page 26 of 30
location of logfile
1 to maintain customize state
0 to NOT maintain customize state
how long the logfile manager window
sleeps before checking for a file
change notification (in milliseconds).
0 means DON’T start the worker thread
that automatically updates the logfile
manager window
which TraceMsg() messages should appear
in logfile.
0x0 = none
0x1 = SS_TRACE_DEBUG only
(see SSError.h for more flags)
1 enable logger manager plugin
0 disable logger manager plugin
(default is 0 – the logger manager is
intended to be a debugging or support
tool only)
1 to disable automatic loading of
plugins in the “plugin” folder. 0 to
leave them enabled. (default is 1 for
designer – contributor never enables 3rd
party plugins) – DESIGNER ONLY
html color string (e.g. “#FF0000” or
“red”) that controls the color of the
highlight around the currently selected
element when in design mode for the
layout editor. Note that you can set
this value to “off” to turn off the
selected highlight render behavior.
1 to trace all HDA request/responses
when communicating with the content
workingsite
SZ
autotidy
DWORD
showpagesinsitetree
DWORD
showzeroborder
DWORD
resetstatecounter
DWORD
allowiecontextmenu
DWORD
autoconnect
DWORD
tracelayoutevents
DWORD
startinsourceview
DWORD
disabledesignview
DWORD
27Page 27 of 30
server (through the CSSIdcClientCtrl
class which wraps the IdcClient.ocx
activeX control)
logical site name of the ‘site’ that is
currently (or most recently) connected
to. – DESIGNER ONLY
1 to automatically tidy to XHTML when
switching from design to source mode, 0
to not perform this automatically
(defaults to 1) – DESIGNER ONLY
1 to show separate icons for the
primary and url pages in the site
hierarchy tree, 0 to only show icons
for the nodes in the tree (defaults to
1) – DESIGNER ONLY
1 to show a thin gray border around
borderless elements, 0 to not bother.
counter to be able to force a clean
action on the BCG registry settings.
This counter contains the value from
the currently installed SiteStudio
executable. If a new version is
installed with a higher internal state
counter, then the BCG registry settings
will automatically be cleaned and this
registry setting will be updated to the
new value so it only cleans once.
1 to allow IE to show its own context
menus in the layout design view (and
the layout dynamic preview view) 0 to
suppress the IE menu and let site
studio provide it’s own (0 is the
default) – primarily used for debugging
purposes if we need to view the source
in the design view or dynamic preview
window. – DESIGNER ONLY
1 means autoconnect to most recent web
site on startup, 0 means don’t auto
connect. – DESIGNER ONLY
1 means perform a TraceMsg() for each
significant event that occurs in the
layout design view, 0 means don’t
bother – used for debugging purposes
only! – DESIGNER ONLY
1 means start in source view when
opening a layout file, 0 means start in
design view (the default) – DESIGNER
ONLY
1 means hide the design view tab, 0
means show the design view tab (the
default) - this is useful for people
who want to work ONLY in source mode
and don’t want to risk accidentally
changing something in design view and
have IE change all their formatting. –
DESIGNER ONLY
unknowntags
SZ
Decide how to treat unknown tags during
HTMLTidy actions...



dosilentcheckinonsave
DWORD
“discard” means throw them away
like the default HTMLTidy
behaviour.
“block” means keep them but treat
them as generic block elements
(e.g. DIV)
“inline” means keep them but
treat them as generic inline
elements (e.g. SPAN)
The default value if missing is “block”
– DESIGNER ONLY
0 – means show an ASSIGN DOC INFO form
every time an open layout is saved.
1 (DEFAULT)– means don’t bother, just
check it in immediately with the same
metadata – DESIGNER ONLY
NEW IN 7.5:
language
SZ
xhtml
DWORD
28Page 28 of 30
2 character language code for loading
localized resource libraries
1 – means the HTML Tidy library will
generate XHTML compliant layouts
0 – (DEFAULT) means it will generate
HTML 4.2 compliant layouts. – DESIGNER
ONLY
Additional configuration registry settings for turning on/off GLYPHS are stored below:
[HKCU\Software\Stellent\Site Studio\SSClient\Config\Glyphs] (v6.5)
[HKCU\Software\Stellent\Site Studio\7.5\Designer\Config\Glyphs] (v7.5)
show
DWORD – 1/0 to turn on/off all glyphs
br
DWORD – 1/0 to turn on/off <BR> glyph
comment
DWORD – 1/0 to turn on/off <!-- --> glyph
div
DWORD – 1/0 to turn on/off <div> glyph
form
DWORD – 1/0 to turn on/off <form> glyph
h1
DWORD – 1/0 to turn on/off <h1> glyph
h2
DWORD – 1/0 to turn on/off <h2> glyph
h3
DWORD – 1/0 to turn on/off <h3> glyph
h4
DWORD – 1/0 to turn on/off <h4> glyph
h5
DWORD – 1/0 to turn on/off <h5> glyph
h6
DWORD – 1/0 to turn on/off <h6> glyph
p
DWORD – 1/0 to turn on/off <p> glyph
script
DWORD – 1/0 to turn on/off <script> glyph
span
DWORD – 1/0 to turn on/off <span> glyph
style
DWORD – 1/0 to turn on/off <style> glyph
table
DWORD – 1/0 to turn on/off <table> glyph
anchor
DWORD – 1/0 to turn on/off <anchor> glyph
All Site Studio DESIGNER customization registry keys are stored below:
[HKCU\Software\Stellent\Site Studio\SSClient\Settings] (v6.5)
[HKCU\Software\Stellent\Site Studio\7.5\Designer\Settings] (v7.5)
All Site Studio CONTRIBUTOR customization registry keys are stored below:
[HKCU\Software\Stellent\Site Studio\SSContributorClient\Settings] (v6.5)
[HKCU\Software\Stellent\Site Studio\7.5\Contributor\Settings] (v7.5)
29Page 29 of 30
Issues Log
ID
1
2
3
30Page 30 of 30
Issue
Original
Date
Update
Date
Status