Re: [Plone-UI] Plone 5 Theme

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 <[email protected]> wrote:
>>
>>>
>>> On 20 Nov 2013, at 4:26 am, David Glick (Plone) <[email protected]>
>>> wrote:
>>>
>>>> On 11/19/13, 1:27 AM, Dylan Jay wrote:
>>>>> On 19 Nov 2013, at 9:02 am, David Glick (Plone) <[email protected]>
>>>>> 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 :
>>>>>>>
>>>>>>> http://bloc.jardigrec.cat/2013/11/plone-5-theme-plonethemebarceloneta.html
>>>>>>>
>>>>>>> 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 UI
>>>>>> 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 custom
>>>>>> 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, or
>>>>>> a custom template that renders in the content area? These are common.
>>>>> +1 it's something we haven't talked enough about.  However I'm -1 that
>>>>> 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 plugins
>>>>> 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 - Plomino
>>>>> - 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 - Solgema.fullcalendar
>>>> - collective.plonetruegallery - eea.facetednavigation - cioppino.twothumbs
>>>>
>>>> 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 UI.
>>>
>>> I'm not saying we remove the consistent way to inject CSS and JS. I'm
>>> 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 compatible
>>> 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 suggestion
>>> doesn't prevent this unless we install every framework known. There really
>>> 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 work
>>> with Plones version of jquery, plones version or Jquery UI, plones version
>>> 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 Plone
>>> 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 likely
>>> 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 Plone's
>>> 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 theme
>>> should be an "example" theme, not the basis for which all themes in Plone
>>> should be built. I think it would be great to ship with multiple example
>>> 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 should
>>> 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 theming
>> and can lead to issues with CSS and markup integrity. In general, if addons
>> don’t have guidelines for markup and CSS they will make their own choices,
>> 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 opinionated
>> 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 popular,
>> well tested, neutral but attractive, and easy to customize with little
>> effort, I believe we make things much easier for most themers.  A framework
>> does that.  Bootstrap is the logical choice because it has the most backing
>> and popular support.
>>
>> Nothing about using Bootstrap as a starting point leads me to think that
>> 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 considering
>> 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 we
>>>>> 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 user
>>>>> registration with PFG now via collective.pfg.signup. Commenting is
>>>>> perhaps another feature that requires special CSS. It's not something
>>>>> I've ever used but perhaps it needs to go out of the core too? Live
>>>>> search should be removed since it's a performance killer anyway and
>>>>> 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 not
>>>>> assume that any of p.a.widgets is available on the FE.
>>>>>
>>>>>> Currently in Plone there is a de facto "standard library" of markup
>>>>>> 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 provide
>>>>>> styles for that markup. This idea of a markup library is similar to
>>>>>> Twitter Bootstrap, only ours has evolved organically over time rather
>>>>>> 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 having
>>>>>> 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 CMS
>>>>> 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 should
>>>>> 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 pack.
>>>>
>>>> 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 go.
>>
>> 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 what
>>>> different markup each addon uses. It also provides greater flexibility.
>>>> A site can be left without a custom theme, if it's look isn't important.
>>>> Or the style framework can be replaced with custom CSS. Or a published
>>>> 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. Yes,
>>>> that happens for most sites by the time the site launches, but flexibility
>>>> in when it happens is good.
>>>
>>> I think there could be ways of handling this. For example a plugin could
>>> 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 optional.
>> 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, logical
>> defaults are good, especially when they are consistent and modern.  The
>> 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 sunburst
> 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 scratch.
>
> 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 predictable
> 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 to 
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 step 
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 don't 
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 means 
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 theme".

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 we 
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", then 
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 innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Plone-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>



------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Plone-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-developers