PLIP (WIP) navigating to add new content is tedious

[djay]

Proposer: Seconder:

Abstract

TBD. This is a problem requiring a solution. This is a placeholder for later decided on solution. Please keep any voting, +1, -1 for if you think this is a problem worth solving, not about a solution. If you see risks in a solution, feel free to edit the risks directly.

Motivation

Plone makes users navigate to where they want content before they can add it. This means

• They have to know where it will live before they have even started writing the content
• If they are writing content in many places they have to jump around
• its unnecessary if the content can only live in one (or a few) places anyway like a news item in a news folder.
• if the content can only be added in one place, a new user might not discover that place.
• It might be easier to type or paste a path than browse
• The folders have to be created in advance

see https://dev.plone.org/ticket/13397 (from https://trello.com/c/d2Majel8/3-tricky-to-configure-single-location-content-types-to-make-it-easy-for-editors)

Proposal & Implementation

TBD

Options (WIP)

1. Edit Path in @@edit

• 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

  2. "Add New" modal

Remove the add new menu and replace it will a dialog which lets you select type as well as the path.

• 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.

How a new "add new" form might look

3. Content Rules

Document/encourage the use of content rules to move single location content to the right place

• allow users to add anywhere but use content rules to move after add.
• similar but more flexible idea - https://plone.org/products/hephaistos
  • pro: no implementation needed

    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. Plone restrictions

• con: doesn't really solve the problem of helping them know where to go.

  Other ideas? Add them

  Risks

  1. Edit Path in @@edit

• 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.

  2. "Add New" modal

• 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.

  3. Content rules

• con: you can't restrict adding items to other places. Users must have contributor role everywhere.
• con: have to add rules for each type
• con: doesn't if content can live in a few locations instead of one
• con: doesn't help the user understand what is going on. Do they get notified why their content has disappeared? (perhaps a redirect content action could help with this?)
  • con: doesn't help with 2,3,5,6

    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

[hvelarde]

-1 on this; IMO the way it's implemented right now is fine and you can solve your use case using content rules.

[djay]

@hvelarde You solve only one of the usecases using content rules, ie when the content should live in a single location. I don't see how it solves any others. You also don't state the downside of any of the proposals.

[hvelarde]

@djay IMO, you are trying to get rid of the beauty of an OODB design; can you imagine your computer's FS without the folder metaphor? just think on your use case: OS X/Windows/Linux make users navigate to where they want content before they can add it…

I have content rules moving content to specific areas of the site in almost all of our deployments using specific field values or dates and I'm totally fine with that.

Plone is not Wordpress.

[djay]

It might not be how you like it hector but nothing prevents navigating to folders to add content. It is a purely an additive change. Forcing people to work one one way when you can support either way equally is just bad UX. These are ideas to a problem that I've observed with real users in both training and support questions. It is not really fair for you to sit there are say the issue doesn't exist. In fact I know of one example, one of the highest traffic plone sites in the world at the time, where this issue was one of a list of issues as to why they dropped plone and vowed never to use open source again. I am not making this up.

On Wed, 10 Feb 2016 8:04 pm Héctor Velarde notifications@github.com wrote:

@djay https://github.com/djay IMO, you are trying to get rid of the beauty of an OODB design; can you imagine your computer's FS without the folder metaphor? just think on your use case: OS X/Windows/Linux make users navigate to where they want content before they can add it…

I have content rules moving content to specific areas of the site in almost all of our deployments using specific field values or dates and I'm totally fine with that.

Plone is not Wordpress.

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

[hvelarde]

@djay your whole argument smells like FUD: if we don't implement this feature people will start dropping Plone and OSS!

I don't think the benefits of this worth complicating more the UI as at the end you will always have to navigate to the target folder; but that's only my opinion and it's fine for you not to like it.

[cewing]

I'm -1 on this as well.

