TCR design

[luisivan]

With the current architecture of our modular TCR implementation, I see the following apps could be shown to the user:

• Registry app: Just a read-only list
• Curation: This app would be a list of all open applications, with a button to challenge them. It would also allow to create a new application. It would also show the parameters that the app instance was created with
• PLCR/Voting: It's just a commit-and-reveal voting app, so its frontend would be the same as the voting app we have right now. It would show the votes in different steps: closed votes, being revealed votes, and open votes. Open votes wouldn't show any stats as they haven't been revealed yet
• Curation staking and Voting staking: Those would be two different instances of the same app. Its UI would be very simple, showing your stakes and letting you create a new stake

Inter-app context linking

We need something similar to deep linking, in which an app can call another one with the specific screen it wants to open, and possibly some form info too. This would be present in the following screens:

• In the Registry app, there should be a link to create a new application for the Registry (a link to the Curation app)
• Similarly, in the Curation app, there should be a link to view existing entries (a link to the Registry app)
• In the Curation app, there should be links to the applications' challenges currently being voted on (a link to the PLCR app)
• When creating a new application, a new challenge on an application, or voting on challenges, the user needs to stake before submitting their action. For that, we could open the Staking app pre-filling all the parameters, and then when the user stakes, take them back to the Curation/PLCR app so they can perform the desired action

[bingen]

Some comments:

• PLCR frontend wouldn't be the same exact as the voting app we have right now, as we need 2 main actions (Commit and Reveal) instead of only 1 (Vote). But it would be quite similar.
• Staking apps should allow to create stakes and lock them.
• Registry app should have a link to Curation -> Challenge for each entry (I mean here just opening Curation app ready to Challenge that particular entry).
• From the drawings, Staking apps are "mono-token". You must define the token the app uses and it's only one. Of course we could show conversions, but all stakes should be denominated in the same token.

[lkngtn]

Discussed the UX challenge and implication of having two staking apps (curation and voting) with @bingen and @izqui and it seems like it make sense to pursue an approach that allows for a single staking application to manage both types of stakes. It would be useful to explore what the design would look like under the assumption that one application manages both types of stakes.

[luisivan]

Sounds good. I don't think the design would change, it'd just be Curation and Voting linking to the same Staking app when asking the users to stake.

[josegaray]

In the read-only registry, it would be nice to see some information about each entry, maybe unfolding in a drop down box when you click on one of them (FAQ style). Some interesting properties about an entry that come to mind:

• How long the entry has been part of the registry
• How many times it has been unsuccesfully challenged
• If it's currently being challenged

Data like this could add some perspective to the binary nature of the TCR.

[bingen]

it'd just be Curation and Voting linking to the same Staking app when asking the users to stake.

Just one comment: the action will be slightly different, as the user has to signal what the stake and lock are for (either Curation or Voting). Not sure how this will be handled from the UI perspective, although I agree that the design shouldn't change too much.

[stellarmagnet]

Just UX some thoughts/ponders here...

• I feel like this is an example of why upgrading aragon.js will be important for UX, bc I don't think any of these apps make that much sense to be independent from one another vs. a single app in left pane and then multiple tabs to represent the different 'apps' so to speak.
• Curation and Registry look a little weird independent from each other, since the main UI difference is the Challenge button. I would also combine these apps and use filtering instead (like Adchain)
• Question on the Staking mechanism: as a user do I stake one time (for a particular function, such as challenging in my example...), and then use that single stake to challenge multiple applications (and be able to use some fraction of my stake...) or do I have to use the Staking app each time I challenge an application?
• Is the Voting app in this case only for voting on challenged applications, bc I think that's how TCRs work right?

[bingen]

I couldn't agree more with your first point, @stellarmagnet We are aware of it and that aragon.js enhancement is going to happen, but I think the idea of this design is to unlock the development of TCR meanwhile. About your questions:

• You can stake only once, but you need to lock each time.
• Yes, the voting app in this set up is for only for Voting on challenged applications.