<p dir="ltr"><br>
On 22 Nov 2013 05:06, "David Glick (Plone)" <<a href="mailto:david.glick@plone.org">david.glick@plone.org</a>> wrote:<br>
><br>
> On 11/21/13, 9:56 AM, Dylan Jay wrote:<br>
>><br>
>><br>
>> On 21 Nov 2013 23:24, "André Nogueira" <<a href="mailto:andre@simplesconsultoria.com.br">andre@simplesconsultoria.com.br</a>> wrote:<br>
>> ><br>
>> > I know a lot of people that just use Plone as a framework.<br>
>> > Just edit one custom CSS file and transform the Frontend. No python<br>
>> > and no PHP too :) And no XML :)<br>
>> > This is the easyer and most important way to use Plone now<br>
>> ><br>
>> > To me, the basic steps for a new themer (for regular users not<br>
>> > advanced users) is:<br>
>> > 1. Clone the default DIazo theme<br>
>> > 2. Try to find and change the logo<br>
>> > 3. Try to make some CSS chances<br>
>> ><br>
>> > Newcommer and basic users will never create a Diazo theme from the<br>
>> > scracth. I dont see this action as a trivial action. Can be trivial<br>
>> > just for advanced front end developers<br>
>> ><br>
>> > To me, trown all the Front end responsability to custom diazo themes<br>
>> > could kill one of the Plone most important feature: Accessibility. We<br>
>> > really need a strong starting point for new themes and for small<br>
>> > customizations.<br>
>><br>
>> I agree we need a good starting point for themes that want to start with a base plone theme. <br>
>> 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.<br>
>><br>
>> ><br>
>> > To me, the only option to make plone more popular with the public you<br>
>> > are aiming, is to reach this 5 points:<br>
>> ><br>
>> > 1. One click install in production (something like Ploud or ready to<br>
>> > use droplet in digital ocean or similar players)<br>
>> > 2. A great number of high quality themes.<br>
>> > 3. Very easy way to customize this themes (change logo and base<br>
>> > colors). A editor based in LESS/SASS will be amazing.<br>
>> > 4. Very easy way to install addons<br>
>> > 5. very easy way to updat Plone and addons<br>
>> ><br>
>> > Only after that, Plone can become popular.<br>
>><br>
>> I agree with you. This will make plone even more popular than what I suggest. <br>
>> 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. <br>

>> 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 plugins. <br>
>> 1. Basic content styles. Eg header, call out, title <br>
>> 2. Side nav styles<br>
>> 3. Sitemap ? Or can we drop this?<br>
>> 4. Left and right portlet styles<br>
>> 5. ?<br>
>><br>
>> Things we no longer need insist a theme includes <br>
>> - live search js and CSS<br>
>> - editing and toolbar <br>
>> - info/error boxes<br>
>> - floated document actions like print<br>
><br>
> We can achieve this by simply making sure it's easy to disable the things that some people don't want to theme, right?<br>
><br>
> We already have a setting to toggle live search.<br>
><br>
> Sitemap and document actions are easy to disable in portal_actions, although that's not particularly obvious. A Plone control panel for managing actions would be good.<br>
><br>
> Status messages probably need to stay in many cases, but are easy enough to drop using Diazo.<br></p>
<p dir="ltr">Maybe its three lists. Compulsory, recommended and not included?<br>
This needs to consider plugins too. For example if we say that bootstrap is compulsory then plugins can use anything that bootstrap styles and expect it to look good. However if just the default theme uses bootstrap then plugin authors need to provide simpler markup that can be customoised if not covered by the compulsory styles.  </p>

<p dir="ltr">><br>
</p>