Re: VIDEO: Simplifying Plone with tiles and shortcodes

On 25 Mar 2014, at 11:41 am, polyester <paul-4+yus/[email protected]> wrote:

> On 24-03-14 22:58, Martin Aspeli wrote:
> 
>> 
>> Second of all, this is a tirade of stop energy, and you're making a ton
>> of assumptions about what Dylan is thinking and saying.
> 
> I don't think it's just 'stop energy', but a legitimate concern. I
> partly share the same concerns. I don't think that's necessarily due to
> unwillingness to change, but mostly due to differing experiences with
> the many varied uses of Plone.

I agree it's empassioned concern and I understand what thats like. However I'd like to keep the conversation constructive towards actual examples and use cases so we can move forward. for example Hector alludes to many examples of problems with this proposal, but what we need is those written out.
I'm going to try and sum up and combine both Pauls and Hectors comments.
 

1. Losing "Folders"

On 25 Mar 2014, at 11:41 am, polyester <paul-4+yus/[email protected]> wrote:
> - the 'Folders and files' metaphor is extremely useful in
> intranet/extranet settings. In my experience with training people, this
> has never been a problem explaining. The fact that you can't have
> 'attachments' with a page is, however.
> So while making everything folderish is potentially a big win, we should
> not underestimate the power of the folder metaphor, especially for
> collaboration sites with lots of content. For pure external-facing
> websites, the concerns might be different. Although also there there are
> differences between very content-heavy websites with 100000+ pages and
> targeted, focused websites with < 1000 pages.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> third, the folder metaphor is more than 30-years old and it's widely used all over the world: I can't think of a single OS that doesn't use it; I can't think of a computer user not being familiar with it.
...
> are you aware of TYPO3 and Liferay usage of folders? the later is really funny when you think how they are marketing this new (for them) feature present in Plone from the very beginning:
> 
> "It's much easier to organize web content than it ever was before. Liferay Portal 6.2 introduces web content folders. You can now create folders and sub-folders for web content the same way you can create them for Documents and Media."
> 
> https://www.liferay.com/pt/documentation/liferay-portal/6.2/release-notes
> 
> so they're including folders and we're going to remove them? they want to be like Plone and we want to be like WordPress? really?

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



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. It's still a hard concept to learn.
To make thing simpler lets just look at this tiles idea first and nut out what the real concerns are before we decide to go back to something everyone seems to be in agreement is not an intuitive concept.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> if the default page concept is causing problems, which it is, we should think on how to solve those problems but not by removing the feature and creating other problems (BTW, I can think on a worst issue involving context portlets).


Please can you elaborate on these "other problems" Hector? That is the whole reason I created the video and draft PLIP in the first place. To try and find these problems.


> 
> - shortcodes are very, very questionable in an internationalized
> context. Their semantics/mnemonics have zero meaning to people not
> speaking English, let alone using a completely different script. For
> them, it would be pure copy/paste of random jibberish from the
> Interwebz. That's not behaviour I'd like to encourage. Without a UI, it
> seems like a big regression to me.

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.

> 
> - the de-coupling of URL/menu with content seems to me like a very big
> throwback. It is a crutch other CMS's use, because they have to map a
> relational database onto a website.
> In my experience with other CMS's this de-coupling has always led to
> huge problems. Not in the initial setting up of a website, but in the
> evolution and maintenance of websites.
> Devising a menu structure for a website more or less independent of the
> actual content has two flaws:
> * it only works for a limited set of uses, namely where there is a
> smallish team of editors thinking about it. It does not work in a
> massive intranet setting, where the structure evolves without central
> oversight.
> * every organization will get their initial menu structure wrong.
> Invariably. As time evolves, you will need to move content about.
> One of the great powers of Plone, one that we sometimes take for granted
> but that still impresses the hell out of people maintaining sites over
> years and years: You can copy/paste content!!!
> That means you can archive stuff, you can move stuff around as your
> organization evolves and re-organizes.

Thats not in the draft PLIP. It's not being proposed. You can still cut and paste content.

> 
> So, while I'm fully in favour of making Plone easier to use for new
> users, I also want to preserve the strength it now has:
> 
> - 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.

> 
> - workability for non-english users. Shortcodes that only work in latin
> script are very suspect to me.

no a problem. see above.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:

> fourth, I think you're missing the point of where is Plone positioned: we're are not competing with WordPress neither Google Sites so bringing those concepts to Plone is a big mistake as we're going to lose what makes us powerful: flexibility. have you seen big government sites or intranets successfully made with those tools? I don't.
> 
> Plone is an enterprise-level CMS and should be marketed like that; nevertheless, Plone can be used successfully as an entry-level CMS as it's right now.

I don't see where positioning enters into things at all. Your assumption seems to be that this proposal reduces flexibility in favour of simplicity? I've repeated tried to show this draft PLIP gives us more flexibility, more power not less. I mostly work with government and some very large sites, not intranet and extranet if it helps. Either way, please elaborate on exactly how, step by step, we lose power and flexibility with this PLIP.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> I think we should be working on Deco's layout editor and on Plone's standard tiles. both things can be further tested on collective.cover and we can learn from that; then we can think on moving those things to the core.

The Deco idea doesn't have folders or default pages in either?? 
In fact the only real difference between the full deco proposal and this one is the method of inserting tiles, (and no concept of layouts (yet) or replacing portlets). So I'm pretty confused.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:

> first, according to Eric's post what you're proposing is not in the roadmap for Plone 5:
> 
> http://willrantforbeer.com/post/52975919723/plone-5
> 
> (and BTW, Eric's original estimation on Plone 5 seems to have proven overoptimistic).


It's a draft PLIP, a work in progress. Sorry if thats not clear. 

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> second, the PLIP title states one thing (Remove default pages via tiles), the proposal involves many other (Remove the concepts of Folder, collection and default page from Plone) and the implications and risks are not clear for me; I think you're mixing too much stuff and that's dangerous.

It's hard to name. That's the third iteration of the name. Everything in there is what needs to happen to remove default pages in the nicest most powerful way I can think of. Does the name really matter?

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:

> let's dig a little bit further: the video mentions Limi's proposal from 2008 to simplify Plone's editing experience; I couldn't find any of the things you want to change there:
> 
> http://limi.net/articles/simplify-plones-editing-experience/


Removing folders and collections and replacing them with a single type. Using widgets to insert functionality into a page.
I would love to add some more of the ideas from that post but I was trying to keep this focused.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> the PLIP clearly states "This is partial step towards the full Deco implementation" and I say no, this is an ugly monkey patch that, IMO if implemented in Plone's core, is going to backfire us in the future when we really want to implement Deco.

How? Please elaborate.
Also, I've previously stated that the I'm not convinced full deco is a good idea. It enforces a single grid layout on themers which I think could be a big restriction on a generalised CMS.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:

> Let's go to the risks now:
> 
> you say "Incorporating tiles within tinymce without more use of collective.tinymcetiles poses some risk"; I ask, which risk?


That was written before working on the code for the demo. The risks were where if it worked in practice and how to deal with things like previewing the content in a visual way and the editor being able to identify which tile was which. The shortcodes is my current solution to that. There might be others.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> you say "Tiles themselves have been used in production via collective.cover however there could still be some risks involved"; I ask again, which risks?


Perhaps I'm using risks in the wrong way. I just pointing out areas for which I at the time needed to fill in some knowledge. You've worked on collective cover and know the tiles implementation much more than me. Are there any risks?

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> you say "There might existing other functionality that will be lost hasn’t yet been considered"; then I think we must think more on this: unexpected consequences could be worst than the issue you want to solve.

of course. Please please think on this BEFORE dismissing the idea.

On 25 Mar 2014, at 8:27 am, Héctor Velarde <[email protected]> wrote:
> you say "Caching settings have different rules for folderish and content-ish types"; I think this is a huge issue.

If you can can you elaborate that would be helpful?
I think this can be easily solved by changing how the caching system classifies content. Instead of just using content type, it could information about which kind of tiles are embedded in the content. 
Honestly, our caching rules already have problems with regard to portlets and viewlets. It's an area that needs more thought on how we can better seperate dymanic content from static content and content type is a crude way to do it that already doesn't work well.





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