[Plone-UI] Folderish Page Proposal

Guido Stevens guido.stevens at cosent.net
Tue Oct 22 07:00:53 UTC 2013


So instead of having folders with default pages, we'll have folderish pages which are the hardcoded default page of their own folder.

What Dylan highlights is significant, in that the issue of "You're now editing the default page. Do you want to edit it's container instead?" Is not a bug. It's a fundamental feature of our object graph.

Moving to "folderish pages" does not eliminate the meaningful difference between the /concepts/ of "folder" versus "page" from a user experience perspective. 

We should be very careful not to trick ourselves into thinking we can solve the default page issue by technically making folders and pages identical. Only to find that we now have spread the conceptual confusion of "do you want that only here, or in the whole subtree" all over the place, affecting all folders/pages.

I'm not arguing for/against folderish pages. Just want to flag it may compound instead of solve the issues it's intended to solve.
--
   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


On 22 okt. 2013, at 04:22, Dylan Jay <djay at pretaweb.com> wrote:

> 
> On 21/10/2013, at 11:12 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
> 
>> yes, let's do it :)
> 
> There is more to change than we think. So far working on this document [1] I've uncovered portlets setting on folders vs page, sharing tab settings applying to page vs folder, and how will Iterate work?
> Any form like sharing that works differently if used on a folder vs a page will have to change to allow an explicit selection of something like "do you want it to apply just to this item or the subsection". I think thats a good thing though. Not sure how it might complicate the internal code however.
> 
> [1] https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit#heading=h.i4eaajle9ew5
> 
> 
>> 
>> 
>> On Mon, Oct 21, 2013 at 9:10 PM, Dylan Jay <djay at pretaweb.com> wrote:
>> Just got this support request verbatim from a client
>> 
>> "How do I designate an existing page to be a child page of another page
>> within the same section? "
>> 
>> Yet more proof that the folder-defaultpage idea is not that obvious.
>> 
>> 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 09/10/2013, at 1:10 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Wed, Oct 9, 2013 at 11:08 AM, Dylan Jay <djay at pretaweb.com> wrote:
>>> 
>>> 
>>> On 09/10/2013, at 12:19 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>>> 
>>>> I'm actually warming up to the original concept anyways--been chatting with co-workers about it.
>>>> 
>>>> The positives really outweigh the potential risks as far as I can see.
>>>> 
>>>> You can put me as a +1 on this.
>>> 
>>> Was that +1 to folder-page-collection merge?
>>> Or to folder-page merge with tiles replacing collections?
>>> folder-page-collection merge.
>>> 
>>> 
>>> When I get back from holiday I want to look at how hard it is to get the tinymcetiles into mockup. Is it now easier to make tinymce plugins?
>>> I think it'd be easy for me to do but I wrote the 2 current plugins that are for the tinymce mockup :)
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Wed, Oct 9, 2013 at 9:47 AM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, Oct 9, 2013 at 8:50 AM, Dylan Jay <djay at pretaweb.com> wrote:
>>>> On 08/10/2013, at 6:15 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Oct 8, 2013 at 3:55 PM, Dylan Jay <djay at pretaweb.com> wrote:
>>>>>> On 08/10/2013, at 4:32 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>>>>>> 
>>>>>>> So starting this discussion back up, I don't like the idea of adding a display tab to the page type and getting rid of the collection type--I thinking solving a problem by creating another less bad problem.
>>>>>>> 
>>>>>>> However, I really do like the idea of getting rid of default pages and having everything folderish.
>>>>>>> 
>>>>>>> I'm inclined to say we push plone 5 with the current set of features we've already agreed on and then in plone 6, we move everything folders, get rid of collections and have a deco layout editor.
>>>>>>> 
>>>>>>> If we just let the deco layout engine be applied to any type, it would also solve the default page issue.
>>>>>> 
>>>>>> It seems a shame that since we are going to break things with plone5 and we seem to mostly agree everything folderish (done right) solves lots of problems, that we don't explore more a stepping stone approach.
>>>>> I think we need to solve it another way then. I'm not adverse to this but I don't think making a display tab on the page type is a good idea.
>>>>> 
>>>>> 
>>>>>> I'd like to look more at tinymcetiles since it is more flexible than the page-folder-collection merger but means we don't have to deal with grids in both backend and frontend when we're still not sure how that will work with a world where the frontend could include anything including another grid system.
>>>>>> Collections get converted to a tile on a page but we don't need to ship with many other tiles. We don't need to change how we do images for example.
>>>>>> We also don't need to change portlets yet or include the deco idea of saved layouts.
>>>>>> When you think about it, its almost the same as the proposal to merge collections and display into the page type, except that you can pick where in the page that listing goes, instead of it being at the bottom.
>>>> 
>>>>> Okay, I'm intrigued with this also.
>>>>> 
>>>>> Some thoughts:
>>>>> - would we still keep the collection type around for plone 5?
>>>> 
>>>> Rob's proposal came out of the us thinking "if you get rid of default pages, then you can't have collections as default views, whats the best way to support collections?".
>>>> It's possible we could keep collections and make them folderish but accepting all other types. This would make things that want to be views on top of collections easier to upgrade.  Or Rob's proposal is basically the same thing except page==collection. We could do that in addition to supporting tiles but possibly make it confusing as there would be two ways to make a "collection".
>>>> Right. I understand that. I was just carrying on the idea of tinymcetiles which I thought we'd only pursue if we didn't merge the collection with page.
>>>> 
>>>> 
>>>> 
>>>>> - still make everything folderish and get rid of default pages
>>>>> - do we need to add a rich text field to the Folder type?
>>>> 
>>>> No, I think folder and page merge. Although again we could keep it to be safe and for backwards compatibilty but I think it would be confusing.
>>>> 
>>>> 
>>>>> dealing with migrating a site that uses all kinds of folders with default pages could be really messy
>>>> 
>>>> a little messy. I think all default page items will have their base class changed to be a folder. then they will be move to where their parent folder was and the contents moved into them. Also all items have to have two tiles and descriptions so the folder tile and description are not lost and still appear in navigation.
>>>> I think its doable but how to upgrade third-party content types is the hard part I think.
>>>> 
>>>>> - maybe just use js patterns instead of tiles? Or is that a bad idea to mix the concepts?
>>>> 
>>>> I think that would be a bad idea since it means lots of ajax loads per page and requiring JS on the frontend.
>>>> Tiles are kind of like patterns but on the server side I believe. They have two ways to store their configuration. Either as http arguments or in annotations. The idea of storing their data in html5 data attributes is interesting however to make them closer to patterns. But for now I think there is no need to change it. Tiles are implemented and working in places like collective.cover. All we are talking about here is to insert them via tinymce and then have the extra rendering step that converts them to full html.
>>>> One issue is perhaps that the layout options in tinymce are limited. In tinymce you can left and right float and put them in invisible tables but not much more.
>>>> 
>>>>>    - The TinyMCE integration would just provide a form to insert the appropriate pattern markup
>>>>> 
>>>>> 
>>>>> Although thinking about it more you still don't get rid of the display menu completely as what happens to plugins like solgema.calendar? They rely on being views on collections. I guess they would have to turn into a tile instead and include the query in their own configuration?
>>>>> We're not getting rid of the display menu. We're just trying to get rid of the default page selection
>>>>> 
>>>>> 
>>>>> 
>>>>> http://svn.plone.org/svn/collective/collective.tinymcetiles/trunk/README.txt
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -Nathan
>>>>>> 
>>>>>> 
>>>>>> On Sun, Oct 6, 2013 at 2:48 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Sun, Oct 6, 2013 at 2:43 PM, Johannes Raggam <raggam-nl at adm.at> wrote:
>>>>>> I like the idea to have everything folderish and to get rid of the
>>>>>> "Default View" mechanism.
>>>>>> 
>>>>>> For my projects I always use folderish types because I see a lot of
>>>>>> advantages in it. For Archetypes based sites I use
>>>>>> collective.folderishtypes.
>>>>>> 
>>>>>> In my experience, this has these usability downsides:
>>>>>> 
>>>>>> - The folderish types don't show their contents in their view (I solved
>>>>>> that with a viewlet or portlet on folderish types).
>>>>>> Make the new folder contents much more useful and encouraging people to use it more should should help this.
>>>>>> 
>>>>>> 
>>>>>> - After adding a folderish type, one lands in it's detail view and
>>>>>> immediately adding another item adds it into the content created before.
>>>>>> That's not what you'd expect if you're in a hurry and doing lot's of
>>>>>> editing. (Can be solved by redirection after creation to the parent
>>>>>> folder)
>>>>>> Everyone should take a look at the new folder contents in the mockup project. There is an add menu there that creates the content while keeping you in the folder contents view for these types of situations where you want to add a lot of content at once to build your site quickly.
>>>>>> 
>>>>>> 
>>>>>> Like Martin, I dislike mixing the Collection functionality into a
>>>>>> Über-Page. To clients I always explain the Collection type as something
>>>>>> as a Search-Folder and I - from a user-perspective - wouldn't expect
>>>>>> that functionality in a "Display" fieldset. A collection can still be
>>>>>> folderish too.
>>>>>> 
>>>>>> I'm unsure on getting rid of the "Display" menu. While moving it into
>>>>>> the editing fieldsets could be a chance to allow users to also add an
>>>>>> optional content listing of their folderish content, the current menu
>>>>>> placement makes a lot of sense to me.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Johannes
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> programmatic  web development
>>>>>> di(fh) johannes raggam / thet
>>>>>> python plone zope development
>>>>>> mail: office at programmatic.pro
>>>>>> web:  http://programmatic.pro
>>>>>>      http://bluedynamics.com
>>>>>> 
>>>>>> _______________________________________________
>>>>>> UI mailing list
>>>>>> UI at lists.plone.org
>>>>>> https://lists.plone.org/mailman/listinfo/plone-ui
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Nathan Van Gheem
>>>>>> Solutions Architect
>>>>>> Wildcard Corp
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Nathan Van Gheem
>>>>>> Solutions Architect
>>>>>> Wildcard Corp
>>>>>> _______________________________________________
>>>>>> UI mailing list
>>>>>> UI at lists.plone.org
>>>>>> https://lists.plone.org/mailman/listinfo/plone-ui
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Nathan Van Gheem
>>>>> Solutions Architect
>>>>> Wildcard Corp
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Nathan Van Gheem
>>>> Solutions Architect
>>>> Wildcard Corp
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Nathan Van Gheem
>>>> Solutions Architect
>>>> Wildcard Corp
>>> 
>>> 
>>> 
>>> --
>>> Nathan Van Gheem
>>> Solutions Architect
>>> Wildcard Corp
>> 
>> 
>> 
>> 
>> -- 
>> Nathan Van Gheem
>> Solutions Architect
>> Wildcard Corp
> 
> _______________________________________________
> UI mailing list
> UI at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-ui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20131022/2618e39c/attachment-0001.html>


More information about the UI mailing list