Nostr

Yes. Would love to join efforts.

so as part of NDK I plan on having UI components, probably unstyled since I don't want nostr apps to become boostrap-ified (i.e. what happened when twitter open sourced the boostrap CSS framework); the whole internet started looking alike.

I want NDK to provide unstyled components that deal with all the annoyance (i.e. parsing/replacing mentions)

I think a good follow-up would be for designers to create styled-versions of these components so that app makers can quickly glue them together.

Kinda like what Skeleton UI framework does but better 😅

#[3] What would help in order to layer components easily on NDK?

nothenry 2y ago

Idk if this would be considered “styled”, but a virtualized, infinitely scrollable feed would be nice

Yeah, good idea

47 2y ago

Good call avoiding the css contagion of bootstrap and the like.

What would be the most useful UI design components for #nostr developers?

#opendesign

JeffG 2y ago

Absolutely profiles and threaded conversations.

Thanks, JeffG. ☑️🗒️

I propose we have a nostr nests about this with ndk, and open invite to nostr devs

That’s a good idea, elsat.

zap/payment components!

ie make payments frictionless and intuitive for folks new to btc/ln. this is the power of the nostr network and deserves critical design thinking

I proposed a few days ago using #introductions as part of the onboarding flow to get the first few sats after writing a worthwhile intro

interesting idea! wonder if a crowdfunded greeter bot would be feasible or if it would just get gamed 🤔

brb

On #damus team has an onboarding feature request +design ready: immediately upon profile creation new user sees draft post including intro yourself prompt including #introductions tag.

If bot is done incorrectly it could turn off new users who might experience a bot interaction as their first nostr interaction. New user might think there are only bots, and there are no real people on nostr. This is especially true if onboarding mechanisms are not improved for finding other people.

agreed, was exploring a zapping idea

I think the onboarding experience needs to be thought-out beyond damus (i.e. damus' UX should be considered as one piece of the whole onboarding experience)

what I'm saying is that we need tooling to discover/welcome high-quality #introductions posts

imo, the onboarding flow should prompt users to write in the introductory post something significant about what they are interested in to try and connect those users as quickly as possible to what they care about and not just dump them on the ever-present #bitcoin topic

Agree.

Working nip-50 search, follow hashtag, hashtags in profiles discoverable by search as user profiles interested in a certain topic move in this direction.

“Topics” discovery without relying on hashtags is not explored afaik. Being wary of algos, this more detecting topics in notes, and classifying said note under said topic.

wait, #nostr is the orange pill to #bitcoin ?

🌍 👩‍🚀 🔫👩‍🚀

ofc!

⚡️⚡️⚡️ zaps are a foundation of a value4value culture

regardless of your understanding or thoughts on bitcoin, onboarding flows should address zaps, and give people that choice with the least amount of friction

Zaps onboarding is needed, and pending definition. Both damus, and across nostr

💯 we need to help people discover niches based on their interests, so they can dive in and express themselves…

We don’t need one perfect solution, but an amalgamation of many different pieces that support someone’s experience of #nostr, no matter which client they are using.

Every improvement helps, and can get tied in to other efforts, including introductory posts…

This is where that bridge between design and development should be built, translating development into design.

If there’s development of lists or groups of people to follow, can we make that part of the onboarding process?

If there’s stronger search and data discovery based on topics, hashtags, trends, relays… how we can we help make search intuitive? how do we display search suggestions?

If there’s other back-end capabilities that are already getting built to help people discover #nostr, how can we, as designers, help you display that?

We need to have more of these kinds of conversations to guide the designing journey to what’s most needed.

This is what nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj is working on

I am all for this kind of discussions; a lifetime ago I used to do user onboarding consulting; it's a topic I'm extremely passionate about (I know, my apps don't show it... one thing at a time! 😂😅)

Thank you for your time & feedback.

From your wide perspective of #nostr development, which aspect of onboarding needs the most help?

How can we help with NDK’s design layer?

Thanks, ben. ☑️🗒️

Avatars

Name

Event cards (w/user+event tags embeds)

User cards

Boost/quote button (displays count)

Zap button (zaps + displays zapped amount)

Lists

Tracks (kind 31337)

Thanks, Pablo. ☑️🗒️

jonb 2y ago

Definitely like this coordination! Conversation on the onboarding piece is ongoing in this doc by nostr:npub1kuc70777tsvj67fl75s2dmy376t97hv05xmyuyshzzy6vhj5q5jstv0eyw: https://docs.google.com/document/d/1GUNGN7wTr3tNBOE3eCy0T3BTyKhrDay2vd8a0b7ryBk/edit?usp=drivesdk

Thank you for sharing, JonBasa.

I made a few notes on that doc.

Note that I see quite some disagreement with Gene (sorry, don't know the npub, but would be nice to tag him here)

I don't think this disagreements need to be bridged. Likely, the combined result will be worse that executing exclusively on either direction.

I want to see multiple onboarding apps/widgets, competing and implementing all kinds of weird visions, not some generic, appease everybody thing.

Would be nice if the onboarding widgets generated a tag so that we could get some stats on churn from each onboarding widget + app.