Or, if the existing side bar for page navigation can be removed like that in https://plone.org/security/hotfixes (since navigation also can be done from the toolbar above), it can be replaced with the filtering criteria.
iii)or, redirect to pypi page details directly ( since most of the details are retrieved from there except for curated status which can be denoted with a special mark/colour in the listing itself)
I like the idea of having filtering, but I'd like to know what you envision as navigation to the current right portlet, which I used to reduce clutter on this page (it was previously too long).
A modal would be great, with maybe a link in the modal to view it on a normal page. I have seen catalog web sites that make a product appear in a modal if you choose "quick view" vs clicking on the link to see the product appear in its own page.
I think this would be the least good option, because it would probably confuse new visitors ("why am I being taken to an entirely different, non-Plone.org site?")
I think is very important to know how are you going to get the information on those different categories; for me most downloaded and newest is clear, but I'm not so sure on recommended.
who is going to recommend an add-on? how is going to recommend it?
In the old site we had a self-certification checklist that could be interesting to somehow take into account; see this as an example:
we also had links not only to PyPI, but also to the VCS repository; information on tests passing and testing coverage could also be interesting.
probably most downloaded also has to be limited to a certain period of time.
finally, I think is very important to have clear information on compatibility with different Plone versions.
I'm bringing this now as I think is very important to avoid the same issues we had in the past with things like the integration of social network activity on members of the plone.org site.
Good point. We tried to tackle that question with http://paragon.plone.org (it lists criteria we were going to use) too but that was too labour intensive. An automated mechanism would be preferable but doesn't capture anything except what's currently popular, not what an experienced integrator recommends (which could be different).
Maybe instead of 'recommended' we could have some sort of manual 'highlight' section where a human decides which add-ons to highlight periodically.
Most downloaded: the download numbers from PyPI are dust and smoke in in general wrong
"Most downloaded" in the age of automatic builds, automatic testing etc...completely reliable and worthless
"Newest": in the sense of completely new add-on, new major revision (e.g. ported to Plone 5), new minor release...?!
"Recommended": this is a highly opinionated process and requires a curator. The Paragon process failed for whatever reason. Recommendations require an endless and committed effort by someone.
Well If we think about the columns layout in Plone, and inheritance of Portlets (Navigation Portlet in this case) it makes it very hard to have multiple right column elements. I would prefer the filter element. But also a manual added navigation could go above and help.
Well I like the modal idea, and have the open in new page as a fallback for open in new window / tab or if javascript is disabled.
About the order of Element in the Listing, your proposal was:
Most Downloaded Add-ons
Recommended Add-ons
New Add-ons
I would go by:
Recommended Add-ons
New Add-ons
Most Downloaded Add-ons
The previous discussion was to have flags (currated and black-list) that either puts an addon into "Recommended Add-ons" or does not show at all (for example core packages). I am not sure if Recommended Add-ons" or a more neutral name would be better.
Currated also means that there could be an additional text maintained on Plone.org and upload of Images, ...
Getting download numbers from PyPI allows to make a general sum, or latest versions, but I am not sure about a specific timeframe.
I think a consens at the last discussion at PloneConf 2016 Boston was to make a round table at some sprints / the annual Plone Conf and go through the Plugins and currate them. I am not sure if that works out better than paragon, but at least it sounds like a doable plan.
@zopyx Andreas you are totally right, having a recommended state needs transparency and a defined process. Paragon failed mostly because it needs an group efford with meetings and discussions. which did not happen.
I hope that we become better at that. At least we could go and overwrite some automatically processed data from PyPI and prevent problems with bad add-ons like plone 4 artists like.
@polyester@pbauer@sally and others of the Paragon Project could we get some imput from your side?
It would be nice if we could avoid problems by talking about them before they ocure and also as we want @pavithirakc to help us efficently to improve how Plone.org presents the product Plone and its add-ons to the larger community.
It would be nice to be able to find 'bad and alpha' add-ons, they might be useful anyway, and could prevent 'duplicate add-ons' ( contribute to fix it instead of making a new add-on).
There is a field for blacklisting an add-on, e.g. if a package happens to be part of Plone core then we don't want it shown in this list.
Rating systems cause conflict if you start downvoting things... best to stick with upvoting where appropriate, hence the idea of "recommended" add-ons. If an add-on isn't in that list, you could assume it's because it's either so-so or bad.
Also, given the nature of the collective, we can't prevent anyone from making what others might consider to be a duplicate add-on. Your duplicate is another's use case... But again we can fall back on the recommendations (if ever humanly implemented) to point people to the "best" of a set of similar add-ons.
I understand that it'll be better to develop over the existing alpha-stage add-ons instead of reinventing the wheel. But, instead of showing them as seperate listings like recommended, new or most downloaded addons, an additional filter criteria can be added to the filter portlet. Since, there exists a field for describing the curated_status of an add-on
and the vocabulary that is being referred here has been defined as
Adding them as filter criteria could help in finding the desired add-ons.
An alternative to both downloaded and recommended counts is a simple phone home script implemented as a TTW python script to register as many production sites and what plugins they actually use (and with which version of plone). Then each plugin can have a rating of
"in use by 25% known of plone 5 production sites"
for example.
Basically a slightly better and more automated version of the old Annual Great Backyard Plone Count we used to do. I think a lot of people would be willing to run a simple python script 1-2 a year on each zope install they manage especially if it was opt in and it was simple to filter information they didn't want to reveal (like url and some plugins).
Previously discussed (in Add-on listing for Plone.org) but this is a prototype python script that launches a button that submits plugins on the current site to plone.org where you would then get the option to filter them. I'm pretty sure it will work on any version of plone.
data = context.portal_quickinstaller.listInstalledProducts()
return """<form method="POST" action="http://plone.org/census/@@rapido/plonecensus/block/submit/add">
<textarea name="data">%s</textarea><input type="submit">
</form>""" % data
