Content Management System Requirements

cameramanfrictionInternet and Web Development

Dec 8, 2013 (3 years and 4 months ago)

60 views

04/18/2006 10:31 AM
Content Management System Requirements
Page 1 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
Content
Management
System
Requirements
The
"Big"
Questions
Should
the
CMS
be:
Our
entire
web
site
-
test,
production,
backout,
etc.,
responsible
for
authoring,
serving,
backup
of
files,
etc.
Our
"test"
web
site
only
-
staff
author
pages
in
the
CMS,
and
then
a
separate
mechanism
(a
modified
self
-
submit
?
)
moves
it
to
production,
serves
it
to
users,
etc.
Presumably,
if
the
CMS
is
only
the
"test"
web
site,
many
of
our
requirements
could
be
dropped
and/or
existing
pieces
can
still
be
used
(Apache
web
server
for
permissions,
self
-
submit
accounts
for
moving
things
to
production,
others
?
)
Is
content
static
or
dynamic
?

In
other
words,
are
pages
built
on the
fly
by the
CMS,
or
generated
at
time
of
need
?

Is
it
safe
to
assume
that if
we
use
the
CMS
only
as
our
test
environment,
we
need
it
to
generate
static
pages
that we
can
move
to
production
?

There
has
been
a
desire
for
snapshots
of
the
web
site
for
archival
periods
-
can
this
be
done
adequately
with
a
totally
dynamic
site
without
relying
on technologies
that may
not
be
around
as
long
as
simple
web
browsers,
etc.
?
The
answers
to
the
above
will
likely
impact
how
editorial
control
works
for
those
managing
the
site.
Other
Things
To
Consider
Don't
give
system
the
responsibility
for
enforcing
rules/don't
proscribe
process
-
offload
to
style
guides/policies
(sometimes
a
person
needs
to
make
a
decision
to
override/do
something
different
-
responsibility
for
such
issues
should
lie with
people,
not
code).
Let
CMS
function
as
a
decision
-
making aid
rather
than
policeman
(presents
user
with
options
of
what
they
can
do with
content;
doesn't
tell
them what
they
must
or
must
not
do, doesn't
let them try
and
fail,
only
show
what's
do-
able).
Should
be
able
to
be
reused/repurposed
without
destroying
original
content;
system
should
support
multiple
levels
of
use.
Should
consider
using
"design
patterns"
rather
than
templates,
possibly
in
conjunction
with
content
genres
(see

http://developer.yahoo.com/ypatterns/index.php
).
Should
support a
more
collaborative
model of
content
creation,
not
an
assembly
line/factory
individual
worker
model (group
access
to
content/functions
for
example).
The
use
of
the
CMS
should
be
in
no way
apparent
to
the
users
of
our
web
site.
Requirements
.
I
Technical
.

A
Must
.

i
Administration
Of
The

System
04/18/2006 10:31 AM
Content Management System Requirements
Page 2 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
.

a
Must

allow

administrators

to

have

access

to

the
"guts"

so

they
could

check

the
system's

work
(i.e.

it

won't

squirrel

away

a
file
uploaded

into

it

where

it

can't

be
found
in

case

you
need

to
troubleshoot
-
direct

access

to

the
directory

structure

or
database

at
a
view

level

at
least;

no
"black

box"

problem).
.

b
Must

be
able

to

be
reliably

backed

up
without

public
system
downtime.
.

c
Hosting
.

1
Must

be
able

to

be
hosted
by
DoIT
/

LTG.
.

2
Must

be
hosted
by
a
provider

with

knowledgeable,
responsive

24x7
support
at
a
reasonable

(to
the
purse-
holders)

cost.
.

d
Must

have

reliable

updates

made

available

in

a
timely
manner

-
For

example,

if
it

was

a
PHP

code

base

and

if
a
new

PHP
exploit
was

announced,

we
need

to

be
able

to

update

PHP
without

breaking

our
CMS

and

conversely

update

the
CMS
code

base

quickly
and

with

minimal
interruption.
.

e
Must

either

have

logging

of
access

of
web

pages

by
end

users,
or
allow

that
logging

by
an

external

web

server.
.

f
Must

work
in

Solaris

environment.
.

ii
Performance
.

a
Must

recover

from
extreme

loads
(Slashdot

effect)

without
administrative

intervention.
.

b
Must

serve

pages

at
a
reasonable

speed

(1-2
s/request)

at
ordinary

(average

weekly

peak)

load

levels.
.

iii
Content
.

a
Must

allow

secure

(SSL)

pages

and

support
secure

(SSL

or
equivalent)

authentication.
.

b
Must

be
able

to

integrate

data

from
other

data

sources

into
content.
.

c
Must

