Re: VIDEO: Simplifying Plone with tiles and shortcodes

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.


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