Profiles - UI/UX redesign #508

Open
opened 2023-09-23 08:37:22 +12:00 by dtonon · 13 comments
dtonon commented 2023-09-23 08:37:22 +12:00 (Migrated from github.com)

As requested by @mikedilger I opened this issue to share some ideas about the restyling of the profile view. I tried to keep the redesign as simple as possible, using only plain components that are already available, to increase the UX without overburdening the development.

Screenshot 2023-09-22 alle 22 03 16

The dot on the top-right of the picture can have different colors:

  • Blu (accent color): Followed
  • Green (secondary color): Priority
  • Orange (complementary): Muted

This element should make clear the user status, and so we can keep the "switch buttons" simple, without playing too much with dimmed colors and labels, which are always complex to balance. We can also add a little icon or the status first character (F, P, B) inside the circle and add a hover popover that explains the meaning.

The relay section probably needs more visibility, and more details.
@nbenaglia is working in https://github.com/mikedilger/gossip/pull/507 to add followers and followed to the profile, so this point also needs to be taken into consideration. I will work on this.

Another critical point is how to copy-paste the texts. If the classic selection is not possible (@bu5hm4nn? ), a solution could be to fire the copy when the user clicks anywhere on the block, but we need a proper way to signal the function and give feedback; a hover effect on the block (background + cursor), maybe with a little icon on the corner too, should work fine. When the user clicks, the icon can also change to a confirmation symbol.

Screenshot 2023-09-22 alle 22 21 02

For the QR codes we can use the same logic:

Screenshot 2023-09-22 alle 22 25 20

But this opens a modal with the content and the copy handle:

Screenshot 2023-09-22 alle 22 27 13

I wait your feedbacks!

As requested by @mikedilger I opened this issue to share some ideas about the restyling of the profile view. I tried to keep the redesign as simple as possible, using only plain components that are already available, to increase the UX without overburdening the development. <img width="933" alt="Screenshot 2023-09-22 alle 22 03 16" src="https://github.com/mikedilger/gossip/assets/89577423/fafbac88-8e11-4337-9dbf-92605f867f7e"> <br/><br/> The dot on the top-right of the picture can have different colors: - Blu (accent color): Followed - Green (secondary color): Priority - Orange (complementary): Muted This element should make clear the user status, and so we can keep the "switch buttons" simple, without playing too much with dimmed colors and labels, which are always complex to balance. We can also add a little icon or the status first character (F, P, B) inside the circle and add a hover popover that explains the meaning. The relay section probably needs more visibility, and more details. @nbenaglia is working in https://github.com/mikedilger/gossip/pull/507 to add followers and followed to the profile, so this point also needs to be taken into consideration. I will work on this. Another critical point is how to copy-paste the texts. If the classic selection is not possible (@bu5hm4nn? ), a solution could be to fire the copy when the user clicks anywhere on the block, but we need a proper way to signal the function and give feedback; a hover effect on the block (background + cursor), maybe with a little icon on the corner too, should work fine. When the user clicks, the icon can also change to a confirmation symbol. <img width="925" alt="Screenshot 2023-09-22 alle 22 21 02" src="https://github.com/mikedilger/gossip/assets/89577423/8592be59-aa28-415a-95eb-b2d8a8f63b19"> <br/><br/> For the QR codes we can use the same logic: <img width="923" alt="Screenshot 2023-09-22 alle 22 25 20" src="https://github.com/mikedilger/gossip/assets/89577423/7b40a363-aa50-48cc-bc7b-ea0f44a26811"> <br/><br/> But this opens a modal with the content and the copy handle: <img width="933" alt="Screenshot 2023-09-22 alle 22 27 13" src="https://github.com/mikedilger/gossip/assets/89577423/069b719b-3a22-449a-8054-2f98cd488b39"> <br/><br/> I wait your feedbacks!
mikedilger commented 2023-09-25 18:23:23 +13:00 (Migrated from github.com)

My only feedback is don't wait for feedback. Run fast and break things.

