Profiles - UI/UX redesign #508
Labels
No labels
Blocked
Bug
Documentation
Duplicate
Enhancement
Good first issue
Help wanted
Idea
In progress
Invalid
Major feature set
Packaging
Question
Soon
UI/UX
Upstream
You're dreamin'
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nostr/gossip#508
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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!
My only feedback is don't wait for feedback. Run fast and break things.
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)
@mikedilger @bu5hm4nn
display_nameisn't a standard (NIP-01) field; the wizard doesn't offer to add/edit thedisplay_name, but the it is shown, if exists, by overwriting thename, 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.
@bu5hm4nn
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.
Refer to the new https://github.com/nostr-protocol/nips/blob/master/24.md
I've never liked
display_namebecause it confuses people. If I have to type theirnameto tag them but I see adisplay_nameall the time with potentially hard-to-type unicode shit in there, I'm not even going to know what theirnameis. So at the moment gossip only showsdisplay_nameas the title of the Person page, and it usesnameeverywhere 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.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_nametoo much. Compared to the current situation my proposal moves the weight toward thename, and makes more coherent the overall user visualization.I've never liked
display_nameeither and if I could choose I would nuke it out of existence. The other weird fields are even worse.So in trying to condense all the opinions above, how about doing petname > name > display_name > npub?
I thought I did something like that but I don't see it in names.rs. So ok.
Pushed a restyling.
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.
bug: The LUD16 QR is showing the value of the Website.
Fixed.