I understand that the in-place editing principle is different from other CMSs, but it is also the feature that best distinguishes Plone from other systems. It is a selling point for the large majority of content created, and for items like News Items or Events, where a single, global location might be preferrable, content rules can handle moving those types to where they should be automatically, either on creation, or after some workflow transition.

As for users "have[ing] to know where it will live before they have even started writing the content", that's just not true at all. It's a common practice to create content in a personal folder and then cut-paste it into a different location.

People use a folder-based file system all the time, it's a part of daily life. Not having to think in terms of "path" is an advantage that can be sold.

I would suggest that if this is a strong enough requirement--if there are users who do in fact want things to work this way--it would be best to implement an add-on that would provide this UI. Then it can win by proving popular and can be iteratively improved without jeopardizing one of the most characteristic features of Plone.

Finally, I would also suggest that having two separate ways of deciding how and where to add content in your site is a path to madness. We've spent a lot of time building second and third ways to do lots of things without ever removing old ways. We've also spent a lot of time trying to undo those mistakes by narrowing in on the best way and eliminating poorer options. Let's learn from that lesson.

[davilima6]

I agree with @cewing in the add-on approach. That's the best way to get a feature suggestion like yours into core, don't you think so, @djay? That's how folder contents, which is central functionality, got so many improvements in P5: it was so good on its own it became highly desired in core.

I'm not saying I don't like the idea (it's even nicer for heavy users like us) but it's important to keep in mind this change has the potential to mess with Plone's mental model for adding content, bringing it closer to other CMSs where you add from a central location, often modelling target path as a field which can later be updated (Joomla is like that, IINM). IMHO this risk of impact is the greatest reason this should be born in an add-on and even tested/refined as a frontend-only mockup beforehand.

[djay]

I've updated the format. Hopefully it's made it clearer that its confusing what you guys are -1 to. It would help if you picked a specific idea that you have found risks with, and you or I can add extra risks to that particular idea.

What I'm mostly trying to do is highlight the areas of plone that, while we are used to them, I often find new users confused by. So I understand how old users will likely reject this as a real issue unless you are often training new users or running a support desk for new users.

@cewing @davilima6 I wanted to add the "could mess with plones folder model" as a risk for both Edit Path in @@edit and Add new model but I'm still trying to work out how that would happen?

You seem to be saying if Fred is in News, he clicks "add new/Page" and then opts to change path from "/news/new-page" to "/news/related-news/todaysnews" or "/contactus/howtofindus" he would get confused? It's not really changing the model. It's just giving someone a shortcut. It's not really different from "save as..." in word.

Or perhaps is it about the inplace editing? Ie the navbar/breadcrumbs being visible during the edit itself? Yes that could be confusing, but that has its own issues to do with allowing theming of the editing interface making themeing much harder. Also Add new model doesn't suffer this problem.

Perhaps another way you are thinking it could be confusing is that Add new list of types now includes things not currently addable in the current location. A) you have this issue with the content rules solution. B) you can mitigate this by separating the list into "Addable here" vs "Shortcut to add elsewhere".

Finally, the idea that having two ways to do things is bad UX. This is untrue. Its good UX to have multiple ways to do this as long as the are exactly equivalent. A good example is keyboard shortcuts for cut, copy and paste, as well as menu items vs toolbar icons. Another example is rename in both folder contents vs action rename. People think about something in different ways. If can cater for both ways of thinking without cluttering the UI then its a very good thing.

Where you should never allow multiple ways of doing things is when they are slightly different and have hidden pros and cons. This isn't the case here. Adding something via browsing the adding, vs add then browse, will have the exact same result. It's just a shortcut.

BTW, I never precluded a plugin and in fact @vangheem already has one in the works. This is about highlighting the problem first while knowing its not obvious yet the best way to fix.

[hvelarde]

for me the only interesting thing is Favorites, something that Plone used to have included in the past, as @agnogueira use to remind me all the time.

currently, there seem to be 2 implementations as add-ons:

• collective.favorites
• ftw.dashboard.portlets.favourites

@djay if you want to push a PLIP for re-adding that feature to Plone, I'll be supporting it.

[Rudd-O]

OP is right, in more ways than one.

I know that many times I have felt like writing something quickly on my Web site, but the whole navigating then clicking add turns me off from publishing.

Imagine the following user experience:

• Editor reaches for the Add... menu. Selects a content type.
• Plone edit view shows a field that lets the Editor typeahead-search-select where to store the content (defaulting to the current folder), and, upon save, can deploy or move the content there.
• If the Editor does not have permission to add content to that folder, we proceed with the following:
• The Editor selects the desired content type from the Add... menu.
• He is redirected, not to the standard ./++add++/, but to a page that lets him typeahead-search-for / select one of any writable (to the Editor) locations where the Editor may store the added content. Bonus points if the interstitial presents a list of "recent locations added to" and preselects the very most recent one, so that 99% of the time, the Editor can proceed with zero or one click.
• Once the Editor has selected the destination folder, the /++add++<content/ URI for that folder is loaded via redirect, and the normal edit form can finally appear.
• If it turns out that there is only one folder where the user can add content, then the whole interstitial "where do we add this?" page can be skipped, that folder can be selected by Plone, and the Editor will be automatically redirected to the pertinent ./++add++ URI for that folder. This is useful for sites that have a Members content folder, where the Member can add content only to that folder, and then the Manager or Editor takes the workflow actions to publish that content (manually or with content rules).
• If the user cannot add content anywhere, perhaps then the Add content button can be eliminated.
• If checking for this sort of thing ahead of time poses an undue database load, then it's perfectly okay as a fallback to let the "Add content interstitial" show a message to the user "You don't have write permission to the selected folder".

Yes, the above is (in some cases) one more page load, but it's better / faster / more intuitive than the many page loads it involves to browse to the target folder.

Note that this solves several particularly irritating use cases:

1. "Oh, shit, I added this content in the wrong folder, now I have to go to the damn folder view, hunt the content, and cut/paste it."
2. "Why can't I add any content here?"
3. "You know, perhaps this folder is not where I want to publish this content, how about I click on this "Save to..." / "Move to..." box and search for a different folder?"

Plone is certainly not WordPress, but it's okay to shamelessly steal the good ideas from WordPress. I say this as a former WordPress user who migrated to Plone.

One more note: in no way is this proposal a proposal to "ruin the beauty of the OODB". We're all in agreement that content should be stored according to the hierarchical rules of the OODB. What we're discussing is how to make it faster for the end user to publish content. Letting the user "add content anywhere" (not really, but that is the idea behind the illusion) — incidentally, the same model of other CMSes, as well as the model of most desktop applications — seems like a very good way to incentivize Plone use.

One more thing: if the Actions menu could gain a Move To... item that popped up a typeahead search for a folder, and when confirmed, moved the content there, I would be so happy.

[hvelarde]

@Rudd-O the workflow you're describing is overly complex to implement and you have no real gain as you need to select where to add the content anyway, it doesn't matter it you select it before adding it, or select it while adding it: you'll need to go to the folder anyway; and, as you already described, there's the problem of permissions.

I think there could be a way to solve this use case for certain kind of sites: we could add an option to have a folder to store static content and make that the default location for adding files and images; but only in that case to make it easier to implement and maintain.

I'm totally +1 on the Move to… option in the actions menu; I don't know why nobody thought about it before; please add a new issue describing that feature.

[agnogueira]

I think we are trying to implement a very complex solution to solve a very small feedback problem. When the user add a content, its not clear where the content will be created. Especially if the breadcrumbs is not present. We can easily solve this adding a small message in the begining of the add form, telling the user where the content are beeing created:

"This content will be created here yoursite/xxx/yyyy/zzzz. Click here if you like to change the place."

If the user click the link he can choose another place to create the content and "move" the creation to that new place.

Experienced users can just ignore the message.

[Rudd-O]

@hvelarde there is a gain, as others have tried to explain. The gain is that I, as an Editor of Plone, get to user experience gratification milestone of typing / uploading my content faster than without this feature. Saying "well, you eventually get to add your content" discards the vast and well-studied emotional impact distinction between 10 seconds to get to one's goal and 1 second to do so. The question of when to get to the folder is the key, and the answer is that the ways may all be valid, but from a user experience standpoint, they are not at all the same.

I want to note that what I described may be a bit complex to implement, but from the standpoint of the users who would see a benefit, it's far simpler than demanding the users browse to a location before adding content. Which is, frankly, an absurd demand. No OS or CMS does this in 2016. Do you navigate to a folder in your desktop before you create a document? No, no one does that, not on the desktop, not on the phone, not on a Web site. You open your app and you get the instant gratification of typing on your document, and then you decide where the document goes (which it bears reminding: 99% of the time, it's gonna be on a recent or the most recently used folder anyway).

I ask you to consider very carefully why that is. At the end, you'll discover that "navigate first, create document next" (which, if you remember, was a thing in Windows 95 and, suddenly, was not a thing anymore) was dropped / deemphasized / never implemented anymore for a reason. And that reason is: to get the user to do their work faster. The system model be damned — and it really was, as all OSes maintain the same hierarchical file system, even when they don't show it — the user model of "get me to content production faster" won in the end, and that was a good thing.

OK, having said that, here's what I would like you (@hvelarde) to do for me and for OP. I would like you to momentarily put your own objections aside, and tell me whether you accept that there's a good amount of the user base who would strongly prefer the user experience of "add-first-move-to-destination-later" over the current user experience of "browse-first-then-add-later". We need to at least be able to agree on that, and if we do not, then I kindly ask you to tell me what evidence would change your mind.

[Rudd-O]

@agnogueira it's a bit larger than a feedback problem.

However, what you are proposing is a great first step, because it would avoid the user having to navigate to the folder before initiating the "Add content" interaction. A slight improvement over your proposal — which already looks better than what we have — is to make that link and text say something like this:

    Store this news item in [           ~News~          ]

Where this UI element is a typeahead search box, much like the Related Content search box. The box will, of course, have the current folder preselected, and searching within it would only allow the user to select folders he has write permission to and that accept additions of that content type. Alternatively, the search results can show any folder, but — should the user typeahead-select a folder he can't write to — an error message to the right can tell the user that he is not allowed to store content on that folder.

The fallback non-JS implementation of this feature can either be a SPAN showing the location, like you showed us, or — alternatively — a text box that contains the path to the folder relative to the site root (ISiteRoot?) or portal root.

After your proposal is implemented, all that would remain is to make the Add content interaction available everywhere, and use a redirector to choose the most appropriate place based on the context (in non-folderish content views, for example, usually the right thing to do is to add the content to the parent folder).

Edit: I'm thinking this can be implemented with a "Movable" Dexterity behavior. Content that implements the behavior lets the user move it to a different folder directly from the Edit form, using a typeahead box line the Related Content box.

[djay]

As the title suggests it is as much about all the clicking ans navigating to add content as is about not being sure what you can add where. Its also about how some people think what something is (content) before location or URL. Think how many times in a word document you go to finder and click add new doc, vs write the doc and choose a location on first save?

On Thu, 29 Sep 2016, 4:58 PM André Nogueira notifications@github.com wrote:

I think we are trying to implement a very complex solution to solve a very small feedback problem. When the user add a content, its not clear where the content will be created. Especially if the breadcrumbs is not present. We can easily solve this adding a small message in the begining of the add form, telling the user where the content are beeing created:

"This content will be created here yoursite/xxx/yyyy/zzzz. Click here if you like to change the place."

[image: captura de tela de 2016-09-29 11-54-40] https://cloud.githubusercontent.com/assets/1030139/18959173/988c7250-863b-11e6-93ab-baaf88d8d67d.png

If the user click the link he can choose another place to create the content and "move" the creation to that new place.

