Update UX around "Connected/Active Address" <= Objective 1

[zakhap]

Master Figma Link

• https://www.figma.com/file/mJMPTzEnpEFIaR2wBWkElq/Session-Keys-and-Login?type=design&node-id=256-59608&mode=design&t=QSl6fkBJMNcsl5o3-0

User Story 1

• As a user, I need to know which address is connected to a community I’m a part of, so I know how my identity will show up as I take actions within the community (i.e., commenting, upvoting, creating threads, etc.). Solution:
• Connected and Not connected address module with the address tag shown

User Story 2

• As a user, I need to clearly understand why a community I’ve previously joined is saying I am not using the correct linked address, so I can (1) easily switch to the correct connected community address or (2) link a new address to the same community. Solution:
• Not connected address module and clear informational banner explaining to a user they are using an active address that isn’t connected to a community they’ve previously joined (and is tied to a different address than their current active address)

User Story 3

• As a user, I need to know whether I’ve joined a community at the individual community-level, so I can take the correct actions to participate. Solution:
• New location for the Join CTA and Joined status in the left nav

[masvelio]

@zakhap

General Questions:

1. Do we want to keep those 3 user stories as a single ticket or maybe it would be better to split it into 3 separate ones that are in main bucket story.. Or keep it as a single ticket but make 3 different PRs? Imo we should have separate tickets and separate PRs (better for tracking progress, dividing scope and reviewing code)
2. From the top of your mind, do you think any of these tickets in bucket require some logic/model/backend changes or they should be mostly about updating UI using current logic. I am gonna investigate it as well, but want to ask first for any advices/directions.

[masvelio]

@zakhap @meeshlin

User Story 1 Questions:

