Re: [Plone Mosaic Sprint Barcelona discussion] Re: Plone Mosaic Sprint Barcelona June 10 - 13

On 19/05/14 06:58, Asko Soukka wrote:
> Thanks Simone.
>>> Note that, the main goal here is to ease the way we present the
>>> content of the page (what's now identified by the
>>> #portal-columns element) not the entire site layout.
>
> Is this commonly agreed as the scope for the sprint? This would

I think so.

> definitively make the goal easier, because we can keep using the old
>  rendering for the rest.

Yes, the scope is big enough as it is for a four-day sprint...

Dylan says:
>> I would go one step further and say the themer should be given the
>>  freedom to decide how much control the admin and editors have
>> over the layout, ie a decision made at the birth of a new site.

Very important. This was my immediate concern when I saw the initial
Deco demos way back when. And this should not only be a global policy
but something that can be different for various parts of the site, or 
even tweakable at the tile/block level.

> This sounds like how p.a.blocks is made to support two level of
> layouts ootb: site layout and page layout.

I have some concerns about that. That doesn't seem to support the
level of granularity in access controls we're used to in Plone. It also
cuts the rendering problem space in two, which seems awkward. While I'm
all for solving the #portal-columns rendering first I'd rather not lock
myself in a box.

>>> Another difficult part - maybe not so difficult - is: which kind
>>> of blocks do we want? We had an interesting discussion with
>>> Ramon about the fact that portlets could fit the requirements
>>> instead of tiles
>
> This more political than technical issue, because we can make all of
>  them (viewlets, portlets, tiles). Personally, I would not want to
> limit the options.

Maximizing compatibility increases the viability of this project.
"Be conservative in what you omit and liberal in what you accept."

>> One other goal that wasn't mentioned aspart of the discussion was
>> one of the original deco goals of simplifying the editing
>> experience by removing default pages, folders and collections and
>> replace them with a way to insert blocks/tiles/portlets into the
>> middle of the page.

I'm strongly for separating the problem of layout editing from the 
problem of content editing. Mixing those two and then also changing the 
object model underneath is a recipe for failure at this stage.

>> I realise this will unlikely be in the minds of those at the
>> sprint. However I think that we don't want multiple systems in the
>> core to do layout and insert stuff, so hopefully whatever is built

The Plone Way ;-) http://xkcd.com/927/ But of course you're right.

>> should be thinking about how to make plone simpler for beginners
>> managing content not just provide tools for the most complex sites.
>> That's my hope anyway.

We agree on that goal. IMO creating an elegant solution for a complex 
problem is likely to result in elegant solutions for simpler problems as 
well. Once we have a good and flexible grid layout solution, we can use 
that as a foundation for better content editing experiences. I would 
argue that the UX of the editing experience overall will benefit from a 
clean separation between the concerns of layout and content.

:*CU#
-- 
     Guido Stevens  |  +31.43.3618933  |  http://cosent.nl

     s o c i a l   k n o w l e d g e   t e c h n o l o g y


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs