Introduction

This is a preliminary survey of our experience trying to use Plone 'out-of-the-box', with minimal customization and a focus on rapid deployment.  Extensive customization and software development were beyond the scope and budget of the first phase of our project.

The lessons described below involve process, technical and implementation challenges. We understand there are solutions out there to many of the technical issues described, through the creation of customization policies, Zope page templates and skins on the file system, and installation of third-party 'Products' to extend the functionality of Plone.  Hints and suggestions for further research appear throughout this document.

1. Streamline our editorial process for information we share publicly and with field partners (Publishing)
   
2. Share research notes, links, meeting minutes and other internal information (Intranet/file-sharing)
3. Discuss and collaborate on projects - both internal and joint efforts with outside organizations
   

We also needed a way to manage information about all the people that would be participating in these three activities.

Plone is a very comprehensive system, with many powerful features.  To properly document everything that works well about Plone would produce a document several times longer than this one, and would duplicate much of the work that has already been done at plone.org and other sites.

In this document, I will focus on how our actual experiences differed from the feature lists.  This is not comprehensive, but we think it is representative of a small non-profit using Plone in-house.  We would like to express our gratitude to the Plone Foundation and all the Plone developers who have made Plone the fantastic tool that it is.

Many of the details below (the attention section, for example) can be generalized to many other content management systems and web tools, so we would hope that even users, administrators and technologists who are not using Plone may be able to apply some of these experiences to their own projects.

Adding/Editing Content

• By default, anyone can add folders and sub-folders to a Plone site. Having too many top-level folders is confusing, but too few can hide the breadth of content available on the site. A site with no structure at all can be intimidating, but total freedom leads to confusion and fragmentation. Each section needs regular pruning and grooming, and possibly limitations on adding folders to certain levels so the structure doesn't get too deep. 
  
• Users are often unsure about which content type they should use. For example, if they want to point to several PDF files on another website, should they make a folder and populate it with link items, make a single document and paste the links inside it, or download the PDFs from the other site and upload them to the current site as individual files?  Sample scenarios could suggest which approach is best in different situations, but ideally the system should suggest or enforce best practices.
  
• The content type icons are not distinct enough for all users to understand, or in some cases notice, the difference.
• The interaction of actively-edited, dynamic documents and comments which were attached to prior versions of those documents can create a lot of confusion.  For example, if User A creates a document on Monday, user B adds a comment on Tuesday, and then User A makes significant changes to the document on Wednesday, the rest of the document's readers will have a tough time making sense of it all.  Comments often contain critical information that needs to be kept for reference, even if the original content has been replaced.  One option would be to only enable comments on 'static' or archived documents. A discussion board-style system may be better than adding comments to dynamic documents that are subject to change.
  
• It is unclear how multiple editors can work on a content item in Plone over time without losing information in the editing process.  Ideally, a versioning system would be added into Plone via a third-party product.  If so, it needs to be in the form of a user-friendly 'past versions browser' rather than a programmer-oriented "diff"-style output.
• There also need to be locking mechanisms or strategies for documents that might be edited by multiple people at the same time.
  
• It is also unclear how multiple editors of multiple versions of non-web format documents such as Word or Excel files should manage these files.  We need the files uploaded so that the uploader's name and time of upload are clearly displayed in a list of past versions of the file.  This could be achieved through a product that stores multiple file versions, or using a folder that stores the most recent uploads at the top.  Archiving deprecated versions should be part of this process.
  
• Content added to the system via cut-and-paste from certain email clients and programs like Word or Excel can introduce an extraordinary number of unnecessary tags (styles, fonts, and MS Office XML namespace spans and divs) that can swell the size of a document to 10x or 20x what it would be in simple (X)HTML.  In addition to hogging database space and bandwidth, these extraneous tags make future editing within Plone difficult or impossible, and they also interfere with Plone's ability to format content properly for presentation. Tidy or a similar tool needs to be installed and enabled by default.
• If a Plone-based system is going to be a primary interface for users to create and compose information, users may be inhibited by fears that their contributions won't be perfect.  Adding spell-check into Plone could be helpful.  Contributors also need to feel confident in their understanding of who is and isn't seeing the information they add.
• The title and description for each content item will appear in a number of places throughout Plone:  the item itself, folder listings, RSS feeds, search results and portlets.  Titles need to be detailed enough to make sense out of context of the main item view.  Long titles can cause other problems in portlets, and also make the 'breadcrumb' too long for content that is nested in several folders. A standard model should be established within the organization to illustrate how much detail to put into titles and descriptions.

