I’m really grateful that Lovely Systems sponsored my participation on, flight to and board and lodgings at Plone Conference 2006 in Seattle. As some kind of small wrap up i’ll blog some of the topics/tool i learned about, heard of or will take a closer look at in the future.
This conference i did not only focus on development talks as i did in vienna 2004, but also on more business related talks.
Besides meeting people, getting more and more familiar with zope3 technology, my main intereset was to find an answer to the question:

Can you build a small, easy to use and most important: low-cost website with cms functionality using plone, or do you have to use some other technology for this?

These are the talks that provided me solutions on how to effectively make plone easier to use, and less expensive to support.

Building a Humane CMS With Plone

by Joel Burton, slides

I really enjoyed this talk a lot since Joel provided solutions for a lot of problems i encounterd while training editors for their plone sites.
His hints are very simple yet very effective.

Content Types
The descriptions of plone’s default content types are very generic. The add new item dropdown is overloaded by default. Use “add item / restrict” to select addable type for a folder or move less used ones into the “more” menu by not selecting them in preferred types.

Many people don’t understand that they can upload a pdf using the File type. Cloning the File fty and rename it to PDF, Word Document, Excel Sheet or whatever makes it a lot more user friendly.

Note:

• You should be aware of loosing plone’s translations when renaming fti
  title and descriptions. However low-cost sites are often not
  multilingual and even if it’s worth to add the new messageids to have
  less confused users.
• It might be a little more work to migrate a page that uses this custom filetypes. If for example a future version of ATContentTypes uses ExternalStorage for File you’ll have to make it migrate you custom types too somehow.

Organization:
People often don’t know where to put their content. Unless you’re running a community portal, remove the Members folder before you deploy the site.
Provide folders for different content types and restrict the addable types there (eg: http://lovelysystems.com/staff/events)
A neat trick is to clone the Folder fti in portal_types, and change the addable types there. This way you can also allow types that should not be implicitly addable elsewhere and give the folder a special icon.

Archetype development
Move the keyword field into the edit view (schemata=’default’), use an AddRemoveWidget and rename it to “tags” because keywords confuses most people.
Use the DateBoxWidget for datetime fields. It allows users to enter dates in the format they are used to and tries to parse it. You can even type in “last Monday”, “yesterday” or “12 feb”

Kupu
Kupu offers a lot of buttons and styles that are not needed in some cases.
You can “switch off” buttons using css:

#kupu-subscript-button{display:none;}

You can even change the paragraph styles on field level:

TextField(’text’,
widget=RichWidget(
parastyles=(
(’div|contactInformation’,’Contact Information’),
(’div|notesToEditors’,’Notes to editors’), ),
),
),

SuperUser role
I also liked the idea of having a special role for superusers.
The superuser can cope with the folder_contents, permissions and sharing tabs, change the default_view of a folder, copy,paste,rename and undo actions, whereas these are hidden from the normal user.

These are just a few tips i remember by heart. I really recommend to have a look at the slides.

Plone in 100 hours or less

by Patrick Shaw, slides

This tutorial was not about how to code or configure a plone website, but how to create an effective scope of work (an offer including milestones and cost estimations) for deploying and support a plone site.

The offers we are currently writing at Lovely Systems more or less include the same points Patrick mentions in his slides.

I liked the idea of putting a risk clause to the scope of work that includes solutions for problems such as what happens if

• the customer does not approve the 3rd iteration of the design
• we don’t get graphics for the design and have to create them on your own
• the customer changes his mind and priorizes other or even new features

some additional notes i took during the presentation

• use a very simple workflow (publish-hide)
• they use kupu templates (don’t know yet how they work) that place a picture always at a certain place. this way you need not eplain all the features of kupu. (i’ll ask patrick how this works)
• they use calendarX, i’ll aks how this speeds up the site development or improves user experience
• they use PloneDropDownMenu which i’ll have a look at in the near future

In the last month i often had to write an offer estimating costs for features or components neither i nor the customer really knew how they should work.
In this case it is a great idea to offer the customer some hours of payed consulting.
Discussing about the whishes, technical limits and alternatives and writing the results down helps the customer understand what he really wants. This will help you estimating costs and planning milestones. The customer can use the documentation for talking with compelling companies too, if he is not already convinced by your great consulting ;-)

I’ll definitely try this out in the next projects. It would be a great improvement for our project management and also for the customers.

GenericSetup for Fun and Profit

by Tres Seaver, slides

The first time i heard about GenericSetup was at SnowSprint 2006 in a short presentation from Rob. Until yet i never took a closer look at it but already bookmarked some information.

By now i do all the configuration of a plonesite (setting skins, configuring language_tool, portal_catalog or topic_tool, ..) in AppInstall.py. I never used a configuration policy to create some default content (eg. typical folder structures) and did a lot of configuration (hide portal types, adapt workflows, register kupu styles/libraries/resourcetypes) in the ZMI and documented it in some INSTALL.txt file.

Using GenericSetup would possibly allow me to do my standard configuration of a plone2.5 site once using the zmi and control_panel, store all this in one single configurationfile that can be loaded while installing my product.
I could even safe and compare snapshots or create diffs to compare the configuration of a site with the standard configuration or the configuration on the development server.

According to Tres GenericSetup is currently beeing improved to play nicely with QuickInstaller (esp. uninstalling) and handle “delta” profiles.
He also mentions the management of Archetypes schemas TTW which could safe people from coding custom event types just for adding a special field.

Summary

To wrap up the whole post, the motto is KISS.
Plone offers a lot of functionality that should be hidden from average users and only be available for superusers.
GenericSetup could help in storing this configuration once and apply it on different portals.

If i missed some important talks related to more efficient plone deployment, or you would like to share your knowledge please add a trackback or a comment.