---
# System prepended metadata

title: Core UI Discovery Notes (6/1/22)
tags: [' discovery', v3, ' core ui']

---

---
tags: v3, core ui, discovery
---

# Core UI Discovery Notes (6/1/22)

- Walking through the Core UI Figma prototype coming from the initial Discovery user journey statements
- Starting with the *Proposals* view

## Proposals

- Using same pattern for v2 for the proposal cards but want to do user research to see if there are any changes we'd want to make
    - Cards and steps are the same as v2 as of now
    - In general, we won't be able to tell what all types of proposals are
    - We can tell Tribute proposals (which could be a Membership) but we'll need a version of the card for supporting when we can't predict the details
        - *View More Details* similar to the multi-call ones since everything is a multi-call now
- If we define the proposal type we should be able to get closer (via the proposal type metadata) 
    - We can see if it matches a pattern

## DAO Favorites List

- Moving away from Playlists -- removes an extra layer
- Edited in *Settings* and can access a *Search* if they don't see a proposal type in the list
    - First set of core proposals

## Disperse Token Proposal

- Own page with all of the form fields required for disperse
- There will only be 1 vault to start
    - Could be the DAO main vault or it could also be a minion vault (not sure when this will be in place)
- Could default to main treasury but user can select another
- Recipients select list will select between *Select Member* and *Input address*
    - This may have a place in Summon or other spots in our apps
- **Funding Type**
    - Dispersing the native token (such as xDAI) or an ERC20
    - Custom can be a list of ERC20 tokens that are in the select vault
- Working on a pattern to unlock a token
    - Something near the submit button to unlock if needed?

## Proposal Page Skeleton 

- Displays while the data is loading, once loaded this will display the proposals

## Proposals Sponsoring

- Autosponsor could send proposals right into voting period
- If a proposal is taking a long time to load where do we send a user?

## Usability Testing

- Will start testing with users 

## Individual Proposal View

- Rethought from the ground up and modeled after a proposal that was in grace period for the example
- Proposal data:
    - Name
    - Description (with a read more button)
    - Submitted by
    - Simplified version of the contract actions?
        - Can pop open a viewer with the actual contract data for deeper dive
        - "Target Contract" / "Integration"
        - Link to the contract on the block explorer
    - Can do these custom views on the proposals we're defining since we'll know what we'd need
- Add links / copy to the contract addresses in the detailed view
- Expand accordions via arrow for more details such as *Sponsor* 
    - Shows additional details about who/when sponsored
    - Includes transaction links

## Proposal States

- **In voting**
- **Grace**
- **Needs Processing**
- **Expired**
    - Can indicate when you want a proposal to expire
    - Will be on every proposal -- can add this and we can default to *no expiration*
- **Voting Failed**
- **Voting Passed, but execution action failed**
- **Expired**
    - If a proposal is expired you can't sponsor it
    - Can also expire *before processing*
        - Can make through voting but expire before processing
- **Action Failed**

## Vaults

- What do we call our main RQable vault?
- When we add other vaults besides the main vault we could consider naming, but right now we're unsure how we'll do multiple vaults -- could potentially use the first part of the address?
    - "Treasury" could be name for the main vault
- Sorting:
    - Most votes
    - Action needed
- ACE Proposal Warning
    - If unverified we won't be able to look at this at all -- we can look at the block explorer API to see what type of response we'd get
    - We search for the ABI with the block explorer, but there are times when it is down/unverified so we can't encode anything
    - We need a *bigger warning*
    - Can link to it but won't be able to display functions or args -> "Come back later"
- 