[Plone-UI] Folderish content PLIP

Tue Jan 28 01:00:38 UTC 2014

On 26 Jan 2014, at 6:20 am, Héctor Velarde <hector.velarde at gmail.com> wrote:

> On 25-01-2014 14:38, Dylan Jay wrote:
>> On 25 Jan 2014, at 11:15 am, Héctor Velarde <hector.velarde at gmail.com> wrote:
>>> I think we are trying to change to many things on Plone 5 without having a clear path for this... or probably I'm missing most of the story.
>> 
>> Clear path?
> 
> HV> yes, a clear path; IIRC, at the beginning Plone 5 was about having Dexterity, Diazo, Chameleon and Deco; the later is not going to happen and the last I heard was this post from Eric: http://willrantforbeer.com/post/52975919723/plone-5
> 
> it mentions replacing Deco grid system with something else, an it does not mentions anything about tiles.
> 
> all the stuff there is doable and it doesn't represent huge risk as almost everything has been proved in production on earlier releases.
> 
> I think we can start using tiles to replace portlets infrastructure, but we will have to maintain the portlets probably until Plone 6.
> 
>>> I have no strong opinion on the folderish/default page; for me is not an issue but I almost don't have to deal with end users and I don't know if this is an issue. I would love to know what André has to say about this.
>> 
>> you really see it when you train people. I think a lot of us developers end up solving the problems of making Plone flexible and powerful as thats what we need for our jobs. We often don't get to see the beginner experience. A lot of stuff we take for granted is not that intuitive at all.
> 
> HV> we have to be careful here: Plone is not an entry level CMS and I don't want it to be less powerful just to solve some use cases with beginners.
> 
> we have been working last year on reproducible yet powerful site configurations that let us compete on the WordPress and Joomla market share but we are mostly playing on another league with most of our customers and we want to keep power and flexibility.
> 
>>> I was trying to test collective.tinymcetiles but I wasn't able to make it work.
>> 
>> Looks like this is the commit that broke it https://github.com/plone/plone.app.tiles/commit/1ff564180181346f07cb166f0e7145fc4405808d
>> It used the json tiledata to insert the dummy image and close the popup. Is this a change that c.cover needs?
> 
> HV> no, I have no idea what was that commit about.
> 
>>> In my opinion the problem with Deco is a little bit more complex: original Deco idea (AFAIK) was a layout framework with a layout editor and a grid system. the idea was really revolutionary 5 years ago, but, as the concept was never fully implemented, some stuff is now showing its limitations. for me Deco is way dead and is not going to happen ever.
>>> 
>>> now, to push the development of a layout editor for Plone using the rest of Deco's infrastructure we will probably need the following:
>>> 
>>> - finish plone.app.widgets and plone.app.toolbar
>>> - get rid of the Deco grid system; designers and developers could select whatever grid system they want to use
>>> - link the future of the layout editor to collective.cover to avoid duplication of efforts; collective.cover layout editor is working but is limited, I don't know what's the current status of Deco's one
>>> 
>>> I think the future of tiles and the layout editor is related with the future of collective.cover.
>> 
>> I think this is probably true. I see this as a stepping stone to that as collective.cover isn't ready to replace the Page type yet. This isn't trying to solve the layout problem. Just make content UI simpler and easier to understand. Deco wasn't just about layout, but also about a simpler more powerful content model. For example collections just being pages with a collection tile on it.
>> I think for now the goal is to do enough work to show this will be an easier content editing solution. Only after that will I submit the PLIP.
> 
> HV> I don't understand what you're saying here; collective.cover is something completely different from a Page; our idea was never to replace a Page type because a Page type is a different creature. collective.cover wasn't about replacing Deco neither.
> 
> collective.cover is about landing pages: flexible, complex, yet simple to create and manage; you can easily replace and surpass a Page with a Cover using its standard content type view, and you can do many more things with it.
> 
> there are many ways to replace a Collection, inserting tiles on the body text could be one, but, as someone else mentioned, creating a Collection behavior could be another.
> 
> I mentioned many months ago that we want to join efforts to help on the development of standard tiles and a standard layout editor but we are a small company with limited resources and, to survive and progress, we have to very pragmatic on the way we use them.
> 
> I want to kill collective.cover tiles to use Plone standard tiles and I want to use the Plone standard layout editor, so we can concentrate on developing the missing parts of collective.cover like permissions and UI.
> 
> but if I need to chose between working on collective.cover and working on plone.app.deco I will have to keep with the earlier because that's one of our biggest business differentials right now.
> 
> I want to change that.

Hi Hector, 

The Plone roadmap is what we make it however I'm not suggesting we introduce tiles without first showing they work well in practice.
On the other hand, at the moment the Plone 5 release includes a lot of changes to help Plone under the hood and also aid integrators. It doesn't contain a lot to help the end users, the editors. The new folder contents implementation is perhaps the only exception. We run the risk of Plone that is hard to sell as an upgrade to clients. You might say "so what?". Well the danger there is you get a python3 type situation where no one is upgrading to plone5 except perhaps some new sites. This means not all the development effort is going into plone 5 and progress is slowed in the future. I currently run most of my sites on Plone 4.1 because the pain of upgrading outweighs the benefits I can promise to my customers.

So let's say removing default pages is a big advance for end users and be a good reason to upgrade to plone5 (needs to be proved with user testing)

Then it's just a matter of choosing how we solve combining dynamic content onto a page which contains subpages (a problem default pages solved).

The options I can see are :-

1. something like deco or cover which means all our pages are no longer single html but are divided into subobjects (tiles) and combined into a grid. I think we both agree it's too soon for this and too much of a change?
2. Insist all 3rd party types are folderish so if you want something complex you move your subpages into it. I think this will create another python3 situation where all your plugins need to change to be used, slowing uptake.
3. Use behaviours for all complex views such as collections. It's not clear there will be a way to do per object behaviour setting so I'm not even sure how this would work in practice.
4. Keep pages the same as they are now but allow inserting dynamic behaviour where you want to on the page. Like shortcodes in wordpress or inserting objects into a word document. If you want a collection then insert one into the page. If you want 2 collections side by side insert them. If you want to include the body of another 3rd party type you can. If an integrator wants to allow a special kind of content such as a form or a flash object to be added into a page, they can just create a new tile. Image being able to create tiles TTW like you can in this wordpress shortcode video [1]. We should be able to do that in Plone.

To me, of these options #4 seems to give the best combination of ease of use, power and not too much risk. Only 1 & 4 give us the extra power of having multiple types of content on one page.
I'm trying to see the downsides which is why I need your help. If you think this proposal provides less flexibility then please say so.

So far the downsides you mentioned :-
- alternative visual editors would have to integrate inserting tiles. I don't see this as a big risk. They have to integrate inserting images and resolveuid links. The integration code is very small. The hard work is done in a transform layer.

Others I can see :-
-  in a future release, if we want to go for #1 would introducing #4 in a previous release make things confusing. ie would it be confusing to allow tiles to be inserted inside the visual editor inside a tile? or would we insist that tiles are removed from inside editable content and turned into a grid layout of tiles?
- we end up integrating tiles infrastructure too early and we will need to refactor it later to add missing things. Is this a big risk?
- anything else?

[1] http://www.youtube.com/watch?v=Ai56zFq-B3g

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20140128/5d75134d/attachment.asc>