Ticket #9210 (closed PLIP: wontfix)
Folderish pages
Reported by: | laurenskling | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | General | Version: | |
Keywords: | folder, page, folderish page | Cc: | plip-advisories@… |
Description
Overview:
At the Sorrento European Plone Symposium, we talked about folderish pages and decided it should be a PLIP for the new Plone 4 release. To create a page with sub pages, you have to create a folder and set a standard display item. This is a technical way of creating content. Our end users just want to create pages with pages inside.
Solution:
Give pages folder functionality, like containing content.
Why?
We simplify the current “make a folder, put in files, choose which to show” method. Adding pages in pages is a more natural way of creating content. With this proposal for the new Plone 4 release, we can create a bridge between Plone 3 and Plone Trunk.
Migration:
By turning the standard display item of a folder into the parent page, we migrate most of the cases. If a specialized display is created for a folder, things could get complicated.
Change History
comment:2 follow-up: ↓ 10 Changed 7 years ago by wichert
I solved that recently by changing the add item menu like this:
- always show the add item menu
- if the current context is a container and new items would be created inside it use add child as title for the menu
- if the current context is not a container and new items would be created alongside the current context use add sibling as title for the menu
That is a simple change which restores the ability to easily create multiple items and removes any possible confusion.
comment:3 Changed 7 years ago by laurenskling
But if we make all pages into folderish pages, most context is a container. So is the new item going to be a child or a sibling? Is it possible in your situation to create a sibling to a container?
Should we make both options available for folderish pages, or just adding child pages?
comment:4 Changed 7 years ago by wichert
In my current project it is not. I was thinking of extending it so create 'add sibling' and 'add child' sub-menus, but have not done that. This is the kind of decision that requires careful user testing, and I have not been able to do that.
comment:5 Changed 7 years ago by wichert
In case this is useful for others, here is the code I use to improve the add item menu in Plone 3.x.
from Acquisition import aq_inner from zope.i18n import translate from zope.i18nmessageid.message import Message from Products.CMFCore.utils import getToolByName from Products.CMFPlone import PloneMessageFactory as _ from plone.app.contentmenu.menu import _safe_unicode from plone.app.contentmenu.menu import FactoriesSubMenuItem as BaseFactoriesSubMenuItem from plone.app.contentmenu.menu import WorkflowSubMenuItem as BaseWorkflowSubMenuItem class FactoriesSubMenuItem(BaseFactoriesSubMenuItem): @property def title(self): itemsToAdd = self._itemsToAdd() showConstrainOptions = self._showConstrainOptions() if showConstrainOptions or len(itemsToAdd) > 1: if self._addingToParent(): return _(u'label_add_new_sibling', default=u'Add sibling\u2026') else: return _(u'label_add_new_child', default=u'Add child\u2026') elif len(itemsToAdd) == 1: fti=itemsToAdd[0][1] title = fti.Title() if isinstance(title, Message): title = translate(title, context=self.request) else: title = translate(_safe_unicode(title), domain='plone', context=self.request) if self._addingToParent(): return _(u'label_add_sibling', default='Add sibling ${type}', mapping={'type' : title}) else: return _(u'label_add_child', default='Add child ${type}', mapping={'type' : title}) else: if self._addingToParent(): return _(u'label_add_new_sibling', default=u'Add sibling\u2026') else: return _(u'label_add_new_child', default=u'Add child\u2026') def available(self): itemsToAdd = self._itemsToAdd() showConstrainOptions = self._showConstrainOptions() if self._addingToParent() and not self.context_state.is_default_page(): return False return (len(itemsToAdd) > 0 or showConstrainOptions)
comment:6 Changed 7 years ago by robgietema
I've created a product called collective.folderishpage which adds this functionality. We've tried it with some customers and it works really well. You can find the product at: http://svn.plone.org/svn/collective/collective.folderishpage
The main issue with the current folder/default view is adding a subpage to an existing page. Steps you have to take now are:
- Create a folder with the same name on the same level as the page
- Move the page into the folder
- Set the default page of the folder to the moved page
- Then add a subpage to the folder
For me this is always the hardest part to explain to content editors when giving a course. Making pages folderish fixes this issue.
comment:7 Changed 7 years ago by limi
I would argue that this should be fixed properly in Plone 5 instead of doing it in Plone 4, which will only add confusion. :)
comment:8 Changed 7 years ago by wichert
Can you explain how Plone N+1 intends to do this? Will it really be that different from this proposal?
comment:9 Changed 7 years ago by elvix
I strongly dislike the menu proposal of conditionally adding siblings or children. Users don't add children they add pages. I'd say: If the current context is a container show the menu to add a "child" page. If the context is not folderish, don't allow adding at all.
This is imo similar enough to the Plone 5 way that it can be implemented. It is also similar to the current way. It can act as a nice bridge to Plone 5-
comment:10 in reply to: ↑ 2 Changed 7 years ago by alecm
Replying to wichert:
I solved that recently by changing the add item menu like this:
- always show the add item menu
- if the current context is a container and new items would be created inside it use add child as title for the menu
- if the current context is not a container and new items would be created alongside the current context use add sibling as title for the menu
That is a simple change which restores the ability to easily create multiple items and removes any possible confusion.
Funny, this essentially used to be the default behavior "Add item" for "Structural Folders" "Add to folder" for everything else. The language probably wasn't clear enough, but I agree it's better than the current situation. It doesn't have much to do with this PLIP though. And the potential idea of two add menus on most content seems pretty frightening.
comment:11 Changed 7 years ago by alecm
There are a number of add-ons which provide folderish pages. I'd like to see an assessment of which of those might be appropriate for inclusion or as a model for reimplementing the ATDocument type. Even if none are appropriate, they provide a good starting point for understanding the potential pitfalls with this approach. This change could be very beneficial, but a lot of thought will need to go into the UI.
comment:12 Changed 7 years ago by pupq
There are two separate ideas here (technically similar, but from users perspectives, different):
- "the page-ish folder" (let's call it a "section"). People want a folder, which shows like a folder, and they think of as a folder, but that has a body field. Folder+DefaultPage is the same as this, but it's *very* confusing for many people to use default pages (in my usability tests with Plone, success rates for things like editing and sharing when default pages are used drops to the low 20%s!). I've recommended, in classes, for years: "Build a content type that is a folder+body field, and use that for the common case of folders-that-can-have-a-body-plus-list-whats-in-them").
- "the folderish-page" (let's call it an "article"). This is the problem that RichDocument solved, and solved well. People don't think of it as a folder, but think of it as a page that happens to be able to hold its own images/files.
Ideally, in a dream world, the content menu would have "Folder" and "Page", where folder=section and page=article, and people didn't have to decide, in advance, whether they wanted a body field for their folders, or whether their page might one day hold its own images and files. That may not be feasible (it would probably require changing the base classes of the existing classes and migration). But that's how people *think* about these things.
I'm not sure this PLIP really covers both of these cases, or that a full implementation is well explained here. But i can tell you that getting some help here would close a significant, major area of confusion for our integrators.
I don't think this should wait until 5.0. It might be that there's too much here to do in the 4.0 timeframe. But this is one of the most critical of the PLIPs I've seen.
Definitely +1 to these ideas.
comment:13 Changed 7 years ago by elvix
In Plone 5, the second concept (RichDocument: pages contain their own binary data, images and files) will hopefully be solved by tiles containing files/images, and images/files not being treated as content anymore (a wrong decision that we inherited from the early CMF days).
In Plone 4, we can perhaps solve much of the first concept (complexity of default pages) by simply giving folders a body text rich field. We can still call them folders IMO. Users will still need to sometimes choose default pages: especially for the listing scenario with collections as defaults.
comment:14 Changed 7 years ago by pupq
(just to be clear: I wasn't suggesting that we actually rename them; rather that, in this conversation, it's useful to talk about the two cases as distinct things)
Adding a body field to folders would be a killer feature for a lot of people.
comment:15 Changed 7 years ago by regebro
Although I generally agree that merging folders and pages is the way to go, it's a big change that pervades many aspects of how Plone currently work. Most of these aspects are going to be changed in Plone 5 anyway, while they are not going to be changed in Plone 4. So doing this properly in Plone 4 is not a good idea, especially as we have to do it again, slightly differently, in Plone 5.
Therefore many solutions of quick fixes that doesn't actually merge folders and pages have been proposed, but I think they might actually just add confusion instead of solving it.
So I'm -1 on this. It should be done, but I think it should be done properly. And we can't move *all* the big new features from Plone 5 into Plone 4, because then we can just drop Plone 4 and move Plone 5 back to be called Plone 4 again. ;)
comment:16 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:18 Changed 7 years ago by MatthewWilkes
FWT Vote: -1 for the reasons already stated, it's a confusing half-way house between 3 and 5, I think we're better keeping it as it is until we're ready with tiles.
comment:19 Changed 7 years ago by rossp
FWT vote -1 for reasons stated. To make this an improvement in clarity would require the full set of changes proposed for Plone 5. IOW, I think this is a case where trying to bridge the change will actually make things worse.
comment:20 Changed 7 years ago by davisagli
FWT vote -1. I agree that we probably want this in the long term, but this is a risky UI change and there simply isn't enough consideration of the implications of how things like the add menu and assigning default items would change for me to feel good about supporting this.
I would be +1 on adding a text field to folders, which is low risk and would remove the need to understand default items just to add a page within a page.
comment:21 Changed 7 years ago by raphael
FWT vote: -1 for the reasons stated
(no problem with adding an optional text field to folders if that helps some)
comment:22 Changed 7 years ago by calvinhp
FWT Vote: -1 and to wait until 5 to see a better final implementation. Although I wouldn't mind seeing another related PLIP to add a rich body field to the current folder.
comment:23 Changed 7 years ago by erikrose
FWT vote: +1 simply because I'd like to have the chance to evaluate this with all the UI issues worked out. The quality of the UI would determine my final vote. (Note that users won't think of Plone 4 as just a stepping stone to 5, as we do. They'll be surprised if the UI undergoes a major change and then changes again.)
comment:24 Changed 7 years ago by esteele
- Status changed from new to closed
- Resolution set to wontfix
Rejected for Plone 4.0 by FWT vote.
comment:25 Changed 6 years ago by wichert
A major reason for rejection for this PLIP appears to be that it will be too much of an 'in-between' thing between Plone 3 and Plone 5. I have not seen a proposal for Plone 5 in this area, nor has the request in this ticket for more information on that been answered. Which makes me wonder: is there a plan for Plone 5 to address this issue, or are we handwaving?
comment:26 Changed 6 years ago by alecm
My understanding is that in the idealized world of Deco/Tiles every page will be folderish. The fact that we don't yet have PLIPs covering the specifics of those technologies might seem a bit worrying though :-)
comment:27 Changed 6 years ago by limi
Yeah, that's the idea. One of the core ideas of Plone 5 is that everything can behave as a container.
There's no PLIP yet, since people are still mostly busy with Plone 4. I'll most likely be writing the PLIP on this (or at least a starting point) if nobody beats me to it. :)
comment:28 Changed 5 years ago by erral
We currently use a custom "folderish-page" content-type called "DonEdukia" (already implemented when we built plain Zope sites with Localizer) in all of our Plone sites. You can get it from:
http://www.codesyntax.com/en/products/cs.donedukia
Some background on this product:
http://www.codesyntax.com/en/blog/donedukia-pages-and-folders
I strongly support this. The usability gains are much bigger than the possible drawbacks.
The biggest challenge is knowing where content will end up when you ad it from the "add item" menu. contained in the page/folder or next to it?