You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The message is exactly the same as in the feed. It shouldn’t be just a picture, because we want to allow TEXT SELECTION HERE.
See also the notes to the right of there in the Figma design, about scrolling behavior.
Implementation
I expect this will involve reusing most of the implementation of MessageWithPossibleSender. That will probably require some refactoring, in order to make the relevant parts reusable without other aspects that aren't desired here.
Also if the message in its original context in the message list didn't show the sender, we'll want to still show the sender here.
Old ideas
In the redesigned message bottom sheet #90 from @terpimost, the top of the message sheet shows the text of the message you're acting on (cutting it off at two lines). This is helpful when the message itself isn't visible, which becomes more and more likely as we add more actions to the bottom sheet.
I'm splitting this out from the rest of #90, because the concept of "the text of the message" is actually a bit slippery and raises some product/design questions.
We could use the message's Markdown source. But that isn't great for this UI context: it may have a bunch of markup that obscures what the message actually says.
Consider in particular the case where the message starts with a quote-reply.
Consider also a message that starts with one short paragraph like "Yes.", and then has more details in a second paragraph. The first two lines of the Markdown source will be just "Yes." followed by a blank line. That's not very informative, and we might want to show more text than that.
If we decide we're OK with that, there's a second pitfall which we'll need to pick a response to: we don't normally keep around the Markdown source for all the messages we have, only the rendered HTML. On the occasions where we need Markdown source (like for generating a quote-and-reply), we make a separate request to the server to get it. We can do that here… but then we need to decide what to show when that request hasn't completed yet, which will be at least a frame or two and often more.
We could delay the whole bottom sheet. That seems bad.
We could show nothing; when the text arrives, the top edge of the bottom sheet jumps up to make room.
We could show a blank space; when the text arrives, it pops into existence in the top area of the bottom sheet. Until it arrives, that area looks oddly blank.
We could show a CircularProgressIndicator, or another loading indicator. Might feel noisy; this message text isn't meant to be a point of focus, just a helpful bit of context in the nature of a breadcrumb.
We could use the message's HTML. That will definitely have a bunch of cluttery-feeling markup, more so than the Markdown. On the other hand we have it immediately and don't have to wait.
We could introduce some new notion of a "text summary" of a message's content: we'd walk the content parse tree, and try to generate something like its plain text without markup. This will require some work to define just what we want and to implement it.
The text was updated successfully, but these errors were encountered:
Another option is to take a screenshot of the rendered message on which user has clicked and show top part of that, cutting out the rest:
It might be ok to copy that with a background:
In the redesigned message bottom sheet #90 from @terpimost, the top of the message sheet shows the message you're acting on.
We've left that part out of the scope of #90; this is a follow-up issue for adding it. See Figma design:

https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=3483-29796&m=dev
and quoting a note from there:
See also the notes to the right of there in the Figma design, about scrolling behavior.
Implementation
I expect this will involve reusing most of the implementation of MessageWithPossibleSender. That will probably require some refactoring, in order to make the relevant parts reusable without other aspects that aren't desired here.
Also if the message in its original context in the message list didn't show the sender, we'll want to still show the sender here.
Old ideas
In the redesigned message bottom sheet #90 from @terpimost, the top of the message sheet shows the text of the message you're acting on (cutting it off at two lines). This is helpful when the message itself isn't visible, which becomes more and more likely as we add more actions to the bottom sheet.
I'm splitting this out from the rest of #90, because the concept of "the text of the message" is actually a bit slippery and raises some product/design questions.
We could use the message's Markdown source. But that isn't great for this UI context: it may have a bunch of markup that obscures what the message actually says.
If we decide we're OK with that, there's a second pitfall which we'll need to pick a response to: we don't normally keep around the Markdown source for all the messages we have, only the rendered HTML. On the occasions where we need Markdown source (like for generating a quote-and-reply), we make a separate request to the server to get it. We can do that here… but then we need to decide what to show when that request hasn't completed yet, which will be at least a frame or two and often more.
We could use the message's HTML. That will definitely have a bunch of cluttery-feeling markup, more so than the Markdown. On the other hand we have it immediately and don't have to wait.
We could introduce some new notion of a "text summary" of a message's content: we'd walk the content parse tree, and try to generate something like its plain text without markup. This will require some work to define just what we want and to implement it.
The text was updated successfully, but these errors were encountered: