Re: VIDEO: Simplifying Plone with tiles and shortcodes

Just a bit brainstorming:

The 'Display' menu is not going away for folderish content types, or is it?

right now it is mostly used for folders and collections, but also for
nonfolderish types like links.

A simpler solution may be:

You create a document, and have the option to select a Folder view + the
rich text of the body  (like the current collections). By default it has a
'This Document only' view, which does not show any folder contents. You can
change between a 'folder' and 'document only' view.

For adding 'folders': In the add menu the entry folders may still exist but
it creates a 'Document' with the 'folder view' applied, (which than you can
change back into the 'document only' view)






On Thu, Mar 27, 2014 at 1:07 PM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:

> On 27 Mar 2014, at 3:37 am, Sean Upton <[email protected]> wrote:
>
> > On Wed, Mar 26, 2014 at 1:55 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
> >> That is only 3 more than you currently do.
> >
> > With Paul's dozens of folders, those extra three clicks are a
> > coefficient, not an isolated constant.  This is a non-issue if what is
> > possible from the add-new menu is pre-configured templates to route
> > around those extra steps (not just a vocabulary of FTI titles) [1].
> >
> >>> That is just a *lot* of work to create a folder-like page.
> >>> I fully agree with Sean's comments earlier that some way of quickly
> >>> generating pre-defined subtypes (one of which I can then call "Folder",
> >>> thank you very much ;-)  would be a solution.
> >
> > Something marked as a folder ought to behave differently for DAV/FTP,
> > so there is some real marking/subtyping necessary, not just view
> > manipulation?
> >
> > Also, having only one portal_type can give us extra work to route
> > around normal workflow arrangements bound to type names.  Selecting a
> > workflow chain based on some ordered list of interfaces provided
> > (lookup multi-adapter by type interface, subtype marker) instead of
> > solely by portal_type might be helpful?
> >
> >> So if we did have a kind of layout/template idea where clicking Add New
> > Folder, created a FolderishPage type, preset with a folder listing, would
> that solve your issues?
> >> Something similar to this? http://plone.org/products/plonetemplates
> >
> > Subtyping (for templating/add-menu purposes) could be about any/all of
> > tiles configured, extra form schema conferred to the edit tab [2],
> > icons, pre-defined portlet assignments, and marker interfaces (and by
> > consequence object actions available, workflow definition chain
> > binding/lookup, maybe other things).
> >
> >>> I guess what worries me most is that it does not easily translate into
> >>> filesystems. On more occasions than I care to remember, having an
> >>> opt-out in the form of Transmogrify, Import/Export, Webdav or even FTP
> >>> has saved my sorry behind, and a lot of content.
> >>
> >> Webdav is a good point.
> >> One way might be support folder rich content as a .index_html file
> inside the folder. I think we might need to look at supporting additional
> field values via a .properties.yaml file anyway because what we have now is
> a real mess.
> >>
> >
> > Agreed, don't think DAV/FTP representation is intractable.  Having
> > solutions for the "primary field" and properties payloads as you
> > suggest makes sense.
>
> I think webdav is going to take some thinking about. If you have a lot of
> pages with nothing in then you don't want them represented in webdav as
> folders with .index_html files in them. I'm not sure either about the idea
> of separating folders from pages based on which button the user clicked in
> the add new menu.
> So this really only leaves what you are suggesting a folder representation
> is determined by marker interfaces, or which tiles it has, or some kind of
> rule, just as you are suggesting.
> But that could get kind of confusing.
> Perhaps if things like workflow and search was based on Interfaces more
> than Type. And we used something like content rules to determine when
> certain marker interfaces are applied. Like rules to add an interface when
> a page has nothing in it, when it has something in it, when it has a
> listing tile in it etc. Again not sure this isn't far to complex for people
> to use.
>
>
> >
> >
> > Sean
> >
> >
> > [1] There are are always UX risks for changing what shows up the add
> > menu, if not done right: (a) too many choices, (b) too few choices,
> > (c) too flat a list, (d) too many submenus, (e) list so large the menu
> > scrolls off the viewable page area.
> >
> > [2] This is really the only space I've worked in from a subtyping
> > standpoint; at a former employer seemingly ages ago, we sponsored
> > development and were the initial user of Products.ContentFlavors.  The
> > closest thing I have come up with now for Dexterity types is
> > https://github.com/seanupton/experimental.flavors -- the problem with
> > either approach is that marking a content instance with a flavor (or
> > behavior) after creation is tedious, and this was largest user
> > complaint I received from deployment of a large media CMS deployment
> > using the "flavors' concept.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>



-- 
Best Regards,

Christian Ledermann

London - UK
Mobile : +44 7899488511

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers