Designing Content Types

1
Designing Content Types
2
The Idea of a Content Model

• A content model defines what your content is
• A content model is designed to account for the
  specific uses of the content it models and is
  built to evolve as the content in the system
  evolves
• Content model and data model
• A data model defines how you will store your
  content in a DB or XML
• During logical design ? content model
• During physical design ? data model
• During implementation ? create and store content

3
Much of a content model becomes the data model
for the content repository
4
Parts of a Content Model

• Content domain the overall universe of content
  that you have decided to manage
• Access structure how you want the content to be
  organized
• Hierarchies, indexes, cross-references, and
  sequences
• Content types major categories of content within
  the overall domain that you have specified
• Service describe one service that your
  organization offers
• Elements major information constituents of a
  content type
• Title, service type (consulting, technical
  report), service description
• Element types and allowed values what
  information is allowed to go into each element

5
What Are Components
6
Overview

• To make information useful (or re-useful), you
  must divide it into discrete chunks, called
  content component
• Each content component belongs to one content
  type
• Synonyms of component
• Chunk, content object, reusable information
  object (RIO), content item, element, block

7
Components are like objects

• Object-oriented programming
• Encapsulation ? content worker learns how to work
  with the component, not with the information
  within the component
• Reuse ? content components are small, reusable
  pieces of content that you can link together to
  achieve larger results
• Class/instance ? content type / content component

8
The basic unit of CM

• Components divide your information into
  convenient and manageable chunks.
• You create content components to establish a set
  of content objects that you can create, maintain,
  and distribute.
• Each component travels through your CMS as a
  unit
• Whenever you create new content
• Whenever you move existing content into your
  system
• Whenever you store content
• Whenever you archive or delete content
• Whenever you create a publication page
• Whenever you gather statistics

9
Components are the basic chunks that you move
around in a CMS
10
Component VS Pages

• A Web site consists of a set of linked pages that
  all contain unique content.
• Pages come in types (home pages, product pages,
  article pages)
• Pages are a natural candidate for the title given
  to components as "the basic unit of management."
  in the Web world
• Page is an entirely inadequate
• The content on a page and its design change
  separately
• Pages share content
• Pages creation often occurs automatically
• Web pages aren't all that you need to create

11
Component VS Pages (Cont.)

• A component is much better
• You can separate it from design
• It's the unit of content that you share among
  pages
• It's an essential part of any automated
  page-creation system
• You can use it to create any sort of output, not
  just a Web page
• From a CMS and component-centric view, a Web site
  is a particular kind of publication

12
Content Has Types and Components

• A content type is a model, a template, and a set
  of rules about how to create a component of a
  particular kind
• The type establishes the definition of a
  component of a certain type
• A content type includes the name of the type, the
  elements that it consists of, and any rules that
  you want to establish about how to create such
  components.
• This component is called Farewell. It has a
  unique ID (F and an integer), followed by a name
  (last, first, middle), message (fewer than 256
  characters) and a reference to an existing image,
  if available (relative path and file name)
• Types are rules, whereas components are
  rule-based content

13
Content Has Types and Components (Cont.)
Content Type
Content Component
14
Content Types Have Elements

• In a content system, the element is the smallest
  unit of named locatable content
• A product content type may consist of the
  following elements
• A product id code
• A name
• A price
• A description
• A picture
• Elements either contain the information that you
  want to use, or they help you find a component
  that you want

15
Elements Types, Values, and Identification

• Element categorization (not mutually exclusive)
• Body element
• Contain the content that you actually display in
  publications
• Abstract, contact name
• You create such an element because you want the
  option to use that part of the component apart
  from the rest.
• Management element
• To manage the component
• Create date, status
• Metadata
• Each component needs a name for individual
  (unique) identification and use

16
Locality in Components

• Most of what you must localize in a CMS is its
  components
• Three possible localization sites within a
  component
• Body elements
• Management elements
• Whole components
• Methods to localize content components
• Element variants (the best way) ltAbstract
  localityTaiwangt
• Local elements ltAbstract_Taiwangt, ltAbstract_USgt
• Local components (the easiest way) Article_TW,
  Article_US

17
What Do Components Look Like?
18
Components in Flat Files
19
Components in Structured File
20
Components in Databases
RDBMS
OODB
21
The Relationship between Functionality and
Components
22
Overview

• Content is information and functionality
• A functionality content component has a type,
  body elements, and management elements
• Purpose of published functionality
• Connection to other system, like a catalog, a
  transaction
