I have repeated, many times throughout this tutorial, that it is easier to produce web pages in the CMS (aka Plone) than it is to write your own HTML and plunk it into the Museum's web server. This is a bit of a misleading statement. Working with the CMS is certainly different than writing your own web pages from scratch — if you're used to writing web pages using HTML or a WYSIWYG editor, then you'll probably find the CMS to be a bit stifling. In fact, if you have written your own web pages using HTML and are considering whether to to integrate them into the Museum's server or into the Division CMS, then you will find it much easier to just upload your existing HTML and other files to the Museum's server. Also, if you develop a bunch of pages in the CMS and then move to a different institution, it will be problematic to move your web pages there unless they, too, are using Plone[1]. Nonethless, I still contend that it is easier to deliver your content, in the form of a web page, using the CMS.[2] To understand why I maintain this opinion, you need first to understand the goals of the system.

There were two primary drivers for moving to a system like the Division CMS:

1. A desire to have a consistent look to the Division web pages (and, ultimately, all of the Museum's research pages).
2. A need to make it possible for researchers to keep information about their research up to date as easily as possible. (I mean really make it so much easier that there are no excuses not to do it and no reason to try and get someone else to do it. Big hint here =;-)

Consistent "Look and Feel"

A cursory glance at the research pages at the Museum shows a different style for every departmental site, even among those departments within a division (such as EPS and Astrophysics) — even the top-level AMNH Research page has a different layout and style. Not only is the "look and feel" of each page different, but so is the available navigation within each site. This can be confusing for a visitor to our web sites (including prospective grad students, post-docs, and interns).

A few years ago, the Museum (through the MIF) realized this and contracted a web developer to create templates of pages which could be used to standardize the look of the Research pages. Aesthetically, they left a bit to be desired but otherwise were great:

• they were cleanly organized so that it was easy to find information on each page.
• they were written with standard HTML and CSS (cascading style sheets) so that they looked the same in most web browsers (even IE, which is notoriously broken in both respects). This is no easy feat.

Here they are:

• The generic Departmental page
• A generic article/exhibit page
• A generic staff page

Unfortunately, for all their merits, the templates weren't very practical to actually use. Here's why:

• The template files are plain HTML files. In order to change the information in the generic templates, the HTML had to be editted: it is too easy to break some of the underlying HTML "code" in a visual HTML editor such as Netscape Composer. This made the templates impractical for a lot of people.
• Although there were boxes on each page for navigation, the actual links for navigation had to be maintained by hand. Too easy to mess up, and too tedious for a lot of people.

The only way to fix these problems was to use a suite of software that allowed for the use of true templates, in which the layout information could not be inadvertently broken, and that maintained internal links for navigation. Ideally, the software should accept some simple input (such as an existing HTML page) from a user, put the text into the template, and update all navigational links.

Simple, no?

There were a number of packages that would do these things, both proprietary and open-source: I ended up choosing Plone.[3] As described elsewhere in this tutorial, Plone allows you to input the information you want displayed in the template five different ways: an embarrassment of versatility. With a little modification (Plone is open-source, and freely available, so I could make the changes I wanted) Plone could easily satisfy the "Look and Feel" requirement.

Ease of use

One reason the Division web pages weren't being updated is that doing so is a pain. For personal pages, you need to write the pages locally, upload them to the server, check that they look correct on the staging server, then fix any problems; for departmental pages, you need to find the person who had the account name and password and get them to do all of this. Also, actually doing the work of updating web pages is tedious.

An added bonus to making the system easier to use, and removing the tedium of updating and maintaining links, is that researchers can concentrate on the content they put in their pages. By removing the initial inhibition of creating and updating pages, the public web presence of our research will be increased.

Creating a web page for a project, exhibit, or publication in Plone is extremely simple:

• log in to the CMS
• create a folder for your project and name it appropriately (make it private if you don't want it to be visible right away).
• create a default document for the folder and type in or upload your content.

If you've received word that your latest manuscript has been accepted for publication and want to put the abstract, and maybe a few figures, on the web for further dissemination, the receipt of your acceptance e-mail to the publication of the abstract could be as little as five minutes or less.

To be honest, there are a few drawbacks to using the CMS. For example, if you're an HTML/CSS wizard, you'll find your skills are less than useful when using the CMS: the CMS expects plain content with little embellishment. If you don't like the colours or layout of the CMS, you can complain to the developers but can do little else (a large part of the impetus for using the CMS is consistency — if the default layout is changed in one place, it has to be changed everywhere). The only room you have to show of your elite CSS hacking skills in the the "body" or content section of the CMS — even then, you won't be able to use javascript or anything fancy-schmancy like that.

[1] It is possible to export the HTML that is generated by Plone. It is a bit awkward and will require a bit of editting of the final product, but it is possible.

[2] It is easier. Trust me.

[3] Actually, I initially chose a different package called Zope. Zope is an "web application development platform" which allows you to build your own dynamic web sites: I recognized that this would allow me to build a package that would do exactly what we wanted. However, shortly after finding Zope, I found Plone, which is built using Zope, and realized it had all of the features we needed.