Customization through deep links #105
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coracle/flotilla#105
Reference in New Issue
Block a user
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?
This might be a better way to give community organizers the ability to customize Flotilla while users still can use the vanilla apps. Ideas:
Hi @hodlbod. I'm interested to work on this idea. Can you assign this to me?
Sure thing
Hi @hodlbod. I was working on this issue and looking at how other relays and deep links are handled in the codebase. Should the deep-link updates be best-effort, or should a single relay rejection or rate-limit failure block the entire customization flow?
I think probably what would be best is to show users any errors that come up and allow them to abort or ignore them and continue. Users might also want to customize, so if a given relay is blocked but there are two other valid relay, they should be able to remove the blocked one and proceed with the others.
Sure. I'll keep this in mind. Thanks :)
A first pass is in progress at #169, but I think we need to do some design work on the dialog, since users aren't going to know what a lot of this means. Maybe a multi-dialog process with UI tailored to the customization being made would be the right approach. Any takers?
Hii @hodlbod & @bhavishy2801 ,
Really appreciate the work done on this so far!
While going through the issue and current PR, I felt the customization flow could be more intuitive. Right now, presenting everything as bullet points makes it hard to distinguish each action and understand its impact.
It might help to group different actions (relays, follows, theme, etc.) and add brief context for clarity. A multi-step dialog flow could also guide users through each change, making the experience more understandable and building confidence before applying updates.
I had a couple of clarifications:
I’d love to explore design directions for this - if this approach aligns, could you please assign the issue to me?
Yes, I agree, multiple steps per section, or even per item (follow/community/relay etc) would be good. Users should be able to selectively apply or dismiss customizations. Plenty of information should be displayed; for joining spaces we should probably use existing join dialog functionality to probe connectivity/auth as well. So be sure to draw from patterns that already exist in the software.
@hodlbod
I've designed the first iteration for the deep link customization flow, tried making the experience more descriptive while keeping it intuitive.
Implementation
Suggestion
Figma File
Prototype Link
Would love your feedback on this direction - happy to iterate further!
Looks pretty good, but I think it's important to include details about what relays/blossom servers etc are being added. The join space dialog includes lots of good information, we should do the same for the others.
@hodlbod Completely agree with the point of adding more configuration details for relays & blossom server.
I've incorporated these changes in the updated design.
Implementations:
Outcomes:
Prototype Link
Better, thanks. Let's remove the link which opens the relay selection screen, that's a little too deep for this use case. Also, just show a separate screen for each relay/server and remove the "x dm relays" purple text. We also shouldn't support profile editing via deep link, that's a security problem waiting to happen. Moving this to dev.
Updated the flow as per the feedback. Does this align with what you had thought of?
Please let me know if there are any further refinements required.
Prototype Link
Yep, looks great!