Related Communities / "Directory" page

[sachben91]

User Story

When I’m managing my community as an admin for an ecosystem (such as Near or Solana), I want to be able to automatically create a directory of projects/communities that are in the same ecosystem so that community members can explore and join these other projects. The automation is important to me since there could be several projects that I’m not aware of that could get missed in manual curation

As a community admin, I want to be able to turn on/off the directory page.

Design solution doc

Designs on Figma

Prototype on Figma

Loom

Behavior

• Admin should be able to see the option to toggle the directory page on in "manage community" page
• Admin should be able to select the chain for the directory page. The default chain should be the underlying chain of the community that the user is an admin of. The user should have the option to change this to another chain
• The directory page that a normal user sees should have a table view and card view as shown in the design. The columns Community, Members and Threads should be sortable in alphabetic order (community) and ascending or descending order numerically (Members, Threads)
• User who is visiting the directory page should be able to search by Community.

New Components:

• Typeahead search drop down #4680
• Table component #4682
• Related communities table search #4681
• Community Card Component #4828

Screenshots

Directory page set up

Directory page view

Acceptance criteria

• [ ] Admin see the directory page option in the manage community page
• [ ] Admin is able to toggle the directory page on and off
• [ ] Admin can select the chain for which they want to display related communities in the directory
• [ ] user visiting the page can toggle between card view and table view in the directory
• [ ] user visiting the page search for communities on the directory page

---

PM: @sachben91 Designer: @jessmart1213 This ticket is a blocker on onboarding some Enterprise Ecosystems we're courting.

[Miaplacidus]

@jessmart1213 @sachben91 @zakhap The directories page provides an option for both a table view and a card view. The cards will vary in height depending on the length of the community description. Do we want the cards to all have the same height? In addition, some of the cards have a call to action. What is the CTA and under what conditions will it appear?

[jessmart1213]

@Miaplacidus Re: card height It is fine for the cards to have varying heights at this time, this is intentional and represented in the designs.

Re: Card CTA In the design system 2 card variation were created, one with the CTA and one without. This was done as there was some back and forth on whether or not to have a CTA at this time within the Directory page, so I created 2 options. For the directory page, the car without the CTA is to be used. When the time come to use the card variation with the CTA, that will be when the function and copy for the CTA will be decided.

[jnaviask]

@masvelio Tagging you as the core developer on this screen. The two components needed to address this ticket are #4680 and #4682 which should both be nearly complete.

Please sync with @Miaplacidus to make sure you have full context regarding any updates design/product may have surfaced since ticket creation, and then please update the body of the issue to correspond with the final decisions.

[jessmart1213]

It has come to my attention that the loom I created was recorded without sound. So I just re-recorded the with sound.

Here is the new Loom.

@masvelio @sachben91 @zakhap @Miaplacidus

[masvelio]

After my review and sync with @Miaplacidus, I am attaching my thoughts and questions.

Work that has to be done here.

Frontend

• add “directory page” section to “manage community” page
• add “Directory” list item in left sidebar
• create “directory” page

Backend

• add boolean field to ChainInfo model for directory page section toggle
• add string field to ChainInfo model for selected community’s chain
• update updateChainData method to support those two values above
• prepare data that are displayed in directory page (list of communities with description, members, threads)

Questions

• @jnaviask Where should I get the list of community’s chain dropdown from? Is this something we already have in app store or we should prepare it on the backend specifically for this page?

• @jnaviask Should we create new endpoint that will be serving data for directory page (list of communities with description, members, threads etc)? Should this list be paginated?

• @jnaviask To what endpoint the seachbar should be hooked up to?

• @jessmart1213 Requirement is that “Directory” list item in left sidebar should appear right after the toggle is turned on. However, we have already similar situations that left sidebar is updated eg for changing the order of the topics, update the name of the topic or showing homepage. All of these actions are reflected in left sidebar after pressing the save button. Both from UX and technical point of view, it would be good to follow this pattern. If we turn the toggle on and show the Directory list item in left sidebar, but we do not click “save changes”, after leaving the “manage community” page, the list item will be not visible anymore and the new value for toggle won’t be save neither. I am adding video below to show the current behaviour.

https://github.com/hicommonwealth/commonwealth/assets/14819225/c7f54e0b-0903-4656-a6c8-7c9112830a47

[jnaviask]

@masvelio

Where should I get the list of community’s chain dropdown from? Is this something we already have in app store or we should prepare it on the backend specifically for this page?

We should be able to populate this list from app.config.nodes, which stores each of the possible chains (used in the general sense, not the "chains <> communities" sense). It should default to the app.chain.meta.ChainNode.id entry.

Should we create new endpoint that will be serving data for directory page (list of communities with description, members, threads etc)? Should this list be paginated?

Yes we will need a new endpoint, but we need clarification on which exact communities to surface on the page. I will bother @zakhap @sachben91 for the specifics, which are not clear from the Solutions doc. My sense is it should be paginated.

To what endpoint the seachbar should be hooked up to?

Ideally the same endpoint that we query the original list from. However the logic of searching is still unclear based on the Solution doc, what is "relevance" specifically...

[masvelio]

@sachben91 another question that came to my mind - do we support related directories for custom domains? For example explore communities is not available on custom domains:

[masvelio]

@jnaviask thanks for the answers. In this case I am gonna start with the front end part as it seems that backend needs more clarification.

[jessmart1213]

@masvelio responding to

