[Framework-Team] Notes from Joel on simplifying Plone

[Jon Stahl]

Hi FWT!

Per a brief conversation in #plone-framework tonight, I remembered
that back in October, while I was on sabbatical, I actually got around
to interviewing Joel Burton about how he thinks Plone could most
effectively be simplified for greater "approachability."  For what
it's worth, here are my somewhat-cleaned-up notes from that 2-3 hour
conversation.  I hope it's helpful to you.  I know that some of it is
already a little bit out of date (woohoo!).

best,
jon
---------


Since 2006, Plone has gotten vastly more powerful and flexible, but it
has also become more complex and harder to approach for new site
integrators.  This is not a new observation.

Most of the increased complexity stems from our past choices to adopt
new technologies that we didn't build ourselves, without adequately
considering how well they fit our average integrator's knowledge or
skills.  In many cases these new technologies offered considerable
benefits, but also had significant missing features or
confusing/awkward aspects that we failed to address.

The good news it that there are fairly straightforward ways of
addressing most of these issues.  The result will be vastly increased
satisfaction for the vast majority of our everyday site builders, and
renewed energy and enthusiasm in the Plone community.

Joel Burton and I spent a few hours talking about some of these
issues, and came up with the following list of challenges and
opportunities.

1) Viewlets and viewlet managers.

While viewlets and viewlet managers provide some clear benefits to
add-on product authors, they are very clumsy and confusing for more
basic theming tasks. The biggest specific problem is that our current
design doesn't allow us to move viewlets between viewlet managers
without writing code and ZCML.  This makes a complete through-the-web
viewlet manager like GloWorm impossible to realize.

We need to rethink the design of viewlets (in a backwards compatible
way) so that a tool like GloWorm can move viewlets, create new
viewlets and customize existing viewlets through-the-web, THEN dump
the results to a disk-based product.   We believe that this kind of
workflow would transform average integrators' loathing of viewlets
into love.


2) ZCML-wired page templates

It is currently too difficult to override a default Plone template.
We need to have a mainstream, best-practice way "wire-by-name" way to
add new templates, override templates in themes (layers) and override
things that are already overridden.

Jbot is a good portion of the way there, we don't know if it can go
all the way, but we certainly hope so.    We need to move this type of
solution to the front and center of our template customization story.

3) Product installation with buildout

Buildout offers many benefits, but also presents a learning curve for
new site integrators, especially w/r/t add-on product installation.
Some specific challenges and ideas for improvement include:

- There's no obvious, easy way to find out the name of an egg from the
product listing on Plone.org.  This is easy to fix in PSC.

- The redundant need to add many products to both "eggs" and "zcml" is
very, very confusing and frustrating to new users.  With Plone 3.3, we
finally have the capability to use autoinclude, but we have to
aggressively get product authors to update their products to take
advantage of this capability, or else sprint through the collective
and do it for them. Let's get this done!

- Right now, if buildout fails (e.g. because it can't download
something), it often kills your existing site.  That's not cool.  Even
some basic sanity checking (download all eggs before touching the
existing install) would help a lot.

- Buildout offers opaque and confusing error messages.  This really
needs to change, but we know it requires some pretty sophisticated
attention.

- The "apache-style" buildout.cfg file is inherently intimidating to
new site developers.  At first, they just want any easy way to install
add-on products.  We used to have that -- just unzip stuff into the
Products folder.  We need to bring back this idea: we envision a
"products.d" folder where you can drop an egg, or a file named
"my.egg.cfg" and it just works.   This will also greatly increase our
deb/rpm friendliness, since installing products via deb/rpm would just
involve dropping those products in the folder.

- Pinning does not currently lead to predictable, repeatable
deployments. Pinning is also still very confusing.  Even a good,
commented-out example of pinning would help.  We're not sure how it
work work, but some approach to auto pinning would be excellent;
people expect if they have the same buildout file and run it on their
server, they'll get the same stuff.  We need to come up with some way
to "bake" a buildout (e.g. bin/buildout --generate-deployment-file) so
we can guarantee that a buildout will always get the exact same code.

4) Product uninstallation

While many more experienced developers don't often uninstall products,
or test products in a throwaway buildout, our new users don't have the
skill/experience to do this.  And many of our products don't uninstall
cleanly.  This creates massive early-stage frustration for new site
integrators.  Part of the problem is that GenericSetup doesn't have
support for uninstalling everything it can install; we need to address
this with both code and documentation.  Then, we need to educate
add-on product authors to create uninstall profiles.


Other minor things

5) zopeskel/paster
 - but the recipes are a sink of super-advanced practices ie, most
people still use cmf skins but the skeleton to "build archetype
product" doesn't make a skins/ folder.
 - reposition as average integrator tool
 - in general, tho', I'm still puzzled why we bash agx.  it's a huge
hit with integrators, and the generated code quality is quite good
 - "designing content types" was our "killer feature"


6) ldap integration [seems to be harder than for other cmses, no
direct experience on this myself]


Things we need to focus on in a strategic planning call:

- Name the audience we aspire to serve, what we expect of them, and
what they can expect of us.

 - Some description of external environment + our positioning in it
over the next 2-3 years.

- What our core cultural values are, and how to structure our process
so that we successfully deliver on those values.