Profiles - UI/UX redesign

[dtonon]

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.

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.

For the QR codes we can use the same logic:

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

I wait your feedbacks!

[mikedilger]

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

[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)

[dtonon]

@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):

@fiatjaf I would like your opinion on this matter.

[dtonon]

@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]

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]

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]

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]

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)
        }
    }

[mikedilger]

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

[dtonon]

Pushed a restyling.

[mikedilger]

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]

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

[dtonon]

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

Fixed.