Re: VIDEO: Simplifying Plone with tiles and shortcodes

On 26 Mar 2014, at 5:14 pm, polyester <paul-4+yus/[email protected]> wrote:

> On 25-03-14 23:39, Dylan Jay wrote:
>> 
> 
>> 
>> 1. Losing "Folders"
>> 
> 
>> I'm still not understanding what the actual complaint is here. It
>> might be my use of the word "Page". Equally, that content type could
>> be called a "Folder". Folderishness, containment and the way plone
>> works with regard to having sortable content within an item won't
>> change. The folder metaphor is still there. The proposal is to have 1
>> more flexible type, instead of 3 separate but less flexible types.
>> And we can call it whatever we like. A FlexiFolderPage? The only real
>> difference is that the "add new" menu now works consistently by
>> adding something inside something in all cases, not some, and we
>> don't have to use default pages, which no one seems to say they
>> actually like. As previously stated this proposal isn't incompatible
>> with having pages and folders and collections as different content
>> types however they would all be the same thing, just with different
>> default text content. However since anyone can adjust the tiles to
>> make a collection work more like a folder, or a page into a folder,
>> the content type distinction here would be confusing rather than
>> helpful I think. Fundamentally the folder metaphor is still there.
>> What has changed is the default page metaphor (which isn't really a
>> metaphor since it doesn't really map to anything in the physical word
>> that I can think of).
> 
> While you can make your new pages work as folders (or more correctly as

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

> collections, if I get the video right), it is a manual step that has to
> be done for each folder. If I want to quickly organize 300 docs into 17
> folders, which is more or less a daily occurrence, that just takes up a
> lot of time.
> In many intranet/extranet sites, the folder without any markup or text
> is just a valuable, recognized way of structuring content. The reason
> being that it's easy to explain to office workers who are used to file
> systems working that way, and who like their intranets to be a good
> reflection of that.
> 
> So while technically you can create 'folder-like' pages, it takes about,
> what was it in the video, 17 clicks to do so? With plenty of conscious
> decisions to be made on each one (simple listing, collection-style, ...)


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.



> 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 



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

> 
> 
>> 
>> 
>> 
>> 2. It's better to improve the default pages UI
>>> - the 'default page' concept is something that's slightly difficult
>>> to get across at first for new users, but in my training experience
>>> users get it quite quick. The major stumbling block, and
>>> panick-moment in a live site, comes later. The reasons for that:
>>> the "View" menu does not have two essentials for good UI: Preview,
>>> and Undo. So people mess around with it, and can't revert it to the
>>> original state. (Try finding the 'pick an item as default view'
>>> when that folder has now been filled with seventeenthousand news
>>> items...)
>> 
>> I disagree. I think the issues with people clicking on the display
>> menu later on are a symptom of the fact that they never really
>> understood the default page idea in the first place. 
> 
> I disagree with that. The reason people use the display menu later on is
> simply that the content evolves over time. When there were 3 pages in a
> folder, the 'show all content' view was good. When somebody added 20
> more, it had to change.

I thought we were talking about when users "break" their page by clicking on the display menu and then have to ring support to ask what happened to their homepage.
This is  regular occurrence for us, despite training on default pages and folders.

> Or: at first, we show a folder with pictures in thumbnail mode, since it
> looks cute. After a while, you just want to list them in default mode.
> The pics have lost their instant relevance, and are just kept for
> archival purposes.
> And so on. I have many real-life examples where choosing differing views
> for a folder is a perfectly natural and reasonal thing to do, depending
> on the development of the content.
> 
> And choosing a different 'choose item as default view' is also not
> uncommon. It's not unreasonable to have
> http//my.intra.net/myteam/minutes always show the latest minutes by
> default, and it still being a folder where all the minutes are chucked in.
> 
> again, I am not trying to block innovation. I am worried that making
> things newbie-friendly in such a way that power users are despairing, is
> not the way forward.
> I'm sure a middle ground can be found, but that's why it is good to
> discuss these issues.

ok, but aren't you starting from the assumption here that the tiles/widgets approach is hard to learn for existing users?
Let's ignore the shortcodes for a minute and pretend you can 
- click edit on a page
- put the cursor on the part of the tinymce that is showing the gallery view. It shows its selected.
- double click or click "edit tile"
- select for a list of other list styles such as "summary view"
- click save tile

This is not just giving us undo and preview of listing views, it is also a lot in line with how plone logically works.
For example, now the bit in the middle of the screen called the content area, is normally controlled by clicking edit and doing things with the visual editor.... except where it's controlled by the displaymenu, and sometimes its controlled by the displaymenu aloing with the criteria tab, or the facet navigation tab. Yes, we manage to teach people this stuff, but its really not as clean and logical as we think it is. Instead, this proposal is putting more stuff into the visual editor which is the most logical place to find it. Got a folder and want to listing whats in there? Edit it and insert a listing. What two listings? one for each of the two subfolders (current and archived news say), just insert two tiles.


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

> (And not 'in almost all simple cases', which is why I still enable
> old-style collections in every site, since the new ones don't have all
> their powers. But I digress...)
> 
> 
> (on shortcodes)
>> 
>> There is a UI. It's shown in the video. It is entirely usable without
>> touching or understanding the shortcodes so the i18n argument doesn't
>> really hold. Also, I've already said I'm looking into how to hide the
>> shortcodes, so I think if we can remove shortcodes from the debate at
>> this point it would be helpful.
> 
> fair enough. Although a few concerns are still with me:
> - a semi-unified UI for tiles and embedding external things like video
> would be preferable, I think, otherwise it gets confusing for users.

yes, thats the idea. Tiles are plugins and would be the most logical tool to use to install anything other than text or images into a page/folder. Videos. flash objects, forms, even other content objects.
Have a look at the original video made by limi. It's hidden in the middle of this blob post http://limi.net/articles/simplify-plones-editing-experience
I'd like to get the experience of inserting a tile down to the something like the dropdown he envisaged.



> 
> - 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 ;-)
> 
> 
>>> 
>>> - maintainability. I have quite a few 5+ year old sites with Plone.
>>> I have zero with Wordpress/Drupal/Joomla. When they had to change,
>>> you just had to start over. While that may be good for consultants,
>>> it's less good for implementors inside institutions.
>> 
>> So specifically what is your concern here? Are you worried about the
>> upgrade step? This is covered in PLIP. It should be possible to do an
>> automated upgrade. Are you worried about retraining? That is a
>> concern but I don't see this as a big change for old users. Instead
>> of adding a folder you add a page. Instead of using default pages you
>> either edit the page or add a tile. That to mean is a lot simpler
>> than training new people on default pages and dealing with the
>> inflexibility on default pages.
> 
> 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. 


> 
> Once users are re-trained (which indeed, they will have) they will of
> course go wild with tiles. So while a simple NewPage with one
> contentlisting tile is more or less equivalent to a folder, of course
> people will put 23 tiles on a page. Just because they can. And that then
> does not translate back into anything I could get *out* of Plone again
> in a pinch. That worries me, in a long-time archival sense.

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.

> 
> 
> paul
> 
> 
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers


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