[Plone-UI] Folderish Page Proposal

Dylan Jay djay at pretaweb.com
Wed Nov 27 21:43:36 UTC 2013


BTW, this is going to bring to plone something very similar to shortcodes in wordpress.
You can see what a similar plugin in wordress does to allow visually adding shortcodes.
http://envato.dropntheme.com/wp-tinymce-general-shortcodes/

The differences are, we're not inserting "code" but rather an image. And there is no way to edit the properties of the tile by hand like you can with a shortcode.
Also tiles can contain a lot of data if they have to like a video which shortcodes can't.
In terms of UX I'm wondering if there is something better we can use for a marker than an image?

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 28 Nov 2013, at 8:28 am, Dylan Jay <djay at pretaweb.com> wrote:

> Hi Nathan,
> 
> I had a look at tinymcetiles. It's relatively simple. It consists of two parts. 
> - A transform layer to render the marker html into the real tiles, 
> - and some JS to insert the markers. 
> and almost nothing else.
> I had a look at tinymce in mockup. It seems clear how to add core plone stuff to tinymce, but if I wanted to add a tiles button should I be doing this in mockup? Is there an example of how to integrate a tinymce plugin with plone5?
> otherwise maybe it's simpler for now to branch mockup and try out tinymcetiles that way.
> 
> 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 23 Oct 2013, at 6:20 am, Nathan Van Gheem <nathan at vangheem.us> wrote:
> 
>> Yes, we can't really solve some of the problems until we have a deco/cover solution in core.
>> 
>> 
>> On Tue, Oct 22, 2013 at 2:18 PM, <nguyen at uwosh.edu> wrote:
>> It's my impression that the details and questions uncovered in this discussion show that this is a very non-trivial change.  
>> 
>> -1 on putting this into Plone 5.  
>> 
>> How about making this change an optional install so we can see over time what else might break or need to be modified so that by Plone 6 it's ok to consider making this the default behaviour?  This is what we decided to do for Dexterity, Diazo, and (ducks) Deco...
>> 
>> Back when Joel Burton was talking this up it seemed to me a relatively simple change, to add a rich text body field to the ATFolder type… or perhaps it's just me being a simpleton. :)
>> 
>> 	Kim
>> 
>> 
>> On Oct 22, 2013, at 8:29 AM, Guido Stevens <guido.stevens at cosent.net> wrote:
>> 
>> 
>> On 22 okt. 2013, at 14:53, Nathan Van Gheem <nathan at vangheem.us> wrote:
>> 
>>> Isn't this a misunderstanding? Are we doing this with the idea of getting rid of default pages or still having the concept of default pages around?
>> 
>> That's exactly what I was trying to highlight. If we have a lot of UX elements where one has to choose between folderish and page-ish semantics (sharing, portlets, navigation title, etc) we risk ending up in a situation where the ghost of default page is very much present in the user interface, regardless of whether Page is a dexterity.Container.
>> 
>> --
>>   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
>> 
>> 
>>> 
>>> The reason we have all the "here or folder" warnings throughout plone is specifically because of default pages.
>>> 
>>> Once we get rid of them, then those warnings are no longer present. This actually solves a problem right.
>>> 
>>> However, iterate and versioning could certainly be a problem. I'm not exactly sure how those are implemented but if they're making copies of the objects, we'll have to make sure it only makes a copy of the object without the sub-items.
>>> 
>>> Another huge problem I just thought of if we get rid of default page is the home page. How do you design it then without either having a deco or cover installed that can apply to the homepage.
>>> 
>>> Thanks Dylan for going through all this. We'll definitely have to find solutions to these problems that are palatable or it won't be worth making the switch.
>>> 
>>> 
>>> On Tue, Oct 22, 2013 at 4:17 AM, Dylan Jay <djay at pretaweb.com> wrote:
>>> On 22/10/2013, at 4:00 AM, Guido Stevens <guido.stevens at cosent.net> wrote:
>>> 
>>>> 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 think it's a better UI to ask right where you are what kind of portlet you want, rather than make people move.
>>> However I wonder how many more forms are going to have to change? Anyone think of anything else? 3rd party plugins?
>>> 
>>> 
>>>> 
>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 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
>> _______________________________________________
>> UI mailing list
>> UI at lists.plone.org
>> https://lists.plone.org/mailman/listinfo/plone-ui
> 



More information about the UI mailing list