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
<[EMAIL PROTECTED]> 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
cases.
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
Firefox:
- 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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