1. Should the tag with address be clickable (don't think so but just want to confirm).
2. Should it have some tooltip on hover that shows the full address?
3. Regarding left icon: we need to define the list of all possibilities here to be able to map address to correct icon. 3.1 For non-social addresses, are they gonna be community avatars we use currently in the app or icon of the chain? This is not clear for me. We can't use phosphor icons here probably as they do not have those specific blockchain icons. 3.2 Also, we need to prepare the "default" icon in case that there will be address which does not fall into any category (unless we have finite list of options - but I would prepare it anyways).

[masvelio]

@zakhap @meeshlin

User Story 2 Questions:

1. This requires us to have new banner component fully implemented https://github.com/hicommonwealth/commonwealth/issues/4407 I have already prepared the foundation for this component in #4488 (supports only default type) so this should be pretty quick to deliver. Please make sure that #4407 have proper description and AC
2. The designs show that the banner is only visible in the forum (discussions) page. Do we also want to show this banner anywhere else eg. in view thread page?
3. I want to confirm about the current solution and desired solution. Currently, when I joined community with address A and want to connect address B, I can do it as in the video, however, the address B is automatically joined in the community. My understanding from the design is that I can connect new address, but after connecting it should not be joined to the community automatically. It has to be done manually by clicking join. Question is if the current behaviour is buggy and if I understand desired behaviour correctly?

https://github.com/hicommonwealth/commonwealth/assets/14819225/325b54e9-2dda-49ee-ac0c-d59c04d0b7c8

4. If I close out the banner with X it should be gone forever? I mean, we will keep the info about visibility in the local storage so once the cache is cleared, the banner will be visible again. I am asking if it should be back after some time like 7 days, similarly what we did in #4380

[masvelio]

No questions to User Story 3

[zakhap]

General Questions:

1. Do we want to keep those 3 user stories as a single ticket or maybe it would be better to split it into 3 separate ones that are in main bucket story.. Or keep it as a single ticket but make 3 different PRs? Imo we should have separate tickets and separate PRs (better for tracking progress, dividing scope and reviewing code)
2. From the top of your mind, do you think any of these tickets in bucket require some logic/model/backend changes or they should be mostly about updating UI using current logic. I am gonna investigate it as well, but want to ask first for any advices/directions.

1. While there is at least 1 clean line to draw between stories in this PR (remove user story 2, 1+3 go hand in hand), the user experience around the active address selection + community joining isn't resolved cleanly without providing clear visual context to the user about why they should switch addresses. Important to note: these warnings only appear if the user's active address doesn't have an active session key!
2. I do not think these stories will require any backend logic. However, I do believe this work might rely on the root session key work, @jnaviask to link/provide other context to if necessary.

User Story 1 Questions:

1. Should the tag with address be clickable (don't think so but just want to confirm).
2. Should it have some tooltip on hover that shows the full address?
3. Regarding left icon: we need to define the list of all possibilities here to be able to map address to correct icon. 3.1 For non-social addresses, are they gonna be community avatars we use currently in the app or icon of the chain? This is not clear for me. We can't use phosphor icons here probably as they do not have those specific blockchain icons. 3.2 Also, we need to prepare the "default" icon in case that there will be address which does not fall into any category (unless we have finite list of options - but I would prepare it anyways).

1. Nope
2. Not in scope for this PR, but a good UX improvement.
3. I would use the community icons that we currently use next to the addresses on the editProfile page.

   3.2. No default icon is necessary, just don't render anything before the address.

[zakhap]

User Story 2 Questions:

1. This requires us to have new banner component fully implemented Design System: Banners and Alerts #4407 I have already prepared the foundation for this component in Show join community banner when user has not joined #4488 (supports only default type) so this should be pretty quick to deliver. Please make sure that Design System: Banners and Alerts #4407 have proper description and AC
2. The designs show that the banner is only visible in the forum (discussions) page. Do we also want to show this banner anywhere else eg. in view thread page?
3. I want to confirm about the current solution and desired solution. Currently, when I joined community with address A and want to connect address B, I can do it as in the video, however, the address B is automatically joined in the community. My understanding from the design is that I can connect new address, but after connecting it should not be joined to the community automatically. It has to be done manually by clicking join. Question is if the current behaviour is buggy and if I understand desired behaviour correctly?
4. If I close out the banner with X it should be gone forever? I mean, we will keep the info about visibility in the local storage so once the cache is cleared, the banner will be visible again. I am asking if it should be back after some time like 7 days, similarly what we did in Show CTA Banner when not a joined #4380

1. It does require another version of the banner which has not been implemented. I will prepare ticket #4407 to be worked on, either in serial or parallel.
2. This is a good question! I believe it should also be added to the thread page, not just the listing page. @meeshlin to confirm with a 👍 .
3. Your understanding of the new behavior is correct. Pressing "Join" will be a separate step from connecting a new address for clear consent.
4. The banner should come back every time you switch between communities. If I close it while in community A, going into community B should retrigger the banner to come back. If I then go back to community A, it should also reappear.

[meeshlin]

Agreed with @zakhap on his responses, but answering questions below for these specific points for clarity.

User story 1

3. Regarding left icon: we need to define the list of all possibilities here to be able to map address to correct icon.
   • 3.1 For non-social addresses, are they gonna be community avatars we use currently in the app or icon of the chain? This is not clear for me. We can't use phosphor icons here probably as they do not have those specific blockchain icons.
   • 3.2 Also, we need to prepare the "default" icon in case that there will be address which does not fall into any category (unless we have finite list of options - but I would prepare it anyways).

3. The icon is the chain of the address—the ones of which we cover can be found here. If it's a social login, they shouldn't see the Magic-generated address but the social icon and their social username. @zakhap let me know if I'm missing anything.

   User story 2

2. The designs show that the banner is only visible in the forum (discussions) page. Do we also want to show this banner anywhere else eg. in view thread page?

Yes, ideally. It should be visible on every page when a user has an address tied to the community but hasn't signed post-session key expiration.

3. I want to confirm about the current solution and desired solution. Currently, when I joined community with address A and want to connect address B, I can do it as in the video, however, the address B is automatically joined in the community. My understanding from the design is that I can connect new address, but after connecting it should not be joined to the community automatically. It has to be done manually by clicking join. Question is if the current behaviour is buggy and if I understand desired behaviour correctly?

I'm a bit confused by the solution shared in the video. The problem is this is meant to solve is that on Common, we currently default the user to the address they have "connected" to a community. However, we automatically default to that specific address that a user joined a community with. If that address's session key is expired, we still default the user to it, but they need to re-sign or join with a different address.

• If a user is a part of a community, we will default to their address (of all the ones they may have linked), to the first one they joined the community with.
• If a user's default address for a community has an expired session key, they will see the banner telling them to re-sign to join with a different active address. Need to add a fast follow and more discovery here because we missed the use case of when a user's active address has an expired session key, we defaulted them to it, and they may need to choose from their list of linked addresses if they have one to join the community with if they choose not to re-sign. cc: @zakhap
• If a user's default address for a community has an expired session key, we will still default to it but the side nav component will still say Connected as it's meant to denote whether or not that address has joined the community, but they will need to re-sign. This was caught late and needs a fast follow, which is being worked on in here.
• If a user has switched to a different active address for some reason, they will need to switch to the community-connected address or re-join. They will consistently see this banner. Note that the banner is only for users who have joined the community with one of their linked addresses/social logins. It doesn't show up if the user has never joined the community with any linked addresses. Actions they can't take will need to be in its disabled state, as seen here.

For now, I'm just defaulting to @zakhap's responses but we need to revisit this problem as not all user stories and edge cases were captured.

4. If I close out the banner with X it should be gone forever? I mean, we will keep the info about visibility in the local storage so once the cache is cleared, the banner will be visible again. I am asking if it should be back after some time like 7 days, similarly what we did in https://github.com/hicommonwealth/commonwealth/issues/4380

What @zakhap said. Also, it will stay closed after they've closed it during the session they are logged in to Common for the specific community they closed the banner for. If they re-login and run into this issue again, we will re-expose it. They can always manually switch to the right address using the top nav user dropdown.

cc: @masvelio @jnaviask @MuonShot

[masvelio]

UI components should take no more than 1.5 days. I am worried about the logic though that should handle the whole flow. Hopefully 3 days will be enough to adjust it, that's why 8 points. I am planning to split this work to two PRs

• UI - components
  • join community / joined button
  • connected / not connected indicator
  • blue banner
• Logic - hook up new UI to adjusted logic

[masvelio]

UI part is done, PR is ready to be merged #4584 (behind the feature flag). I am moving this ticket back to teed up and jumping over to #4315 to work on UI there. Will be back here for final phase.

[masvelio]

@jnaviask this is not completed, #4584 was just first part of the ticket, opening again

[jnaviask]

Memorializing discussion items / outcomes from today cc @masvelio @zakhap @raykyri.

Problems raised:

• Given that we've cut scope to showing only addresses joined to a community, the "switch to address connected" banner does not make sense / will never appear. What is the proper definition of active address / active account?
• How can we see extant addresses WITH session keys available?

Action items:

• Hide "Not Connected" (show only Join Community) display on sidebar.
• Remove "switch to connected address" banner from product requirements.

Remaining in scope:

• Show checkmark in joined addresses dropdown if session key exists.
• Show join button in sidebar.

[masvelio]

Considering the scope cut down, here is a summary:

User Story 1

• component is displayed only for activeAdress in the sidebar

User Story 2

• banner is removed from the code as it is not usable for now

User Story 3

• join button moved to the sidebar

All of these work above is ready on raymond.react-session-keys-on

@jnaviask @CowMuon how about closing this ticket and we will track any inconveniences caught up during the QA separately?