---
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