Plone Addon Listing design discussion


As part of a GSoC-17 project, we are trying to improve the addonlisting of The current version screenshot is below:

Mockups of possible alternatives are below:

Or, if the existing side bar for page navigation can be removed like that in (since navigation also can be done from the toolbar above), it can be replaced with the filtering criteria.

When an add-on is clicked, the details can either be
i) displayed in a modal without redirection
ii) or, redirected to a new page with details

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)

Any comments/ suggestions/ new ideas are welcome :slight_smile:

1 Like

These are wonderful mockups!

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, site?")

1 Like

I was thinking that the below nav bar can be used for navgating to and back from this page.

The download page can retain the right portlet to lead to the addonlisting page and others(like hotfixes, releases)

I agree. Though, I was wondering whether we can include a link to the corresponding pypi page as part of the details displayed.

That makes sense, e.g. "view on pypi"

great work, @pavithirakc!

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


Good point. We tried to tackle that question with (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.

Some paragon criteria we proposed to use:

  • does it have end-user docs?
  • does it have screenshots?
  • does it have has screencasts?
  • is it i18n ready
  • is it translated
  • is it actively maintained?
  • does it have an issue tracker
  • does it have tests?
  • does it have a travis-integration?
  • is it dexterity-ready?
  • is it compatible with Plone 4.3?
  • is it compatible with Plone 5?
  • is it used in production?
  • does it uninstall cleanly?
  • is the code-quality ok?
  • is it ok/usefull/great/mind-blowing?
  • other notes (good or bad)

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.


Hi @pavithirakc the mockups looks very promising.

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

1 Like

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.

1 Like

Until we have at least had one successful set of recommendations, I think we should hide this section, but we can argue about this offline :slight_smile:

@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 presents the product Plone and its add-ons to the larger community.

I like this one. You can see things much better!

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.

sure, but sometimes people make an add-on without knowing one is already doing basically the same (?)

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 but this is a prototype python script that launches a button that submits plugins on the current site to 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="">
<textarea name="data">%s</textarea><input type="submit">
</form>""" % data
1 Like