Ticket #12199 (closed PLIP: wontfix)
Display both default item and folder 'new item' menu in the same menu
Reported by: | encolpe | Owned by: | encolpe |
---|---|---|---|
Priority: | minor | Milestone: | 4.3 |
Component: | User Experience and Interface | Version: | |
Keywords: | Cc: |
Description (last modified by encolpe) (diff)
Proposer: Encolpe DEGOUTE
Seconder: None as yet
Motivation
When using a folderish content type like PloneFormGen or Collection as the default view's chosen item the Add menu display only addable content type of the parent. To manage the folderish content type content you must change the default view of the parent, add you new content then set again the folderish content type as the default view's chosen item. That procedure is confusing for contributors.
The Display menu yet display both default item and parent options when the default item is a folderish content type.
Assumptions
Users are able to understand where they will add their new content if the separator is cleat enough.
Proposal & Implementation
Integrate modification done in the Display menu in the Add menu. It there's one addable type in the default item the menu Add menu is splitted.
Deliverables
Standard items:
- Branch plone.app.content and plone.app.contentmenu
- Unit tests are yet implemented
- Localization: 3 more chains are added
You can look at the image below to see the result.
Risks
This UI modification should be implemented in others content menus. This will not slow down the menus implementation nor speed up it. Performance work must be done in another PLIP.
Participants
Encolpe DEGOUTE (encolpe)
Progress
Two branches were created last month to implement this plip:
Attachments
Change History
Changed 5 years ago by encolpe
-
attachment
new-item-menu.jpeg
added
comment:3 Changed 5 years ago by eleddy
After discussion with the FWT, we think that the current proposed solution is more confusing in the non-edge case scenario. Those menus could get quite large and unmanageable/confusing.Can you work with the UI team on these mockups to try and come up with something a but more approachable?
comment:6 Changed 4 years ago by eleddy
the FWT is going to get a couple opinions on this before deciding. We are nervous that this is too special of a case to break the standard. MOre soon!
comment:7 Changed 4 years ago by spliter
I do see what Encolpe wants to solve and how this can be a problem. Though, I don't think this use case is generic enough to be implemented in the proposed way. Those folderish content types are not that usually used as default views. So, we are talking more about a superuser feature.
But even IF we decide that this is generic enough case, the proposed solution really doesn't improve things in my opinion. Though it adds clutter to the menu that can now grow to really annoying hights. In the particular example we see on the screenshot attached, both blocks have identical list of items. And no matter what the titles of those blocks say, the users will have really hard time figuring out the difference between the two. And I don't even discuss the titles of those blocks "Add in Folder" and "Add in Item" sound way too techy and might be (not necessary even) understood only by somebody who is familiar with Plone internals.
So, I think the issue raised is valid, but the proposal is not a solution but is just a workaround that will require even more workarounds and fixes later.
Proposed 'New Item...' menu