Joining communities: Clarifying what role the user will join as

[benjthayer]

A new tag has been introduced to the request to join community flows to clarify which role (Member, Admin or TokenMaster) the user will join a community with based on the addresses they are opting to share. This is to bring desktop into alignment with mobile where that clarity is given to the user.

This tag has been added to both the main request to join community dialog and also the dialog which allows the user to custom select which addresses they wish to share with a community upon joining.

Tag introduced to main request to join dialog:

Tag introduced to select addresses dialog:

On both dialogs, the positioning of this tag is sticky to the base of the dialog with a fixed position above the bottom action bar. This ensures that the tag is visible at all times:

Dependent on the user's address selection and how the tokens within those addresses align with the token gating permissions for the community, the relevant tag will be shown to clarify whether the user will join the community as a Member, Admin or TokenMaster

(Please note, work is needed on the Admin icon shown above).

Figma:
https://www.figma.com/file/qHfFm7C9LwtXpfdbxssCK3/Kuba%E2%8E%9CDesktop---Communities?type=design&node-id=31461-597356&mode=design&t=QPG8DvkYtMpWwGb4-4

--

In addition logic has been added to the flows to clarify that the user will always join with the highest permission available to them. I.e. if they share addresses which meets the token requirements for both the Admin and TokenMaster roles, with their current address selection, the user will join as a TokenMaster. The same is true if the user shares addresses which meet the requirements for standard membership and being an Admin - they will join as an Admin.

This logic is shown here:
https://www.figma.com/file/qHfFm7C9LwtXpfdbxssCK3/Kuba%E2%8E%9CDesktop---Communities?type=design&node-id=51863-145599&mode=design&t=QPG8DvkYtMpWwGb4-4

[iurimatias]

needs analysis / broken down

[noeliaSD]

I'll take a look, probably we already covert some scenarios in 2.28.1.

[caybro]

Ah, this has already been implemented as part of #14187

[noeliaSD]

@benjthayer I have a small doubt here. We also show the Shared Addresses dialog in the Edit flow. Should we also show this tag there??

I mean here (the user is already a member but depending on the selection she/he can get a different role):

Screen.Recording.2024-04-08.at.11.00.33.mov

[benjthayer]

@benjthayer I have a small doubt here. We also show the Shared Addresses dialog in the Edit flow. Should we also show this tag there??

I mean here (the user is already a member but depending on the selection she/he can get a different role):

Screen.Recording.2024-04-08.at.11.00.33.mov

This is a good point @noeliaSD . While subsequently designing the mobile flows, the team added a couple of additional flows which I've now pulled into desktop. Essentially, this tag should remain in position in the edit shared addresses flows but be updated based on the resulting impact of the edited address selection.

Here's an example of the screen with the role tag in place - the tag confirms the user's current role:

Figma:
https://www.figma.com/file/qHfFm7C9LwtXpfdbxssCK3/Kuba%E2%8E%9CDesktop---Communities?type=design&node-id=31461-572916&mode=design&t=7PS6nS1lioQ5Sq9D-4

I've also added 2 new states/flows which show what the user should see when upgrading or downgrading the role by selecting/unselected addresses during the edit flow:

1) Upgrading the user's role via the edit shared addresses flow:
If the user has the option to upgrade role by selecting new addresses, they will see a green notification bar. When the user selects the relevant address, the tag wording updates to You'll be a [role name]. Selecting additional addresses will mean the user needs to authenticate.

Figma:
https://www.figma.com/file/qHfFm7C9LwtXpfdbxssCK3/Kuba%E2%8E%9CDesktop---Communities?type=design&node-id=53567-145017&mode=design&t=7PS6nS1lioQ5Sq9D-4

---

2) Downgrading the user's role via the edit shared addresses flow:
If the user deselects an address which will result in a demotion in role (eg TokenMaster to Member), the user will see a red notification bar warning them of the demotion and the tag wording updates to You'll be a [role name]. No authentication is needed for unsharing an address but we do change the CTA to Save changes & update my permissions

Figma:
https://www.figma.com/file/qHfFm7C9LwtXpfdbxssCK3/Kuba%E2%8E%9CDesktop---Communities?type=design&node-id=53567-150551&mode=design&t=7PS6nS1lioQ5Sq9D-4

---

NB - Upon revisiting this to make these changes, I've needed to make a couple of tweaks to the toast wording for when the user changes addresses and the app is confirming changes in membership or role.

Eg here:
These are updated where required throughout the edit shared addresses flows.

---

Hope that all makes sense! Just shout if not! :)

cc @John-44

[caybro]

@noeliaSD thanks for raising this up; I'll take the issue unless you want to do this yourself, should be fairly easy to now that we have all the needed logic in place

[noeliaSD]

@noeliaSD thanks for raising this up; I'll take the issue unless you want to do this yourself, should be fairly easy to now that we have all the needed logic in place

Yes, you can take it! There's another specific think we've been discussing offline with Ben. I'll add the comment here later!

[noeliaSD]

@noeliaSD thanks for raising this up; I'll take the issue unless you want to do this yourself, should be fairly easy to now that we have all the needed logic in place

Yes, you can take it! There's another specific think we've been discussing offline with Ben. I'll add the comment here later!

I see Ben already updated the figma so.. I guess it's clear now:

• The message when user is "downgraded" is specific saying that she/he has lost a specific role permission, instead of saying she/he has lost permissions (for me it was a bit confusing like meaning that after the downgrade she/he is not able to be part of the community anymore).

Note that with this change, probably we need to sync with the backend team to see if we can somhow know the role transition (from X to Y).

[caybro]

@noeliaSD thanks for raising this up; I'll take the issue unless you want to do this yourself, should be fairly easy to now that we have all the needed logic in place

Yes, you can take it! There's another specific think we've been discussing offline with Ben. I'll add the comment here later!

I see Ben already updated the figma so.. I guess it's clear now:

• The message when user is "downgraded" is specific saying that she/he has lost a specific role permission, instead of saying she/he has lost permissions (for me it was a bit confusing like meaning that after the downgrade she/he is not able to be part of the community anymore).

Note that with this change, probably we need to sync with the backend team to see if we can somhow know the role transition (from X to Y).

No need to, we know whether we lost/gained permissions or channel access within this popup

[noeliaSD]

No need to, we know whether we lost/gained permissions or channel access within this popup

Oh really?? So do we know that previously we were TokenMaster owners and now, after recheck, we've lost this to only a Member?? Aren't we just observing some backend model??

[caybro]

No need to, we know whether we lost/gained permissions or channel access within this popup

Oh really?? So do we know that previously we were TokenMaster owners and now, after recheck, we've lost this to only a Member?? Aren't we just observing some backend model??

Yes, because we take the initial state as a snapshot, to be able to compare it to the current state when changing the accounts

[caybro]

Small update:

1. Upgrading the user's role via the edit shared addresses flow:

We are simply unable to display that green bar and tell the user that selecting additional wallet accounts would give them higher roles. We can still though display the bubble/pill at the bottom, dynamically indicating which role they would get with the current selection.

I hope it's fine like that @benjthayer

[caybro]

This extra criteria would also depend on #14192