April 14th, 2008

Simplify Plone’s Editing Experience

Part 1: Simplifying Plone’s content authoring experience for end-users. We’re bringing sexy back.

If you haven’t read the introduction yet, please make sure you do so before continuing. Thanks!

Over the past few weeks, I have done some experiments in simplifying the UI to make Plone less intimidating for newbies. A lot of these experiences are based on deploying it in a limited fashion internally here at Google. Generally, Plone is in a state now where most of the major areas of functionality is in place, so it’s time to look at it with fresh eyes — it’s not exactly Plone 1.0 when it comes to number of things you can click anymore.

I have built a clickable prototype of the new UI, since the best way to show you what the new editing experience looks like is to show it in action.

Note that while I’m using the NuPlone theme in this demo, the approach works equally well with any theme — this is about functionality, not looks.

Demonstration & Notes

Movie showing the new approach (no sound, 6.6MB)

Frequently asked questions and additional notes

What happens to in-line editing?

If there’s something that we have heard loud and clear from our integrators, in-line editing — aka. “click to edit” — doesn’t work that well with end-users, so we’ll disable it for general content authoring. Yes, I just admitted we were wrong the first time around.

Instead of trying to work around the problem of editing efficiency with “UI hacks” like these, we should attack the root of the problem, which can be done in much the same way, but with fewer moving parts. There are use cases — mostly specialized applications — where inline editing may be the right approach. This proposal just states that for the basic content authoring use case, it doesn’t add much — except for confusion, annoyance and visual noise.

Where is the current state shown on the view, since the menu bar is gone?

The current plan is to fold it into the by-line along with the publishing date and author info.

What happens to products that have defined custom tabs and/or menus?

Ideally, there are very few legitimate use cases for doing this, but I agree that some exist. I won’t call out which are gratuitous and which make more sense, but I’ll use LinguaPlone — Plone’s multilingual support — as an example of where it might make sense to add a new menu.

In sum, these changes to the user interface make it less cluttered, more efficient, and easier to integrate with custom layouts, as the only thing you have to find space for in a custom design is a button and a pulldown.

Next, let's look at better rich media handling in Plone.

Alex Limi is VP, Design at Highfive , a company that is transforming the way you work. Previously head of Firefox UX & Product Design Strategy at Mozilla , designer at Google & co-founder of Plone .

“No amount of genius can overcome a preoccupation with detail.” —Marion Levy