Experienced users can just ignore the message.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/plone/Products.CMFPlone/issues/1371#issuecomment-250491459, or mute the thread https://github.com/notifications/unsubscribe-auth/AACi5LArov4q16NIdXKoeFNiFkREEMtdks5qu9H8gaJpZM4HWlnU .

[hvelarde]

then the Move to… action seems to be what you're looking for.

[Rudd-O]

I don't have any Move to... action on my sites.

[hvelarde]

not yet, but you were about to propose that enhancement… didn't you? ;-)

[Rudd-O]

Neither @djay nor I are "looking for a Move to... action" in this issue. We want the ability to add content first and later decide where it will go, without having to do intermediate steps. A Move to... action would be a nice to have, but it's not in the scope of this issue.

To reiterate what he said: how many times do you go to Finder and click "Add new doc" vs. first writing the doc? This is a rhetorical question that @djay posed. The answer is zero. Edit first, save later. For good reasons, that's how it works pretty much everywhere, except for Plone. There's a non-zero amount of people who dislike that about Plone. Count me among those people, even though I have had reasons enough to stick to it, since version 2.x.

@hvelarde, I would really like you to answer my question which I posed above. I'll repeat it here to save us time:

Please tell me whether you accept that there's a good amount of the user base who would strongly prefer the user experience of "add-first-move-to-destination-later" over the current user experience of "browse-first-then-add-later". We need to at least be able to agree on that, and if we do not, then I kindly ask you to tell me what evidence would change your mind.

[hvelarde]

I appreciate good arguments also and I understand your points; what I'm trying to find is a simpler approach to solve this issue.

what about changing the behavior of Save button to something similar to what we have in desktop applications? when I select Save I see a widget that list all the containers in which I have add permission and in which the type of content I'm creating is not constrained.

and that should be configurable: if I want it, I can enable it.

now we're approaching to something I could like ;-)

[Rudd-O]

While I appreciate your suggestion, let's first start by establishing the necessary common ground. Please answer my question. Thanks.

[Rudd-O]

To make progress, here's a crude demo of how the "choose where to save upon save" feature could look like:

[Rudd-O]

(I'm aware that the mockup looks wonky. It's meant to be just a mockup. I've proposed usability improvements to that particular widget in the plone.mockup project.

[tkimnguyen]

I know @hvelarde will comment on my marketing but Castle has a nice way of allowing you to add many content items without having to navigate back to the folder each time or having to use the browser's Back button. By default new content items go into the current folder but you can specify another container. You can add as many content items as you want by clicking the Create button, and each newly created content item appears in a list at the bottom of the dialog (clicking on the link lets you see the item in a new tab). If instead you click Create and Edit, you get the behaviour we currently have in Plone (the item is created and you're taken to its edit form).

[hvelarde]

I like this solution because is could also simplify the toolbar UI which currently sucks, BTW.

if this solves @djay use case I'm +1 on porting it upstream Plone's core, but only if it was not implemented using some JS framework, or if it has a good fall back if that's the case.

[tkimnguyen]

It uses React

[djay]

@tkimnguyen @hvelarde It's great that castle has taken these ideas, improved on them, made lots of other brave steps in trying to improve the Plone UX. I'd really like to talk about what is the best next step. Castle is essentially a fork which is not great for Plone or Castle. Is there some plan to by wildcard to bring these features back into the core or at least as plugins?

[djay]

@vangheem btw, I really like the castle UI for this, esp the bulk add idea. Very nice. Perhaps the only think I'd add a description for each content type for first time users. Once to add and then edit one of the ones you add, can you go back to the list of items you added somehow?

[tkimnguyen]

@djay when you click on the items you've added (via the Create button) it opens in a new tab/window.

Castle isn't a fork; it's a distribution. It uses Plone 5.0.x at the moment and adds to it (minus some eggs we have created from branches).

As for who would be taking Castle features and implementing them in Plone: it would probably not be Wildcard folks taking the lead on that, but we would help.

[djay]

On 25 May 2017, at 1:46 am, T. Kim Nguyen notifications@github.com wrote:

@djay when you click on the items you've added (via the Create button) it opens in a new tab/window.

Castle isn't a fork; it's a distribution. It uses Plone 5.0.x at the moment and adds to it (minus some eggs we have created from branches).

As for who would be taking Castle features and implementing them in Plone: it would probably not be Wildcard folks taking the lead on that, but we would help.

I wouldn’t call it a distribution either. A distribution to me is a collection of plugins and theme/s that are tested and work well together. But are still designed be used in isolation. ie should be modular and integrator friendly.

Castle and quieve both seem to follow the same model of “one big customisation on top of plone", similar to how plone was one big customisation on top CMF. I understand why it was done as its way cheaper to develop this way and it takes a lot more thought to consider how to decompose features into individual plugins and predict how they might be reused. But it does create this annoying standoff that no one can use the great code in castle unless they take everything… which is a lot, including having to install elasticsearch. So it might not technically be a fork but the end result is pretty much the same. We can’t use it or contribute unless we stop using plone and start using castle.

I’d be interested in discussing your ideas on how to modularise the features have to get them into the core. That lessons the maintenance burden you guys have if plone changes under castle and improves Plone UX hopefully making it more popular. An unpopular plone is not good for you guys or any of us.

[tkimnguyen]

Elastic search is not required to run Castle. Anyway, this is totally off topic, and I empathize with Nathan because no matter what good ideas people have or implement, they're argued to death and so little actual progress is made.

[hvelarde]

@tkimnguyen is sad to see you continue to discredit other people arguments no matter how justified they were and are: fixing broken things is way harder than discussing changes before they are implemented. that's why conservative visions in projects are so important, as people have to maintain existing projects and migration paths are essential.

the resource registries and the toolbar are just two examples of this: if we had discussed those for 6 months, we had saved 2 years of frustration.

[MrTango]

I like the general ideas of the create content first and then put it somewhere. And it would be nice to have this as an option in Plone. I don't see a reason why not as an add-on in the first step. This way we could experiment and get feedback and improve the whole thing over time. Taking the current implementation of castle and implement it similar as an addon. +1 for that

There is even more room for improment in this direction. I guess the same type of user, would like the idea not even to have to think about what type they want to add. Just add something and enhance it peace by peace, field by field, behavior be behavio, tile by tile ;). What a thing is is described by what data types it provides. Does it have a date (behavior/tile you name it), than it counts as an event. Does it have a file attached, than it also counts as a file and so on. The whole thing can start by just giving the THING a name aka title. This can become a todo item by adding a done bolean behavior/tile and could be enhanced by due date or start/end date. This is really powerful, but also not that easy to implement. It would need something like context-behaviors/tiles and this would be another project and brings a lot of changes.

@djay @hvelarde regarding Castle CMS/Quaive, i understand why they decided to just implement there ideas and thats fine and made it possible to realise them. Thats the way OS works and sometimes the only way, you can play ideas out. I agree that it would be nice to bring some of the ideas back to Plone and try to keep things as modular as possible. But for that we, as the community have to decide what and how we want it and that's the real challenge. I'm pretty sure that everyone in these projects (Distributions), yes I would call them as such, would be happy to have a Plone base as big as possible in there distribution and share as much as possible with thye community. But these things have to be worked out from all sides. Castle and Quaive make the Plone commutity ritcher and more diverse. Let's make the best out of it and bring some of the great ideas and solutions to the core system even as an add-on that totally fine.

[gogobd]

I just wanted to show http://www.contentmanagementsoftware.info/plone/cyn-in which we're still using on one vintage system; this plone based "collaboration software" uses that paradigm: first say "add" and then say what you want "it" to be and then where you want "it" to be. For our usecase this was perfect, but it's completely outdated now.

And +1 from me on this "inverted PLIP", and I second the idea to implement this as an add-on first (@MrTango) in order to enrich the spectrum of plone's functionality without removing any features.