Ticket #12199 (closed PLIP: wontfix)

Opened 5 years ago

Last modified 4 years ago

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

new-item-menu.jpeg Download (22.7 KB) - added by encolpe 5 years ago.
Proposed 'New Item...' menu

Change History

Changed 5 years ago by encolpe

Proposed 'New Item...' menu

comment:1 Changed 5 years ago by encolpe

  • Description modified (diff)

comment:2 Changed 5 years ago by encolpe

  • Owner set to encolpe

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:4 Changed 4 years ago by eleddy

Any update on this?

comment:5 Changed 4 years ago by encolpe

I'm waiting the beginning of a discussion on the UI list.

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.

comment:8 Changed 4 years ago by eleddy

  • Status changed from new to closed
  • Resolution set to wontfix

thanks for the review spliter. for the moment we are going to close this ticket until a better solution is presented.

Note: See TracTickets for help on using tickets.