Skip to main content

an example proposal for adopting plone

Frequently, potential adopters of Plone at universities tell me that they have a difficult time convincing administration within their organizations that Plone -- or any open-source content management system, for that matter -- is worth the investment of time and effort. Or in the case of Penn State's WebLion services, any consulting fees that may be involved.

This proposal is loosely based on what I wrote for my own shop. However, I am fortunate to work in a highly clueful department. Making the case for adopting an open-source enterprise-level content management system was not an arduous task.
With that in mind, I'm sharing the following example proposal for adopting Plone at the university department level. If you are striving to convince your organization to adopt Plone, feel free to make use of any part of this material for your own justification.

In this example, the department currently maintains a home-grown content management system based on proprietary tools - a situation perhaps not as widespread as complete reliance on static HTML, but nonetheless rather common. In addition, this example assumes a one-person Web shop, also a very common situation.

The Proposal

Issues with Current System

  • Home grown = high maintenance. Our current content management system has served us very well through the years. However, any fixes, upgrades, enhancements, and added functionalities must be hand coded by the Web Administrator. Creating, maintaining, and adjusting Web administrative forms (used for managing Web content) can be very labor intensive. For example, it can take approximately 2 weeks to install and configure a Web-based WYSIWYG editor for use in all forms. Likewise, all public-facing pages displaying content in various ways are hand coded.

  • Limited scalability and extensibility. The current CMS was built specifically with the departmental Web presence in mind and is supported by one programmer (the Web administrator). Since the CMS was developed, the department's Web presence and related requirements have grown exponentially. This puts a strain on the existing CMS and requires an increasing amount of intervention.

  • Built over top of a (proprietary) relational database.

    • This database model is not ideal for managing Web content. Ongoing alterations rely upon revising database tables along with writing, maintaining, and revising SQL queries for all additions and changes in the management and presentation of content.

    • The proprietary database server is complex to install, configure, and back up and routinely requires patches to address security vulnerabilities. It also requires two separate server boxes, one for production and one for backup.

  • Built with proprietary middleware (programming software used to display Web content). With each new version, the price of this software continues increases.

  • Lacks workflow and versioning. The current CMS lacks this functionality except for an e-mail notification system that pings the Web Administrator with some details when content is added or changed. It would take six months to a year to build full workflow and versioning into the databases and applications of the current system. Without workflow, content errors and problematic HTML code have the potential to go live on the Web site, to be caught and corrected after the fact. (Diligence of the Web administrator currently prevents this.) Versioning, which allows one to revert back to previous versions of Web content when necessary, also is not a feature of the current CMS.

  • Lacks other higher-end administrative functionalities. The current administrative forms lack many features that would ease workload on both the Webmaster and content providers. (e.g. full Web-based image handling and full-feature placement of, and linking to, files (pdfs, excel sheets, etc.) is not present. This means that the Web Administrator frequently must step in and manage this content for befuddled content providers. As an example, editing, uploading, and placing images and their captions can take about 10 hours each week.

  • All programming support falls to Web Administrator, who in turn has no programming support. This programming is far too mission critical and sophisticated to give to temporary, part-time, or inexperienced workers. Furthermore, because no one else uses this particular CMS, there is no programming/support community addressing its framework.

  • Continuity regarding staffing can become an issue. Future Web administrators or Web programmers coming to the department would have to learn how the current CMS works as they go along, using in-house documentation.


Bottom Line - Current CMS



  • The department has outgrown it.

  • It grows increasingly labor intensive.

  • It generates unnecessary expenses.

  • It does not offer the functionality that an enterprise-level CMS would provide and from which the department could greatly benefit.

  • It does not benefit from a larger support community.




Advantages of Plone




  • Open Source. Because Plone is open-source, it is available at a relatively low cost, is infinitely customizable, and is supported by a global community with a considerable amount of cohesiveness and expertise. More about the open-source model...

  • Enterprise-level. Plone provides a robust collection of tools and features out of the box. In addition, Plone is completely customizable, and its functionality can be extended by a wide array of add-on products.


  • Some of what Plone offers:

    • Built-in database and Web server using the Zope framework. The Zope object-oriented database is ideal for Web content management:

      • Extremely flexible, not requiring constant database-level intervention when making site changes.

      • Integral with Zope framework, requires no installation or maintenance of separate engine.

      • Extremely secure, robust, and portable.

      • Does not require writing and revising database queries.

      • No hand-coding and constant revision of administrative forms. These are an integral part of the Zope/Plone environment and frankly are better than anything a lone Webmaster could build in any realistic time frame.



    • Platform-neutrality, running on Windows, Apple OS, or Linux.

    • Ability to work with other databases as needed.

    • Workflow and versioning, RSS feeds, Site mapping, News and calendar management, and many other enterprise-level content-management tools.

    • Administrative forms that are extremely user friendly (and browser friendly). These forms are integrated in such a way that even content providers with a low level of comfort with the Web can manage content, images, and other files quite easily. Plone's ease of content management can take many hours of low-level, routine work off content providers and the Web Administrator. Example: Basic photo handling alone can take up 10 - 15 hours a week of Web Admin time. This is largely automated in Plone. Example: Helping certain content providers upload and link to files such as pdfs can take up another 10 -15 hours each week. Handling such files is *much* more simple in Plone.

    • Web Standards compliance. Plone also has undergone accessibility and usability testing, generates user- and search engine-friendly URLs (not the long, unreadable, varible-passing URLs frequently generated bu dynamic sites). It is also relatively easy to customize Plone to meet organizational usability and accessibility requirements. Plone's visual editor also strips out problematic and noncompliant code copied from MSWord and other sources.

    • Add-on products. Everything from blogging, to digital asset management tools, to courseware packages can extend Plone's functionality.

    • Enormous amount of support and documentation. This is one of Plone's greatest strengths. While Plone can involve a significant learning curve, the Plone community is vast and provides support through its extensive documentation; its online forums and chat rooms; its smaller, localized groups such as WebLion and users groups; and training opportunitiesof stellar quality.



Some additional advantages:


  • No more hand coding a CMS from the ground up. Although developers always have the option to build customized Plone products, programming is minimal compared to what is required when building and maintaining a home-grown CMS.

  • No costs involving proprietary middleware. Switching to this open-source product can save at minimum $5,000 to $6,000 over the next few years.

  • Professional development opportunities for current Web staff. The Plone community provides many opportunities for collaboration on training, products, and documentation.

  • More continuity regarding staffing. There are many, many Web professionals at within this institution and elsewhere who can step into a Zope/Plone environment at any time and be up to speed very quickly with department-specific customizations.


Summary


Adopting Plone will result in dramatically increased efficiency while saving money both in the short and long run. In addition, this powerful CMS and the related open-source community opens up numerous opportunities for the departmental Web presence and its users.

Related Links


Popular posts from this blog

Plone Advocate Andreas Mantke to Lead Site-Administration Workshop at 2012 LibreOffice Conference

I just published this article at plone.org on Andreas Mantke, a deputy member of the Board of Directors of the Document Foundation for LibreOffice . Mantke led a workshop for new Plone site administrators in the LibreOffice community during its annual conference last week. See the full article at plone.org/news/andreas-mantke-to-lead-site-administration-workshop .

customizing wordpress

I've been experimenting with creating custom themes in WordPress, one of which is the interface of this blog. WordPress is remarkably easy to customize.