[Plone-UI] [Plone-developers] Plone 5 Theme

Dylan Jay djay at pretaweb.com
Thu Nov 21 17:56:13 UTC 2013

On 21 Nov 2013 23:24, "André Nogueira" <andre at simplesconsultoria.com.br>
> I know a lot of people that just use Plone as a framework.
> Just edit one custom CSS file and transform the Frontend. No python
> and no PHP too :) And no XML :)
> This is the easyer and most important way to use Plone now
> To me, the basic steps for a new themer (for regular users not
> advanced users) is:
> 1. Clone the default DIazo theme
> 2. Try to find and change the logo
> 3. Try to make some CSS chances
> Newcommer and basic users will never create a Diazo theme from the
> scracth. I dont see this action as a trivial action. Can be trivial
> just for advanced front end developers
> To me, trown all the Front end responsability to custom diazo themes
> could kill one of the Plone most important feature: Accessibility. We
> really need a strong starting point for new themes and for small
> customizations.

I agree we need a good starting point for themes that want to start with a
base plone theme.
However I think the goal here is to decide  the base set of requirements
that all themes must implement regardless if you base it on default theme.

> To me, the only option to make plone more popular with the public you
> are aiming, is to reach this 5 points:
> 1. One click install in production (something like Ploud or ready to
> use droplet in digital ocean or similar players)
> 2. A great number of high quality themes.
> 3. Very easy way to customize this themes (change logo and base
> colors). A editor based in LESS/SASS will be amazing.
> 4. Very easy way to install addons
> 5. very easy way to updat Plone and addons
> Only after that, Plone can become popular.

I agree with you. This will make plone even more popular than what I
However to get #2 you need a lot of web designers willing to create themes
for plone. To do that we need to make it easy to implement a completely
custom theme. So we need to think very carefully about what this base set
of requirements are going to be for every plone theme.
Perhaps to get this discussion back on track let's try and make that list
of things every theme must include to work with base plone 5 plus common
1. Basic content styles. Eg header, call out, title
2. Side nav styles
3. Sitemap ? Or can we drop this?
4. Left and right portlet styles
5. ?

Things we no longer need insist a theme includes
- live search js and CSS
- editing and toolbar
- info/error boxes
- floated document actions like print
- ?

