[EPIC] Deltas between designs and build for join token gated community flow

benjthayer commented 6 months ago

Below is a list of differences between the intended user flow for joining a token gated community and what is currently in the app (2.27.0-rc.6)

Screen recording of app: https://github.com/status-im/status-desktop/assets/110033914/e6805cf8-71c1-4932-ab64-fdca402fec52

Differences:

1) Join CTA labelling

App: Reveal your address and request to join (with authentication icon)

Design: Request to join community (no authentication icon - there is no authentication at this point)

Additional note: The n members should be pluralised if >1 but not if only 1. I.e. we should never see member(s) here only member or members depending on the number of members.

2) Request to join dialog

App: Dialog title reads Welcome to [community name]

Design: Dialog title reads Request to join [community name]

App: Dialog primary CTA reads Join [community name] (without authentication icon) Design: Dialog primary CTA reads Share all addresses to join (with authentication icon)

App: Missing eligible to join tag Design: Contains an eligible to join tag sticky to the base of the dialog with the relevant highest possible role the user can join the community as based on their aggregated token balances across all of their Status accounts

Additional note: Community icon looks a little blurry

3) Select addresses dialog

App:

Unknown rationale for account ordering?
The account which holds the relevant collectible for joining the community doesn't show the collectible under the account name
When the user checks accounts on and off, the UI in the backgrounds seems to shift / change according to the selections.
The Requirements check pending text resizes the dialog when it is shown each time an account is selected/deselected which is a little distracting. Perhaps one for design to take a look at.
The Share selected addresses to join should have an authentication icon in the case where the user is opting to share addresses that are all stored in the same location because the user can authenticate a single time for all accounts. The CTA should omit the authentication icon if the relevant key pairs are stored across multiple locations (i.e. a mix of keycards or a mix of device/keycards). In this case, the authentication wiki flow should launch. The flows showing this logic are here:

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

Design:

Account ordering should be according to balance of relevant tokens for joining the community/channels. If there are no relevant tokens across any of the accounts, the accounts should be ordered according to the user's wallet ordering.

4) Prove ownership of key pairs dialog

App: The user should not see this dialog if all key pairs for the selected accounts are stored in the same location. For example in this flow, all of the accounts I wish to share with the community are stored on device and therefore the primary CTA on the Selected addresses to share with [community name] dialog should feature an authentication icon - clicking that should launch the authentication dialog not the Prove ownership of key pairs dialog. The Prove ownership of key pairs dialog should only launch if the key pairs associated with the accounts the user wishes to share with the community are stored in different locations and therefore require individual authentication.

Also when the user clicks the Authenticate button on the Authenticate dialog, there is a long pause 0:49-0:55 in the video. If the authentication process takes time, we should add a spinner state to the Authenticate button so the user knows something is happening and not to move away.

Design:

5) After authentication

App: Once the user has authenticated the relevant keypair/s, the user is returned to this screen state where the Reveal your address and request to join button is still shown:

Design: Once the user has authenticated, the button should change to Membership Request Pending.... Clicking on this CTA should relaunch the Request to join dialog - the only CTA on the Request to join dialog should be Cancel Membership Request

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

cc @John-44 @iurimatias @jrainville

Subtasks UI-TEAM:

JOIN / GLOBAL / MAIN VIEW:

REQUEST TO JOIN DIALOG

[x] https://github.com/status-im/status-desktop/issues/14100

SHARED ADDRESSES POPUP / PANEL:

jrainville commented 6 months ago

@alaibe @alexandraB99 it might be worth splitting this task in 2. Sale can keep working on https://github.com/status-im/status-desktop/issues/13974 and the UI team can do the other UI element fixes listed above

caybro commented 6 months ago

Agreed with Sale he'd do points 3. and 4., the rest is on me

noeliaSD commented 6 months ago

We are going to consider this task as an EPIC and I'm going to create smaller tasks to be able to work in parallel (added in task description).

UI team investigation task but could be potentially moved to another team (wallet or messenger depending on what we conclude):

[x] https://github.com/status-im/status-desktop/issues/14090

NOTE: After this PR is integrated, UI team must give a second look at points 3 and 4 to verify the complete list of UI design deltas are solved

saledjenic commented 6 months ago

A short update, at least points 3 and 4 are fully handled in https://github.com/status-im/status-desktop/pull/14024

noeliaSD commented 5 months ago

Closing the epic since all the important tasks have been closed and the missing ones are postponed to other milestones bc they have lower priority.

status-im / status-desktop

[EPIC] Deltas between designs and build for join token gated community flow #13988

Subtasks UI-TEAM: