Allow muting topic from within topic narrow

[WesleyAC]

Currently, the only way to mute a topic in the app is to go to the stream view, and long press on the topic name. This involves possibly marking messages as read in the stream view, which is frustrating. Instead, the user should be able to mute a topic from within that topic.

The UX for this that makes the most sense to me is a long-press on the topbar (where the topic name is), which would pop up a "mute topic" option (the same kind of menu that long-pressing a message gets you). That's what I expected to work, and I've talked to one other user that expected that as well.

[chrisbobbe]

The UX for this that makes the most sense to me is a long-press on the topbar (where the topic name is)

Currently, long-pressing the topic in the top bar brings up a toast that shows the topic's full name, in case the topic was long and got truncated where it appears in the top bar.

I think an alternative interaction that does both things (shows the whole topic name, and lets you mute the topic) would be good! What do you think?

[chrisbobbe]

One thing I notice in the current behavior is that the touch target for the topic name is kind of thin, height-wise. The height is no greater than the height of the topic-name text. Not having changed the system font size from its default, I see that being less than 48px on my iPhone.

We have a goal of making touchable areas be "at least 48 x 48" layout pixels (doc, doc).

I'm not sure about the best thing to do about that here, if anything—especially since it's common for the width of the touch target to be greater, even much greater, than 48px.

On the other hand, I'm checking now and I don't think the stream name (which is always present just above the topic name, and quite close) has a touch target? For some reason I thought it did (I can check more closely when I'm back to my regular dev setup on a weekday). So maybe the topic name has enough elbow room for its touch target to extend through part of the stream name.

The thing to use to extend a touch target without altering the visual layout is the hitSlop prop on React Native's View component. You can see an example of using it in #4442.

[Gautam-Arora24]

@chrisbobbe I have a send a PR where I increased the touch target of MentionedUserNotSubscribed beyond 48px using hitSlopprop here.

I can also work on this area where I will increase the touchable area of the buttons to be "at least 48 x 48" layout pixels".

[gnprice]

Definitely agreed that we should have this! See also #3473, which was originally about unmuting a topic but also discussed this. When adding this, it'd be good to make "unmute this topic" available in the same spot in the UI.

One solution would be to put an "overflow menu", with an ellipsis icon, at the end of the app bar at the top of the screen. That's a standard Material Design way to handle a low-frequency action that applies to the screen you're looking at: https://material.io/components/app-bars-top (search for "overflow menu" to find the "Action items and overflow menu" heading.)

If we do that, the "stream info" action can probably get pushed down into an item in that menu -- I think going from a topic's message list to the stream info is also not an action that's real common or needs a high-salience UI.

[gnprice]

Currently, long-pressing the topic in the top bar brings up a toast that shows the topic's full name, in case the topic was long and got truncated where it appears in the top bar.

I think an alternative interaction that does both things (shows the whole topic name, and lets you mute the topic) would be good! What do you think?

This could also work well! Perhaps as a bottom sheet / action sheet? (I.e. a modal bottom sheet in Material terms -- we have a couple of these already which our code calls "action sheet".)

One thing I notice in the current behavior is that the touch target for the topic name is kind of thin, height-wise. The height is no greater than the height of the topic-name text. Not having changed the system font size from its default, I see that being less than 48px on my iPhone.

Hmm, yeah. In addition to hitSlop, another solution might be to make the whole title area of the app bar (i.e. including the stream name) the target for this. That might feel a bit odd when it's a toast with the topic name, but if it's a modal bottom sheet with some other actions then it'd probably be pretty natural.

[WesleyAC]

The actionsheet/bottom sheet approach sounds good! I think I'll implement that, possibly with a three-dot menu to bring it up as well (since it seems like we almost never use overflow menus currently, and have lots of actionsheets, but a menu would help with discoverability — open to other thoughts, though, if that seems confusing).

It'll have on it (not sure of order yet):

• Mute topic (if topic is unmuted)
• Unmute topic (if topic is muted)
• View topic list (Add way to view topic list from inside thread narrow #4529)
• View stream details (what the current ⓘ button displays)

If I do a three dot menu to bring it up (in addition to long-press), I'll replace the current ⓘ button with the three dot button, since IMO the ⓘ is extremely rarely useful, but I'll leave the ↑ icon, since that seems more likely to be part of people's current workflows. IMO the "View topic list" would be a better thing to put there on the whole, but I don't want to mess with any workflows that people currently have, at least not without some data backing up that that won't frustrate people.

[WesleyAC]

Looking at the app more, I think we should actually have:

• Untruncated stream and topic name (shown in the same greyed-out way it is on a long press on a topic name in the stream view)
• Mute topic (if topic is unmuted)
• Unmute topic (if topic is muted)
• Mute stream (if stream is unmuted)
• Unmute stream (if stream is muted)
• View topic list
• View stream details
• Cancel

Which closely mirrors the other actionsheets we have. Not 100% sure if mute stream should be there, but it's there in the topic name long-press actionsheet, so I think it makes sense to mirror that.

Having the untruncated name there is also (to me), a compelling reason to use an actionsheet rather than a overflow menu, even if we use a three-dot button to trigger it.

[gnprice]

That list of menu options sounds good!

If I do a three dot menu to bring it up (in addition to long-press), I'll replace the current ⓘ button with the three dot button, since IMO the ⓘ is extremely rarely useful, but I'll leave the ↑ icon, since that seems more likely to be part of people's current workflows.

Yeah, I agree.

to use an actionsheet rather than a overflow menu, even if we use a three-dot button to trigger it.

I think it'd be pretty confusing, at least on Android, to have a three-dot button at the top and have it open the overflow menu as a bottom sheet, rather than as a menu there at the top by the icon. I see overflow menus in a lot of apps and I don't think I've ever seen that behavior.

Or more precisely: I've seen it once, which was a couple of hours ago, and I was pretty surprised. 🙂 Specifically I'd seen that Material prescribed the overflow-menu icon should be three horizontal dots ⋯ on iOS, while three vertical dots ⋮ on Android, and I was looking for examples to confirm that anyone actually did that. Turns out if you open Google Maps on iOS, and go select some particular place and pull up the sheet so that the whole screen is the info about that place, there is indeed an overflow-menu icon at top right and it is indeed three dots horizontally, like ⋯. And if you touch that icon, you get a Material modal bottom sheet with actions like "Add label", "Add a photo", etc. I think that works on iOS because it's pretty common on iOS to have a button at the top that opens an action sheet at the bottom, but it'd be quite weird on Android.

[AkashDhiman]

One more thing to consider adding on the list of options is the searching messages functionality. Currently the only way to search messages is through home screen (via the search button). It searches all channels, and although we can narrow the search using keywords, I think it would be better if we provide such an option on the stream itself.

[gnprice]

One more thing to consider adding on the list of options is the searching messages functionality. Currently the only way to search messages is through home screen (via the search button). It searches all channels, and although we can narrow the search using keywords, I think it would be better if we provide such an option on the stream itself.

Yeah, I agree.

[WesleyAC]

Closing, now that #4568 is merged. I'll make separate issues for the other things we mentioned in this thread (replacing the stream info icon with a three-dot menu, and adding a search option)