---
# System prepended metadata

title: Hub UX Design Review
tags: [' hub', v3]

---

---
tags: v3, hub
---

# Hub UX Design Review

- Test out with Figma prototypes for card and table view, but we're going to start with building the table view

## Table List View UX

- List of DAOs and DAO data for each DAO that you're a member of
- Start with what you're a member of and then expand to all DAOs for exploration
    - DAOs (sorted by name)
    - Proposals (count)
    - Vaults
    - Members (count)
    - Power (voting power)
    - Network
    - Delegate address (clickable)
        - Add delegate (in future)
- Proposals, name, and delegate address are clickable and 
- User profile is least interactive portion in the Hub, so should be a lower priority when looking at your own Hub
- Useful if viewing *someone else's* profile
- Hierarchy: Navigation -> List view -> Profile
- Deprioritized the Haus Price Component
    - Least important for a user since primary purpose is interacting with DAOs, not viewing Haus price data (but this is important from a product point of view)
- Clickable actions:
    - name -> homepage
    - proposals -> DAO proposal list
    - delegate -> (in the future) open a modal and view/change delegate
- Delegate next to name: shows if you're a Delegate of a DAO (could also be an icon)
- Proposals:
    - Count is *Active Proposals* and shows the sum of all active proposals for the DAO, and then clicking directs into the DAO's proposals page
    - Could also add another for showing *All Proposals* if folks think this is useful
- Members:
    - Members are the larger umbrella, so likely should include both shareholders and loot holders
    - How do we want to think about this?
    - Shares and loot columns being ERC20s can now be translatable to other DAOs
- Functionality:
    - Filters
    - Sort by table header
    - **Infinite scroll over pagination**
        - Default to this but we may want to use pagination in other instances
        - Giant, unbounded lists should default to infinite scroll, but there may be other bounded lists that are smaller where we may want to use pagination instead
- Search:
    - Optimizing around search fields, so may want to include this in Alpha
    - Which field? Search DAO name for Alpha, but could be useful to search for users, tags, or other metadata

## Meta Navigation Dropdown

- Navigation between apps
- **Dropdown** menu in Navigation -- Search (navigate to DAO page), Hub, Explore, Summoner, Core UI, Yeeter, etc.
- Context sensitive menu populated with apps and Search field which goes directly to DAOs
- Molecule:
    - App Icon + App Name
- Color themes:
    - Each app could have its own primary color scale
    - Hub: Crimson
    - Explore: Indigo
- DAO names by address
    - Used in the Hub and the Search
    - Searchable list from DAOs that a user is in
    - What happens if a user isn't connected?

## Card View UX

- What is the value of the Card View?
    - Still being explored and validated via user testing


## Molecules

