Let there be TTW add-ons

+1, I'm aligned with this idea, making it easier to use, easier to extend and easier to explain is a good thing. The challenge is doing that while navigating the realities of security, dealing with breaking changes, etc...

I like the term "instant add-ons". It is more descriptive than some of the other names.

I'd love the name to communicate:

  1. Easy to Build in the browser
  2. Easy to install
  3. Quick
  4. Safe
  5. Adds new capabilities

"instant add-ons" covers 2, 3 and 5 (maybe it also hints at 1).

Here's an initial draft of an experiment that could be conducted very easily with non-Plone users. If each of us could try this on 25 persons in our circles we might come back with interesting results. I'm also curious if the cultural context (the Caribbean vs Europe vs Asia vs North America) makes a difference.

To determine what is the best single name for TTW add-ons.
This is not to determine qualifiying names like "live add-on" or "instant apps", just to deterimine the base name:
apps, add-ons, packs etc...

Cards for writing each possible name.

0. Write the possible names on cards ("add-on", "apps", "packs", "accessories", "pods")

  1. Identify users who are not familiar with Plone
  2. Classify them as power user, average, unsavvy
  3. For each user read the following scenario to them

Product X is an easy to use system that allows a team or individual to create or manage a website. Your team is using Product X and you've been asked to investigate what else it is capable of.
You are presented with a list of terms, only one describes a system used by Product X for extending it's capabilities.

  1. Show them the cards and ask them to eliminate the ones that they would not be likely to select if tasked with investigating new capabilities.

Keep a tally of those words that are most commonly selected.

Analysis can be done based on whether someone is a power user, average or unsavvy. I would put greater weight on the input from the average and power users and discount the feedback from less savvy users.

Next steps
After this we could then select a "base name" like apps, add-ons, pods, accessories, packs and begin to determine if we need a qualifying word like "instant", "jet". To determine the qualifying word we could repeat the experiment.

I decided here to accept the current state of all APIs and just focus on making all the existing TTW features more accessible through this "Instant add-on" pattern.

I'm primarily making this for myself at first: We have a lot of shared policy profiles between sites, distributed now using a single egg with a dozes of GS profiles. We don't have fully automated tools to upgrade sites without downtime (it's just about calling supervisor and varnish in order, but we still haven't automated that – probably because we are waiting for our Docker clusters to mature with other services before trying Plone on it). We also have many sites running with only a single zeo instance.

"Instant add-ons" would allow us to update shared workflows, rolemap, TinyMCE configuration and other such "TTW only configuration" profiles without downtime. In addition, those could then also be maintained without knowledge about buildout and Python packaging.

I wonder, if Generic Setup's portal tool (portal_setup) was supposed to do something similar in its original plans.

+1 for "instant".

+/- 0 for "add-on"

The casual user might clearly see "Plone instant apps" as a different thing from "Plone add-on package" if the terminology was consistently used, and this would be easily FAQ.

I believe it has been decided at some point in the last 2-3 years that add-on would be the preferred terminology, so I'm +1 to Instant Add-ons too. They shouldn't be that different in terms of functionality after all, the difference being mostly 1) how you can install them and 2) some restrictions as side-effects (an understandable/acceptable tradeoff).

1 Like

Instant addons is also seems to stick for me more than the others. It's almost alliterative (agile addons is but not sure thats better).
One thing I don't like is that it's not very concrete. Instant can be hard to remember because you remember the concept rather than the name, ie was it quick addons?, fast plugins? etc. This is why visual or auditory type words tend to get used in brands more.

I found this book to be really useful for working out names - https://en.wikipedia.org/wiki/Made_to_Stick.

An example of a more concrete name would be "one click addons" but I'm not sure thats an improvement either :frowning:

I like build in the browser as a byline. "Plone uniquely lets you build in the browser with its instant-addons feature". An alternative I've been trying out is "cloud coding" or "online development".

How about using coffee cup as a control panel icon?

1 Like

We're not gonna doing Java, are we? :wink:

1 Like

Our icon doesn't need to be burning like Java's is.

1 Like

That doesn't really help :slight_smile: To be honest, java as a name works not because it reminds of you of coffee but because java is java, a place. You aren't going to remember it has Borneo or latte instead.
Also word of mouth is often litteral just verbal. So imagine at a conference someone saying, you friend says "you got to checkout plone, it has this instant apps feature with an appstore where you can click to install plugins right away". That's a great selling point, but if you don't remember the word plone, then you are unlikely to google to work out which cms it was later on. But If you forget the word wagtail (but notice how wagtail is also very visual) you might remember streamfields (which gets you directly to wagtail).

I'm not saying don't keep instant addons for now but there might be a better name out there.
FeatureZaps? MinuteMods? FeatureFlash? but to be honest one-click addon is probably the most visual and explanatory. Does any other CMS have an appstore built into their open source CMS?


Å control panel called 'appstore' where one could install 'apps' and maybe manage settings?


