UI Upgrade for Address Selector

[zakhap]

Objective #2: Allowing users to easily switch between their different addresses with an improved universal top nav.

User Story 1 => Update Address selector dropdown.

• As a user, I need to be able to easily view my linked addresses along with their status (session key, “signed out”) and switch between them as I navigate Common, so I know the addresses and social logins I have linked to take the correct actions when I’m in specific communities. Solution to implement:
• New user dropdown using the new design systems dropdown component
  • User dropdown button updated
  • Dropdown to include two sections with sub-headers and a divider in-between each
  • Section 1 is Addresses with ~all the linked addresses~ active addresses and icons to show their chain (icon + address) or social login method (icon + socialUsername). => Update: the scope reduction from Objective 1 remains true here.
  • Section 2 is Settings which will include: (1) View profile, (2) Edit profile), (3) Notifications, and (4) Dark mode which includes a toggle => These are already existing dropdown menu buttons and will keep their functionality.

User Story 2 => Update Universal Nav IconButtons

• As a user, I need to be able to clearly understand the universal actions I can take that is visually consistent with the rest of the product, so I can (1) view my notifications, (2) provide feedback, (3) explore help docs, and (4) explore other communities.

Solution to implement:

• Use new icons from Phosphor
• Explore = compass / regular, neutral-500
• Help = question / regular, neutral-500
• Send Feedback = PaperPlaneTilt / regular, neutral-500
• Notifications Bell = BellSimple / regular, neutral-500.
• All above Icons are used as Icon Buttons.
  • All icons are 16x16px within a container with a 4px padding all around and a 6px radius for hover states. Each component will show up as 24x24px with the added padding and each icon button is separated by a spacing of 8px.
  • Hover state: The icon becomes Neutrals/600 with a background (entire container with the 6px radius) of Neutrals/100

User Story 3 => Updating Logout button

• As I a user, I need to be able to log out of my Common account, so I have control and agency over how and when I use the platform. Solution to implement:
• Logout = SignOut / Regular, Neutrals/500
  • (Behavior) Hover state: The icon becomes Neutrals/600 with a background (entire container with the 6px radius) of Neutrals/100

Out of Scope:

• Search Bar

[masvelio]

@zakhap @meeshlin

User Story 1 Questions:

1. We do not have new dropdown component from the design system. Do we want to (1) implement it before this ticket and use new component or (2) use component we already have that looks very similar to the design but won't be 100% identical.

CURRENT COMPONENT THAT WE CAN USE AND SWAP LATER

DESIGNED COMPONENT

2. As discussed in comment (point 3) in other ticket about the addresses' icons: we are gonna use community avatars instead of designed icons. But does it also work for let's say social logins? If I login with google or github, should we show relevant social icon or the icon of the community that address belongs to?
3. Are those addresses that are signed out are clickable? What happens when I click it? Tbh I don't understand why they are signed out but this is probably something I can catch up with Ray or Jake.
4. I can't see connect a new address option in the dropdown any longer. Do we remove this functionality, it is moved somewhere else or it is oversight?
5. Currently in the dropdown we have option Notification settings but in the design we have Notifications. Former seems more accurate because it takes user to notification settings page, while bell icon is responsible for navigation to notifications page.

[masvelio]

@zakhap @meeshlin

User Story 2 Questions:

1. What about the plus icon that we currently have in the top nav bar. It is pretty important (although duplicated because it is also visible in left sidebar)
2. New designs looks great but I would love to hear from you what is your strategy for the mobile navigation? If we are modifying big-screen-nav, we probably should think about redesigning mobile-nav as well. Currently, in mobile dropdowns are the same as on desktop but the icons are hidden also in 3 dots menu that appears as a full width box. Please let me know how to approach mobile navigation in terms of this ticket. I would say that we have to rethink how the sidebar works in the future as well (it is related to the top nav especially on the mobile).

[masvelio]

No questions to User Story 3

[zakhap]

User Story 1 Questions:

1. We do not have new dropdown component from the design system. Do we want to (1) implement it before this ticket and use new component or (2) use component we already have that looks very similar to the design but won't be 100% identical.

• Aw shucks, I made the unfortunate assumption that because we use newly design dropdown components for sorting/filter threads and comments that they had been added as their own component. Do you mind providing how long you think it would take to generalize/componentize these components?

2. As discussed in comment (point 3) in other ticket about the addresses' icons: we are gonna use community avatars instead of designed icons. But does it also work for let's say social logins? If I login with google or github, should we show relevant social icon or the icon of the community that address belongs to?

• The behavior of the dropdown should be to only enable addresses that are able to join the community.
• The list of addresses shown are not every address as role in a community (with community avatar) but every unique address (in standard encodings: hex, bech32, etc). We should probably arrive at what chain icon to show by encoding type. @jnaviask to confirm.
• For socials, we don't currently do "overrides" where we hide the address we generate using Magic and visually replace them with the socials used to generate those addresses. Unfortunately, it seems like we only store "magic" as the wallet_id and not anything else about the social for overriding. @jnaviask is there something we can do here to do the overrides? If not, let's document that here and come up with a solution to show the addresses magic generated as such.

3. Are those addresses that are signed out are clickable? What happens when I click it? Tbh I don't understand why they are signed out but this is probably something I can catch up with Ray or Jake.

• "Signed Out" addresses are addresses that don't currently have an active session key. @meeshlin What do you think of replacing the copy of "Signed out" with "Inactive" (as that's more accurate).

4. I can't see connect a new address option in the dropdown any longer. Do we remove this functionality, it is moved somewhere else or it is oversight?

• We should absolutely maintain a "Connect a New Address" option at the bottom of the address selection options above the Settings section.

5. Currently in the dropdown we have option Notification settings but in the design we have Notifications. Former seems more accurate because it takes user to notification settings page, while bell icon is responsible for navigation to notifications page.

• "Notification settings" just is moved further down in the new popover menu under Settings as simply "Notifications".

[zakhap]

User Story 2 Questions:

1. What about the plus icon that we currently have in the top nav bar. It is pretty important (although duplicated because it is also visible in left sidebar)

• Ah superb question. I think we should keep it (if that's ok @meeshlin) and simply use the phosphor icon plus-circle for consistency.

2. New designs looks great but I would love to hear from you what is your strategy for the mobile navigation? If we are modifying big-screen-nav, we probably should think about redesigning mobile-nav as well. Currently, in mobile dropdowns are the same as on desktop but the icons are hidden also in 3 dots menu that appears as a full width box. Please let me know how to approach mobile navigation in terms of this ticket.

• @meeshlin How would you like to handle mobile? In my opinion, we should simply have an option in the mobile menu for each of the icons that are hidden. Explore being the only new option there, it could easy just be added to the list of mobile options.

I would say that we have to rethink how the sidebar works in the future as well (it is related to the top nav especially on the mobile).

• Coming soon 👀

[masvelio]

User Story 1 Questions:

1. We do not have new dropdown component from the design system. Do we want to (1) implement it before this ticket and use new component or (2) use component we already have that looks very similar to the design but won't be 100% identical.

• Aw shucks, I made the unfortunate assumption that because we use newly design dropdown components for sorting/filter threads and comments that they had been added as their own component. Do you mind providing how long you think it would take to generalize/componentize these components?

@zakhap As I see on the design this is quite complicated component, with all those states, list placements, multiple types of elements inside etc. I would say that this is 2-3 days depending how much we can use from existing components (plus icon - create dropdown and sort/filter dropdowns -- these are two different components as well so it would need to be unified properly). Probably one day more to make it work in storybook. No matter what will be your decision, we need ticket for this. But let's decide in next 1-2 days which way we go!

[jnaviask]

@zakhap @masvelio @meeshlin

We should probably arrive at what chain icon to show by encoding type

Why not show the icon of the wallet used to link it?

is there something we can do here to [show social login info]

Yes, but we will need to add it to the login flow. Magic exposes the following route:

GET https://auth.magic.link/v1/oauth2/user/info/retrieve
QUERY
  * provider     (string) - The name of the OAuth provider (i.e.: google,
                            facebook, twitter, apple).
  * field_format   (enum) - Option to return the user info fields as camelCase
                            or snake_case (one of: 'camelCase' | 'snake_case').
HEADERS
  * x-magic-api-key  (string) - The publishable API key for your Magic app.
  * authorization    (string) - An OAuth access token for the specified provider
                                in all cases except Apple, for which you should
                                provide a Magic DID token instead. Please
                                provide in a "Bearer {token}" format.
RESPONSE
  200/3xx:
    {
      data: {
        ...Open ID profile fields
        sources?: If applicable, an object mapping provider-specific endpoints
                  to their raw return value, we combine the result of these
                  endpoints to formulate the Open ID userinfo fields in the
                  `data` object.
      },
      error_code: "",
      message: "",
      status: "ok",
    }
  4xx:
    {
      data: {
        oauth: {
          provider: The OAuth provider (i.e.: google, facebook, twitter, apple).
          error: The OAuth2 error code.
          error_description?: The OAuth2 error description.
          error_uri?: The OAuth2 error URI.
        }
      },
      error_code: Same as `data.oauth.error`,
      message: A formatted error message containing information from
               `...data.oauth`.
      status: "failed",
    }
  5xx: Uh oh, get in touch with us because something's up!

We can use this route to query OAuth data at social login validation time, which would allow us to store the metadata about which method was used (and also "verified" social information such as usernames on other profiles).

However, this would be a fairly significant change (although we could start by simply tacking it onto the route), and does not yet have a ticket.

The other thing to note is that magic logins are indexed by email. So one address could technically be the same for BOTH github AND discord logins, if the two refer to the same email address. That complicates the question of "which icon to display?

[masvelio]

Here I want to exclusively talk about icons that are part of User Story 1.

• First of all I need you guys to agree on one solution because @zakhap is suggesting to "use the community icons that we currently use next to the addresses on the editProfile page". @meeshlin wants to use custom chain icons defined in figma.
• If we choose to go with Zak's solution then this probably be simple (as it is already used in the code). If we choose to go with Meesh's proposition, I have some questions here.
  • I would say again that we should have a defined list of supported icons. I was looking at the code and we can use Address.chain.base for cosmos, substrate, ethereum, near, solana. In this case we are missing substrate and solana icons @meeshlin. Correct me if I am wrong @zakhap but Polygon and Polkadot are not needed?
  • Another set of icons are socials. Currently in the code I can't see how we could identify if this address if from discord, twitter or github. All of them have propertywalletId: magic. Same for email/google authentication. @jnaviask provided some suggestions how we can handle it so the question would be now @zakhap what should be the scope of the v1 and if we want to do any FF?

For now I am gonna work on UI components so then when we will have the decisions, swapping proper icons will be easy.

[meeshlin]

@masvelio @zakhap

User story 1

All icons can be found here: https://www.figma.com/file/yCUKk46hg9Fy3EXGkSoaKT/%F0%9F%9A%A7-Foundation?type=design&node-id=709%3A120&mode=dev

Do you need me to export them all in SVGs?

User story 2

@meeshlin How would you like to handle mobile? In my opinion, we should simply have an option in the mobile menu for each of the icons that are hidden. Explore being the only new option there, it could easy just be added to the list of mobile options.

For native mobile apps, you want to avoid dropdowns as much as possible—there are many solutions to this (ex. bottom sheet). Native apps use different patterns entirely for modals, dropdowns, and more. This is why you can't "rip and replace" an mWeb responsive experience to native mobile. However, in social apps, these navigational elements are exposed as a side nav. Refer to how this is designed in Reddit. You tap the user avatar and it exposes a right slide-out component.

[zakhap]

Being that we do not currently collect the wallet for addresses (re: @jnaviask's comment), we should probably default to the community icons for the moment to unblock this work.

As we continue to work toward clearing up our domain model of identity (addresses, login, etc), we can continue the work there with collecting the wallet and showing the wallet icons. This will be later work.

As for mobile menus, that is out of scope for this ticket.

[meeshlin]

Community icons can lead to more issues, the purpose is to show context in regards to the address and how the user logged in. An address can be tied to numerous communities, so showing the community icon doesn't serve a clear purpose here.

The only other solution I see that makes sense, which will lead to design debt, is not showing any icon at all.

@jnaviask @zakhap @masvelio

[zakhap]

That is fine. Let's not include an icon next to the address.

[jnaviask]

Can we make a follow-up ticket to add icons, once #4574 is implemented? @zakhap

[masvelio]

I will start with work on UI component first and make the PR out. Then will handle the logic hookup

[masvelio]

@zakhap

1. Asked already but did not get an answer. Can those items that are marked as Signed out be clickable? If yes, what happens if I click it?

   

2. Currently we have a case that if you do not have address that is based on the community you are watching, you can see the NO ${chainName} Address instead of the join button, which opens up login modal on click. I can't see something similar in the new designs. What we want to do about this scenario?

3. Is there any example in the figma, how icon button should look like with the default/hover/click state? The description is not super clear for me, especially that the icons on the designs have size of 24px, not 16 as described.

All icons are 16x16px within a container with a 4px padding all around and a 6px radius for hover states. Each component will show up as 24x24px with the added padding and each icon button is separated by a spacing of 8px. Hover state: The icon becomes Neutrals/600 with a background (entire container with the 6px radius) of Neutrals/100

[masvelio]

@meeshlin

The design of the top navbar is missing the state when the user is logged out. Currently, it looks like this

I am talking here specifically about the Person & Log In button in right hand side. Should this be unchanged or you want to update the icon/copy here?

[meeshlin]

@masvelio

1. Asked already but did not get an answer. Can those items that are marked as Signed out be clickable? If yes, what happens if I click it?

Yes, if you click it it'll open up the login modal so the user can reauthenticate/sign to get back into their account. Think of the Gmail experience when you have numerous emails. You can see when a user is logged out, but it's still connected to the account.

2. Currently we have a case that if you do not have address that is based on the community you are watching, you can see the NO ${chainName} Address instead of the join button, which opens up login modal on click. I can't see something similar in the new designs. What we want to do about this scenario?

There should be no button in the top nav, it is now going to be within the window in the secondary navigation for when a user is within a community (secondary left nav). It was previously added for a different solution, but now it is within the context of a specific community. Not sure what's going on here as a button isn't meant to be informational...which is what's happening here. It can be if you click on it and it becomes a status, but that's not what's happening here...?

3. Is there any example in the figma, how icon button should look like with the default/hover/click state? The description is not super clear for me, especially that the icons on the designs have size of 24px, not 16 as described.

Good question. I'm still sorting out icon buttons, so please build this as is as icons can be 16px, 20px, and 24px. I created a Loom for the hover state, which is linked here. You can also see it in Figma.

When you hover over an icon button, there's a fill of Neutrals/100 with a 6px radius.

4. The design of the top navbar is missing the state when the user is logged out. Currently, it looks like this. I am talking here specifically about the Person & Log In button in right hand side. Should this be unchanged or you want to update the icon/copy here?

This shows the Common displayName, always, which is above the collection of linked addresses hierarchy-wise. It's not meant to reflect anything about linked wallet addresses or social logins, just the Common displayName of the user. So, even if they are logged out of an address, they should still be logged into Common. Feel free to confirm or add to this, @jnaviask.

[jnaviask]

This shows the Common displayName, always, which is above the collection of linked addresses hierarchy-wise. It's not meant to reflect anything about linked wallet addresses or social logins, just the Common displayName of the user. So, even if they are logged out of an address, they should still be logged into Common.

@meeshlin I believe @masvelio is asking about designs for the fully logged out state, not when a user is in a logged in but not-yet-joined state within a community (which, as you correctly note, should still reflect the user's profile information regardless of address status).

[meeshlin]

If a user is completely logged out, the name component along with the Log out icon button will be replaced with a small, primary button that says Login.

• Figma prototype
• Figma dev mode

@masvelio

[masvelio]

According to our latest agreements with @jnaviask and @zakhap, the current architecture of the app does not allow us achieve all desired behaviour prepared by the design team at this moment.

User Story 1

• user dropdown with addresses will work similarly as now, meaning, that we will display only activeAccounts (those addresses that have joined this particular community) instead of displaying all connected addresses as in the designs
• this work is ready on raymond.react-session-keys-on

User Story 2 & 3

• no problems here, everything is ready on raymond.react-session-keys-on

@jnaviask @CowMuon considering this ☝️ I am wondering if we can close this ticket to make a session-keys project a bit more cleaner?