Folderish content PLIP

classic Classic list List threaded Threaded
12 messages Options
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Folderish content PLIP

Hi,

I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.

https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#

What do you think?

Dylan Jay

---
www.pretagov.com - Secure SaaS for Government hosted locally.
P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75



_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
ajung ajung
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

This post has NOT been accepted by the mailing list yet.
Dylan Jay wrote
Hi,

I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.

https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#

What do you think?

Dylan Jay
The general idea to make all content-types folderish is nonsense. What is the semantics of a folderish "Image"? I agree that are special cases where non-folderish content-types could be folderish e.g. a folderish page type holding only images for being displayed as slideshow - this make sense.  But a general folderish behavior does not make sense and appears confusing.
The current default page handling with folders with partly broken. Not that the feature is broken but how it is handled especially inside the navigation portlet (the default is always hidden in the navigation portlet). Most remarks related to the default page handling is affected by its handling in the navigation. This should be fixed instead of introducing a more generic behavior...this PLIP appears to complex to me ..it tries to solve a problem by introducing a much more complex pattern....sorry, -1.

-aj

ajung ajung
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

This post has NOT been accepted by the mailing list yet.
In reply to this post by Dylan Jay
Dylan Jay wrote
> Hi,
>
> I'm working on a folderish content plone5 PLIP to put together the ideas
> discussed up to now and try and get more support.
>
> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>
> What do you think?
>
> Dylan Jay
The general idea to make all content-types folderish is nonsense. What is
the semantics of a folderish "Image"? I agree that are special cases where
non-folderish content-types could be folderish e.g. a folderish page type
holding only images for being displayed as slideshow - this make sense.  But
a general folderish behavior does not make sense and appears confusing.
The current default page handling with folders with partly broken. Not that
the feature is broken but how it is handled especially inside the navigation
portlet (the default is always hidden in the navigation portlet). Most
remarks related to the default page handling is affected by its handling in
the navigation. This should be fixed instead of introducing a more generic
behavior...this PLIP appears to complex to me ..it tries to solve a problem
by introducing a much more complex pattern....sorry, -1.

-aj
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

In reply to this post by Dylan Jay
On 12/10/13, 6:43 AM, Dylan Jay wrote:
> Hi,
>
> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>
> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>
> What do you think?
>
>
This is quite a large development task that hasn't been started yet. I'm
not comfortable with adding it to the scope of Plone 5, as I think
adding it would delay Plone 5 by at least half a year, at best.

I also don't like the idea of adding tiles to Plone core without
unifying the concepts of tiles, viewlets, and portlets.

David
_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP


On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
>
> On 12/10/13, 6:43 AM, Dylan Jay wrote:
>>
>> Hi,
>>
>> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>>
>> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>>
>> What do you think?
>>
>>
> This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.

Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
However unless we get more support to get this started now we don't have a choice.

>
> I also don't like the idea of adding tiles to Plone core without unifying the concepts of tiles, viewlets, and portlets.

Its not perfect I admit. But we have to make some kind of stepping stone. Removing portlets would be bad without having a solid replacement. Here we are only introducing tiles as a content area thing. It allows us to get it into the core for a good reason. Then we can build an eco system around tiles and give enough time to deprecate portlets and viewlets.
At the moment we aren't changing anything because its no big bang enough. I think this is a good pragmatic approach

>
> David


_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP


On 11 Dec 2013, at 9:42 am, Dylan Jay <[hidden email]> wrote:

>
> On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
> >
> > On 12/10/13, 6:43 AM, Dylan Jay wrote:
> >>
> >> Hi,
> >>
> >> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
> >>
> >> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
> >>
> >> What do you think?
> >>
> >>
> > This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.
> Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
> However unless we get more support to get this started now we don't have a choice.

Alternatively we could target it for having a quick plone 6 after plone 5 and warn people there will be another backwards compatible upgrade coming soon?
I really don't think we should wait for removing viewlets and portlets though. I don't think it's clear at this stage that what was proposed for page layouts in deco would work in practice. I suspect we might end up replacing viewlets with something akin to tiles placed via diazo rules, ie under themer control. Portlets I'm not sure about. We could potentially allow tiles to be added as portlets as a way to transition? Then rethink how portlets work later? Portlets have lots of issues we'd need to address like that they don't have workflow, working copy support, sharing permissions etc. These things weren't really covered by the deco layout proposals.

>
> >
> > I also don't like the idea of adding tiles to Plone core without unifying the concepts of tiles, viewlets, and portlets.
>
> Its not perfect I admit. But we have to make some kind of stepping stone. Removing portlets would be bad without having a solid replacement. Here we are only introducing tiles as a content area thing. It allows us to get it into the core for a good reason. Then we can build an eco system around tiles and give enough time to deprecate portlets and viewlets.
> At the moment we aren't changing anything because its no big bang enough. I think this is a good pragmatic approach
>
> >
> > David

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

On 12/10/13, 7:45 PM, Dylan Jay wrote:

> On 11 Dec 2013, at 9:42 am, Dylan Jay <[hidden email]> wrote:
>
>> On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
>>> On 12/10/13, 6:43 AM, Dylan Jay wrote:
>>>> Hi,
>>>>
>>>> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>>>>
>>>> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>>>>
>>>> What do you think?
>>>>
>>>>
>>> This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.
>> Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
>> However unless we get more support to get this started now we don't have a choice.
> Alternatively we could target it for having a quick plone 6 after plone 5 and warn people there will be another backwards compatible upgrade coming soon?
> I really don't think we should wait for removing viewlets and portlets though. I don't think it's clear at this stage that what was proposed for page layouts in deco would work in practice. I suspect we might end up replacing viewlets with something akin to tiles placed via diazo rules, ie under themer control. Portlets I'm not sure about. We could potentially allow tiles to be added as portlets as a way to transition? Then rethink how portlets work later? Portlets have lots of issues we'd need to address like that they don't have workflow, working copy support, sharing permissions etc. These things weren't really covered by the deco layout proposals.
>
Yeah, I was thinking not so much of totally replacing the portlet and
viewlet mechanisms, but more just making it so that tiles can be used in
portlet managers and viewlet managers, and translating the existing
portlets and viewlets into tiles. That way it's possible to create a
component (a tile) which can be used in any location, rather than
needing to pick the right type of component based on where you want to
put it.

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

On 11 Dec 2013, at 4:36 pm, David Glick (Plone) <[hidden email]> wrote:

> On 12/10/13, 7:45 PM, Dylan Jay wrote:
>> On 11 Dec 2013, at 9:42 am, Dylan Jay <[hidden email]> wrote:
>>
>>> On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
>>>> On 12/10/13, 6:43 AM, Dylan Jay wrote:
>>>>> Hi,
>>>>>
>>>>> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>>>>>
>>>>> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>> This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.
>>> Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
>>> However unless we get more support to get this started now we don't have a choice.
>> Alternatively we could target it for having a quick plone 6 after plone 5 and warn people there will be another backwards compatible upgrade coming soon?
>> I really don't think we should wait for removing viewlets and portlets though. I don't think it's clear at this stage that what was proposed for page layouts in deco would work in practice. I suspect we might end up replacing viewlets with something akin to tiles placed via diazo rules, ie under themer control. Portlets I'm not sure about. We could potentially allow tiles to be added as portlets as a way to transition? Then rethink how portlets work later? Portlets have lots of issues we'd need to address like that they don't have workflow, working copy support, sharing permissions etc. These things weren't really covered by the deco layout proposals.
>>
> Yeah, I was thinking not so much of totally replacing the portlet and viewlet mechanisms, but more just making it so that tiles can be used in portlet managers and viewlet managers, and translating the existing portlets and viewlets into tiles. That way it's possible to create a component (a tile) which can be used in any location, rather than needing to pick the right type of component based on where you want to put it.

That would be nice. If this did take longer do you think it would be bad if that made it into a dot release such as 5.1? It's giving people another way to create viewlets or portlets rather than taking away anything so I don't think it would be backwards incompatible. Then we could work towards Plone 6 which could include replacing viewlets and portlets completely and perhaps include a grid system for laying out tiles.



_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

Hi Hector,

As someone who has worked on collective.cover I was curious what your opinion on the draft PLIP was.
Specifically bringing in Tiles into Plone 5 but not introducing a layout or grid system. Allowing them just to be used like you'd insert an image into the visual editor.
My reasoning is
- It helps get rid of default pages which is a big UI win
- it gets us closer to deco
- but without fundamentally changing how content is edited or if a grid is required for all themes. Leaving that until later when we are more certain.
- it's ok to have portlets and tiles coexist. Particularly if we can build some kind of bridge between the two. It allows migration to occur.

BTW, David, you are right, we'd be better off creating a way for tiles to be used as portlets than visa versa. That would push more reimplementations of portlets to tiles which is what we would want. Having a way to use portlets as tiles would just delay people from changing their code. I don't think that would be hard to do. I'll add it to the PLIP.

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 11 Dec 2013, at 4:52 pm, Dylan Jay <[hidden email]> wrote:

