@ron_jeremy has some good thoughts on how we can improve Plone adoption. I thought I'd start a new forum thread with those.
One of the things we've been doing is deemphasize at least a bit the "download this installer and run it locally" concept in favour of "click this button to install Plone on Heroku" or Digital Ocean, etc. OK so one of the things on my plate is to finish that by continuing to revise https://plone.org/download...
If you look at our docs and training materials, they've gotten a heck of a lot better. Our unified installer is wonderful. Hopefully by the end of this semester we will have a Windows installer for Plone
I think @jon_jeremy idea of having 20 normal people install and customise plone and use plone in front of core developers is a good one. If there was a way to have this happen every conference and open garden it help in ways we can't foresee.
I can't tell you how many times I've been surprised when doing training of new users, how many things I think are obvious and sensible, just aren't always so.
I recently tried to hire a angular developer to work on a addon for plone. The angular bit was fine, they didn't need to understand plone. But I tested a lot of developers and to test it they had to install plone. It took between 3-8 hours or back and forth to try and get a stable buildout working. This support forums seems to indicate the unified installer can face similar, hard to debug issues.
Really? Must be on some really messed up platforms... on OS X I download the unified installer, untar it, cd, ./install.sh standalone, wait 10 minutes, done...
Also @djay with our fantastic Vagrant installer, I hope you're asking them to use it if you're seeing many problems with the unified installer, e.g. (AND still filing issues on the latter)
I think this is our old problem, of insisting on sending people to the "wrong" setup method. Each person/scenario has an idea setup method.
I also like the container approach, but I prefer LXC like container here.
Because Docker changes to much for the people.
LXC is clean and easy and very close to standard Linux many people know.
And we can even build ready to use production container.
They run on every modern Linux and don't care about hardware.
As we use this for our hosting, I'll probably work on that topic and try to make it usable for others. Of course it only works for Linux, but it improves it a lot there. For Windows & co one need different ways, but the same applies to Docker.
"Just" that you know, there is already two tickets, open ticket 1"Improve/Update: Installation Docs" , open ticket 2 "Update OSX install part" in the docs issue tracker, which partly discusses some of this.
This is not 'only about the download page' this a 'thing' what we have in general .
For some parts of it, like installing all needed dependencies on macOS, there are various ways to do it, see the ticket, about pro/cons.
IMHO one other point, also mentioned in the ticket is the audience and how we communicate !
And please do not forget, how more different ways we add, how more work we have to keep all this up to date
@tkimnguyen this was a slightly different scenario as it was a dev buildout so I wasn't getting them to use the unified installer. Mostly the issues are buildout related but I didn't have access to their machines so couldn't get that much information on what went wrong. Just that it seemed like almost no ones install went well. One person even managed to get it working after a long time on windows, but I've no idea how.
The one issue I do find is buildout related. https://github.com/buildout/buildout/issues/264.
Buildout is a liability because any new version can lead to conflicts which, even with the nice new log statements, are hard to work out what to fix.
This could be improved if buildout did backtracking. Would make it slow but at least it would finish more often. I'm not sure there is much interest in this however.
If you are making features for plone, then you should be regularly seeing people learn plone. Not just install it, but learn to use it.
Expert intuition is unreliable when it comes to new user experience.
If the intention is to decide on a roadmap at Plone open garden then my suggestion would be to first get everyone going who isn;t a developer, sit them down with a developer, give them 4 hours training. And everyone come back with a list of 3 things to improve.
Maybe it's me but almost all my own development (things I start on my own, including making changes to existing add-ons) is done starting with my unified installer builds. I have several (multiple versions of Plone), to which I add a line in eggs and in develop... Fairly painless.
I should add that I do the above because in part in the past I've been through trying to build Plone from scratch with minimal buildouts on various machines and it can (as you say) be frustrating. That said I have not tried building Plone from scratch on any new machines other than Ubuntu VMs and that always goes without a hitch.
so as kim has mentioned there is an active attempt to make an installer for windows, and I am one of the students working on this project one necessary byproduct of this work will be a single script for Ubuntu that will install plone in which the user will have no to very little input about the settings and plone will just be installed. obviously that is not good for a production environment but for the purposes of just getting it up and running I feel it would be very beneficial to users.
