PLIP (WIP) Not obvious where to add non-global types

[djay]

Proposer:

Abstract

TBD

Motivation

User problem

As a site admin you are setting up a site where news items only go in the news folder. You might have a specific group who are the ones able to add the News type but once they log in they don't aren't offered any help in knowing they have to go to the News folder and Click on the Add dropdown to add News (their primary job). (from https://trello.com/c/d2Majel8/3-tricky-to-configure-single-location-content-types-to-make-it-easy-for-editors)

Internal

• to work out if a type can be added in only one or a few places a new index would likely be needed. Alternatively a special store could be updated whenever "restrictions" changes are made.

  Proposal & Implementation

TBD

Options

1. Existing Plone restrictions
   • con: doesn't really solve the problem of helping them know where to go.
2. You can train them.
   • con: These users could be infrequent users so could forget.
3. Content rules
   • allow users to add anywhere but use content rules to move after add.
   • similar but more flexible idea - https://plone.org/products/hephaistos
   • con: you can't restrict adding items to other places. Users must have contributor role everywhere.
4. Favourites
   • e.g. Group portlets with instructions and links
   • or short cuts in the toolbar.
   • pro: very flexible
   • con: users have to look in two places to add things which is confusing
5. All types in "Add new" drop down.
   • Change the Add dropdown to include items you can add anywhere not just in the current folder.
   • During the process of adding/editing include the ability for the editor to pick the location you want the content to go.
     • If only one location is possible then its readonly.
     • If only a few locations are possible then its a dropdown. (This could also allow them to preview url of the new item before they add it).
     • if more than a few its free text (or widget to browse)
     • pro: allows moving while inside the edit interface
     • con: Might require an extra index to determine quickly where you can add
     • con: Add drop down might be very large in a site with location specific type.
     • could mitigate this by allowing a site admin to hide certain types not wanted to add globally.
   • con: doesn't really help in the case where the content type is the same ie big images in one folder and small images in another folder.
6. like 5, but turn "add new" into a form rather than a drop down.
   • pro: gives extra room to explain the different content types and give a preview
   • con: it's an extra page load but then if you are adding content anyway you are going to go to edit regardless so its really any slower.
7. ??
8. ??

How a new "add new" form might look (option 6)

Risks

see cons above

[vangheem]

Something like #5 should be done.

[jensens]

FYI: Products.Hepheistos https://plone.org/products/hephaistos is some rule base factory I wrote more than 10 years ago and allowed to add some Portal Type everywhere and it got placed at the place where it belonged to according to the rules.

[jensens]

But imo this all increases Plones core complexity a lot and should live in an addon. I will close this issue now (cleanup session currently)

[djay]

I can understand your desire to be want to be tidy(??) But since when does complexity of the implementation determine the importance of a user need? This is outside of your wrong judgement of this being hard/complex to implement or making the core complex. Do you have proof of this? Third, are you the fwt? Where is it written the rules of what goes into the core?

This open unmet need of plone. It is something plone doesn't do well. We should be honest about it and discuss how to fix it. This is the best place to do that. Would it help if I labeled it as PLIP WIP?

Reopen it and please don't close any other similar issues for similar spurious reasons.

On Fri, 26 Feb 2016 10:14 pm Jens W. Klein notifications@github.com wrote:

But imo this all increases Plones core complexity a lot and should live in an addon. I will close this issue now (cleanup session currently)

— Reply to this email directly or view it on GitHub https://github.com/plone/Products.CMFPlone/issues/464#issuecomment-189297286 .

[jensens]

I try to keep a sane number of issues in here - and i'am not sure if its a good idea to make the issue tracker an idea list. If we decide to make it one I'd introduce an new category "type: idea". Anyway. It would help a lot if you provide some information if you or anyone else plan to actually work on it. otherwise this entry is a zombie in the issue tracker. It would indeed help if you plip it, so it can go through the official PLIP process. But keep in mind, PLIPs w/o any probability to be implemented will be closed too at some point.

[hvelarde]

-1 for the same reasons I mentioned in #1371 (BTW, this is mostly a replica of what was already proposed there).

I agree with @jensens, this adds a lot of unnecessary complexity and should live in an add-on that could be installed by site administrators dealing with users that can't remember they must add News Items in the News folder.

[djay]

@hvelarde , @jensens a) please argue against the user problem, not the implementation details. Does it add any user complexity? If it does add any implementation complexity, can you be more specific so I can add your concerns to the risks?

[hvelarde]

@djay that's exactly the problem: I don't see a use case here for the core. I'm not saying there is no problem with users not remembering where and/or how to do certain things, but that's another story.

image the following scenario based on yours: a user has to add press releases (news items) in one folder and internal memos (also news items) in another, and she forgets where to add the content… then what? worst: a user has to add product specifications (PDF files) in one folder and product certificates (also PDF files) in another... then what? are you going to implement OCR and semantic analysis in the core to avoid them putting the content in the wrong place?

your use case belongs to an add-on or to a theme, not to the core and your solution breaks normal Plone workflow and UI.

[djay]

Tell you what @hvelarde. Let's just agree from now on: if I say the words "stick to the risks!" you can take it as read I mean the following.

• if you want to tell me it's technically too complicated, great, tell me how its complicated and I will add it as a risk and we can both think of ways to mitigate it.
• if you want to suggest an alternative way to solve the problem that has less risks. great I will include it
• if you want to point out a risk with one of the proposed solutions, great I will include it. for example it prevents users doing X, or makes Y usecase harder to do.
• if you want to tell me why a usecase is low priority, great I will include that as a risk that we might be wasting resources on fixing something that not many people will use.

but

• neither you or I are in the FWT so it's not our decision whats in core or not so anything +1, -1, in core, plugin I will ignore
• if you want to based your arguments on an assumed understanding of the rules of whats in core or not, and what normal plone workflow is and UI then you should define them otherwise I will ignore it. BTW, Plone UI is not set it stone. If instead you want to say there is a risk of creating churn for existing users and integrators by changing the UI then great then I wlll add that as a risk
• if you want tell me that something fixes one usecase and not others, this isn't constructive and I will ignore it. Fixing some usecases instead of all usecases is still better than fixing no usecases.
• similarly if you argue against one case while missing/not reading the other usecases I will also ignore it.
• if you want to tell me that solution 1 is better than solution 2 because solution one fixes less usecases than solution 2 I will ignore it. If you want to instead tell me the risks in solution 2 then great, I'll add it.
• if you want argue that a usecase doesn't actually exist in the real world, great noted but since I only put up stuff that I've seen real users get wrong, then I'll likely ignore it.
• if anyone wants to close a UX bug for a reason other than its fixed, I will reopen it. We need to document whats broken (even if its a little bit) so we can improve.

if we do this, then we can both spend more of our time trying to help improve plone ok?

Hector please stick to the risks.

[jensens]

Process:

• You can discuss here whatever you like, but - hint - sometimes a hangout/fon/skype/...nameit call to discuss is more efficient and reduces misunderstandings,
• There is an offical process to get new features into Plone: PLIPs http://docs.plone.org/develop/coredev/docs/plips.html
• PLIPs are a good place to collect ideas and opinions, start as a kind of RFC, refine later.
• a PLIP implies a way to get it implemented (pay somebody out of a project, find a volunteer, fundraising, ...).
• PLIPs are not meant as a long-term store of ideas.

Use-Case (my very personal opinion):

• The overall use case is valid, but does not apply everywhere.

• The details like location selection

  • freely,
  • from a given list of possible locations,
  • via auto-detecting using a rule-chain (where to place the new content)

  are not defined completly.

• this issue does not cover the complete set of use-cases involved in the problem space.

[thet]

We discussed the role of the issue tracker and where to add ideas at the last FWT meeting. I actually like to have a place where to add ideas and discuss visions about Plone. IIRC we agreed that we will introduce a new "ideas" label. But we didn't document this in our protocoll. Is that correct, @jensens ?

Regarding PLIPs: They need a PLIP proposer, which takes care the PLIP is getting developed and not abandoned. And a PLIP seconder, who takes care, all the necessary information is at hand and supports the PLIP proposer. Otherwise, the FWT won't process it.

@djay regarding this user problem - would it help, if we had some kind of bookmark system, which integrates in the toolbar (with icon, title, description)? Maybe even in the add menu as first section - with context specific "add" items below. The place where to add something has to be defined by site admins anyways - so they also can add bookmarks for that. Disadvantage is, that these adding-bookmarks won't update themselves, when constraints are changed.

[hvelarde]

I spend hours of my time every day keeping an eye of what is going on because I also have ideas, experience and, last but not least, I make a living on Plone; it is sad to hear you dislike that, @djay.

in the future, if my time permits it, I will try to give you more arguments when worth it; just try to have some patience with me because I'm going to continue commenting on everything I have something to say and not only on what you want me to comment.

BTW, the voting process on accepting a PLIP or not does not takes place here; this is just an open space to exchange opinions.

[djay]

@thet, @jensens It's great the FWT agree on a place for harder UX problems. I know the CMFPlone issue tracker is not ideal but I've previously tried things like trello (https://trello.com/b/h8J1evdp/the-plone-ux-hit-list-beta) without success. We already have too many "communities".

I'm not sure "idea" is the right term however. What is the difference between enhancement and idea?

My intention is more to highlight UX issues, get voting on them by real users (I'm working on this part) and then after that, think about solutions. I'm not that fussed on the name however, as long as we do have a process where its ok to suggest UX problems before we have solutions and those UX problems don't get deleted (or voted down prematurely on technical grounds). I actually just changed it to PLIP WIP because I was frustrated and thought it was less likely to get closed, but it actually works ok IMO. Maybe PrePLIP? I will experiment with the format to show the two processes are perhaps not that different

BTW, hangout/skype/irc etc works great if we all lived in one timezone. I ran the UX team for awhile and it sucked being in the least popular timezone. Same thing applies to events like PlOG. To be more inclusive we maybe have to use less ideal, but more asynchronous tools like this.

[djay]

I updated the format. I'll also merge with #1371 as its a duplicate. My mistake.

[djay]

@thet, @jensens I think the other confusion that is cropping up is that people are used to the idea of voting on an idea/feature/proposal. A -1 without even picking one solution yet doesn't make sense. Are they -1 on the problem, or one of the solutions? Maybe a WIP PLIP makes it more explicit that no solution has been picked yet?

[jensens]

@djay Well, as Github comment, depends really on. I usually vote for the solution. But often its more a "Oh yes, had the problem, good you think of a solution" - w/o deeper inspection.

In PLIP votings (which are done by FWT here) the proposed solution with its risks and impact is in focus. Later on a review happens - more or less deep - depends really on the impact. The review then is discussed at FWT hangouts.

A WIP or RFC mark is anyway a good idea. It signals: the idea is not thought to the end, what do you think, what are your ideas.

[djay]

closing this in favour of https://github.com/plone/Products.CMFPlone/issues/1371 as its a duplicate