Closed dmnyc closed 4 months ago
This is great feedback @dmnyc 🙏
Bringing up with team
Thanks. The reference note is:
note1y30778c7pxf7jcct2dykl7gzq7f5p5alj5cqdl686ku4wtl0njwqts6xy3
Reply with the most reply depth:
note169hacwg8q5wc3j7757wd2j69s5x6fqk8hk3ep0ykyftan0dxgrmqtuc35e
Love this! 🔥
@danieldaquino
@danieldaquino
Thank you @alltheseas. @alltheseas, @jb55, should I add this to the new sprint?
@dmnyc what do you think
I really don't like this nested thread thing that keeps indenting. people actually like that?
In the early versions of damus I had a view that flattened an entire thread into a chat view, where replies were simply quote replies like on telegram. I thought that was a great way to follow the conversation of an entire thread. People didn't like it because it was confusing when there was two view so I abandoned it, but I really don't see another way cleanly other than doing what twitter does by unrolling conversations and then you just keep scrolling to read all interactions.
I would like to have an agreed upon design before anyone starts working on this.
I agree, the best way to expose all notes in a conversation would be ideal. It's cumbersome and easy to lose track of replies to a post when you force the user to go back and tap on each individual reply to see further replies.
On Wed, Mar 13, 2024 at 5:26 AM William Casarin @.***> wrote:
@dmnyc https://github.com/dmnyc what do you think
I really don't like this nested thread thing that keeps indenting. people actually like that?
In the early versions of damus I had a view that flattened an entire thread into a chat view, where replies were simply quote replies like on telegram. I thought that was a great way to follow the conversation of an entire thread. People didn't like it because it was confusing when there was two view so I abandoned it, but I really don't see another way cleanly other than doing what twitter does by unrolling conversations and then you just keep scrolling to read all interactions.
I would like to have an agreed upon design before anyone starts working on this.
— Reply to this email directly, view it on GitHub https://github.com/damus-io/damus/issues/1126#issuecomment-1993909811, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3YJQZ6CGHNGHI2SYA7DQLYYALWBAVCNFSM6AAAAAAYA2PLJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTHEYDSOBRGE . You are receiving this because you were mentioned.Message ID: @.***>
Basically what I'm hoping to see is something like this thread where second level posts get shown, but there's also a "Show replies" link to expose lower-level posts.
Thank you for sharing the screenshot - I think this is what @jb55 had in mind when mentioning a preference for inline replies.
Going through Rune's thread carries friction
It's very difficult to navigate through.
Should follow twitter approach - just scroll down. No need to tap to see replies.
cc @danieldaquino
@jb55 references chatroom, and produces mea culpa " not a designer "
4ac3da76121eebcf794b7ac5e8b68bbebcdf88eb
@jb55
The more i think about it i think there really should be two thread modes: one for reading a long chain of replies within a thread and one for when you first open a thread. I said this before above but just wanted to reiterate it.
For example, I’m having a long reply chain within a thread here:
This is pretty much perfect ux for this scenario. I’m having a single subthreaded convo with a single individual, having the reply after reply laid out removes any other noise in the thread.
In the case where there aren’t many of these long reply chains or for small or new threads this is not the best ui, since you have to click around a lot.
I still think the simple heuristic is from timelines, open into threaded chat, but in notifications open up what we have today. Will experiment
@danieldaquino
What if we have the threaded chat view we have on the mockup, but then we can activate the “chain view” by long pressing a note, which will hide all other notes that are not part of the chain from root to that specific note?
@jb55 tg example
@danieldaquino
Ahh I see
Yeah, similar to what I was thinking. The only differences between that and what I have in mind are:
- Use long press or another interaction that is more obvious/visible
- Collapse all other chat bubbles within the same view instead of opening a new page
maybe this is called branch vs tree view
a, b, c, d, e are messages (not people)
@jb55
my only concern is that most people will never find the long press
Can tipkit fix this?
@jb55
tipkit is a bandaid
@danieldaquino
Maybe some haptic or visual feedback that starts immediately and builds up over the course of a few seconds, to make users naturally discover it?
A bit how the “record voice message” feature works on Signal or WhatsApp
If you tap the microphone icon, it will give you a tip
@robagreda
Tap should work, is more natural.
@jb55
btw, I literally had it before in damus where tap would switch between chat and standard thread view. people were horribly confused.
maybe we can improve the ux on this so its less confusing
basically you would open a thread like normal, then tapping on the note again would bring you to the chat view. I don't think there are many apps that do this so it was a bit jarring for people
Made a draft 85% similar to the Figma design: https://github.com/damus-io/damus/tree/%231126_option_1_v1
This should be enough to get us started with testing
starting to think we should use long press to reply,repost,like,zap in this view? otherwise the reply bar needs to be offset -y pixels, made smaller, and reduce the drop shadow like the design. getting there though. we should also reduce the border-radius, I very strongly dislike "bubbly" looks of things. in roberto's design the border radius was much smaller and more tolerable.
we should use long press to reply,repost,like,zap in this view
If we do this, there should be intuitive hints/tipkit/signal type guidance on this slightly hidden feature
Its actually a pretty common interaction in imessage, so maybe its ok
imessage | longpress |
---|---|
Also swipe to reply:
https://github.com/damus-io/damus/assets/45598/537c6bda-5eec-4ea1-9783-6bc9b226aff6
Its actually a pretty common interaction in imessage, so maybe its ok
Also swipe to reply:
Good points. Lets see the feedback in practice.
Also I just discovered you can double tap on an iMessage to open the reaction menu, and a reply option
Also I just discovered you can double tap on an iMessage to open the reaction menu, and a reply option
I had no idea lmao
Could we add all three:
1) swipe to reply, 2) double tap to open reaction menu, with an option to reply, 3) long hold to open reaction menu
if we can save space without littering action buttons on every post that would be ideal
swipe to the left reveals the timestamp
signal also does both of these swipe interactions
no double tap on signal. swipe right reveals a detailed message view. could this be useful real estate for nerds - e.g. JSON view?
Thanks for the feedback everyone!
Updates today:
Things left to do for improvement:
New WIP branch: https://github.com/damus-io/damus/tree/%231126_option_1
Screenshots:
What's the best practice on negative space / spacing between chat bubbles @robagreda ?
What's the best practice on negative space / spacing between chat bubbles @robagreda ?
I think in the mockups I have used a default padding between bubbles, but if a bubble has likes, zaps, replies, etc the spacing between bubbles increase to leave some room to breathe. This is a thing to improve as well @danieldaquino other than that, it's looking amazing, falling in love with this implementation. 😍
Add emoji reactions to the context view (I did research on this today, and unfortunately it does not work out of the box with SwiftUI, but I found a library that can help us do it, I will try to integrate it)
I tried using the library, but it looks like this kind of UI pattern will take a large amount of time and effort to get it working well (mostly due to the way UIKit integrates with SwiftUI)
So I started looking for alternative ways to allow interaction with each notes that are simpler to integrate and deliver an equivalent level of UX.
I found that SwiftUI compact popovers can be a great alternative. Here is a rough draft of how it might work (This is not refined yet)
https://github.com/damus-io/damus/assets/24692108/9f795e80-6973-4b7c-81be-198b991b8424
I will use this for now as I believe we can create a great UX/UI pattern with this while reducing the development cost of this (and probably avoid a ton of future bugs by avoiding UIKit integration complexity)
@robagreda any tips on how I could improve this popover design? @jb55 @robagreda any other thoughts regarding this?
I see you are using a mouse in the simulator. Logical move.
I wonder how the above popover works when you are thumbing on an iPhone.
Right now when you long press on a bubble you must also display the note actions displayed here. So besides the reactions(like, zap, repost, reply) we should also display this!
Not sure if we should display the number of emojis you have here, that's why you have a default emoji already se, maybe we can have a + emoji so you can pick another from the emoji keyboard. Any thoughts @danieldaquino @jb55 ?
I wonder how the above popover works when you are thumbing on an iPhone.
@alltheseas, good point, I will test that before pushing the internal testflight prototype
Right now when you long press on a bubble you must also display the note actions displayed here. So besides the reactions(like, zap, repost, reply) we should also display this!
Good point @robagreda, I forgot to show that! Here are the two interactions configured:
https://github.com/damus-io/damus/assets/24692108/f528ad00-9eb4-4841-87d6-36c2ff911093
Not sure if we should display the number of emojis you have here, that's why you have a default emoji already se
@robagreda, I am currently showing the emojis the user has configured in settings. It's a similar concept to when we press and hold the reaction button on the App Store version (or at least it was before we replaced that small emoji selector with the full emoji selector), except it now shows right away without the long press on the "shaka button"
I was thinking of leaving those emojis hidden until the user long presses the default emoji, but then it takes two or three clicks to get there, would that be too much friction for reactions?
maybe we can have a + emoji so you can pick another from the emoji keyboard.
I like this idea! I will implement that
@jb55, @robagreda, @alltheseas, I added an internal TestFlight build containing the latest prototype: 1.9 (7)!
Please note that there are still lots of little refinements to be made, this prototype is just good enough to be "feature complete", so that we can ask ourselves the question "Does this new UX design concept/layout feel more intuitive in practice? What can be improved?"
Please let me know how the experiment goes for you!
Interesting. Test on this thread
I enjoy not having to click to go through a 15 note thread. Need a few days to adjust to the new design.
On Mon, Jun 10, 2024 at 10:37 PM, Daniel D’Aquino - notifications at github.com @.***(mailto:On Mon, Jun 10, 2024 at 10:37 PM, Daniel D’Aquino - notifications at github.com < wrote:
@.(https://github.com/jb55), @.(https://github.com/robagreda), @.***(https://github.com/alltheseas), I added an internal TestFlight build containing the latest prototype: 1.9 (7)!
Please note that there are still lots of little refinements to be made, this prototype is just good enough to be "feature complete", so that we can ask ourselves the question "Does this new UX design concept/layout feel more intuitive in practice? What can be improved?"
Please let me know how the experiment goes for you!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I got some great feedback from the team trying it out.
There are many things which are bugs and I am keeping track of them.
But before I get to them there seems to be some very important feedback/uncertainty on:
I will make some different iterations of it for us to test until we are generally happy or one of them makes sense.
I got some great feedback from the team trying it out.
There are many things which are bugs and I am keeping track of them.
But before I get to them there seems to be some very important feedback/uncertainty on:
- The interactions with the chat bubbles (e.g. popover, the little bubble on top of the chat view, the context menu, etc).
- When to show/hide reply quote views
I will make some different iterations of it for us to test until we are generally happy or one of them makes sense.
Came up with a new prototype that I believe improves these significantly! I will put it on TestFlight!
On Wed, Jun 12, 2024 at 07:16:10PM GMT, Daniel D’Aquino wrote:
I got some great feedback from the team trying it out.
There are many things which are bugs and I am keeping track of them.
But before I get to them there seems to be some very important feedback/uncertainty on:
- The interactions with the chat bubbles (e.g. popover, the little bubble on top of the chat view, the context menu, etc).
- When to show/hide reply quote views
I will make some different iterations of it for us to test until we are generally happy or one of them makes sense.
Came up with a new prototype that I believe improves these significantly! I will put it on TestFlight!
The popover is gone now, is that intentional? To reply you seem to have to navigate to the non-chatview and there is no way to go back, so you lose your spot.
Most refinements are in!
Opened a tentative draft PR: https://github.com/damus-io/damus/pull/2299 Published internal testflight: Build 1.9(11)
Still TBD:
Set patch via email! https://groups.google.com/a/damus.io/g/patches/c/IPlc6o6A33Y
Known issues were documented in the commit. If we merge the changes, we should create tickets to address them
@jb55 please let me know if you need anything!
what happens Threads with multiple replies are extremely difficult to follow. Scrolling does not load additional messages, and replies are invisible to the user unless the user taps to view them.
If there are multiple replies to a single reply, they create separate reply chains that one must go back and continue tapping again on each deeeper reply.
what I think should happen If there are a small number of replies to a message, they should be automatically visible when scrolling down, or refresh once the user reaches the bottom of the screen. A "view replies" button chould be added beneath replies if necessary to improve conversaton flow.
The video below shows the difficulty of viewing just a single conversation involving 2 users that takes 15 taps to see all of the messages. https://nostr.build/p/nb8281.mp4