Ticket #13397 (confirmed PLIP)
PLIP. Placeless adding
Reported by: | djay | Owned by: | vangheem |
---|---|---|---|
Priority: | minor | Milestone: | Future |
Component: | User Experience and Interface | Version: | 4.2 |
Keywords: | contentmenu | Cc: | amleczko |
Description
Proposer: Dylan jay Seconded:
Motivation
Many times custom types are only designed to be added in a certain place, or you may want restrict built in types to limited places in your site. In such cases plone is harder work than it should be to add a new item. You have know where to add it, browse to that location, often with a nav designed for exploring not fast access, then you can select from the menu. We've seen installs with lots of place specific types where training is needed to teach where to add each type.
Proposal
We propose two modifications to Plone.
- All add forms will have a path/location field. You can browse or search for a folder to add your item too, after you have clicked add. This will be filter to just places you are able to add this content type. You should be able to paste a path too, and possibly set the shortname, so the field becomes a "url" field.
- The "add new" menu will be modified to have two clearly marked sections. The top section will items that can be added in the local context, marked "add here". The bottom section will be types not already listed in add-here but which the current user has the ability to add "somewhere" in the site. This could be labeled "global add"?. When using global add, the location field would be empty, unless just a single folder is available to add that type and path field will be ready-only Some type might need to be excluded from global add like pfg types.
Adding the path field to types makes plone more familiar to users of other CMs and also allows a user to change their mind on where it should go as they are creating content.
Assumptions
This proposal mixes context actions with global actions so if added to the green bar it would it could be confusing. Currently the "green bar" is for context specific actions only, however CMSUI doesn't make such a clear distinction. We assume Plone will be switching to a CMSUI/p.a.toolbar type UI in the near future so this proposal won't be confusing.
Deliverables
- New add menu implementation
- modify standard metadata on standard types so forms include path
field. Or else use schemaextender. Modify dexterity to do same.
- widget for path with browse button and editable path.
- Change the way factory creation works in AT and dexterity to allow
creation in different folder.
Risks
- Add menu could get long. Could be mitigated having a more button or scroll list.
- Mixing global and contextual adding in one menu could be confusing. Having two separate menus for global adding vs contextual adding might also be confusing as there are two places to add. There is a risk confusion either way and some testing might be needed to determine which UI is best.
Change History
comment:1 Changed 3 years ago by frapell
- Owner set to vangheem
- Component changed from Unknown to User Experience and Interface
- Type changed from Bug to PLIP
- Keywords contentmenu added
comment:4 Changed 3 years ago by davisagli
I'm not a huge fan of this idea; I think it has the potential to make the UI for adding content a lot more confusing. Plone's paradigm of adding content in the folder you're looking at is one of it's nice simplicities compared to other CMSs.
It's already possible to change the expression used to generate the add URL for a type, so you should already be able to make sure that a particular type always links to its add form in a particular context from the add menu. Along with that, we could implement https://github.com/plone/plone.app.contentmenu/issues/2 and gain some more flexibility with a lot less effort than what's discussed in this PLIP.
comment:5 Changed 3 years ago by vangheem
I agree with davisagli on this and think we should just implement: https://github.com/plone/plone.app.contentmenu/issues/2
comment:6 Changed 3 years ago by djay
Kind of misses the point of the PLIP. The point wasn't to provide a developer a way to add new items to the add menu, but rather provide a way for a user to quickly add content deep in the site if thats the only place they are allowed to add content anyway.
I will take it back to the UI team and get consensus on the best way to solve this problem.
comment:7 Changed 3 years ago by THijs
The suggestion of davisagli and vangheem would only give a small handhold for a developer to create global add links, so that does not give a nice clear solution. In this this case you would at least an info box telling you you've been redirected somewhere.
On the other hand the PLIP also misses something. Part 1 would be confusing. The current way of adding content "where you are" (I agree with davisagli) is one of the strong points of Plone, I would not muddle it with a location field.
Global adding is a good idea, maybe even under the add menu, but I would expect it to work together with "implicitly addable". For instance through site setup. Now you need an extra content type to allow one specific content type in one place. You also have to do everything through the ZMI. Or you allow it everywhere and then restrict it away. If you would be able to point the "not implicitly addable" content types to a location and you could add them to the global menu, that would seem a better fit to me.
On the menu becoming long, it could be "big dropdownish" and be two colums (global and local).
comment:8 Changed 3 years ago by THijs
Going further on the two column add menu, one column would just have the "implicitly addable" content types. The second column could be "Content type in Location", for instance "News Item in News" or "Blogpost in Blog", "Image in Imagebank". You can even have the "implicitly addable" types also come back in the global column, like "Collection in Portlet collections". It could have a small disclaimer at the bottom saying "you will be redirected".