@jessmart1213 Requirement is that “Directory” list item in left sidebar should appear right after the toggle is turned on. However, we have already similar situations that left sidebar is updated eg for changing the order of the topics, update the name of the topic or showing homepage. All of these actions are reflected in left sidebar after pressing the save button. Both from UX and technical point of view, it would be good to follow this pattern. If we turn the toggle on and show the Directory list item in left sidebar, but we do not click “save changes”, after leaving the “manage community” page, the list item will be not visible anymore and the new value for toggle won’t be save neither. I am adding video below to show the current behaviour.

I see what you are saying here. Thank you for bringing this up. From my understanding, to adhere our UX patterns and best practices of clicking "save changes" lets change the user journey to the following:

• As an Admin who wants to enable the "Directory page" I go to the "Manage community", I scroll down to the Directory page section, I click the toggle on, I ensure the dropdown is populated with the chain I want, I scroll further down the page, I select "Save changes". Once changes are saved, I see the "Directory page" appear within the sidebar, but I decide to scroll back up to the Directory section and I see the tertiary button "Go to directory page" has also appeared and I select that button to be taken to the Directory page.

Let me know if what I wrote is clear enough to be actioned on. If not, I will update the designs.

[masvelio]

This is all good @jessmart1213 thanks for adjusting it

[sachben91]

@masvelio re:do we support related directories for custom domains? what is the effort on supporting related directories for custom domains? and how many communities have custom domains? If the effort is medium to low, we should support related directories, if its high, lets have a discussion to look at the custom domains and how important they are.

[sachben91]

@masvelio

Where should I get the list of community’s chain dropdown from? Is this something we already have in app store or we should prepare it on the backend specifically for this page?

We should be able to populate this list from app.config.nodes, which stores each of the possible chains (used in the general sense, not the "chains <> communities" sense). It should default to the app.chain.meta.ChainNode.id entry.

Should we create new endpoint that will be serving data for directory page (list of communities with description, members, threads etc)? Should this list be paginated?

Yes we will need a new endpoint, but we need clarification on which exact communities to surface on the page. I will bother @zakhap @sachben91 for the specifics, which are not clear from the Solutions doc. My sense is it should be paginated.

To what endpoint the seachbar should be hooked up to?

Ideally the same endpoint that we query the original list from. However the logic of searching is still unclear based on the Solution doc, what is "relevance" specifically...

we should have all the the "base chains" that have communities, @zakhap had provided this list which he mentioned can be got from the endpoint that Talking about - https://docs.google.com/spreadsheets/d/1g1KGr8BgR0qEgVq_GFICWk7CAuJw4D45PD3sQ4YBwPA/edit?usp=sharing

[jnaviask]

@sachben91 this list is not useful because it doesn't clarify the logic involved in determining what a base chain is + which communities to populate on the queried list.

[sachben91]

@jnaviask A base chain is all the chains that a community can be connected to, so the list to be queried would have all the chains that we have nodes for. cc @zakhap for more clarity

[zakhap]

We can drop the term "Base Chain", as it is simply the "Chain" that a community is "based on".

The logic for the dropdown would be to show all the possible "Chains" that a community can be based on. The suggested/pre-selected default input should be the "Chain" that the community is currently associated to. For example, if the Community "Zak's Clubhouse" was created as an Ethereum Mainnet Community, then the pre-selected input should be "Ethereum Mainnet". For example, "Freedom DAO" is based on the XDai chain and then the pre-selected input would be "XDai Chain".

[masvelio]

We can drop the term "Base Chain", as it is simply the "Chain" that a community is "based on". The logic for the dropdown would be to show all the possible "Chains" that a community can be based on. The suggested/pre-selected default input should be the "Chain" that the community is currently associated to. For example, if the Community "Zak's Clubhouse" was created as an Ethereum Mainnet Community, then the pre-selected input should be "Ethereum Mainnet". For example, "Freedom DAO" is based on the XDai chain and then the pre-selected input would be "XDai Chain".

@zakhap Thanks for giving the examples, that helps. Spreadsheet is also helpful.

1. So my understanding is that the dropdown list will always have the same set of items (chains), regardless of the community we are looking at. The list will be basically the same as the one in spreadsheet and it can be accessed from app.config.nodes as @jnaviask mentioned above.
2. What will be different between communities though is the default value in the dropdown. Eg for "Freedom DAO" community, default value will be "xDAI" chain, for "dydx" community, default value will be "ethereum mainnet" chain, etc.
3. When I click "Go to directory ->" button, I use selected value from the dropdown eg "xdai" or "ethereum mainnet" to fetch every community that is based on this chain and display them in the table. So if I have "ethereum mainnet" selected, then in the directory page I list every community that is based on "ethereum mainnet", so "dydx", "aave", "alchemist", "alpha venture dao" etc.

Sorry for being so verbose here, but I really want to understand the logic, relation and the flow here. cc @kurtisassad for visibility

[sachben91]

@masvelio your understanding is accurate

[masvelio]

@ForestMars @jnaviask Eng update: I run into issue with searchbar. I am not able to reuse recently created CWSearchBar because it is not generic design system component. When I import and use it, it has all the logic for searching communities/members/threads etc, exactly the same as searchbar for top navbar (see image). I need to refactor it to make it reusable. Shouldn't be high lift, but want to inform that it will take a bit more time than I expected.

[CowMuon]

Setting status to In progress to catch the last remaining merge conflict, and then we're GTG.