Replies truncate too much

[nadonomy]

With the new replies implementation, I never see as much of a message being replied to as I want to. I'm spending my life clicking on messages being replied to and bouncing up and down the timeline, where before I'd just see more of the original message in context in the reply.

[t3chguy]

Related #18179

[ShadowJonathan]

I'd argue that this is the reason why the new reply design was implemented; to only give a small preview, not the complete message, of that reply.

Tbh if that is something Design or Product doesn't agree with, it should've been caught way earlier in the process, as it's been in the works for quite a while, and now it's been out for a week or two.

Also, if usability issues occur with the feasibility and UX friendliness of jumping around the timeline, I'd argue to focus on that instead of the new replies that are exposing/pressuring it.

[HarHarLinks]

to only give a small preview, not the complete message, of that reply.

in terms of user interaction that is "to remind of the original message which you likely already read and know", so it might be unnecessary to repeat it.
in my opinion, and why i like it, it also is: if replied to short messages, images and media, or if long ones weren't truncated, it translates to "use up way less space on the timeline"

a replied-to message that was navigated to should perhaps offer a button to jump back from whence you came.

as per #18179 I'm obviously a proponent of the replied-to-should-be-interactible-on-their own way to do things, because I don't see it possible nor reasonable to jump around so much. however I also like the new compactness of replies.

i tried to propose a couple ways in #18179 to reenable that without significantly compromising or cluttering the new UI, e.g. just click the ... to show the whole message in place.

[ShadowJonathan]

Also note that some people still find this new approach too verbose, and would rather hide away the reply message and/or the replied-to preview entirely (something I personally disagree with); #18078

[HarHarLinks]

I would actually agree with that to some degree for my own use (see below), and potentially a setting in general for those who want it if the code is already there anyway.

---

Someone brought it up somewhere else in a related issue, but I can neither remember nor find it atm, but additional to my above points:

Contrary to popular believe it is not so uncommon at all to reply to the direct predecessor message.
A common example would be a bot see below, but it also happens very regularly in the wild between humans.

This is another reason for why I believe the previews might profit from more contextual truncating, e.g. to only one line if the message is still on screen; or as I have seen mocked up somewhere, connect direct replies without quoting a bit like this.

[ShadowJonathan]

Someone brought it up somewhere else in a related issue [...]

(I think that was me, or at least around here; element-hq/element-meta#1547)

[robintown]

Potentially part of the issue is that replies currently look like any other normal text, and so it's easy to start reading them before realizing it's only a truncated preview. Part of my reason for suggesting in matrix-org/matrix-react-sdk#6396 that they be colored like blockquotes is to better set the user's expectations when they see them in the timeline.

[ara4n]

This is really impacting my ability to use Element - i simply can't see the contents of the message that I'm replying to, and the last thing I want to do lose my place in the timeline to jump around.

Please can we implement an expand button on the truncated replies to let users expand them inline to avoid the truncation?

[ShadowJonathan]

and the last thing I want to do lose my place in the timeline to jump around.

That's why i opened element-hq/element-meta#1572, FWIW

[nadonomy]

Please can we implement an expand button on the truncated replies to let users expand them inline to avoid the truncation?

Agree, in lieu of printing the whole message (which harms legibility of the timeline overall) this is the most pragmatic & predictable fix to improve the goal at the core of the issue.

We'll take a look at what interaction makes the most sense (text buttons as show more/less or expand/collapse, or using dropdown iconography? etc).

[ShadowJonathan]

@nadonomy #18179 provides some mockups, and more information.

[nadonomy]

@ShadowJonathan thanks. The ellipsis design looks interesting at a glance.

[Palid]

Throwing this one back into design, we need to figure out some UX that will handle both the typical cases and corner cases in a proper manner.
The moment I started wrapping my head around this I immediately found a couple of cases where this may break the UX even more than jumping to a thread, for instance if you try to reply to a very nice amount of lorem ipsum e.g. (Generated 20 paragraphs, 1885 words, 12873 bytes of Lorem Ipsum) you'd need a way to both open and close the preview in a simple way that won't break your flow and current position in the timeline, which in this particular case where you have two screens of letters will screw things up immensly.
Maybe having some kind of a pop-over for that, or a hover effect would be good enough? Dunno about screen readers though.

@HarHarLinks's suggestion in #18179 for expand/collapse buttons seems pretty good for this case, but when there's more text in the message you'd have to click it multiple times to get to a satisfying point, which seems a lot more suited towards keyboard/power users, and not casual ones.
@nadonomy what do you think?

[HarHarLinks]

Toggling the expand (once) could expand it up to a certain size (in pixels) and if the message still overflows have scrollbars.

btw did somebody mention that the same principle that applies for "quoted" replies in the TL as discussed here also applies to the composer during writing a reply?

[bkil]

As a quick alternative, could we perhaps drop newlines when producing the two lines of preview? The thing is, sometimes people share a link and/or press enter a few times, and in such cases the preview contains very little information, while for the same vertical pixel space, more information could be shown.

On the same note, perhaps if the preview also contains an URI, it may also be shown as a shorter variant (like after chopping off parts of it, like protocol, www., and perhaps the fragment or some of the query parameters as well - or possibly even anything but the hostname). Hovering over it would show the original link anyway.

[Palid]

Added a video of why it is blocked in the pull request.

[Palid]

Closing in favor of #18884