• Advanced navigation, like fly-out menus in
  Javascript
• Communication, like feedback or order form
• Advantages of functionality contents components
• Reuse, reconfiguration, version control, access
  control, workflow

23
PLAN Example

• PLAN wants to develop and present functionality
  for subscribing to press releases
• Core code ShowSubscription(user, style, format)

The subscription functionalityon the PLAN home
page
The subscription functionalityon the
subscription page
Run ShowSubscription(user,"Table","HTML")
24
Code for the Subscriptions Page
ltTABLEgt   ltTRgtltTDgt           ?Run
ShowSubscription(user,"Table","HTML") 
 lt/TDgtltTDgt            ltFORM ACTION"subscribe.jsp
" method"get"gt            ltUgtSubscribe me
tolt/Ugt                   ltBRgt                
  ltSelect name"new"gt                         
   ?Run ShowSubscription(user,"NewList","HTML") 
                 lt/Selectgt                
  ltPgt            ltUgtDelete me fromlt/Ugt       
           ltBRgt                   ltSELECT
name"delete"gt                           ?Run
ShowSubscription(user,"DelList","HTML")       
           lt/SELECTgt                   lt/Input
type"submit" value"Submit My Request"gt       
    lt/FORMgt   lt/TDgtlt/TRgtlt/TABLEgt
25
PLAN Example (Cont.)

• To aid the management of the preceding code and
  its placement on the various pages, PLAN can
  create a functionality component that has the
  following elements
• Management elements The component can have such
  elements for the owner of the functionality, the
  contact person for the subscriptions database,
  the date of the last change, and so on.
• Body elements The component can have three body
  elements. One element can hold the code that goes
  on the home page and another can hold the longer
  chunk that goes on the subscription page. A final
  element can hold the binary programming object
  for the subscription feature.

26
PLAN Example (Cont.)

• Advantages
• Collection safely store and track the chunks of
  HTML programming code as well as the binary code
  in the subscription object
• Management enter the code in any workflows that
  it may need for review or other administration
• Publishing Best of all, PLAN can push just the
  right code segment to the right page at the right
  time from its component. The subscription object
  itself can deploy from the component to a Web
  site as part of the publishing of the site