I've just skimmed this thread and wanted to add a few points for clarification/comment:

  • This discussion is part of one of my favorite discussions: how do we present and market Plone's myriad technologies effectively to users.
    • I believe I saw someone address the move from "products" to add-ons, which was a long time coming and still in process. (I still see "products" mentioned occasionally.) Plone-the-marketed-product should exist independently of Plone-the-amalgamation-of-myriad-technologies. Not relying on Zope Products (at least in naming conventions) to promote Plone's add-ons feature is one example of that approach. "Plone has add-ons (or apps, or extensions, or whatever)" No end user needs to know that these add-ons are technically "Zope 2 Products". (Or in the present day, that they once used the Products namespace …) The point and message to deliver to end users is: Plone has a core set of features which you can extend with add-ons.
    • Confusion is inevitable, but can be effectively mitigated with clear and concise documentation. "Oh you are confused about Products? Go read this section of the documentation …"
  • I think the best answers to the question of "what do we call them?" is in the title of this thread: TTW add-ons, or Through-the-web add-ons or Add-ons through the web.
    • I'd stay away from "instant" or "hot" anything clever or meaningless because we've seen that fail in the past. That said, "instant" at least is generic enough to be categorized as "marketing terminology" and not "technical code name". Technical code names escaping into documentation should be discouraged in favor of "words that means something to everyone" which "instant" and "hot" certain do. But "through the web" I think has a lot more meaning … "I can do this entirely through the web without touching a server or file system"

Hope that helps and I'm excited to see Plone moving in this direction.


I'm just ordinary plone user, but the 'App Store' is the right magic word here - everything else like plugins, apps, themes or even critical core updates could and should bend around the word 'App Store'.

1 Like

:+1: yeah I think everyone with a phone now knows that a store means you get to install it right away.
@datakurre I know u are only thinking of plugin side but the store is the end user consequence. Browse directly in Plone and instant install (<- I think I just found the alliteration).

Well apparently there is no trademark issue - https://en.wikipedia.org/wiki/App_store#.22App_Store.22_trademark.

Still somewhat confusing since they will largely be enhancements rather than stand-alone applications (with their own start page and url space).

Chrome "chrome web store". Andorid uses "Play store". So it seems as long as you have store in the name people get what you mean.

So I think Plone web store with instant installation.

1 Like

@datakurre, I hope the naming debate, which is valuable, isn't holding up the actual implementation.

Is there a way to pre-qualify an add-on so that it's approved for the version of Plone they are installing it on? So if they have 5.0.7 and the add-on has been 'approved' somehow for that version then it installs, but if the add-on has been stamped 'approved' for 5.0.4 but not tested on 5.0.7, can we warn the user somehow? I don't like the idea of our users just willy-nilly installing add-ons that could bork their system without any warning.

If we are doing an 'Add On Marketplace' model, would these approved add-ons go through a vetting process to make sure they work? Who will approve that? What testing goes into this approval to ensure the stability of their system and integrity of the 'Add On Marketplace'?

1 Like

Given the volunteer nature of the community I can't see any vetting system being maintainable due to the amount of work required. But I think the idea of warnings and restrictions put in by the addon authors could work. Where they can say what versions it doesn't work with, and what version its been tested with and everything else gets a warning. And addons don't appear if they don't have this.

I also think it should be possible to connect multiple marketplaces to your plone site so that 3rd party stores can exist to provide vetted plugins if they want. Or perhaps large universities or organisations can have a private marketplace for new plugins and upgrades (to addons, not to plone).

To make this work we are going to have to put a lot of effort into putting security assertions in plone code again so it is usable in restricted python. I've spent hours trying to do something basic like get the an automated summary text in a pythonscript. Dexterity is no accessible to our code. Obj.text.raw not working. File.data.read() not working. Subrequests not working. Plone protect not working. Namedblobfile not working. Is it hard to put them in or something? We have made plone so much not fun :frowning:

No. As I wrote, this discussion encouraged me to name the implementation technically plone.app.addons (still nothing public available yet) and the control panel Instant add-ons. Of course, it can be enhanced and rebranded to some kind of app marketplace later, once installing and updating works reliably and the concept is also otherwise proven.

I'm planning to embrace and extend jsonfeed for per package update feeds. Adding support for jsonfeed based "app store" later makes sense (to easily support both small in-house and community add-on repos).

To keep packaging simple, one could always just upload a zip, but manifest.cfg in zip could include update-url pointing to a jsonfeed. Obviously, the update feed is used to check for newer versions of the package. Also, if update-url is present in zip-uploaded add-on, the update feed is loaded and the original zip is validated against the detached signature found in the feed. Otherwise add-on would be marked as unsigned. Possibly there could be an option to disallow uploading unsigned add-ons.

(The above model of detached signatures requires to allow outbound connections from the server and leave some room for man-in-the-middle attacts in validating signatures, so possibly there should be a way to validate signature manually. Yet, I would not go as far as the current Firefox add-ons signing requiring additional tools and services to automate the process.)

@vaporboy My idea is that the manifest.cfg in add-on package could define its dependencies in detail enough that e.g. add-on requiring certain behavior could only be activated if that behavior is present. The first phase is to simply allow requiring certain Python packages, but possibly also other web add-ons later. (The add-on itself coul require in its profile that dependency GenericSetup profiles are installed during its activation.)

If we go with "instant add-ons", how to distinguish between those and (non-instant) add-ons? We currently have a control panel for Add-ons.

Regarding marketplace: once we get Pavi's https://github.com/plone/ploneorg.addonlisting GSoC work onto Plone.org we will have a really nice way to highlight our add-ons, including version compatibility and many other search/filter criteria. You can look at the wiki to see related issues and how we hope to tackle them. But... those are for "add-ons", not (at this point) "instant add-ons".

How about "power ups"? :smiley: