Plone at Upfront

Our old homepage dates from about four years ago. We were mostly quite happy with it, and we received a fair amount of favourable comments on its looks and navigability.

Unfortunately we always had to respond to these comments with "I'm glad you like it but some of the info on there is years out of date!" It was hard to keep fresh for all the usual reasons: the templates contained a lot of dtml-var cruft to maintain the layout, the menus were hardcoded, and all changes (especially the ones that break the template, of course) were immediately publically visible.

We had also set ourselves a standard of bilinguality that we wanted to maintain. In the original site, there was no infrastructure supporting this. Nothing related translations to each other, they were simply separate documents. Authors had to take care of linking them from the appropriate menus themselves. We wanted to stay bilingual, but we didn't want to move forward like this.

Another feature of the old way of doing was that exceptions were trivial to do. If you didn't want something linked from the menu, just leave out the link. You could add a once-off page for a single user, and if you don't link it elsewhere, it wouldn't clutter anyone else's view. In Plone, by and large, all content is equal: all News Items are going to feature in the news slot, and so on. Usually, this is good, but it does sometimes force you to think!

Problems with Plone

In its default configuration, Plone leans toward being a collaborative content management system (I should note that we're on Plone 1.0.5 as of this writing). It wants to expose everything that's put into it (by listing folder contents, searches, and in slots), and it invites new visitors to join.

This makes for a bad company homepage. Usually, a company has a more or less fixed number of pages (frontpage/about/contact/...) that need to be featured prominently. It doesn't work to have them mixed up in the navigation machinery for all the other documents and folders that may exist. Also, when a company allows people to login, this is usually not so that they may use the company's site as a content management system: perhaps they may edit their contact details, or log support issues, but they are a long way from fully-fledged Plone members.

In short, default Plone has too much UI furniture and functionality for a tidy homepage.

Stripping it down

For our purposes, simple two-level access was fine. Anonymous visitors may view everything that's visible or published. We solved the navigation clutter issue by including only published items in navigation. If you want someone to read a visible item, you need to mail them an URL, or link to it.

We also removed all global and local actions for Anonymous, leaving only navigation in the right column. The site isn't intended to serve masses of information, so we want to keep the navigation as basic as possible. In practice, this means that the frontpage will only have the toplevel navigation entries and recent news items. Other pages may also show the related slot.

Beefing it up

We are the only site members, and we can do all the Plone-y things that members expect: add documents, put them through workflow, edit their properties, and move them around. We see more slots as well, and personal actions are relevant to us, so they're back too. Our navigation doesn't include only published items, and we can view listings of contents, so our interface can become a lot more involved and cluttered than that of Anonymous. It's much better than the raw ZMI though!

Translation

Offering a bilingual site turned out to be a quick trip down the rabbit hole. Localisation is a deep and interesting topic. To do it well, it is necessary to pay attention to the user (for example, by looking at their browser preferences), while leaving them free to change their mind. Also, a localised Plone is a good start, but in itself it doesn't deliver a multi-lingual site. We used longsleep's wonderful I18NLayer to handle that aspect.

We needed two kinds of translation:

• although we stripped down the UI a lot, some Plone UI does remain: for example, the "You are here:" text in the breadcrumbs, the "Search" button, and some slot headings. Therefore, we needed to translate Plone into Afrikaans; at least as much as would be exposed via our site.

  It's hard to stop once you're started though, and now I've got the rest of Plone in Afrikaans to translate. If anyone reading this is willing to QA, give me a shout via the plone-i18n list.

• many (but not all) of the documents on our site are available in two languages. When a visitor arrives at our site for the first time, the Plone UI and the document language will reflect their browser preferences. At any point, they can choose a different content language. This sets a cookie, and content is presented in that language from then on. Note, however, that their browser preference is still used for the Plone UI. This is further explained in the Language selection document. For instructions on setting your preferences, see Setting language preferences in a browser from the W3.

  While we don't have rules governing whether content is translated, we have a Translation policy document that tries to explain when we translate.

We're aware that the tools we used are already being obsoleted. We should be on Plone 2.0 with PlacelessTranslationService. I'll get to that when there's time!

UI changes

It's a tribute to Plone's design that we could implement all the UI changes we needed by customizing scripts and templates in the skins.

Those tables

One of Plone's characteristic UI features that we hacked out was those hunchbacked tables. You know, some cells swimming in masses of whitespace with others cramming too much text into a tiny box:

(fullsize)

We replaced them with unordered lists, for a more readable, narrative presentation. The lists are CSS-styled, using Simplebits's Styling Nested Lists howto. We use these lists in all our slots (navigation, news, related, ...) as well.

CSS

Most of our look could be done by editing stylesheet_properties, but we also have ploneCustom.css which edits 17 classes, of which 3 are new ones we added. One of those are used for the abovementioned lists.

The skins

In the custom skin layer, we needed to override 18 items and add two scripts. Most of the changes were very light. The changes in functionality boils down to the following:

• another filter was added to querying for items (e.g. in slots, searches and topics). It checks whether a found item has an I18NLayer as parent, and if so, returns that instead.
• This means that Catalog proxies aren't sufficient: the objects need to be fetched, and therefore the slots and templates were modified to iterate objects instead of brains.