It took less than a minute to figure out both obvious easy-to-spot problems. This translates to: it takes less than a minute to distract a potential n00b from choosing Plone. It did not invest any more time for trying out the other
This lack and absence of quality control is currently symptomatic for the overall Plone 5 development.
It distracts potential new Plone users, it distracts existing integrators, it distracts existing Plone users.
The marketing for the themes is "five lovely mobile-ready themes for Plone 5,". In reality we deliver half-baked quality. Not only in this case but throughout the complete Plone 5 project.
The lack or ignorance of understanding that Plone5 having a severe quality problems speaks for itself.
AGAIN this one example (out of many) where simple issues, obvious issues, easy-to-spot issues are taken to the end-user.
AGAIN these simple issues distract people from using Plone 5.
AGAIN you are only looking through the eyes of a Plone core developer - you don't have user in the focus.
AGAIN the developer must have figured out these issues by itself - very easy to test, very easy to detect. Very little quality control in this case by the developer, very little quality control in this case by the GSOC mentor.
AGAIN this is not about me finding and fixing a problem. It's all about user experience, it's all about user experience when you touch Plone for the first time in order to try things out.
AGAIN this is was only a representative example of the Plone user experience with Plone 5 0 and 5.1 at the moment.
And this is one reason why people move to others systems that just work for them - independent of Plone features, its security record or whatever. I tried several other systems over the last weeks from Odoo to Wordpress for some simple landing pages. At least for Wordpress I installed dozens of themes and I never found such obvious issues that I found in both cases within one minute in Plone with very little test magic (just resizing the browser windows).
I am not the only one with similar feelings and the perception that some of you core developers are sitting on the moon and care about nothing outside. The current development process from outside appears completely headless with a lack of vision and concepts. Instead of addressing the core problems we see experiments like Webpack integration, headless Plone etc...no issue with experiments and thinking into different directions but at Plone core development at the moment is without direction, without commitment, without resources.
XML-Director: it took many approaches, rewrites, complaints to get the integration of some JS add-ons working because of the resource registry mess -> lack of vision and conception -> integrator costs - in this case this is my personal project, I can deal with it.
AGAIN many of you have lost the perception on Plone from outside. More than 15 months after the first official Plone 5.0 release and almost 3 years after the first Plone 5 alpha release the state of Plone 5 is sad.
AGAIN companies running Plone or developing with Plone internally are looking for alternatives or least options to outsource the Plone stuff since they can no longer handle the complexity and want to deal with issues (with Plone 5 in particular).
No one is disagreeing there are bugs such as these. No one is disagreeing that they detract from initial experience of starting with Plone.
If something is wrong you have several choices. You can
a) fix the problem yourself
b) report the problem
c) whinge about it, and how nothing is good anymore and chastise the community at large
d) consider constructive ways to improve the community to get the mutually desired outcome. Work towards implementing these.
I know I've done my fair share of option (c) too but I've also tried really hard to do a lot of (d) (and a and b too).
I took over leadership of the UX team a few years ago to try and fix the issues around focus on UX and onboarding. I've worked on proposals about changing the PLIP process and strategic summits to be more focused UX. I've even tried to change our bug documentation process to create a more UX focused process via github issues. These efforts didn't work (obviously) but watch any of my plone conference talks on youtube if you don't believe me.. Trying to tell me I'm not concerned about user experience of Plone makes me consider you haven't considered the end user experience of how and to whom you are directing your anger and also what you think will be the end result of your rants?
My point is, this is a hard problem to solve, but as I've found in the past, getting angry about it and accusing other volunteers doesn't help either. We are an under-resourced community where the majority of members have very technical interests. This is not unusual for open source. UX is hard and even harder for developers. It does require strategic vision and leadership to steer developers from shiny things, to things that that seem less interesting but will benefit their income more in the long term. But my question is, do you have any ideas on how to fix this situation? Because I am 100% behind any new suggestion you have.
I must say Andreas that it's hard not to get angry reading your tweets about this. I see your point, and I'm not disagreeing with you that there are many areas we could use more help in. However, the themes were developed by a GSOC student, and they really are lovely, and ok you found bugs in them, but it's not very nice to disparage the work, the student, the GSOC mentor, and Plone.
You raise valid points. OK. That is a service. I guess we need to find volunteers who can help address each of your points.
But some of your points really are comparing apples to oranges. E.g. the Wordpress themes, and at least I've hashed this out with others, is that those designers are paid to develop the themes and they're sold for profit. Unless we can develop an equivalent market for Plone themes, I don't see us coming close to what WP does in that area.
I know that Plone firms create their own custom themes for clients, or we purchase themes and customize them. Perhaps it's fine... that works for our kind of markets. We are not Wordpress, and we do not cater (cannot maybe) to the mass WP market.
Apart from the different audience WP and Plone serve, Andreas is right from the noob point of view. Installing a custom Theme and some Add-ons is normally one of the first things you do when trying out a CMS. For me it's as well a point to drop any more efforts on a technology if a product I'm trying "not even install a Theme or Add-on properly".
Lots of problems Plone 5 faces results from the new resource registry. As Integrator I spent at least a week for simply delivering some CSS and JS in Plone 5 when migrating some Add-ons from Plone 4 (in a backward compatible way). For small companies it can cause huge problems if an update to Plone 5 takes half of the budget of the initial implementation. And of cause some needs to deal with possible alternatives.
I disagree with Hector about rewriting the resource registry again. Just FIX WHAT'S THERE. The mood to rewrite everything from scratch as soon as some problems are faced has heavily hurt Plone a lot of times before.
I'm not calling for rewriting the resource registry again; I'm calling for simplifying it, removing the parts that are needless and useless: resource bundling is not, and never has been, something a CMS most address; it was a workaround to address an HTTP protocol limitation, that had to be fixed (and has been fixed) there and not here.
and I'm talking here about trying to bundle other people's resources; that's the kind of "problem-solving" technologies that leave us with even more problems than we previously had.
seems I was not clear enough in my PLIP about what I'm proposing; I'll work on that next week.
I kind of agree with Hector here. The new registry works well for defining/configuring requirejs aliases for js libraries and defining the entry point js files. Bundling kinda works, but is the most fragile part.
Yet, besides bundling, the new registry also does:
LESS compilation (required for TTW customisation with LESS variables)
cache busting (by generating cache key for bundles)
CSS is slowly catching features in LESS / SASS, but cache invalidation will remain hard.