[Framework-Team] Moving Collection settings to ZMI (was: The big 3.0)

Alexander Limi limi at plone.org
Wed May 16 19:13:31 UTC 2007

Disclaimer: This mail has been sitting around in my email inbox for a  
while, and I wanted to answer without sounding rude, so I had to let it  
cool down for a while. Bear with me, hopefully I won't ruffle any  
feathers. It's a bit sharp, but not intended as anything else than  
matching the tone of the original. ;)

On Wed, 28 Mar 2007 09:20:22 -0700, whit morriss  
<d.w.morriss at gmail.com> wrote:

> the argument that we are now using the zmi by design really rings hollow  
> for me.  Though I strongly support generalizes ui that works with or  
> without plone, I'm not sure designing in any more context switches into  
> plone is at all a good idea.  Let's keep people in the application or on  
> filesystem, not rummaging though our hot nineties legacy layer.

There's a very large amount of settings that fit perfectly well in the  
middle category, explained below. And your ad hominem (well, on Zope 2 ;)  
attacks make you come across as not arguing the case, but arguing for  
taste. Which I'm fine with, just don't present it as something that it's  
not. :)

The reason why this mail pisses me off slightly is that it (rightly or  
wrongly) assumes that the current work done by Hanno and all the others  
helping out at the sprint in Baarn doesn't change anything. There's a  
*major* difference between 2.5 — which has a limited set of configuration  
switches exposed — and 3.0, which took a step back and identified pretty  
much *all* the common questions from the lists and the FAQs we get and  
made these settings available in the Plone control panel.

These panels are not arbitrarily chosen, they are carefully selected and  
grouped, and there's a major "odd one out" right now: the Collections  
control panel; which is where this discussion started — more on that later.

> Context switching has almost always been an unfortunate bump on our  
> learning curve for Plone. Just having to explain navigating the zmi  
> increase our support burden.  People should design good configuration  
> uis, not just stick badly drawn ones in the zmi.

Yes, but there is a middle level. These people are comfortable with  
following instructions, clicking around slightly less than optimal UIs,  
but it's a big difference for them to make changes on the file system  
using GS or similar techniques. They might not even have FS access in all  

> with these things in mind, we may need to rethink the application of the  
> pattern we use in plone.app.controlpanels so it can be easily reused for  
> things like advanced options or container level configuration.  This  
> seems like the right direction, rather than claiming the inevitable use  
> of better technology as wrong by decree and advocating a return to the  
> bonny days of 1999.

Ignoring the non-sensical argument here, let me show you an example of how  
this was solved in another rather successful open source project called  

- They have their "primary settings", which contain a carefully selected  
set of preferences that are either a) hard to make sensible defaults for,  
or b) things that are likely to *have* to be adjusted on a daily/monthly  
basis. This is pretty much equivalent to the control panels we have  
exposed in Plone 3.

- They have their "secondary settings" (aka. "preferences by obscurity" ;)  
about:config URL bar trick, which shows every setting that Firefox has  
available. This is equivalent to the ZMI in Plone, where there are a lot  
of settings available, but you really need to know what you are looking  
for to find anything, and there's nothing to stop yourself from killing FF  
or Zope, respectively. I'd even argue that it's harder to find things in  
FF just because you have to know what the variables are called, and there  
are thousands of them.

Of course the secondary settings (both in FF and Plone terms) is a UI  
workaround. But there's a point of diminishing returns, we want people to  
be able to get to these settings if they really need to — after all, they  
have a job to do — but we can't hand-hold them through every one of them.

You now want to invent *another* layer just because you have some personal  
beef with the ZMI? Come on.

I do agree that we need to look into how to solve container-level settings  
in a consistent way, but this is a different discussion, and isn't going  
to happen for 3.0.

> long live frames!

Oh please. This is getting ridiculous. :)

To get back to what was originally discussed:

Moving the Collection (nee Smart Folder) control panel into the ZMI is an  
easy operation, makes sense (as it's equivalent to the portal_types UI,  
just used less), and removes the last control panel that isn't immediately  
understandable from the Plone side.

If you need to change the name of an index representation, that's not a  
common enough task for me to defend it from being in the main control  
panel. It's something that you're likely to change once (if ever), and  
then never touch it again. Sounds like a "secondary settings" panel to me.

Alexander Limi · http://limi.net

More information about the Framework-Team mailing list