> Andre Nogueira
> andre at simplesconsultoria.com.br
> Simples Consultoria
> www.simplesconsultoria.com.br
> Tel. (11) 3898-2121
> On Thu, Nov 21, 2013 at 6:40 AM, Dylan Jay <djay at pretaweb.com> wrote:
> > Hi,
> >
> > I'd be interested to know of those in this discussion how many do
custom themes on a regular basis? ie take html/css or a PSD from a designer
and construct a theme.
> > I suspect we're coming at this issue from a variety of different
experiences and perhaps there are a lot of people on the plone developers
list who consider themselves more of a python programmer than a FE
> > I'm not saying that plone shouldn't be useful out of the box but I am
saying it's a huge barrier to it's adoption by other that it is so hard to
customise. Diazo is a massive improvement in this respect and I can only
think that you must be doing very different work from us if you don't see
> > As an example, this week we're tutoring a fedral government department
on how to create their own intranet. They've already installed, configured
it, installed the plugins they want, setup the IA, dummy content etc. They
have got a html/css design mockup in php from a web agency based on their
ideas (we had no input). Now we'll do a day workshop with them using diazo,
the theme editor and within the week they will have a working intranet. No
python written, no php written. However the biggest hurdle will be
integrating the editing UI, something that will be fixed with toolbar. The
next biggest hurdle is to make sure all the bits of Plone UI and the right
versions of jquery etc still work with the theme, or someone has to rewrite
> >
> > Also trying to attract Python developers to Plone IMO is a waste of
time. I understand the attraction. We love python, and we love other stuff
python people do. However 99% of python programmers don't need or like a
CMS. A CMS solves problems they don't have. Most python programmers are
happy with static html generation like pelican. I think it's our pride that
makes us want to be recognised within the Plone community for doing
something worthy. I certainly feel that sometimes.
> > The solution however is to grow Plone itself into something widely used
and admired. Not by pythonistas but by people who want to build websites
quickly and that look awesome and have huge power underneath. At least then
not only will we still have jobs working with software we love, by
pythonistas would at least have to admit we created something popular even
if it's not something they can use.
> > We won't create this popularity by trying to compete with flask or
django or by make an out a kind of app container hybrid framework thing. If
you want to build forms and apps etc that need complex FE widgets etc then
you probably shouldn't be using a CMS IMO (Except if you want to do it TTW
in which Plone/Plomino is great).
> > To do this we need to attract the very people that aren't here.
Intergrators/themers. They don't care about Plone widgets and frameworks.
They just want software that tick all the boxes for their clients/editors,
and doesn't get in the way of implementing their design.
> >
> > Dylan Jay
> >
> > ---
> > www.pretagov.com - Secure SaaS for Government hosted locally.
> > P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75
> >
> >
> >
> > On 20 Nov 2013, at 11:51 pm, Alex Clark <aclark at aclark.net> wrote:
> >
> >> On 11/20/13, 5:25 AM, Rok Garbas wrote:
> >>> Quoting Ryan Foster (2013-11-20 08:08:12)
> >>>> On Nov 19, 2013, at 6:46 PM, Dylan Jay <djay at pretaweb.com> wrote:
> >>>>
> >>>>>
> >>>>> On 20 Nov 2013, at 4:26 am, David Glick (Plone) <
david.glick at plone.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On 11/19/13, 1:27 AM, Dylan Jay wrote:
> >>>>>>> On 19 Nov 2013, at 9:02 am, David Glick (Plone) <
david.glick at plone.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On 11/18/13, 4:13 AM, Ramon Navarro Bosch wrote:
> >>>>>>>>> Sorry for the cross-posting!
> >>>>>>>>>
> >>>>>>>>> I decided to write down my opinions after working at Arnhem
sprint on
> >>>>>>>>> plone 5 theme, it's just a dump of what I have in mind :
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Go go go !
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> I think there's been a big thing missing from the discussion of
> >>>>>>>> plone.app.toolbar and isolating theme resources from Plone edit
> >>>>>>>> resources. That big thing is what it means for add-on authors:
how can
> >>>>>>>> we make sure add-ons get a look and feel that fits with a site's
> >>>>>>>> theme?
> >>>>>>>>
> >>>>>>>> Some add-ons only change things in the edit UI, and they'll be
fine. But
> >>>>>>>> what about add-ons that provide their own portlets or viewlets,
> >>>>>>>> a custom template that renders in the content area? These are
> >>>>>>> +1 it's something we haven't talked enough about.  However I'm -1
> >>>>>>> it's common.  These days a lot of the front end (FE) facing
plugins can
> >>>>>>> be replaced by custom diazo based solutions quickly since most
> >>>>>>> aren't generic enough to meet the needs of the theme. A good
example is
> >>>>>>> a carousel.
> >>>>>>>
> >>>>>>> I had a look at plugins we often use that are FE general plugins
that do
> >>>>>>> require their own js and css.  - PloneFormGen - PloneBoard -
> >>>>>>> - collective.recaptcha - oembed and video stuff
> >>>>>>>
> >>>>>>> Thats pretty much it. Some of these use their own frameworks, for
> >>>>>>> instance Plomino uses lots of JQuery UI so they don't rely on
much from
> >>>>>>> Plone
> >>>>>>
> >>>>>> Wow, I guess we totally disagree.
> >>>>>>
> >>>>>> Here are some other examples: - collective.cover -
> >>>>>> - collective.plonetruegallery - eea.facetednavigation -
> >>>>>>
> >>>>>> If addons no longer have a common library of markup they can
expect to
> >>>>>> work and a consistent way to inject their own Javascript and CSS,
I think
> >>>>>> we basically destroy the Plone add-on ecosystem. And I think that
> >>>>>> ecosystem is a huge part of Plone's continued success. Without it
we only
> >>>>>> have an archaic web framework with a better-than-average editing
> >>>>>
> >>>>> I'm not saying we remove the consistent way to inject CSS and JS.
> >>>>> saying we reduce as much as possible the opinion plone is putting
on themes
> >>>>> about what CSS and JS they have to implement to make a site work.
 It isn't
> >>>>> destroying the eco-system, it will make it stronger by making plugin
> >>>>> developers develop plugins which are designed to be themed as
opposed to be
> >>>>> ones that can only be used on sites that look like Plone sites.
 Most of
> >>>>> the above plugins install their own JS which may or may not be
> >>>>> with your theme. For example collective.cover uses deco.js.
Facetednav uses
> >>>>> it's own JS. The themer will have to go through a process of
testing these
> >>>>> themes to make sure they work with their theme regardless of if
they are
> >>>>> made to be compatible with the default plone theme or not. Your
> >>>>> doesn't prevent this unless we install every framework known. There
> >>>>> isn't this "common" library of JS and CSS that works with all
themes. By
> >>>>> enforcing such a set of CSS and JS you are instantly dating and
> >>>>> straightjacketing Plone to only be used by themers that know how to
> >>>>> with Plones version of jquery, plones version or Jquery UI, plones
> >>>>> of overlays etc. We keeping the club of people that can use Plone
to just
> >>>>> us experienced Plone developers and missing the opportunity to make
> >>>>> a system that is inviting for anyone to create a site or intranet.
 I see
