Re: VIDEO: Simplifying Plone with tiles and shortcodes

On 26-03-14 08:55, Dylan Jay wrote:

> 
> by working as folders here what we are saying is to create something
> with a listing of the local contents.

yeah, got that now.


> 
> Including "add new" button it would be 5 not 17. 1. Add new 2. Insert
> tile button 3. select tile type (listing tile is the default) 4. save
> tile (I deliberately made the defaults be the same as a file
> listing) 5. save folder
> 
> That is only 3 more than you currently do.
> 

damn, you caught me hyperboling... Can't have someone on the internet
say something wrong ;-)

> 
> 
>> 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.
> 
> 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 I think this is doable and

Yep, that would solve it. That was also the gist of what Sean was
suggesting, that site admins can actually make the 'Add new' menu
*longer*, not shorter, while behind the screens all that does is create
a new UeberFolderPageHybridContentThingie just filled in with a bunch of
presets.
So current practices of intranets won't be disrupted, but you gain the
flexibility, and keep the configuration power where it should be: site
admins. I like.


> 
>> There's a separate concern: If my typical user will create 20
>> pages after eachother in a folder, in the new system they will most
>> likely end up like this: page1 page2 page3 page4
>> 
>> etcetera, since once you've added a page and then click 'add'
>> again, it will be a sub-page of that. Not sure this is better or
>> worse than what we do now, but I'm quite sure this is what will
>> happen, even if they mean to create siblings.
> 
> I'm not sure which usecase is more common either, adding siblings or
> adding children. I do know that currently it's inconsistent which
> isn't good. An unrelated enhancement to plone I'm considering is a
> content location field in the edit form of all content so you can
> change your mind about where it's created after clicking add or
> edit. Also, the new structure (folder contents) in plone5 lets you
> add content in an unambiguous location.


In a lot of other systems (not necessary only CMS but also CRM) you have
two 'submit' buttons when adding content: "save" and "Save + new", which
would bring you to a new contentform as sibling to the one you just
created. Not sure if that could be a solution, needs more UI people
input I guess.


>> 
>> It's still a
>>> hard concept to learn.
>> 
>> but once learned, reasonably powerful.
> 
> and I'd argue this tiles idea, once learned is more powerful. You
> can't insert two listings in Plone at the moment.
> 
>> My question is: will I be able to replicate it in your new idea?
> 
> replicate choosing different views? yes, see above.


OK, you're beginning to win me over


>> 
>> - accessibility. At this early point in the UI that's not a key
>> one, but it needs to be addressed, especially since TinyMCE 4 makes
>> big progress in that area. We don't want to mess that up with our
>> home-grown extensions tacked on to it. We did that once, time to
>> not repeat ;-)


add to that:
- we need a UI for this, one that hides the shortcodes
- but we need to do it in such a way we don't steer ourselves into not
being able to follow upstream TinyMCE.



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

that could be a way, or there may be other ways.


> 
> As soon as you have collections, folders with views, forms, portlet
> pages, youtube links, another other than static text and folders, you
> have this problem. I'm not sure how this changes that.
> 

Yeah, I know. I just have quite a few sites that use foldernames and
folderhierarchy as the main (ahum, read that as 'only' because nobody
bothered to use proper tags and keywords...) classification of
information. These also happen to be the ones that are most worthy of
keeping for posterity.



but hey, you're slowly winning me over, although a lot depends on a
sleek execution.


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech