Topic muting/unmuting/following UI redesign #1078
Labels
a-design
Visual and UX design
Milestone
Comments
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Jan 29, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Jan 30, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Jan 30, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Jan 30, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Jan 30, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
PIG208
pushed a commit
to PIG208/zulip-flutter
that referenced
this issue
Jan 31, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
PIG208
pushed a commit
to PIG208/zulip-flutter
that referenced
this issue
Feb 4, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
PIG208
pushed a commit
to PIG208/zulip-flutter
that referenced
this issue
Feb 5, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
PIG208
pushed a commit
to PIG208/zulip-flutter
that referenced
this issue
Feb 5, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
PIG208
pushed a commit
to PIG208/zulip-flutter
that referenced
this issue
Feb 6, 2025
Zixuan points out that this could be helpful here: zulip#1301 (comment) This probably makes sense to not do until zulip#1078, when we'll have separate buttons for each of the four possible user-topic states. This same comment *could* be added on various other action-sheet buttons. But realistically it wouldn't make a difference on any that we've implemented so far: all the others (besides this and ResolveUnresolveButton) are on the message action sheet, and they're all about actions that would only be done by the self-user -- starring, marking as unread, etc. -- so they can't be done without the user's awareness, and will rarely be done anyway because you'd need to do it on a different client.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a follow-up to #348, which aims for implementing a design matching the legacy mobile app. That doesn't support some state transitions, though.
See #1041 (comment) for what we might do in this direction. Before we can open a PR for this, we should finalize the design first.
The text was updated successfully, but these errors were encountered: