[Plone-UI] [Plone-developers] Improvement proposal for Plone and theming

Tue May 24 18:31:56 UTC 2011

I think this is an incredibly sane and reasonable response to a situation
which has made Plone more and more difficult to theme, and which has also
raised serious issues for those who are "mere designers" but not experts in
the inner workings of Plone.

Not being a hardcore Plone coder, I've always felt that the current way of
doing things imposed too much additional effort to accomplish things which
would otherwise have been far less involved. It raises an undue barrier to
entry for folks who are interested in moving to Plone from another CMS - or
companies which would like to add Plone to the list of programs they create
themes for.

The marketing guy in me thinks that is very bad - and that we should be
working to make Plone easier for folks to get involved in rather than
putting up a daunting challenge which serves to keep people away. I hear
about the difficulty of theming Plone from designers who've never even tried
creating a theme for Plone, and it is something that shows up commonly when
folks compare Plone to other CMS options. It seems to me that this approach
offers an opportunity for us to address this head-on, and hopefully make the
Plone theming story something that draws people to our product rather than
making them wary of it.

There are certainly discussions that will need to take place, and work that
needs to be done to assure that Plone's accessibility remains world class.
But there is nothing in this proposal which seems a serious issue in making
this happen. It is a testament to the quality of the community that this
concern was raised so quickly. I don't think there is any real change the
community would sit by and watch Plone become an also-ran in this arena.

What is the best way to move this forward?

Mark

On Tue, May 24, 2011 at 6:07 AM, Geir Bækholt <plone at baekholt.com> wrote:
> Improvement proposal for Plone and theming
> ===================================================
> Theming Plone is currently too complex and requires special skills beyond
> what most web-themers have. Even with the new technologies we are
> encouraging to do theming, theming Plone is seen as difficult and painful
> compared to many other systems.
>
> One cause of this seems to be that Plone currently mixes:
>    1) content production and management
>    2) site display/delivery
> in the same interface.
>
> While this has some advantages, it means that anyone making a Plone theme
> must take special care handling all of Plone's UI as used by content
> editors. There are plenty of javascripts, stylesheets, macros and complex
> Python expressions in templates — only there to serve Plone's CMS-editing
UI
> in a correct manner to the correct users.
> There is really no need for this to be part of the same templates that
> deliver the finished website anymore, now that we are great at separating
> stuff in packages and have fancy front-end technologies to help us build
the
> interfaces we need.
>
> What
> ======
> This is a proposal to factor out the content management parts to a
separate
> software package (plone.app.cms?) with its own templates, styles,
> javascripts, etc.
> Let's refactor all of Plone's administrative controls and templates, i.e
the
> stuff you use to do edit and manage content, as opposed to viewing it, to
be
> served from a separate package (software wise), separate from the
> presentation templates that integrators usually customise.
>
> Typical things that would be moved:
> * The manage portlets link
> * the green bar
> * the actions menu
> * the object tabs
>
>
> How it would work
> ======================
> 1) When a user logs in to a Plone site, she is presented with a bar across
> the top of the screen, with her name and some actions (the current Plone
> personalbar). This menubar is served from a separate package, and injected
> into the current page with Javascript. Logging in doesn't change the
> displayied html at all. The entire menu is hooked up though javascript.
> (see attached figure 1)
>
> 2) The user can expand the menubar to edit-mode by clicking it. (a button
or
> link or something). In edit mode the menubar is bigger and also contains:
>        a) information about the currently viewed object
>        b) menus to perform actions or open additional views (like the
Plone
> object tabs and actions menu)
> (see attached figure 2)
>
> 3) When the user interacts with the actions/buttons/tabs, Plone opens an
> overlay with further options. The overlay can contain edit forms,
> configuration screens, options for adding content, information and help,
> etc. An overlay also has a lot more screen real estate than the current
tiny
> menus, so our flexibility in presenting the user with good information is
a
> lot better than currently in Plone. This gives us more room to improve
> Plone's user-interface in general.
> (see attached figures 3 and 4)
>
>
> The overlay approach
> =======================
> There seem to be two main models of CMS-user-interfaces in the world
today:
>
> 1) The CMS as a separate entity from the website. This seems to be the
more
> common approach. The CMS looks and feels more like windows explorer. The
> user navigates trees and tables, and has to preview her pages to see what
> they'll look like in the site.
>
> 2) The in-place approach. This is Plone's approach. More usable in some
> ways. Less in others. The user interacts with the website as it is and
uses
> the normal site navigation and site search to navigate the site.
>
> What we can achieve with this overlay approach is to get the strengths of
> approach (1) while retaining the UI advantages of (2).
> We pull all of the editing and configuration controls away from themes,
> making them neutral and generic. That makes it simpler to use advanced
> technologies for them, and also makes it easier to make them generically
> good looking and less prone to breaking.
> Keeping them in an overlay, however, retains the feeling that we are
> actually working on the actual site and not some separate publishing tool.
> The site colors and theme are still visible outside the edges of the
> overlays.
>
> Advantages:
> ==================================
> 1) Cleaning up the content-serving templates, making them much easier to
> customize or override (or theme with new tools like Diazo). They will also
> be easier to improve or optimize for Plone developers.
>
> 2) Separating out the CMS-ui will make it easier for developers to add
> advanced functionality to the CMS-UI without interference problems from
> customisations and themes
>
> 3) Separating out the CMS-ui would make it simpler for developers to know
> where to place functionality for add-ons.
>
> 4) With the theme and CMS separate, we are less likely to see themes
> impacted by Plone upgrades or by adding plugins. We can add functionality
to
> Plone without everyone having to readjust their theme.
>
> 5) Many also think that serving Plone's content should be done by other
> systems altogether, or at least be heavily cached. This approach would
make
> both of those scenarios simpler.
>
> Risks
> ========
> Accessibility handling will need a few considerations. We need to progress
> onwards from our (outdated) point of view that accessible websites means
> that everything has to work without javascript. I'd rather make this a
> high-end user-interface that is good for everyone, also people with
> disabilities. 90%+ of disabled people have javascript enabled.  There is
> still accessibility legislation in some countries that don't account for
> this, so we may need to take special care and produce fallbacks. I may
have
> a non-js-fallback-solution already but that needs to be tested.
>
>
> Please see the attached illustrations (PDF). They should make the scenario
> clearer.
>
> --
> Geir Bækholt
> www.jarn.com/baekholt
>
>
------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Plone-developers mailing list
> Plone-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>

---

Mark A Corum
Writer  |  User Interface Designer  |  Online Marketer  |  Certified
ScrumMaster

markcorum on AOL, Googletalk, MSN, Skype, Meebo, TokBox, Facebook, Twitter
and Yahoo

"Light up the darkness." - Bob Marley
"Quis custodiet ipsos custodes?" - Juvenales, Satires
"As God as my witness, I thought turkeys could fly." - Arthur Carlson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20110524/9a1d1ff3/attachment.html>