> >>>>> no problem with plugins being opinionated and installing their own
CSS and
> >>>>> JS but obviously they have to do this at the risk of making it less
> >>>>> to be used by others since it will require more integration work.
Make all
> >>>>> Plone sites look the same doesn't solve that problem.  For example
> >>>>> current use of jquery means that it's impossible to use custom JS
in your
> >>>>> theme that requires a later version of jquery.  A Plone default
> >>>>> should be an "example" theme, not the basis for which all themes in
> >>>>> should be built. I think it would be great to ship with multiple
> >>>>> themes, perhaps based on different frameworks. If a plugin requires
the use
> >>>>> of bootstrap or the CSS that comes with a certain theme then they
> >>>>> make that an explicit dependency of their plugin. If we can
automate that,
> >>>>> even better.
> >>>>
> >>>> FWIW, I think flexibility can be a dangerous road when it comes to
> >>>> and can lead to issues with CSS and markup integrity. In general, if
> >>>> don’t have guidelines for markup and CSS they will make their own
> >>>> which then makes them harder to support and theme.  A framework, in
this case
> >>>> Bootstrap, might actually make theming Plone simpler and more
approachable to
> >>>> new themers.
> >>>>
> >>>> I truly don’t think it would be easier to theme Plone if it were
less styled
> >>>> and addons provided less in terms of markup and styles.
> >>>>
> >>>> I also don’t prefer it when addons decide to use their own
> >>>> frameworks that differ from plone core. In some cases it is
justified but in
> >>>> others it is just an opinion that gets in the way of my integrating
the addon
> >>>> into my theme.
> >>>>
> >>>> If we provide logical defaults and guidelines for addons that are
> >>>> well tested, neutral but attractive, and easy to customize with
> >>>> effort, I believe we make things much easier for most themers.  A
> >>>> does that.  Bootstrap is the logical choice because it has the most
> >>>> and popular support.
> >>>>
> >>>> Nothing about using Bootstrap as a starting point leads me to think
> >>>> every site has to look the same.  If anything I think it will open
the door
> >>>> for many more themes.  It does however, make it more difficult to use
> >>>> a different framework. Personally, I am fine with that trade off
> >>>> the simplicity that consistency and logical defaults might provide.
My worst
> >>>> case scenario is that Plone makes no assertions about markup and
styling and
> >>>> addons and themes diverge further than they already have.
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> In terms of Plone itself there is very little that needs styling
or JS
> >>>>>>> that is FE. Things like the contact form and public registrations
> >>>>>>> should try and remove I believe. These things we almost always
replace by
> >>>>>>> things like PFG as it gives more flexibility. We even do public
> >>>>>>> registration with PFG now via collective.pfg.signup. Commenting is
> >>>>>>> perhaps another feature that requires special CSS. It's not
> >>>>>>> I've ever used but perhaps it needs to go out of the core too?
> >>>>>>> search should be removed since it's a performance killer anyway
> >>>>>>> almost no public site would want to turn this on unless they can
> >>>>>>> guarantee a very light load.  Once you take all of that out, I
think you
> >>>>>>> only very basic styles such as those that can be set in tinymce.
 I think
