Should templates be apps?


#1

At the moment, we have:

  • Aragon apps (contracts + frontend), that can be configured and deployed by templates (also named kits)
  • Templates (or kits), that also contain contracts + frontend code (for the onboarding configuration screens).

Note: the configuration screens are technically located in aragon/aragon at the moment, but they don’t belong here and should be with the templates (kits) they belong to.

Problems that remain to be solved:

  • How to configure an app when installing it from the apps center?
  • How to install a template (kit) after a DAO is initialized? Using a “templates” category in the apps center?
  • How to group related apps in the menu? (e.g. two apps that are supposed to be deployed together and are acting like a single app).
  • How to avoid making authors declare two different setup screens (one for the onboarding, one for the apps center)? What about alternative clients that are not using React?
  • Can we have an alternative frontend for an app?

Proposal: Templates (kits) as apps

The proposed solution would be to merge into one entity the concepts of apps and templates. It is going to be named “app” in this post, but we could also decide to name it differently, like “package” or “bundle”.

At the moment, an Aragon App contains:

  • A set of smart contracts.
  • An app frontend (the web app that comes with an Aragon App).

And a template (kit) contains:

  • A list of the apps it deploys (can be found in the package.json but not explicitly declared).
  • An optional “setup app”, that lets the user configure the template.

Instead, apps would contain four optional elements:

  • A set of smart contracts (Aragon App).
  • An app frontend (Aragon App frontend).
  • A list of dependencies: Aragon apps that are going to be deployed and are explictly declared (optional).
  • A setup app, to let the user configure things before deploying.

How it works

The Aragon app and frontend would behave the same way they do, except they both become optional.

The setup app contains everything needed to configure and deploy the app, including the configuration screens. The configuration screens can be rendered in two (and probably more) different contexts: the onboarding screen, or the app center installation screen. We might decide to use a description language rather than React components, to make these screens safe and easier to render in different contexts.

The app dependencies are going to be listed to the user when installing an app from the app center. We could also decide to list them on the onboarding app, for more transparency.

Just for illustration purposes, this is how the app directory could end up looking like:

my-app/
  setup/             # The setup app (what we call template or kit at the moment: smart contract + frontend)
  ethereum/          # The Aragon app (smart contracts)
  frontend/          # The web app (named “app” at the moment)
  arapp.json         # The Aragon apps it depends on should probably be declared in this file.

Going further: let apps declare menu items

An app installing other apps could decide to declare the way its menu items behave: we could allow apps to group or hide some of its menu items.

Doing that would mean that the menu is not going to list all the app instances anymore, and would require to have another way to see that. At the moment we already list all the installed instances in the Settings app, but it would be nice to have a friendlier version, maybe with a visualization of the dependencies.

To prevent any surprise, we could let the user know about the menu structure when the app is being installed.

Example: Voting app

The voting app will generally be installed from a higher level app that depends on it (see the Democracy app example below), but can also be deployed from the apps center.

Dependencies

None.

Setup

The setup will run if this app is installed from the app center, and allows to set:

  • The CREATE_VOTES_ROLE, MODIFY_SUPPORT_ROLE and MODIFY_QUORUM_ROLE roles.
  • The token.
  • The required support.
  • The minimum acceptance quorum.
  • The voting time.

Ethereum app

The current voting app, minus the app subdirectory.

Frontend

The current voting web app.

Example: Democracy app

When the user chooses the Democracy template on the onboarding screen, it would actually start the setup part of the Democracy app.

Dependencies

@aragon/apps-voting
@aragon/apps-vault
@aragon/apps-finance
@aragon/apps-token-manager

Setup

Contains an equivalent of the DemocracyTemplate contract, and equivalent of the frontend component we are using on the onboarding app.

Ethereum app

None (this app only deploys and configure other apps).

Frontend

None.

Example: Voting Roulette app

This is an alternative frontend for the Voting app, that lets people vote randomly by throwing a dice. It is based on the Voting app and only contains an alternative frontend. It could use the menu API to hide the Voting app from the menu, and only display the Voting Roulette item.

Dependencies

@aragon/apps-voting

Setup

It could redirect to the Voting setup directly, or have its own setup (e.g. this app could decide to be opinionated about the Voting roles or settings, or get this information in a different way than the Voting app does).

Ethereum app

None.

Frontend

The Voting Roulette frontend, which interacts with the Voting app contract.


#2

Yes, great idea! I must admit that at the beginning of reading I was reluctant and I was leaning more towards other name proposals like “package” or “bundle”, because I was making the distinction based on the contracts. But that’s not something that matters to the user, how many contracts are there behind that app (it may if it’s a tech savvy one, but not the most important thing generally speaking).
Actually, once we fix that issue of aragonAPI (previously a.k.a. aragon.js) where 1 app handles only one contract, to allow richer apps like modular TCR or The Planning Tab, this distinction is going to become more blurry.
So I’m all up for it!


#3

This is brilliant. The implications of this are great, not only from a user experience point of view, but a developer’s as well.


#4

I wonder if it makes sense to also include the possibility of “optional” dependencies which are only deployed if the user selects certain options within the setup app?