Alright. It definitely describes me. Although experienced in the field of IT as an IT specialist, programmer and IT manager for 30 years, I felt like a dummy when first trying to use Plone/Volto and after 2 months deep diving into it, I still feel like a dummy!
There were several moments during that period when I was thinking about giving up and move to a simpler solution. But, since I'm no quitter, I kept going. However, I can imagine people will give up, because they cannot afford to spent that much time getting to know a CMS.
In my opinion the documentation is focused on all the possibilities and you have freedom of choice how to handle things technically. What I am missing here is a Plone/Volto best practice for common use cases like:
Website/Extranet combination
Website/Intranet combination
Website
Extranet
Intranet
Eventually, Plone is meant to be used by non technical users mainly. That is why I am applauding @tkimnguyen for setting up a user training. If we want to reach a broader audience, we must lower the technical threshold and provide coherent instructions that can be understood by regular IT staff.
A larger install base will attract more parties to sponsor and developers to improve and maintain the code / create add-ons.
So, what I am proposing is setting up a best practices page which eventually should be included in the "Get Started" section of the Plone home page.
Get Started
|- Best Practices
-|- Website
-|- Extranet
-|- Intranet
-|- Development
-|- etcetera
Per page, describe the necessary steps (in detail like a work instruction) to reach the goal of the use case. Don't offer too much choices, but select software/add-ons from a best practice point of view.
Is this something that is desired by the Plone foundation members/board?
@ghnire thanks for persisting with this. I like your ideas of describing best practices for common use cases and for lowering the bar to reach a broader audience.
You're not alone in this. @ericof has been pushing the idea of Plone distributions ever since Bristol 2014 and in Brasilia there was more discussion and promotion of Plone distributions by @tisto (I will find the talks and post the links here) including for an intranet, by kitconcept
If you want to start creating a "Get Started: Best Practices" pages, that would be wonderful. It would be good to work on it someplace where others could see and contribute to it. When it looks ready, it could go onto plone.org. How about a shared Google Doc or Dropbox Paper (my fav)?
I'm not sure where your materials would fit in the official Plone docs, but you could also start by developing a training class.
You don't need anyone's permission to get started on this. You've already done a very helpful thing by describing what you think the problem is and by proposing a solution. Even better: you sound like you're willing to work on it
(What you describe is not controlled by Foundation members nor the board. Foundation members have a couple of explicit functions, which is to vote for board candidates and for conference proposals. The board's function is not to direct the software nor documentation/training materials.)
If you get started on this, I and others will be glad to help!
A few years ago I put something together called Plone in a Box that was meant to help less technical folks get a Plone site running on a cloud provider without having to mess with the command line. I need to update it...
I forgot to clarify that the training class @polyester and others and I gave is something that Plone has offered for many years, but we didn't have formal training materials for it because the way the class went depended on the mix of people who showed up, and they often had very specific things they wanted to learn.
That was fine because we had the Working with Content documentation for Classic, but once we were mostly switched to Volto it was no longer as useful so we needed an updated training guide, which we now have (but it still needs a lot added).
We do have the start of a Volto user guide in the documentation.
The way I create documentation or training materials is to write it down quickly/easily, e.g. in a Google Doc or Dropbox Paper, then once it is more stable you can export to markdown, which is what we use for the official Plone documentation and training materials. I do it in two steps like that because I find markdown is finicky and takes me out of the flow of writing.
If you want to include step by step instructions accompanied by screenshots, I'd recommend ScribeHow.com. If you have a paid plan, you can export to markdown. We have a group of 5 people in a team account already, but talk to me if you'd like to use it and we will figure something out.
I like your idea of best practices for common use cases. But, also keep in mind that your assertion stands orthogonal to "Plone is a Contract" - i.e. the implementation details are left to the user. While the initial hurdle might seem high, Plone gives experienced integrators the ability to extend it and tailor it to their needs (Quaive, Senaite/Bika LIMS, Guillotina, PloneGov, Headless Plone/Volto Prototypes), with many of those technologies feeding back into the community.
This leads back to the question: what is Plone and who should use it? A CMS on steroids, a web-framework, or indeed simply a contract? Whether Plone is the optimal framework for your website/intranet/extranet is very much open for discussion... There is no "one size fits all", it is probably easier to say what Plone is not.
My take on this: if we want to make Plone more accessible to decision makers (technical and managerial), the place to start might be They use Plone Add more use cases and present those with better context: explain the considerations / alternatives, and highlight why Plone ended up becoming the chosen solution. Expanding this section of the plone.org site could form the scaffolding for guidelines/best practices in the scenarios you suggest.
I think Plone Distributions are also very helpful in that regard, together with training.plone.org, the excellent documentation initiative shouldered by @stevepiercy, Cookiecutter-Plone, and (past) initiatives such as the Plone Unified Installer or Plone in a Box that might be resurrected in one way or another.
As a new Plonista, keep giving yourself time to discover the advantages of a framework like Plone. When your intranet users inevitably demand features or workflows unique to your organization, you’ll see why Plone was the right choice. In the end, this community (and not just slick tutorials) is what makes Plone great.
Thanks for the acknowledgment, but the authors of those trainings deserve the credit. As with Plone 6 Documentation, the authors are the subject matter experts, and I support them to share their knowledge and experience. I'm more of a Lead Cat Herder.
There's no reason why we can't cater to all. Lots of products and services get sold in different ways to different audiences, and, as you say, once a person or organization has started to use Plone for one of those reasons, they may very well find out that the other reasons also apply to them.
@mtrebron we miss you on the marketing team Come back
I’m going to be opinionated Try Dropbox Paper… it is so much easier to edit and comment on and make to do items and assign them to people with. Google tried to copy those features but still is crappy Plus, Dropbox is written in Python
Thanks, Plone in a Box™ was fun to get going. You make me want to update it
and in Brasilia there was more discussion and promotion of Plone distributions by 
Come back 
Try Dropbox Paper… it is so much easier to edit and comment on and make to do items and assign them to people with. Google tried to copy those features but still is crappy 
Plus, Dropbox is written in Python