Notification/Attention

• Simply posting content to the site is not an effective way to share information unless the audience for that information is constantly checking for new information.  Attention mechanisms such as email notifications, RSS feeds, recent items lists that work with a re-designed workflow and other solutions need to be implemented and explained to users.
• Sending an email with content and then pointing to the link where it is posted online doesn't get people to use the system.  They usually respond to the email in front of them, rather than click (and possibly log in) to the website, and the conversations remain in email.   Clear strategies need to be implemented for maximizing centralization of the conversation.  Another strategy would be to capture email traffic by CCing an archive list, but this requires users to remember to do that, unless the capture address also acts as a hub for a group mailing list.
• There needs to be a way for site users to know there are new comments somewhere within the structure.  A new comments portlet was created as a quick fix for this, but it gives a site-wide list. This is disorienting for a large site because comment titles are shown without any other contextual hints, which makes it difficult for site users to determine what is relevant to them.
• The Dublin Core creator tag is listed as the Plone user name, which has no meaning outside the context of a particular Plone site.  All external metadata presentation needs to be evaluated.
• Every search generates an ad-hoc RSS feed, which is a brilliant feature.  By tweaking the parameters passed to 'search_rss', it should be possible to build all kinds of interesting feeds, such as review lists, new comments, recently published, recently added, and more.
• The default RSS feed is limited to titles, links and descriptions.  We should develop an altered search_rss that adds the body text.

User Interface

• Several interviewees and users have told us that within their own systems there is a wide gap between what's available and what's actually used. At a minimum, unused features should be turned off to reduce screen clutter.  Organizations should also regularly review their actual use, compare it to their goals, and implement strategies for closing the gap.  This includes making sure that all users derive benefit from using the system, not just one set of users.  We need defined ways of measuring usage and success. Developing strategies to motivate usage should be a continual process.
• The 'related' portlet's default behavior can be problematic on occasion.  For example, when viewing an event, every other event in that category is listed in the 'related' item portlet, based on category and not keyword.  This 'noisy' result reduces the value of the portlet.  Related results should be tested and keyword vocabularies designed to make sure that only the most meaningful results are displayed.  Could the number displayed be limited, with a 'read more' link for the full list?
  
• Customizing the recent items and recent comments portlets to display only items from the current folder and below might make them more useful.
• Epoz (the WYSIWYG editor) is fairly reliable, but when something goes wrong, it can be nearly impossible to fix it without digging around in the HTML.  In our case, this will often involve the assistance of technical staff and frustration for content contributors.  HTML editing is also required to edit basic table styles or alter the alignment of images. The current editor also favors <br> tags rather than <p> tags.  Newer versions or Epoz and other editors like Kupu need to be evaluated.
• New content is always added to the bottom of a folder, and the only way to reorder is clicking little arrows which require a round trip to the server each time. A simple 'move to top' or 'move to bottom' button (One/Northwest uses a hack of sorts - they cut and paste multiple items to move them to the bottom of a folder) would be enormously helpful, as would a NetFlix-style numerical reordering scheme.  An AJAX-style editor would be ideal, and the ZCatalog-based listings promised for Plone 2.1 might also help.
  
• Some critical metadata elements that we would like to capture can only be edited on the properties tab.  The document edit templates and scripts should be customized to make all required/desired fields on a single page, including original state if it is different from default.  This will reduce the number of clicks and page refreshes from the server.  It might also make sense to build an 'admin edit' template for more advanced users.
• Browser compatibility is very good, with only minor differences noted by all of our testers.  There are editing problems on old versions of Internet Explorer on Mac, but any incompatibilities are easily solved by encouraging the use of Firefox, which tested well on Windows, Mac and several Linux platforms.
• The print icon works well, and paired with the PDF printing options built-in to Mac OS X and many Linux desktop distros or a tool like PDF Creator on Windows, would allow for well-formatted offline access to information.  Because access from bandwidth-scarce environments is one of our primary use cases, we need to research tools that would allow server-side PDF export, of both single pages and of complete sub-folders, which could then be zipped/tarred for offline use.
• Favorites within a site are a neat feature, but few users understand it without an explanation.  Should these icons appear as text?  Would that take up too much of the screen?
• We are optimistic about the internationalization and localization possibilities of Plone.  In the current edition, most of the basic user interface elements have been translated into 40+ language, and will automatically appear based on a user's browser settings.  One of our test users was delighted to log in and find the user interface in Danish, based on the default settings on his laptop.  LinguaPlone, which will be integrated into Plone 2.1, offers the possibility of parallel translations of content, which would be helpful for reference and training material.

Configuration and Setup

• Managed hosting for Plone is not as affordable as commodified PHP/MySQL hosting accounts.  Alternative hosting options need to be researched in case of price increases or provider instability.
• Keywords and the 'related' portlet are very powerful, but vocabularies need to be defined and managed to be effective.
  
• Defaults for metadata and item properties such as effective date and expiration date need to be set when items are created.  Without defaults, they can't be used effectively  as search/sort criteria.
  
• Importing/exporting of Zope export (ZEXP) files works well for sites with identical Products and Product versions installed.  The import of entire Plone sites needs to be further evaluated for side effects such as catalog duplications and missing creator information in bylines.
• Importing content from a site with different Products or Product versions can be difficult or impossible unless there are migration scripts to assist, or the organization has the capacity to create them.
• While it is generally considered a best practice to develop all customizations and new content types on the file system, a vast majority of the documentation on plone.org explains how to customize using the ZMI.  To follow best practices and apply changes to multiple sites, these should be transferred to file system-based techniques like customization policies and products.
• The WebDAV interface seemed promising, but was not effective.  For example, it will showl objects that a user doesn't have access to, and then display error messages when the user tries to access them. We need to research how others have implemented WebDAV and FTP.
• It is unclear what the best practices are for creating multiple related sites that might share some combination of SSL certificates, authentication data, member lists, and/or content.  For example, if organization A wants to work on a joint project with Organization B, do they create a new folder in their existing Plone site and manage access through permissions/groups, create a separate Plone site, or would there be cases in which a separate instance would be required?  It seems like the obvious answer would be the 'new folder' strategy, but whether that can be managed through Plone (and not Zope) needs to be studied.
  
• Many customizations turn out to be much more difficult than they would seem at first glance.  For example, we wanted to change the byline from its current form (which lists user name and last modified date) to display the full name of the author and the effective date of the content.  This requires customizing the 'document_byline' template.  But we quickly encountered two problems:  to display the effective date, you must handle objects for which this property is null.  Since it is only set on the metadata screen (which most users never see) and not set by default at any point in the publish process, it is almost always null.  Secondly, the full name of the user that created the document doesn't seem to be available in this context without doing a search, and it is unclear how to do this while minimizing memory and performance impacts.  In this case, the wish to change two lines in the default view template opens a sizable can of worms.
• To alter views and edit forms and portlets requires editing Zope Page Templates, which may or may not require knowledge of Python, TAL/TALES, and MeTAL.  In additional, some features still use an old markup language called DTML. 
• Creating your own content types should be done on the file system as Products, and therefore requires Python programming capacity, and a long-term maintenance, migration plan.  Archetypes, which will be integrated in Plone 2.1 may make this simpler.

Management and Administration

• There is no obvious way to view site statistics and usage within Plone.  Analysis of Apache logs would need to filter out requests for presentation files such as icons and CSS.  In addition, different filters would need to be created based on whether you wanted to see what people are viewing (in which case, you would want to filter out all the edit and admin requests) or what your system's users were doing (in which case, you might want to filter out all or some of the document_view and similar requests). 
  
• The amount of content in actively edited folders can quickly become overwhelming. There needs to be a way to maintain a narrow focus on only what is relevant at the moment, while keeping everything else 'one-click away'.  One solution would be to make the default folder view  a 'recent items' list or some other catalog-based search.  That solution might only apply in some cases, such as project folders, so it would be nice to be able to turn it on and off selectively depending on the purpose of the folder.
• Basic bandwidth testing was promising.  A test session that involved a defined path through fifteen different pages and the upload of a 740k image file, used approximately 1200k.
  
• Much of a site's setup has to be performed through the Zope Management Interface (ZMI), and it can take an enormous number of clicks to achieve simple tasks like turning comments on or editing workflows.  Considerable familiarity with both Zope and Plone is required, and there is no audit trail or process for rollback.  Customization policies need to be created in Python on the file system, and tested to allow for quick setup of additional sites.
  
• The ZMI has a steep learning curve, which makes it difficult to imagine that administrative tasks could be delegated to novice users or project leaders. It is very easy to mis-type something and bring the entire site to a halt.  The project centers should be manageable Through-the-Plone (TTP) for stability and security reasons.  More comprehensive TTP configuration options are needed. 
  
• The ZODB stores past versions of all objects, and the database needs to be packed regularly to keep it lightweight. Currently, this requires access to the ZMI's control panel.  Packing needs to be automated.
• Moving ZODB files between platforms can be problematic, and the benefits of maintaining distinct data.fs files for each site on the file system are unclear.  Repozo needs to be thoroughly tested as an alternative.
• Strategies to consolidate, refactor and clear out stale or deprecated content needs to be layered on top of the technical architecture.  A robust, easily-to-manage archive strategy needs to be developed.  Content should be removed from the live ZODB, and archived to PDF or HTML formats, or an archive ZODB that is not web-based.
• Authentication needs to be centralized, rather than using members defined within each Plone site.  Reports need to be developed to show all current member information for each site or project folder.
• Files and images stored in the ZODB will enlarge the database and significantly degrade performance.  By default, all files and images should be stored on the file system.  Memory use should be monitored, and file system cleanup and archive policies also need to be created and scheduled.
• If short names are carefully managed, it is very possible to have clean, short, meaningful URLs.  Users often don't follow the naming conventions if they allowed to enter short names directly, and the auto-generated short names are a mix of content type and date code that is long and ugly.
• The system does not fail gracefully.  For example, if you go into the ZMI, go to Properties, and misspell the path to a portlet, all users will see a traceback detail for the error, and the entire site becomes inaccessible.  It would be nice if it could just show a question mark or a missing link in the spot where that portlet might have been rendered, and notify the administrator of the error.  This occurs on the Zope level, so altering the behavior may be non-trivial and have ramifications up the stack.

Third-Party Tools

• Product installation requires access to the Product folder of a Zope installation on the file system, and access to the ZMI to verify that it isn't broken, run migrations, etc.  Dependencies must be checked, and are often complex and/or poorly documented.  All new products should be fully tested on a non-production server, and the migration of content to those Products must be tested.  For these reasons, adding additional Products will require significant resources and should not be undertaken lightly.
• SimpleBlog is in limited use, but the order of the posts is very problematic.  It will use either modification date or effective date, but it is not configurable which.  This makes it an awkward tool because it doesn't act like a blog unless you manually edit the date for each post, which is not on the main edit screen.  This is too tedious for regular use.
• Because of the functionality we are hoping to implement in phase two of this project, product testing will be a larger component of the lessons learned for that phase.
  

Workflow, Permissions and Security

• The standard Plone workflow is cumbersome for rapid collaboration and private sites.  The default state, visible, is confusing to many users.  Additional default workflows within Plone have been pushed back to version 2.2, so alternatives should be evaluated or designed.  
• Our project center was converted to a private/intranet-style site based on a howto document from plone.org.  One side-effect is that the Published state is now only available to users who are logged in.  This is confusing, and disrupts the workflow.  Publish should always mean public, and not something else, such as private to a single group or person.
• The fuzzy distinction between the automatically managed role Authenticated and the Member role leads to difficulty creating users that can read private folders without owning/managing them.  We would like to have folders available to select members only, but on a read-only basis, and this doesn't work with the default workflow. Defining additional roles may clarify this.
  
• Workflow edits break the functionality of both search and the portlets.  They need to be changed simultaneously.  For example, the built-in news portlet shows published news site-wide, which doesn't work for project teams collaborating within folders, where users might need to view 'private' news that is local to that folder.  Also, the recent items portlet displays only published content, and so is useless on a private site, where content is by default set to a private or group-only state.
• It is possible to assign different workflows to different content items, but it seems like it would be best to have one primary workflow for the entire site that includes all use cases.  The projects workflow, for example, would be a subset of the total workflow.  Using several unrelated workflow models on the same site would be too confusing for most users, based on our experience, but this will require further research.
• Workflow for comments (aka discussion items) is unclear.  Even when assigned to the default workflow, there is no obvious way in the Plone interface to submit, publish, reject, etc.