Client: Quick wins to make the Democracy template more powerful

[stellarmagnet]

Two quick wins to make the Democracy template more powerful:

• Include the Survey app as a default app
• During the token definition step, add a dropdown so the user can decide if it's non-transferable or transferable

I mean, I don't know if these are quick... sounds like it to me though, but correct me if these are complex feature requests or not :)

[luisivan]

Including the survey app should be an easy one -- making tokens non-transferable is easy, but maybe we should just recognize that everything on a blockchain is transferable and that's it.

About including the survey app as part of the democracy template, is that something you guys can take on?

[sohkai]

I think people may be confused about the difference between the Survey and Voting apps if they're included together as they are. We could add some more language in their frontends to differentiate the two though.

I think the non-transferable token is important for reputation use cases that Autark has been thinking about.

[john-light]

@sohkai one way to think of it could be that Survey is used for multiple-choice votes, and Voting app is used for binary outcome votes. Or maybe Voting app could be modified to also incorporate multiple-choice options and we deprecate Survey? Just brainstorming :)

[bpierre]

Some issues I see with the Voting and the Survey apps:

• It don’t see as intuitive that we can only create binary votes within the Voting app. I think the term “vote” is generally accepted as a choice between two or more options.
• The term “survey” doesn’t usually refer to a single question, which is what the Survey app does, but to a group of questions. I see the objects created by the survey app as “votes”, and I believe this is how people familiar with its features see it too (e.g. we talk about AGP votes, not surveys).
• Users have a hard time understanding how the action forwarding mechanism work, and why votes are being created when they achieve an action (especially when the action passes immediately).

And a few ideas:

• I think it could be important in the future to identify forwarded actions as recognizable objects in the interface. Some visual indication could help, but they could also be named explicitly, or made more obvious.
• I believe the voting app as it is now should either allow votes with multiple choices, or not allow manually created votes at all. It is a nice feature to have, but I believe removing it would improve its accessibility towards new users.
• Something I am thinking about since some time would be to rename the Survey app “Votes”, as the way it works is closer to the accepted definition of the word “vote” than “survey”. The Voting app could also be renamed and redesigned to be more aligned with its main main feature, which is validating and rejecting actions that are forwarded to it. It would have the advantage of making a clear distinction between human-created votes, and actions requiring validation.

I also like @john-light’s idea of merging the two apps together. In that case, I think it would be important to have a clear distinction between actions and votes in the UI (e.g. using a badge or a specific card style, naming them explicitly, separating them in two groups, etc.).

[john-light]

I also like @john-light’s idea of merging the two apps together. In that case, I think it would be important to have a clear distinction between actions and votes in the UI (e.g. using a badge or a specific card style, naming them explicitly, separating them in two groups, etc.).

@bpierre in both cases however people are still "voting" to either approve or reject an action, or voting on their preferred answer to a poll (even if the vote passes automatically because the creator is the only tokenholder). So if we do merge these apps, does it make much of a difference _how_ the vote came to end up in the Voting app, whether created in the Voting app or forwarded from another app? It would seem to me that it only really matters to communicate to the user that, "hey there are open votes waiting for your input" which I think we do well right now by showing which votes are open and which are not.

[sohkai]

@bpierre

I think it could be important in the future to identify forwarded actions as recognizable objects in the interface. Some visual indication could help, but they could also be named explicitly, or made more obvious.

This would be really nice, along with https://github.com/aragon/aragon/issues/584.

I believe the voting app as it is now should either allow votes with multiple choices, or not allow manually created votes at all. It is a nice feature to have, but I believe removing it would improve its accessibility towards new users.

We _could_ turn the Voting app into something more similar to a Trigger, where users wouldn't be able to directly interact with it. Now that we have an Agent app, the manual voting actions are less useful than before (if you wanted to do something externally, you'd likely want to install the Agent app and then hide the Agent app's execution capabilities behind Voting).