be
able

to

support
and

configure

multiple
mime
types.
The

process

to

add

new

file

types
shouldn't

be
burdensome
04/18/2006 10:31 AM
Content Management System Requirements
Page 3 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
(Example:

Library

"Clips").
.

d
Must

be
secure

-
Web

form
input

must

be
parsed

for

unsafe
and

malicious

code

in

the
event

of
worst
case

security
scenarios.
.

e
Must

create

compliant/valid/accessible

html/css

with

no
proprietary

languages,

extensions,

etc

(can

produce

valid
XHTML,

XHTML
that
we
want
to

use).

The

markup

structures
and

CSS

implementations

that
are

developed

by
the
web
migration

group
must

be
usable

(including

things

like
DC
metadata).
.

f
Must

have

an

API

to

allow

external

queries

and

loading
of
content

by
other

systems.

Examples

include

extracting

data

for
RSS

feeds,

batch

loading
of
new

pages,

etc.
.

g
Must

store
any

data

in

an

open

format,

not

in

a
proprietary
format.
.

h
Must

support
multiple
content

types
with

configurable
management

work
flows
and

display.

Example:

Change
something
once,

and

see

that
change

reflected

everywhere
(email

address

on
a
web

page).
.

i
Must

use
clean

URLs

(/about_us,

not

/page
?id=1298)

-
either
as
a
native

output

or
ability
to

map

query

URLs

to

English
ones.

Should

support
and

enforces

good
naming
schemes
(matching

URL,

navigation

elements,

page

title,

etc).

REST
model.
.

B
Should
.

i
Should

allow

change

logs

for

reporting

all
creation,

deletion,

and
editing
of
pages

by
authors.
.

ii
Should

be
able

to

be
reliably

backed

up
without

administrative
downtime.
.

iii
Should

be
developer
-friendly

(can

be
easily

installed

for

dev

work
in

a
variety

of
platforms

(UNIX

/

OS

X
/

Windows).
.

iv
Should

be
extensible

(we

should

be
able

to

add

functionality
ourselves).
.

v
Should

have

automated

migration

possible

for

most

existing
content.
04/18/2006 10:31 AM
Content Management System Requirements
Page 4 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
.

vi
Should

have

support
for

RSS

/

API

access

(REST/SOAP)

for

data
exchange.
.

vii
Should

use
Apache

as
the
web

server.
.

viii
Should

work
with

version

control

software

or
include

its

own
version
control

software.
.

ix
If

Open

Source
.

a
Should

be
an

active

product

with

the
source

code

available

if
it
is

open

source.
.

b
Should

have

an

active

community.
.

c
Should

have

good
documentation.
.

d
Should

run
on
a
Free/Open

Source

stack

(Linux|BSD

/

Apache
/

MySQL|Firebird|PostgreSQL).
.

x
If

Commercial

Product
.

a
Should

be
an

active

product

produced

by
a
dependable
company.
.

b
Should

have

good
affordable

support.
.

c
Should

have

good
documentation.
.

xi
Should

include

a
website

search.
.

xii
Should

use
(or

can

be
made

to

use)

WebISO

authentication.
.

xiii
Performance
.

a
Should

continue

serving

pages

at
a
reasonable

speed

(2-8
s/request)

under

Slashdot
-like
loads.
.

b
Should

meet

performance

goals
on
existing
hardware.
.

c
Should

serve

pages

at
a
reasonable

speed

(1-2
s/request)

at
very
high

(yearly

peak)

load

levels.
.
II
Management
Of
The
Site
.

A
Must
.

i
Must

allow

access

restrictions

for

viewing

directories/pages

(Supports
multiple
users

with

different

privileges).
04/18/2006 10:31 AM
Content Management System Requirements
Page 5 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
.

ii
Must

be
accessible

from
anywhere,

anytime

(with
WiscVPN

if
nothing
else)

so

page

maintenance

can

be
done
on
emergency

basis
remotely.
.

iii
Must

be
search

engine
-friendly.
.

iv
Must

have

support
for

multiple
designs
(Main

LWS
look

and

feel,
News

pages,

Friends
pages,

UWDCC,

etc.),

and

different
domains/virtual

hosts

should

not

be
required

for

distinctive
designs.
.

v
Must

host

more

than

one
domain/virtual

host

from
the
same

code

base,
with

differences

in

appearance

and

data

(multiple
domains/virtual

hosts
should

not

require

multiple
installations/instances

of
the
CMS).
.

vi
Must

not

force

us

to

use
its

information

architecture

over

ours.
.

vii
Must

work
with

all
the
core

browsers

(IE,

Mozilla,

Firefox,

Opera)
across

Windows,

Mac

and

*nix

computers.
.

B
Should
.

i
Should

allow

some
form
of
editorial

control:
.

a
A
review

stage

(pages

are

flagged

for

review

by
editor)

before
some
pages

are

pushed
into

production.
.

b
Changing
the
status

of
a
page

(pushing
it

into

review
?)
triggers
an

email.
.

ii
Should

enable

and

encourage

an

editorial

workflow.
.

iii
Should

have

ability
to

apply

style
sheets

and

modify
them
at
will

to
pages/content

-
templates

should

be
update
-able/clone
-able

via
style
sheet,

as
with

a
blog

(restrictions

should

be
in

policy,

not

system).
.

iv
Should

have

author

tracking

for

a
single
document.
.

v
Should

have

templates

be
editable

and

modifiable

in

a
manner

that
it
could

be
branded

with

UW-Libraries

look

and

feel.
.

vi
Should

have

versioning

and

author

info
with

time
stamps

for

creation
and

modification

of
content.
.
III
Management
Of
Authors
.

A
Must
.

i
Must

allow

access

restrictions

for

authoring/editing

(Supports

multiple
users

with

different

privileges)

Access

control


Management

of
who
04/18/2006 10:31 AM
Content Management System Requirements
Page 6 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
can

make

changes

to

which

pages

should

be
intuitive
and

easy

to

use
for

both

the
web

manager

and

the
content

authors.
.

ii
Must

handle

nested

accounts/directories.
.

iii
Must

have

assignment
of
roles

by
the
domain/virtual

host
administrator.
.

iv
Must

have

flexibility/granularity

in

assigning

roles.
.

v
Must

not

have

any

limits

in

the
number

of
domains/virtual

hosts,
roles/groups

of
authors,

or
authors.
.

B
Should
.

i
Should

allow

different

views
(of

editing
tools,

links,

??)
based

on
the
author's

roll/privileges.

Author
would
see

pages

recently

edited,

Editor
would
see

tools

for

managing

Authors,

etc.
.

ii
Should

have

activity

logs

for

reporting

all
athor

activity

to
admin/manager

(who
did

what
and

when

for

page

creation,

deletion,
editing,

etc.).
.

iii
Should

have

permissions

be
role
-based

(can

I
do
Y?),

not

rank
-based
(if

I'm

higher

rank

than

X,

I
can

do
Y).
.

iv
Should

support
the
grouping
of
users/authors

for

permissions
assignment.
Role
~

Function

within

the
CMS

(what

you
can

do)
Group
~

Department

or
other

organization

of
staff

(what

part

of
the
site
you
can

do
it)
.
IV
Use
By
Authors
.

A
Must
.

i
Must

allow

managing

of
content

in

a
way

that
is

not

harder

than

with
current

methods.
.

ii
Must

allow

the
use
of
common
interface

pieces

(banner,

footer,
navigation,

etc.).
.

iii
Must

allow

nontechnical/simple

or

html

code

authoring.
.

iv
Must

be
highly

usable

and

not

take

too

many

steps
to

accomplish

a
04/18/2006 10:31 AM
Content Management System Requirements
Page 7 of 7
file:///Volumes/criley/criley/Docs/Content%20Management%20Systems/cmsrequirements.htm#managementofauthors
task;
batching

certain

processes

would
be
ideal.

Examples:
.

i
Take

such
and

such
action

on
this

file,

all
files

I
just

uploaded,
etc.
.

ii
Batch

creation

of
a
new

site.
.

iii
Batch

changes

to

multiple
files.
.

iv
Global
search

and

replace.
.

v
Must

create

backup

pages

and

allow

easy

reversion

to

them
when
needed

(content

changes

should

be
elegantly

undo-able).
.

vi
Must

have

a
significantly

lower

barrier

of
entry

to

use
than

learning
HTML
for

simple
page

editing
tasks.
.

vii
Must

have

a
test/development

area

for

each

account.
.

viii
Must

provide

intuitive
management

of
non-HTML
content

(images,
PDF’s,

movies...).
.

B
Should
.

i
Should

allow

creation

of
syndication/news

feeds.
.

ii
Should

have

ability
to

apply

style
sheets

and

modify
them
at
will

to
pages/content

-
templates

should

be
update
-able/clone
-able

via
style
sheet,

as
with

a
blog

(restrictions

should

be
in

policy,

not

system).
"Mobility

Of
CSS."
.

iii
Should

have

document

validation

that
is

optional

a
system

that
checks

for

valid
markup

when

authors

do
create

their

own
html,

with
feedback

when

there

are

problems.
.

iv
Should

have

versioning

and

author

info
with

time
stamps

for

creation,
modification

of
content

when

the
end

user

is

viewing

in

the
browser.