feat: Pressable Group Updates #927
Conversation
|
|
||
| // Group Updated Message | ||
| group_name_changed: '{{name}} changed the group name to "{{newValue}}".', | ||
| group_member_joined: "{{name}} joined the conversation", |
There was a problem hiding this comment.
@covrter This string has always felt that it's missing an explanation of how they got into the group. I think WhatsApp/Telegram/Signal all use variations of "{{inviter}} added {{joiner}}" for direct adds and "{{joiner}} joined via invite link". Should we do this too?
There was a problem hiding this comment.
I think that's valuable to include the inviter, because it communicates trust — do we have the data handy?
It does again raise the question of when the "join" happens — if I'm added by a non-consented contact "badboy", I would not expect to see "badboy added andrew" until I consent to join the convo. I might expect for "badboy invited andrew" to appear in the chat, and then when I consent "andrew joined" to appear. (This creates accountability for inviting people in, bc the group can see it.) Does that feel right?
Either way this is its own task :)
Telegram example for my future reference
There was a problem hiding this comment.
We do have the information readily available for who added who (whom?)
But the other members of the group do not know if/when a different user "approves" (currently labeled as joins) the group
There was a problem hiding this comment.
just riffing here, and this would be out of scope for now, but could the approval consent message be presented as a group update message?
There was a problem hiding this comment.
Do you mean the consent popup? "Do you want to join this group?"
There was a problem hiding this comment.
It triggers a consent message, but that's on a different topic that other users in the group could not decrypt themselves (I cannot see your consent preferences)
The app can trigger some custom content type, but I think that's getting close to concerns with privacy
There was a problem hiding this comment.
Ah, right. What is the privacy concern with using a content type message?
There was a problem hiding this comment.
Exposing consent of a group to the entire rest of the group.
If you "accept" a group, and then the app sends a message to tell everyone you have consented to the group might be a little weird
Unless we avoid showing the Group Updated messages and only show the Converse Group Consent message
There was a problem hiding this comment.
I'm probably missing something, but that seems desirable. Group membership is already public to group members, and group consent creates a useful division between "invited" and "joined". We should check how other apps handle.
/cc @covrter
There was a problem hiding this comment.
yeah we would need to be mindful of how we are labelling these things
If Converse is relying on that, we need to run through all previous messages to see who's "consented" to the group, which will likely not be a complete list unless you are the creator of the group
|
I just want to ensure these UI/UX changes are P0 or maybe P1, since we’ll redo most of it later with the design system. Also, the tests will likely break after refactoring, making things harder to refactor. So my suggestion would be to not do any tests for now. |
|
@thierryskoda I'll stop with component tests, but we need to find a balance between new features and introducing the design system |
Added handling when pressing a display name in the group updated messages
Fixed tsconfig Added util to create text styles Updated Chat Group Updated message to match design system Added ParsedText component
alexrisch
force-pushed
the
ar/pressable-group-updates
branch
from
6060c63
to
a64e62d
Compare
|
@thierryskoda Updated with the design system: |
Added handling when pressing a display name in the group updated messages