- DAO avatar + name
- Table view: [React Table](https://react-table.tanstack.com/)

## Questions

- Connecting to Hub: how do we want to look for someone else's profile?
- Add a route and populate based on looking up someone's address
- Dashboard/Profile:
    - Personal view: Dashboard
        - Proposal data, more personal and sensitive
    - Public view: Profile
        - Which DAOs person is in / DAOs both in, etc.
- Need ability to look up via address and populate the Profile/Dashboard
- Put Explore into the Hub? Should this be its own app?
    - Clicking on `Explore ___ DAOs` would pull up *all* DAOs instead of the user's DAOs
    - Does this toggle back to "See my DAOs" when in Exploring?
    - Remove *Power* and *Delegate* and maybe then include total proposals instead of active proposals
    - Use same data but show differently based on self vs. all DAOs
- Won't have avatars until there is more of a Core UI for metadata
    - Fall back to Blockie in the meantime

## DAO Price Component

- Is this deprioritized? Product strategy conversation
- Keep the data for now as we build the Alpha, and then build the component UI at a later point (this can be open to feedback from the product strategy based on business priority)
    - Adding HAUS token visibility can be useful to include
- Balancing the incentives between users and business/product strategy

## Profile

- Store user preferences in a DAOhaus Ceramic schema
    - Edit Preferences
    - If they don't have a profile set, we'd create a DID for them
    - Update, but can't make it destructive
    - Updating and adding is fine, but removing is not

## Notes (5/4/22)

- Updated cards, but we can probably split the table one out
- Keating still working on Jest
- Haus Price Data:
    - Break this up based on what we need for the DAO table itself since we'd need some price data
- DAO Tables:
    - Make multiple tickets for the data aggregations
    - Pagination, Search and filtering are separate tickets
    - `getMembershipsByAddress`
        - Cross chain query getting all DAOs for a specific user
        - name, network, all proposals
            - Will need a way to filter by active proposals (get a count of active proposals)
    - difficulty with some of these queries, such as DAOs with a field of proposals is that the Graph limits these at 100
    - initial build this'll be ok `dao.proposal` but we may want to look into having an aggregate on the DAO of proposal count in the Graph
    - Do we want a Lambda that does this processing ahead of time?
        - Active Proposals: 
            - 3 queries combined together
            - date is after voting starts and before grace ends
            - after grace passed and not processed
            - potentially unsponsored?
            - needs processing
            - is it still active if you've already taken an action?
    - Search and Filter in the frontend
        - Will need to load all the data up front even though we're doing pagination
- Won't have all of these, will need to do a query per chain an combine
- Queries are too complex or the data is already hydrated, so we'll need to create a **Lambda** for this
    - Index this into something easier to query
    - Has these fields so we can query by them
        - Vault total
            - 
        - Members
            - 
        - Power
- Query by user address and support filtering on all the fields
- orderBy and search on them, and pagination

## Lambda

- Runs on a schedule and queries all DAOs across networks
- Calculates aggregate numbers and put into Skynet: vault total, member count, active proposal count, and drops this to Skynet
- Use a Postgres or MongoDB that stores all the fields we need -- will be centralized but anyone can access it
- Make it easier for us to query and for folks to search and filter
    - Querying a centralized service, but the data itself is decentralized
        - If our infrastructure goes down folks can't access it
    - If we don't want hosted services it would make sense to cut features or load everything up front
    - What are the tradeoffs we'd want?
- Querying cross chain and then aggregating, filtering, and searching on frontend may be performance hit to load all of this via the frontend
- Can offload some of this processing to a Lambda
- When frontend calls to get all DAOs for a Member, need to use Graph to get all DAOs for a Member, hydrate with the hydrated JSON data from Skynet to fill in the other fields
- Change UI to either be 1 chain at a time or not support filtering and sorting?
    - Name is in a sub field so we can't sort on that either
    - View that's only Gnosis Chain:
        - Support filtering on any non-aggregate field
        - Delegate?
- Lambdas:
    - Runs on schdule calculating things not in subgraph and drops a JSON file into Skynet with keys of every DAO address
    - Another lambda that frontend hits and gets all DAOs by user address
    - List of user's memberships by DAO address -> grab the Skynet JSON file and then hydrates with the aggregages, and then the frontend will handle the filtering and data
        - Explore All will be problematic with this
    - Handle everything in frontend and have the Lambdas calculate the aggregate fields
    - Document the Lambdas and make it easy for anyone to deploy -- anyone should be able to run their own DAOhaus, so anything we run we'd want to be public and have documentation around 
- Explore All:
    - What will we do with this? 
    - What's our strategy for the larger data sets?

## Cards to Create

- Searching
- Filtering
- Lambda to index DAO Hub data
    - Runs on schedule
    - Queries all DAOs and calculates:
        - Proposals
        - Active proposals
        - Vaults
        - Member count
        - Network (hydrated)
    - Stores in Skynet
- Lambda endpoint
    - Hit with Member address and will return all the DAOs based on address and hydrates with Skynet cache with all aggregate indexed data and returns to the frontend
- Scaffold the Lambdas are separate packages in the monorepo
    - `functions` folder
    - https://github.com/HausDAO/daohaus-monorepo/tree/lambda-test/apps/haus-price
- Pagination
    - Separate story for pagination, and prioritize it as we need
    - Look at infinite scroll React Table?
- Look into decentralized network providers:
    - https://www.golem.network/platform
    - https://akash.network/about