My only feedback is don't wait for feedback. Run fast and break things.
bu5hm4nn commented 2023-10-12 10:30:02 +13:00 (Migrated from github.com)

Just noticed we don't have a Zap button on the profile yet, dearly need that one (I'm trying to zap a bot that has no notes)

Just noticed we don't have a Zap button on the profile yet, dearly need that one (I'm trying to zap a bot that has no notes)
dtonon commented 2023-10-22 01:07:22 +13:00 (Migrated from github.com)

@mikedilger @bu5hm4nn display_name isn't a standard (NIP-01) field; the wizard doesn't offer to add/edit the display_name, but the it is shown, if exists, by overwriting the name, thus admitting its relevance to the name. I think it is ok to not ask for it, but for consistency we should just show it near the name, with less relevance. And maybe we can repeat the two values in the profile details to better clarity.
Finally on update we could remove the display_name if it is equal to name (often happens).

About not standard values, e.g. displayName, handle, username, full_name, probably is better to hide them to encourage the standard. We can show them only in the edit profile view, suggesting the user to delete them.

Proposal (inspired by the njump design):

image

@fiatjaf I would like your opinion on this matter.

@mikedilger @bu5hm4nn `display_name` isn't a standard (NIP-01) field; the wizard doesn't offer to add/edit the `display_name`, but the it is shown, if exists, by overwriting the `name`, thus admitting its relevance to the name. I think it is ok to not ask for it, but for consistency we should just show it near the name, with less relevance. And maybe we can repeat the two values in the profile details to better clarity. Finally on update we could remove the display_name if it is equal to name (often happens). About not standard values, e.g. `displayName`, `handle`, `username`, `full_name`, probably is better to hide them to encourage the standard. We can show them only in the edit profile view, suggesting the user to delete them. Proposal (inspired by the [njump design](https://njump.me/mike@mikedilger.com)): <img width="1279" alt="image" src="https://github.com/mikedilger/gossip/assets/89577423/91689292-21a2-488f-8b2c-e0ed56789a03"> <br/><br/> @fiatjaf I would like your opinion on this matter.
dtonon commented 2023-10-22 01:09:16 +13:00 (Migrated from github.com)

@bu5hm4nn

Just noticed we don't have a Zap button on the profile yet, dearly need that one (I'm trying to zap a bot that has no notes)

Yeah. I think we should open a new issue for this, because we need to create a new UI asking for a custom values (I'm thinking about a modal). And we can use the same one for the note zaps.

@bu5hm4nn > Just noticed we don't have a Zap button on the profile yet, dearly need that one (I'm trying to zap a bot that has no notes) Yeah. I think we should open a new issue for this, because we need to create a new UI asking for a custom values (I'm thinking about a modal). And we can use the same one for the note zaps.
mikedilger commented 2023-10-22 08:12:08 +13:00 (Migrated from github.com)

Refer to the new https://github.com/nostr-protocol/nips/blob/master/24.md

I've never liked display_name because it confuses people. If I have to type their name to tag them but I see a display_name all the time with potentially hard-to-type unicode shit in there, I'm not even going to know what their name is. So at the moment gossip only shows display_name as the title of the Person page, and it uses name everywhere else. I'm really not sure what to do, and I don't like that this got added by juggernaut renegade client authors without any discussion of the negative impact.

Refer to the new https://github.com/nostr-protocol/nips/blob/master/24.md I've never liked `display_name` because it confuses people. If I have to type their `name` to tag them but I see a `display_name` all the time with potentially hard-to-type unicode shit in there, I'm not even going to know what their `name` is. So at the moment gossip only shows `display_name` as the title of the Person page, and it uses `name` everywhere else. I'm really not sure what to do, and I don't like that this got added by juggernaut renegade client authors without any discussion of the negative impact.
dtonon commented 2023-10-22 08:45:30 +13:00 (Migrated from github.com)

I see my proposal is aligned to fiatjaf one: https://github.com/nostr-protocol/nips/pull/794#issuecomment-1732703125

I also never like the display_name too much. Compared to the current situation my proposal moves the weight toward the name, and makes more coherent the overall user visualization.

I see my proposal is aligned to fiatjaf one: https://github.com/nostr-protocol/nips/pull/794#issuecomment-1732703125 I also never like the `display_name` too much. Compared to the current situation my proposal moves the weight toward the `name`, and makes more coherent the overall user visualization.
fiatjaf commented 2023-10-22 10:11:57 +13:00 (Migrated from github.com)

I've never liked display_name either and if I could choose I would nuke it out of existence. The other weird fields are even worse.

I've never liked `display_name` either and if I could choose I would nuke it out of existence. The other weird fields are even worse.
bu5hm4nn commented 2023-10-23 15:51:12 +13:00 (Migrated from github.com)

So in trying to condense all the opinions above, how about doing petname > name > display_name > npub?

pub fn person_name(person: &Person) -> String {
        if let Some(petname) = &person.petname {
            petname.clone()
        } else if let Some(name) = person.name() {
            name.to_string()
        } else if let Some(display_name) = person.display_name() {
            display_name.to_string()
        } else {
            gossip_lib::names::pubkey_short(&person.pubkey)
        }
    }
So in trying to condense all the opinions above, how about doing petname > name > display_name > npub? ```rust pub fn person_name(person: &Person) -> String { if let Some(petname) = &person.petname { petname.clone() } else if let Some(name) = person.name() { name.to_string() } else if let Some(display_name) = person.display_name() { display_name.to_string() } else { gossip_lib::names::pubkey_short(&person.pubkey) } } ```
mikedilger commented 2023-10-23 16:59:53 +13:00 (Migrated from github.com)

I thought I did something like that but I don't see it in names.rs. So ok.

I thought I did something like that but I don't see it in names.rs. So ok.
dtonon commented 2023-10-25 05:47:29 +13:00 (Migrated from github.com)

Pushed a restyling.

Screenshot 2023-10-24 alle 18 45 27 Screenshot 2023-10-24 alle 18 45 42 Screenshot 2023-10-24 alle 18 44 04 Screenshot 2023-10-24 alle 18 39 50
Pushed a restyling. <img width="990" alt="Screenshot 2023-10-24 alle 18 45 27" src="https://github.com/mikedilger/gossip/assets/89577423/9bd5808f-2f2f-4029-8f8d-c817c274e1f6"> <img width="990" alt="Screenshot 2023-10-24 alle 18 45 42" src="https://github.com/mikedilger/gossip/assets/89577423/a2707f5a-93d0-4cd2-89e2-9553c67dfef5"> <img width="990" alt="Screenshot 2023-10-24 alle 18 44 04" src="https://github.com/mikedilger/gossip/assets/89577423/3d9ea880-a268-41a5-a0f3-0a1bfc82c93f"> <img width="990" alt="Screenshot 2023-10-24 alle 18 39 50" src="https://github.com/mikedilger/gossip/assets/89577423/3805ce66-49d5-4a6f-8910-b3c216285518">
mikedilger commented 2023-10-25 06:41:56 +13:00 (Migrated from github.com)

BTW I did the name fallback function in gossip-lib/src/storage/types/person2.rs::tag_name()
but we should probably drop the display_name() function, and change tag_name() to do it as @bu5hm4nn shows.

BTW I did the name fallback function in gossip-lib/src/storage/types/person2.rs::tag_name() but we should probably drop the display_name() function, and change tag_name() to do it as @bu5hm4nn shows.
mikedilger commented 2023-10-25 06:43:36 +13:00 (Migrated from github.com)

bug: The LUD16 QR is showing the value of the Website.

bug: The LUD16 QR is showing the value of the Website.
dtonon commented 2023-10-25 07:42:27 +13:00 (Migrated from github.com)

bug: The LUD16 QR is showing the value of the Website.

Fixed.

> bug: The LUD16 QR is showing the value of the Website. Fixed.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nostr/gossip#508
No description provided.