27
PLAN Example (Cont.)
A print template for the subscribe functionality
Two more elements PrintExistSubs Run
ShowSubscription(user,"Table","Print")
PrintNewSubs Run ShowSubscription(user,"NewLis
t","Print")
28
Functionality Content Types and Components

• One component per type
• PLAN assumes that the subscription component is
  one of a kind.
• The subscription component type contains only one
  component.
• The easiest and most flexible way to create
  functionality components
• If you have lots of different functionality, it
  produces a large number of component classes.
• A few general types
• Create one or a few generic functionality types.
• Ex. Four generic code elements (with names such
  as Code1, Code2, Code3 and Code4), one element
  that you call Binary (to hold any binary
  objects), and an element that you call Type
  (where you can say what kind of functionality it
  is).
• simplify type management
• Must squeeze your functionality components into
  standard forms that may or may not give you the
  best results

29
Functionality Content Types and Components (Cont.)

• Types with multiple components
• Some functionality components may fit the usual
  model of one type with multiple instances
• PLAN may create a feedback functionality
  component type
• Throughout its publications, it may use 20
  different forms of the feedback functionality,
  each with its own feedback component

30
Analyzing Content Types
31
Think

• The idea of components Do you understand the
  concept of content components? Can the use of
  components ease what you perceive as the main
  bottlenecks to your processing of content for
  publications? If not, reconsider why you need a
  content management system.
• The use of components Can you picture how an
  automated system may go about combining
  components into publications?
• Publications Can you see your publications as
  simply the correct delivery of your components?
• Storage format Can you standardize on a tool
  that produces the format that you want to store
  components in? How much work is converting the
  output of the authoring tools to the format that
  you want to store?

32
Plan A competitive content analysis

• Create a set of best practice content types based
  on an analysis of your Web site and those of your
  peers or competitors (about 5 to 10 sites)
• Review those sites in detail, noting what sorts
  of content they contain
• Prepare a list of the relevant and good content
  types on each site
• Compare the content types across the sites and
  choose a set of best examples
• Settle on a name for each of the content types
  you choose and use them to jumpstart your own
  content type analysis

33
Plan Dividing Information into Content Types
A method for going from business goals and
requirements to a fist list of content types
34
Plan Dividing Information into Content Types
(Cont.)

• Brainstorm from your goals to a set of content
  types
• Try to fill in the table without referring to the
  specific requirements you received for what
  content to include
• You want to make an independent analysis based on
  goals alone
• Compare it to the requirements that you received
• If all goes well, the required content fits
  cleanly into the table

35
Plan Dividing Information into Content Types
(Cont.)

• Organize your content into a hierarchy, where
  each goal is a level-one heading and you organize
  content types in priority order below those
  headings.

36
Plan Identification

• Name your types and assign them a unique ID
• Review each type and ask yourself the following
  questions
• Information types Do I have various instances of
  this type of information? Can I get each instance
  into the same basic structure? Do I need to
  create, administer, and distribute instances of
  this information separately from each other? If
  the answer is "yes" to all these questions, the
  content type is a clear candidate for a content
  type.
• Functionality types Do I need to show this
  functionality on more than one type of page? Does
  it take more than one form in my user interface?
  Do I need to track changes to the functionality
  over time and apply version or access control to
  it?
• If the answer to any of these questions is "yes,"
  the functionality is a candidate for a content
  type.
• If the answer is "no" to all of them, you're
  probably better off hard-coding the functionality
  directly into the template that it's to live in.

37
Plan Identification (Cont.)

• For all the content types that make the component
  class cut, fill in the following design
  constraints

Content type
38
Plan Creation

• For each type that you propose, determine an
  approach to the following design constraints

39
Plan Creation (Cont.)
40
Plan Life Cycle

• To provide input to your staffing and workflow
  calculation

41
Plan Elements

• For each content type that you expect to have,
  decide on an approach to the following design
  constraints
• Complete a copy of the following table for each
  type

42
Plan Elements (Cont.)

• With all your component types charted
  independently, pivot the analysis and list all
  elements regardless of the component they're part
  of

(IDs of the content typesthat include this
element)
43
Plan Elements (Cont.)

• Review body elements across all components. Why
  one component has certain elements that others
  don't? Make sure that elements that have the same
  function receive the same name.
• Review the management elements across all
  components. Are the elements consistently named?
  Do you have any duplicates with the same function
  but different names? Is each element that you
  specify really necessary?
• Do you have a set of elements that you track
  across all components? If not, why not?
• Generally, you should end up with some small set
  of management elements that are common to all
  classes. This set of global management elements
  helps you categorize all components. Elements
  such as Title, Author, and Create Date are
  candidates for global management. (All content
  types have an ID element.)

44
Plan Localization

• Add columns onto your second element table to
  describe the localization that you plan for each
  element

45
Tasks

• The creation cycle for each type
• Ongoing metatorial reviews
• Ongoing editorial reviews
• Cycles for including each type in publications
• Retirement cycles
• New component-type design cycles

46
Integrate

• Growth Do you expect the number of components in
  your repository to reach a stable level or to
  continue to grow indefinitely? If you expect the
  number to stabilize, verify your assumptions and
  make sure that the rate at which you expect to
  create components matches your expectations about
  the rate of archiving or deleting components. If
  you expect the number to grow, take this fact
  into account in every further decision you make.
  What you're saying is that, eventually, you're
  going to maintain and publish an enormous amount
  of content. Can the processes and structures that
  you're creating scale to meet ever-increasing
  needs?
• Sponsors Do your sponsors understand this
  content model? Are they likely to support the
  effort that creating and enforcing it takes?

47
Integrate (Cont.)

• Audiences Are your audiences likely to agree
  with the way that you rank content? Does your
  audience expect to see types of content that
  you're not covering? If so, why aren't you
  covering those types? Is your top-ranking
  audience the most well-served by this content? If
  not, why not? What are your audiences' other
  sources for these types of content?
• Publications Can this content set really provide
  enough content to fill up the publications that
  you intend to create? If not, what content types
  do you need to add? Examine your assumptions for
  the authorship, structure, and format of your
  publications. Are these assumptions consistent
  with the content types that you came up with? If
  not, how can you reset assumptions or change your
  publications to meet the assumptions? Does this
  content suggest a need for publications that
  you're not creating?

48
Integrate (Cont.)

• Types How many total component types do you
  have? The more types of components that you have,
  the more work setting up a management system for
  them becomes. On the other hand, the more types
  that you have, the more flexible is your system.
  Does your gut tell you that this number is a lot,
  a little, or about right?
• Localization Review your element localization
  table. Do you have the budget to accomplish this
  much localization? On the other hand, are you
  doing enough to solidly meet the needs of your
  key localities?