> On 11 Dec 2013, at 4:36 pm, David Glick (Plone) <[hidden email]> wrote:
>
>> On 12/10/13, 7:45 PM, Dylan Jay wrote:
>>> On 11 Dec 2013, at 9:42 am, Dylan Jay <[hidden email]> wrote:
>>>
>>>> On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
>>>>> On 12/10/13, 6:43 AM, Dylan Jay wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>>>>>>
>>>>>> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>>
>>>>> This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.
>>>> Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
>>>> However unless we get more support to get this started now we don't have a choice.
>>> Alternatively we could target it for having a quick plone 6 after plone 5 and warn people there will be another backwards compatible upgrade coming soon?
>>> I really don't think we should wait for removing viewlets and portlets though. I don't think it's clear at this stage that what was proposed for page layouts in deco would work in practice. I suspect we might end up replacing viewlets with something akin to tiles placed via diazo rules, ie under themer control. Portlets I'm not sure about. We could potentially allow tiles to be added as portlets as a way to transition? Then rethink how portlets work later? Portlets have lots of issues we'd need to address like that they don't have workflow, working copy support, sharing permissions etc. These things weren't really covered by the deco layout proposals.
>>>
>> Yeah, I was thinking not so much of totally replacing the portlet and viewlet mechanisms, but more just making it so that tiles can be used in portlet managers and viewlet managers, and translating the existing portlets and viewlets into tiles. That way it's possible to create a component (a tile) which can be used in any location, rather than needing to pick the right type of component based on where you want to put it.
>
> That would be nice. If this did take longer do you think it would be bad if that made it into a dot release such as 5.1? It's giving people another way to create viewlets or portlets rather than taking away anything so I don't think it would be backwards incompatible. Then we could work towards Plone 6 which could include replacing viewlets and portlets completely and perhaps include a grid system for laying out tiles.
>
>
>

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

On 23 Jan 2014, at 10:17 am, Dylan Jay <[hidden email]> wrote:

> Hi Hector,
>
> As someone who has worked on collective.cover I was curious what your opinion on the draft PLIP was.
> Specifically bringing in Tiles into Plone 5 but not introducing a layout or grid system. Allowing them just to be used like you'd insert an image into the visual editor.
> My reasoning is
> - It helps get rid of default pages which is a big UI win
> - it gets us closer to deco
> - but without fundamentally changing how content is edited or if a grid is required for all themes. Leaving that until later when we are more certain.
> - it's ok to have portlets and tiles coexist. Particularly if we can build some kind of bridge between the two. It allows migration to occur.
>
> BTW, David, you are right, we'd be better off creating a way for tiles to be used as portlets than visa versa. That would push more reimplementations of portlets to tiles which is what we would want. Having a way to use portlets as tiles would just delay people from changing their code. I don't think that would be hard to do. I'll add it to the PLIP.

Forgot but tinymcetiles allows this out of the box (see https://github.com/collective/collective.tinymcetiles) since a static text portlet will also be able to have tiles inserted into them. So any tile can then be a portlet.

>
> 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 11 Dec 2013, at 4:52 pm, Dylan Jay <[hidden email]> wrote:
>
>> On 11 Dec 2013, at 4:36 pm, David Glick (Plone) <[hidden email]> wrote:
>>
>>> On 12/10/13, 7:45 PM, Dylan Jay wrote:
>>>> On 11 Dec 2013, at 9:42 am, Dylan Jay <[hidden email]> wrote:
>>>>
>>>>> On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
>>>>>> On 12/10/13, 6:43 AM, Dylan Jay wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>>>>>>>
>>>>>>> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>> This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.
>>>>> Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
>>>>> However unless we get more support to get this started now we don't have a choice.
>>>> Alternatively we could target it for having a quick plone 6 after plone 5 and warn people there will be another backwards compatible upgrade coming soon?
>>>> I really don't think we should wait for removing viewlets and portlets though. I don't think it's clear at this stage that what was proposed for page layouts in deco would work in practice. I suspect we might end up replacing viewlets with something akin to tiles placed via diazo rules, ie under themer control. Portlets I'm not sure about. We could potentially allow tiles to be added as portlets as a way to transition? Then rethink how portlets work later? Portlets have lots of issues we'd need to address like that they don't have workflow, working copy support, sharing permissions etc. These things weren't really covered by the deco layout proposals.
>>>>
>>> Yeah, I was thinking not so much of totally replacing the portlet and viewlet mechanisms, but more just making it so that tiles can be used in portlet managers and viewlet managers, and translating the existing portlets and viewlets into tiles. That way it's possible to create a component (a tile) which can be used in any location, rather than needing to pick the right type of component based on where you want to put it.
>>
>> That would be nice. If this did take longer do you think it would be bad if that made it into a dot release such as 5.1? It's giving people another way to create viewlets or portlets rather than taking away anything so I don't think it would be backwards incompatible. Then we could work towards Plone 6 which could include replacing viewlets and portlets completely and perhaps include a grid system for laying out tiles.
>>
>>
>>
>

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

In reply to this post by Dylan Jay
On 25 Jan 2014, at 11:15 am, Héctor Velarde <[hidden email]> wrote:

> sorry for the delay in answering; I'm out of the office.
>
> I was reading all the stuff around this PLIP and I don't know, guys.
>
> 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?

>
> 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.

>
> anyway, I don't think we need tiles to fix this, and also I'm not in favor of linking this to TinyMCE. what would happen with people wanting to use a different WYSIWYG editor?

Another editor would just have to be able to insert a tile in the same way it has to be able to insert an image. It's not a big integration.

>
> 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?

>
> I think most of these features could be included after Plone 5 has been launched. I'm also in favor of refactoring all portlets infrastructure to use tiles.

I think changing the base class of all the content types and removing default pages will break things to the extent that I can't see it being in a dot release.

>
> 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.

>
> let me know if I can help you in anything else.
>
> Héctor Velarde
>
> On 22-01-2014 21:17, Dylan Jay wrote:
>> Hi Hector,
>>
>> As someone who has worked on collective.cover I was curious what your opinion on the draft PLIP was.
>> Specifically bringing in Tiles into Plone 5 but not introducing a layout or grid system. Allowing them just to be used like you'd insert an image into the visual editor.
>> My reasoning is
>> - It helps get rid of default pages which is a big UI win
>> - it gets us closer to deco
>> - but without fundamentally changing how content is edited or if a grid is required for all themes. Leaving that until later when we are more certain.
>> - it's ok to have portlets and tiles coexist. Particularly if we can build some kind of bridge between the two. It allows migration to occur.
>>
>> BTW, David, you are right, we'd be better off creating a way for tiles to be used as portlets than visa versa. That would push more reimplementations of portlets to tiles which is what we would want. Having a way to use portlets as tiles would just delay people from changing their code. I don't think that would be hard to do. I'll add it to the PLIP.
>>
>> 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 11 Dec 2013, at 4:52 pm, Dylan Jay <[hidden email]> wrote:
>>
>>> On 11 Dec 2013, at 4:36 pm, David Glick (Plone) <[hidden email]> wrote:
>>>
>>>> On 12/10/13, 7:45 PM, Dylan Jay wrote:
>>>>> On 11 Dec 2013, at 9:42 am, Dylan Jay <[hidden email]> wrote:
>>>>>
>>>>>> On 11 Dec 2013 06:46, "David Glick (Plone)" <[hidden email]> wrote:
>>>>>>> On 12/10/13, 6:43 AM, Dylan Jay wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm working on a folderish content plone5 PLIP to put together the ideas discussed up to now and try and get more support.
>>>>>>>>
>>>>>>>> https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>>
>>>>>>> This is quite a large development task that hasn't been started yet. I'm not comfortable with adding it to the scope of Plone 5, as I think adding it would delay Plone 5 by at least half a year, at best.
>>>>>> Yes I agree. On the other hand its also a very backwards incompatible change but one with large usability benefit. Do we want a plone 6 release 6 months after plone 5?
>>>>>> However unless we get more support to get this started now we don't have a choice.
>>>>> Alternatively we could target it for having a quick plone 6 after plone 5 and warn people there will be another backwards compatible upgrade coming soon?
>>>>> I really don't think we should wait for removing viewlets and portlets though. I don't think it's clear at this stage that what was proposed for page layouts in deco would work in practice. I suspect we might end up replacing viewlets with something akin to tiles placed via diazo rules, ie under themer control. Portlets I'm not sure about. We could potentially allow tiles to be added as portlets as a way to transition? Then rethink how portlets work later? Portlets have lots of issues we'd need to address like that they don't have workflow, working copy support, sharing permissions etc. These things weren't really covered by the deco layout proposals.
>>>>>
>>>> Yeah, I was thinking not so much of totally replacing the portlet and viewlet mechanisms, but more just making it so that tiles can be used in portlet managers and viewlet managers, and translating the existing portlets and viewlets into tiles. That way it's possible to create a component (a tile) which can be used in any location, rather than needing to pick the right type of component based on where you want to put it.
>>>
>>> That would be nice. If this did take longer do you think it would be bad if that made it into a dot release such as 5.1? It's giving people another way to create viewlets or portlets rather than taking away anything so I don't think it would be backwards incompatible. Then we could work towards Plone 6 which could include replacing viewlets and portlets completely and perhaps include a grid system for laying out tiles.
>>>
>>>
>>>
>>
>

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui

signature.asc (506 bytes) Download Attachment
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Folderish content PLIP

On 26 Jan 2014, at 6:20 am, Héctor Velarde <[hidden email]> wrote:

> On 25-01-2014 14:38, Dylan Jay wrote:
>> On 25 Jan 2014, at 11:15 am, Héctor Velarde <[hidden email]> 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




_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui

signature.asc (506 bytes) Download Attachment