CommonSpot at CornellTechnical Service Providers Forum

March 16, 2005

Agenda:

I. Background and history of CommonSpot purchase (Paul Davis 15 min)

II. CIT’s service offerings for CommonSpot (Nathan Reimer 20 min)-Development-Hosting-Instruction and Training

III. CommonSpot’s features, benefits, and known issues (David DeMello 20 min)

IV. CommonSpot SIG (David DeMello 10 min)

V. Role of Office of Web Communications and its relation to CMS strategy, department efforts, cornell.edu, and the WPG (Diane Kubarek 20 mins)

I: Background and History of CMS Decision

Collaborative Stakeholder Driven Selection Process

• Engineering included CIT in their CMS RFP process (Late Fall ’03)

• Thomas Richardson advocated that CIT spearhead CMS purchase (3/04)

• Thought was “to do something quickly” (3/04)

• RFP development and evaluation (5/6) included broad representation

• AA&D, Engineering, Library, Vet School, Registrar, and Web Communications. Later ILR (and others?) joined us.

• “More non-CIT people, than CIT people” in selection meetings

•Selected three vendors for further consideration

I: Background and History of CMS Decision (cont.)

Vignette

• Very high end tool – Works best at enterprise scale

• Great hooks into enterprise systems (People Soft, WSDL, existing web aps)

•Their complete suit “did everything” but overlapped with existing IT infrastructure. Had to use their delivery mechanism.

• Presentation was for a solution that was much more expensive than what they had bid

• We could make the parts we wanted work with “a little bit of programming”

• Most expensive option, both in purchase price, development, maintenance, and server requirements. We could only afford one server for the campus

I: Background and History of CMS Decision (cont.)

Rhythmyx

• Mature Mid-market product

• Focused on integrating data inputs and outputs• Inputs could be word docs, databases, WYSIWUG editor, etc. • Outputs are always static files or database record sets

• Works with any web delivery technology (CF, php, JSP, .NET, XSLT, etc.)

• Web editor’s user interface was weak and not well connected with web presence

• Too expensive to site license, CIT would have to run the single installation

I: Background and History of CMS Decision (cont.)

CommonSpot

• Lower mid-market product (or upper low market product)

• Fully integrated web content manager. • WYSIWYG editor, template management, and web delivery are all in one package.• Not as strong for delivering content to print or other formats (but it can be done).

• Integrates easily into CU Kerberos and Cold Fusion infrastructure

• Targeted at Department level web sites – Very close to our stakeholders needs

• Least expensive option – Site license available

I: Background and History of CMS Decision (cont.)

Stakeholders Selected CommonSpot (8/04, purchased 12/04)

• Good fit with stakeholders business needs

• Ability to be independent of CIT (or host with CIT if we choose)

• Unanimous vote from stakeholders

• Plan was for WPG to purchase single license and host centrally until there was enough interest to purchase site licenses

• David DeMello drove effort to get site license

• Site license purchased (late 12/04)

I: Background and History of CMS Decision (cont.)

Collaborative Stakeholder Process

• People outside of CIT identified a common need and worked with CIT to find an optimal solution for the campus

• Stakeholder group provided the direction

• CIT provided the implementation

• Everybody ended up happy with the results

• This SIG is an effort to institutionalize a stakeholder driven process for coordination and governance of the CommonSpot site license

• IMHO: This process should be replicated with many of CIT’s projects

II: CIT’s service offerings for CommonSpot

• CommonSpot Service Owner – Nathan Reimer• Supporting user groups, SIG, and vendor

•Development• IWS – Instructional & Web Services

• Hosting• Unix server farm

• Instruction and Training•Stakeholder group provided the direction• On-Site with vendor• CIT training

• Modularized and audience-specific• Train-the-trainer• Customizable

• User groups, website, shared materials

III: CommonSpot’s features and benefits

• Empowered content owners

• Supports different skill sets

• Browser-based administration, design, and editing

• Control over look and feel with free access to content

III: CommonSpot’s features and benefits (cont.)

• Distributed administration and granular security

• Workflow and approval

• Scheduled content publication and expiration

• Versioning

III: CommonSpot’s features and benefits (cont.)

• Manageable metadata

• Link management

• Extensible

• Content subscription and syndication support

III: CommonSpot’s features and benefits

• Empowered content owners• Supports different skill sets• Browser-based administration, design, and contibution • Control over look and feel with free access to content• Distributed administration and granular security• Workflow and approval • Scheduled content publication and expiration• Versioning• Manageable metadata• Link management• Extensible• Content subscription and syndication support

III: Issues

• Fully standards-compliant XHTML/CSS output is not here yet• No silver bullet – we still need systems for some types of content (events, directory, courses of study, etc.)• Sharing content across servers needs work• Education and culture shift is needed • Customization APIs are very basic – Cornell should define some frameworks and best practices to avoid sprawl.• ColdFusion license required. Also MSSQL or Oracle

IV: CommonSpot SIG

• Formed to manage research and decision making around initial implementation issues and long-term goals of campus-wide collaboration on content management projects.

•Representation drawn mainly from units with plans to implement CommonSpot in the next six months.

• Three subcommittees• SIG Governance• Training strategies• Best practices

V: Role of Office of Web Communications and its relation to:

• CMS strategy

• Department efforts

• www.cornell.edu

• The WPG