> >>>>>>> we should make this set of style as small as possible and should
> >>>>>>> assume that any of p.a.widgets is available on the FE.
> >>>>>>>
> >>>>>>>> Currently in Plone there is a de facto "standard library" of
> >>>>>>>> available to add-on authors. You can get an idea of what's
included in
> >>>>>>>> this if you look at /test_rendering on a Plone 3 or Plone 4
site. As an
> >>>>>>>> add-on developer, I don't have to spend time on CSS or work with
> >>>>>>>> a designer, because I know what markup to use for a portlet or
an alert
> >>>>>>>> message or a form, and can expect that all Plone themes will
> >>>>>>>> styles for that markup. This idea of a markup library is similar
> >>>>>>>> Twitter Bootstrap, only ours has evolved organically over time
> >>>>>>>> than being carefully designed.
> >>>>>>>>
> >>>>>>>> We can decide to change this library of markup patterns for Plone
> >>>>>>>> 5 (switch to Bootstrap, perhaps), if we want. But we can't stop
> >>>>>>>> a library available altogether. The result would be that
> >>>>>>>> 1. Add-on authors have to spend time writing their own CSS
> >>>>>>>> 2. Different add-ons will not have a consistent look and feel
> >>>>>>>> 3. Themers will need to spend time overriding the styles for each
> >>>>>>>>    addon's markup, rather than merely implementing styles for the
> >>>>>>>>    standard markup
> >>>>>>> This side steps the issue that in reality themers spend that time
> >>>>>>> overriding the styles assumed by a plugin, whether its provided
by Plone
> >>>>>>> or not. We don't live in a world where websites look like their
> >>>>>>> anymore. We need to encourage an eco system of plugins that make
> >>>>>>> a minimum of style decisions, or make it really easy to diazo to
make the
> >>>>>>> markup work with our chosen style framework such as bootstrap. If
we try
> >>>>>>> to enforce a particular style framework on our themers we lose a
lot of
> >>>>>>> potential users of Plone because Plone is too opinionated. Plone
> >>>>>>> be the blanksheet that a designer can rely on to make any site
they want.
> >>>>>>> This makes Plone a truely useful CMS that will stand out of the
> >>>>>>
> >>>>>> I still think using a framework makes it easier for the themer.
> >>>>>
> >>>>> Yes but which framework? If plone relies of bootstrap 3 then we
lock out
> >>>>> anyone that doesn't want to use bootstrap 3. What happens if a
theme is
> >>>>> built on bootstrap 3 and plone 5 moves to bootstrap4?  Simpler more
> >>>>> independent plugins that are designed to not intefer with each
other and
> >>>>> have simple html that is easy to theme. I think this is the way to
> >>>>
> >>>> Then themes will need to be upgraded, however, the guidelines for
how to do
> >>>> so might be clear and consistent across the board.
> >>>>
> >>>>>
> >>>>>> They can style the conventional markup, instead of figuring out
> >>>>>> different markup each addon uses. It also provides greater
> >>>>>> A site can be left without a custom theme, if it's look isn't
> >>>>>> Or the style framework can be replaced with custom CSS. Or a
> >>>>>> theme addon can be used, since the markup is standard. If we don't
try to
> >>>>>> define common markup, the *only* option is writing a custom theme.
> >>>>>> that happens for most sites by the time the site launches, but
> >>>>>> in when it happens is good.
> >>>>>
> >>>>> I think there could be ways of handling this. For example a plugin
> >>>>> come with same css which you insert into your theme. This is as
opposed to
> >>>>> a plugin that fails to work at all if it doesn't include exactly
the CSS
> >>>>> that came with it and therefore you have to fight against the
plugin CSS to
> >>>>> be able to use the plugin with your custom theme.
> >>>>
> >>>> Again, I think not using a framework encourages addons to include
more CSS
> >>>> which is then harder to work with.  Of course, it could still be
> >>>> But what about the markup?  Do we make the markup optional?  How
would that
> >>>> work?  Well, the theme could include diazo rules to deal with the
markup for
> >>>> the addon, but that is more work for the themer.  In most cases,
> >>>> defaults are good, especially when they are consistent and modern.
> >>>> problem with plone now is that it is neither consistent nor modern
nor in
> >>>> some cases logical.
> >>>>
> >>>
> >>> i think we are forgetting what we are already doing.
> >>>
> >>> default plone theme provides easier way to theme plone and allows
addons to
> >>> know (almost) what kind of html/css to expect. in plone 4 we call it
> >>> in plone 5 we'll call it barceloneta. in the same manner addons in
future could
> >>> expect barceloneta based theme. in case of high customization you
will have to
> >>> manually fix things anyway.
> >>>
> >>> barceloneta (as far as i know, ramon please correct me if i'm wrong)
will be
> >>> based on bootstrap 3.if somebody prefers other framework please go
ahead and
> >>> create your own theme in a similar fasion that braceloneta is doing
it. so
> >>> there is no lockin.  i'm not huge fan of bootstap, but i recognize
most of
> >>> designers/developers are familiar with it and should provide low
entry barrier
> >>> and sane default.
> >>>
> >>> also important to mention is that there is "minimal" theme which
barceloneta is
> >>> based uppon -> no css only clean html which you can style from
> >>>
> >>> i dont see much problem with addons space in future. they will
continue to be
> >>> written in similar manner. what we will add is new area where addons
can hook
> >>> into - let call it "backend" for now. that dom space has more
> >>> css/html then frontend theme which changes from one to another
project and can
> >>> more reliably hook into it.
> >>>
> >>> so in short: we're *adding* possibility to addons to hook into
backend. how
> >>> they hooked into frontend stays the same as in plone 4.
> >>
> >>
> >> Wow, I'm only loosely following this thread and I had to jump back in
> >> Thunderbird to see the full discussion (I've been following things via
> >> Feedly/RSS for months.) :-) Anyway, first allow me to say this: I am
> >> very excited to see the discussion "heat up" over all things Plone 5 &
> >> in particular theming.
> >>
> >> Obviously, we have a variety of different use cases "battling it out".
> >> This is our chance to define what we want Plone 5 to be and it's
> >> important we get it right NOW, because we're going to be living with
> >> Plone 5 LATER (for the next few years at least). Now, let me take a
> >> back from the immediate theming discussion and reiterate what I want
> >> Plone 5 to be, FWIW:
> >>
> >> - Lightweight, fast & modern, in the Python sense. This means: fewer
> >> Python packages and as much deprecation of old technologies as humanly
> >> possible. Ripping stuff out and turning stuff off MUST be the priority,
> >> and easily represents the most challenging work. `pip install Plone` is
> >> still my benchmark for this. Not because I love pip, but because it's
> >> now part of the Python core and we need to start paying more attention
> >> to it IF we want the Python community's attention[1]. I've begun some
> >> work on something called Plock to bridge the gap: `pip install plock`
> >> until `pip install Plone` actually works[2].
> >>
> >> - Lightweight, fast & modern, in the Web sense. This means: using web
> >> technologies that web developers actually understand, are already
> >> familiar with, and can begin using quickly in the Plone context. I
> >> care about what framework we use (e.g. Bootstrap 3) as much as I INSIST
> >> the choice be lightweight, fast & modern in the Web sense. If that
> >> we pick Bootstrap 3 now and a new framework for Plone 6, so be it.
> >> That's a lot of work, but at least it is' *definable* work. My eyes
> >> glaze over and roll back in my head whenever the discussion turns to
> >> "how do we bring the right HTML/CSS/JavaScript in from Plone to our
> >>
> >> Much like with Buildout, I worry our choice to rely so heavily on Diazo
> >> may have been a mistake. Instead, I think we should focus on discussing
> >> why we needed Diazo in the first place. What is Plone? Is it a system
> >> that enables inline editing of websites for every-theme-on-earth? Are
> >> still aiming to perform every management task TTP (through-the-Plone)?
> >> If so, do we absolutely positively need Diazo to do this? If the answer
> >> is "yes", then I don't fully understand why. If the answer is "no",
> >> I'm no better off, because I don't know how to implement the above
> >> feature set without Diazo (i.e. I need to strictly control Plone's UI
> >> and let folks 'tie in' via Diazo). Obviously mapping content to a theme
> >> is attractive, which is why we all went for it in the first place. But
> >> if you look at any other modern system that allows customization (e.g.
> >> GMail) they make it easy for you to customize AND strictly limit what
> >> you can customize. I worry that by relying on an increasingly more
> >> complex Diazo rule set we are complicating the stack and still not
> >> achieving the goal of everything TTP.
> >>
> >> Lastly, I think we should make these decisions first then decide how to
> >> approach them in the current ecosystem. If we are confident about the
> >> direction, then we should have no issue documenting our progress and
> >> leading the users and integrators by example.
> >>
> >>
> >> Alex
> >>
> >>
> >> [1] This is just one case of many: "making Plone appealing to Python
> >> programmers." Arguably not even the most important, but one that I
> >> happen to care about.
> >>
> >> [2] https://github.com/aclark4life/plock
> >>
> >> [3] Both great tools, but overkill in a lot of cases where folks just
> >> want to "do Python & Web".
> >>
> >>
> >>
> >>>
> >>>
> >>> --
> >>> Rok Garbas - http://www.garbas.si
> >>>
> >>>
> >>> Shape the Mobile Experience: Free Subscription
> >>> Software experts and developers: Be at the forefront of tech
> >>> Intel(R) Software Adrenaline delivers strategic insight and
> >>> conversations that shape the rapidly evolving mobile landscape. Sign
up now.
> >>>
> >>> _______________________________________________
> >>> Plone-developers mailing list
> >>> Plone-developers at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/plone-developers
> >>>
> >>
> >>
> >>
> >>
> >> Shape the Mobile Experience: Free Subscription
> >> Software experts and developers: Be at the forefront of tech
> >> Intel(R) Software Adrenaline delivers strategic insight and
> >> conversations that shape the rapidly evolving mobile landscape. Sign
up now.
> >>
> >> _______________________________________________
> >> Plone-developers mailing list
> >> Plone-developers at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/plone-developers
> >
> > _______________________________________________
> > UI mailing list
> > UI at lists.plone.org
> > https://lists.plone.org/mailman/listinfo/plone-ui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20131122/9557f320/attachment-0001.html>

More information about the UI mailing list