The problem with multiple choice voting is assigning executions on each of the actions. Unless you explicitly define that "no" can never have an action, you end up with the problem of people assigning the same action to multiple options (e.g. see https://github.com/aragon/aragon-apps/issues/47). Not to mention that attaching multiple executions would make creating votes vastly more expensive than now.

[luisivan]

As an easy fix, I'd just add a small help icon to the app navbar. If people click on it, it takes them to the app center info of the app. There they can read what the app does. That should help solve confusion now.
In the future, we can apply some of those long-term solutions to separate the apps better.

[okwme]

bumping for the non-transferrable token option. very annoying to have to deploy an entire org by CLI just to make the voting tokens non-transferrable...

[stellarmagnet]

@luisivan if Aragon One can't take this on in the near-term, Autark can do it, but we wouldn't be able to do it until about 7 weeks from now. We are happy to sponsor a bounty though, let me know what you think. Maybe someone can then complete it before!

(Note: I created this ticket before we were an official team, and did it on my own accord. I have not talked to the team to understand how much time it will take, nor have they fully evaluated it technically yet...)

RE: Non-transferable tokens

To reiterate, this is very important to me, and I think it is a common enough use case that it should be supported in the UI. Since the cli supports it, there is no reason to omit it as an option from the UI just because there is no way to guarantee a person won't wrap their token or give away their private key.

Exploiting the transferability of a non-transferable token is an edge case -- whether it would actually occur to scales where it would be detrimental to a DAO.

I think we can generally assume that DAOs with non-transferable tokens will have supermajorities of honest actors, and that users exist that do want this feature and aren't concerned with the exploit: hence we should cater toward the user's demands.

RE: Survey vs. Voting apps

I agree with @john-light that:

maybe Voting app could be modified to also incorporate multiple-choice options and we deprecate Survey?

@bpierre I do not think that there should be two different apps for forwarded actions vs. informational; instead I do agree that we should use some visual indicators in the UI to distinguish between the types.

One idea can be using tabs to separate the different types of decisions. For example, I think there would be an Overview/Dashboard tab that shows a summary of open informational decisions (Surveys) and ones that are binding / result in establishing a policy or execution (Proposals). Hence there would be a Surveys tab and a Proposals tab for more comprehensive views.

What would be included in the "Surveys" tab is similar to the multiple choice option that the Survey app has today or the votes that are manually created in the Voting app today.

Then the Proposals tab would have two types of proposals:

• One is similar to an AGP where there is no execution script, but you want something in your DAO's record keeping book of very official decisions/established policies.
• Another type of Proposal can be those that do have execution scripts (e.g. actions which are forwarded to the app). These can also be multiple choice (like the Range Voting app).

The Proposals should ideally result in the decisions being recorded to a very human-readable format that mimics corporate meeting minutes for passing resolutions. This would then be more compliant for DAOs that have legal entities, reducing paperwork -- and in general, it just offers a better UX for participants of DAOs that don't have legal entities.

There should definitely be more time put into thinking of the best terminology for all of this, but this is my initial braindump.

Ultimately my opinion is that all decisions/votes should be contained in a single app. If we want to separate, we use tabs within the app.

If people agree that the ideal UX is consolidating all decisions into a single app, I would then propose we think about whether we should enhance the existing Voting smart contract so it is more comprehensive, or wait until the "monolithic app" initiative is completed before making any changes, where we can have multiple smart contracts in a single front-end.

Then basically the Voting app, Survey app and even the Range Voting app ends up being consolidated -- where we refactor all of the front-ends, redesign the UX, and upgrade the contracts as needed -- so it's all easier for the user to understand...

Other question: @sohkai has Survey app been deployed to Rinkeby or Mainnet yet?

[sohkai]

@stellarmagnet The question isn't really how long it will take (it is a fairly small item), but if it makes sense to change the template. I still think including both the Voting and Survey apps will make things more confusing for users. The token transferability bit is less ambiguous.

Since the cli supports it, there is no reason to omit it as an option from the UI

This is a difficult argument to make in the general term; there are a lot of things we don't want to allow users to parameterize from the frontend to reduce complexity. A good example is the permissions structures.

I don't know where we'd put the option, but probably in the token naming configuration.

In any case, the multisig template already creates non-transferable tokens.

---

A modernized Survey app has been deployed to Rinkeby, but is waiting for a few more contract changes to be finalized and reviewed before it's redeployed to Rinkeby and mainnet.

[sohkai]

With 0.8, we've decided not to include Survey as an additionally installed app in the templates, due to its similarity to Voting (and thereby potential to confuse users).

There will be a separate template, Reputation, that will allow users to create an organization with non-transferrable tokens.