A Pan-IRIS Content Management System

A Pan-IRIS Content Management System (CMS)

Index

·  Introduction

·  Background

·  Evaluation of image management systems

·  Evaluation of document management systems

·  Examples of simple CMS for IRIS

·  Suggested structure for image management

·  Suggested structure for document management

·  Tutorial on Gallery

·  Tutorial on KnowledgeTree

Introduction

This document is both a guide and tutorial in the use of Content Management Systems (CMS). The first sections relate to the needs, requirements and philosophies of a CMS. Readers may wish to skip to the evaluation of several CMS or to the tutorial on image and document management systems installed at IRIS. It is intended that this document will assist in the selection, configuration, and act as a preliminary users guide for the CMS selected for IRIS. The goal is to have a large number of IRIS staff proficient in the use of a CMS, and be responsible for populating the system, rather than having a single person responsible for CMS population and management for the whole of IRIS.

IRIS should implement and populate it’s CMS quickly. It is suggested that a subcommittee be formed to carefully review and revise this document, identify and install a structure for the chosen system(s), establish group and user privileges, and conduct staff training course in the management of the system. A suggested schedule is:

·  Form subcommittee, evaluate software, develop internal database structure by 8/19/05

·  Install CMS with approved structure by 9/2/05

·  Establish and implement group and user permissions by 9/9/05

·  Conduct staff training course by 9/14/05.

Subcommittee should consist of Simpson, Ingate, Woolley, Willemann, Shin, PMs, Mallett, Levy or alternates they identify.

Background

A Content Management System (CMS) is mandated for IRIS operating the USArray component of EarthScope:

Both the Program Officer and the Awardee are responsible for ensuring that there is a document management system in place that provides for retention of essential and significant documentation related to the project. To the extent possible, project documentation should make maximal use of electronic processes; however, some paper records are also necessary. Of particular importance is the maintaining of good records of project reporting, cost and schedule performance, project scope and changes thereto by written change orders and approvals. Lists of issues, action items, and their resolution must be maintained.

NSF Facilities Management & Oversight Guide (7/31/03), page 18.

Such a system serves as a central repository and distribution node for key documents pertaining to USArray construction and operations. In addition to the examples given above, a CMS for IRIS could manage images and narratives of station installations, all RFPs, responses to RFPs, evaluation criteria of proposals/quotes, all presentations and style-sheets, meeting minutes, hardware drawings, manuals, training materials, etc.

The goal is not only to electronically archive these materials, but also to make such documents readily available for contemporaneous sharing among stake-holders. As such, it makes sense to extend the use of a USArray-centric CMS to pan-IRIS activities.

Selecting an enterprise-wide CMS is a critical activity, to ensure that it would meet all current and projected needs. Assumptions made in this paper include:

·  CMS will be managed on both the intranet and internet IRIS HQ website;

·  CMS will be enterprise-wide;

·  CMS will be open-source;

·  CMS will be managed by IRIS staff and friends of IRIS, but high-level administration will have a single POC;

·  CMS is both image and document management systems, but may be separate software entities.

Note that any CMS system installed is going to increase the level of technical support required and demand expanded skills from the system maintainers.

Requirements for a CMS can be grouped as follows:

·  Content creation – this includes the functionality required by authors of content;

·  Content management – central repository supported by a range of tools for manipulating and managing content;

·  Publishing – implementation and look and feel of the CMS;

·  Presentation – published documents must meet certain standards if they are of use to users;

Factors for consideration within these groups could be:

·  Content Creation – the functionality required by authors;

  1. Integrated authoring environment – CMS must provide a seamless and powerful environment for authors.
  2. Separation of content and presentation – authoring must be style-based, i.e., CMS must support all file formats.
  3. Multi-user authoring – similar to software RCS, enabling check-in/check-out of files and file locking.
  4. Single-sourcing (content re-use) – must enable reuse of material in different contexts.
  5. Metadata creation (includes keyword indexes, search ability, etc) – includes author, subject, keywords, and higher order items such as subject taxonomies and topic maps.
  6. Ability to link between pages – cross-linking between pages/documents must be able to survive restructuring.
  7. Non-technical authoring – no software experience required other than the ability to surf the web.
  8. Ease of use & efficiency – KISS. A CMS is only good if it is used.

·  Content management – a centralized repository, supported by tools for manipulating and managing content;

  1. Version control & archiving – important for legal accountability, backup and disaster recovery.
  2. Decentralized content creation relies heavily on workflow models – content is not created within the CMS, but “off-site”, and must be resilient to organizational change.
  3. Security – must exist to protect integrity of content and includes audit trails.
  4. Integration with external systems – CMS is only one of many systems used to present information on a website, and so should integrate with existing systems (e.g., DMC, Arc-IMS) on the intranet.
  5. Reporting for users and administrators – includes usage statistics, and should pro-actively report issues as they arise.

·  Publishing – the publishing engine takes the content stored in the repository, and generates the final pages, i.e., the GUI interface into the CMS;

  1. Flexible style-sheets and page templates – style-sheets can be built to provide IRIS identity within the GUI.
  2. Support for multiple formats (HTML, PDF, Word, etc) – style sheets may be of a variety of formats (e.g., HTML, PDF, etc).
  3. Usage statistics - should report on most popular pages, daily usage, and include a search engine.

·  Presentation – the look and feel of the GUI;

  1. Usability – covers ease of use, learnability and efficiency.
  2. Accessibility – must conform to W3C (i.e., standard web interface).
  3. Cross browser support – must be viewable by the major browsers (Safari, Explorer, FireFox, Netscape, Opera, etc).
  4. Limited client-side functionality – use client-side technologies such as Java, etc.
  5. Speed this is important in the design stage, so as limit page sizes to ensure load times are acceptable to users.
  6. Effective navigation – users must be presented with a consistent, comprehensive and usable navigation aids.
  7. Metadata - must be provided to allow effective indexing and searching. Should conform to standards such as Dublin Core.

Evaluation of Image Management Systems

The following image management systems can be evaluated for free at http://www.opensourceCMS.com. All systems have a web-based user interface.

·  Gallery

o  Does not support .pdf, .tiff or .eps files. Supported file types are jpg, jpeg, gif, png, avi, mpg, mpeg, wmv, mov, swf and mp4.

·  CopperMine

o  Non-intuitive interface

o  Few categories for metadata

o  Safari not completely supported?

·  LinPHA

o  Non-intuitive interface

·  Singapore

o  Still in beta

o  Nice to use, nice simple interface (easier than Gallery)

o  Metadata not configurable

o  Had problems with bulk uploading

·  SPGM

o  Does not appear to be configurable

o  Too simple

o  No admin (ergo sum, no users/permissions?)

·  Yapp-ng

o  Image captions only, no metadata

o  No search facility

o 

Evaluation of Document Management Systems

http://www.opensourceCMS.com has only one document system available for evaluation, KnowledgeTree.

Other systems are actually portals, and include (among others) Zope (http://www.zope.org/), Bricolage (http://www.bricolage.cc/), Movable Type (http://www.sixapart.com/movabletype/), and Drupal (http://drupal.org). These systems do provide for links between documents and images. However, it is unlikely that any of these systems could be maintained casually, or even allow non-experienced users to make even minor alterations. Often, these systems are hosted by off-site vendors with monthly subscription rates. Offsite hosting and maintenance invokes other technical issues such as backups. As such, these systems have received no direct evaluation, and are considered overkill for IRIS.

Examples of simple CMS for IRIS

Gallery (http://gallery.menalto.com/) is a web-based image management system. KnowledgeTree (http://kt-dms.sourceforge.net/) is a web-based document management system. Both have been installed on the IRIS HQ web server and a tutorial on their use can be found near the end of this document.

Gallery has many customization capabilities. It can be operated "under" a portal (such as Mambo (http:// www.mamboserver.com) and will "pick up" the style(s) mandated by the supervising software. PBO uses Gallery for image management. PBO uses KnowledgeTree for document management. Both Gallery and KowledgeTree are Open-Source systems, and are built on PHP4 and mySQL, also Open-Source systems.

Gallery and KnowledgeTree are two separate systems, and do not satisfy the requirements of being able to link documents with images, and other criteria listed above for ideal CMS. This may be important, e.g., in the 5-year plan construction whereby some (or all) 1-pagers may have a text document and a hi-res image that is not embedded in the text document. Users may select to archive both documents and images under KnowledgeTree, but KnowledgeTree does not provide a thumbnail viewing capability, whereas Gallery does enable users to quickly scan the image archives. However, both KnowledgeTree and Gallery are relatively simple to install and maintain and do not require one or more FTE for administration as do the more complex and fully-featured systems.

Suggested Structure for Image Management

The following proposes a directory-like structure for management of images. Directories can host nested sub-directories. The structure can be simpler or much more complex. Such a structure encourages exploration, which may in turn yield other entries to the user, which is a useful alternative to keyword search. IRIS must decide upon the best way to categorize its image gallery.

·  IRIS

o  Staff

o  People and meetings

o  DMS

§  Waveforms

§  Equipment

o  E&O

§  People and classes

o  GSN

§  Stations

§  Equipment

o  PASSCAL

§  Experiments

§  Equipment

§  PIC

·  USArray

o  Backbone

o  Transportable Array

§  Equipment

§  Sites

·  Y04C

·  A03C

·  ……

o  Flex Array

§  Experiments

·  Parkfield Guided Waves

·  …..

§  Equipment

o  MT

·  Science

o  Sumatran Event images

o  Earth structure

o  ….

Suggested Structure for Documentation Management

The following proposes a directory-like structure for management of documents. Directories can host nested sub-directories. The structure can be simpler or much more complex. Such a structure encourages exploration, which may in turn yield other entries to the user, which is a useful alternative to keyword search. IRIS must decide upon the best way to categorize its documentation.

·  Meetings

·  Committees

o  BoD

o  CoCom

o  Standing Committees

·  DMS

·  E&O

·  GSN

·  PASSCAL

o  Instrumentation

o  Other

·  IRIS Workshop

o  Posters and Presentations

·  IRIS Proposals

·  Subawards

o  RFP

o  Proposals

·  Procurements

o  RFQ

o  Quotes

·  Governance

·  USArray

·  IRIS Proposals

·  Subawards

o  RFP

o  Proposals

·  Procurements

o  RFQ

o  Quotes

o  Responses

o  Evaluations

·  MOU

·  Change control

·  Monthly reports

IRIS should nominate a sub-committee to suggest categories. When this has been completed, the current structure will be removed and the new structure implemented.

Tutorial on Gallery at IRIS

Gallery has been installed at http://www.iris.iris.edu/gallery/. Supported file types are jpg, jpeg, gif, png, avi, mpg, mpeg, wmv, mov, swf and mp4.

Staff are encouraged to look at this implementation, upload files, delete files, etc.

A number of users have been created:

·  login/pass: guest/guest (for read-only privileges)

·  login/pass: worker/bee (for read-write privileges)

Each image in the tutorial has the following metadata associated with it:

·  Caption (this is the name of the image file)

·  Description (a brief description of the image)

·  Photographer (authorship)

·  Date (date image was generated)

·  Location (where the image was generated)

·  Program Affiliation (e.g., GSN, DMS, PASSCAL, TA, FA, etc)

·  Keywords (for search engine, though all text in metadata categories are searched)

·  Photo capture date (date and time photo was uploaded)

Searching is on all text in the metadata.

These metadata categories are examples for the purpose of the tutorial only, and must be established when Gallery is finally configured. Adding additional categories after Gallery has been set-up and populated is an arduous task, and should be avoided. Considerable thought is required when establishing these categories. In the current tutorial, there may be too many categories, or too few. IRIS should nominate a sub-committee to suggest categories that provide adequate information, yet are not overly onerous to fill.

Gallery has the ability to import (captions, descriptions, etc) from external formats. Importing is currently only available at upload time. Form and URL uploads are supported. Image and metadata files can be bulk uploaded as .zip files. In the current implementation, the metadata files can be uploaded as csv files, a text file with semicolon-separated fields. The first line (or row) defines each column. A column of "File Name" or "Filename" must exist, this field name is not case sensitive. All other field names are case sensitive. The remainder of the fields will be used to populate the custom fields. If the custom fields are not set, then they will be ignored. If no caption field is specified, the first of the following non-empty fields will be used. E.g, in the current implementation, the csv text file containing metadata for image files named cisnlogo.jpg, IRIS_20thLogo.jpg, IRIS_Logo2C.jpg and USGS.jpg would look like:

Filename;Caption;Description;Photographer;Date;Location;Program Affiliation;Keywords;

cisnlogo.jpg;CISN Logo;Cal. Integ. Seism. Network;Shane Ingate;Jul 12 2005;Washington, DC;;Logo;

IRIS_20thLogo.jpg;IRIS Logo;20th Anniversary logo;Shane Ingate;Jul 12 2005;Washington, DC;;Logo;