Design suggestions regarding Reply and Options buttons

[dkasak]

The design of the new Reply and Options buttons doesn't work very
well, IMO. A couple of problems and fix suggestions:

1. They are hard to click since they straddle the previous message. This makes
   it easy to miss them with the mouse pointer, which moves the highlight to the
   previous message and makes the buttons disappear. This is basically the same as
   Unable to easily click reply or [...] buttons #9650.

2. The buttons overlap with the text when the message is long.

   

3. It often happens that the topmost message is completely in view, but its
   buttons are only partially visible because they are too high. This then
   necessitates scrolling up the thread. However, that also moves the message
   highlight which makes the button disappear, so you have to reposition the
   mouse.

   

4. This one may be the most subjective, but I think the intersection of the
   lines of the message highlight and the thick button lines is very jarring.

   

   This is exacerbated by the buttons being quite larger in comparison to other
   features of the UI (for instance, in relation to the height a single-line
   message).

It seems to me that the common source of these problems is that the buttons are
straddling the previous message instead of being contained in the message.

Perhaps the buttons should be moved into the seen notification area on the
right? It's better to temporarily obscure the seen icons than the content.
This is especially true because the button actions concern the content, so it
is useful to be able to review it while you are hovering over the message in
preparation for the click.

Alternatively, since the message highlight often extends quite a bit further
that the line length due to wrapping, there is usually some empty space at the
right edge of each message (such as in the screenshot for point 4). Perhaps the
messages could be made to wrap early enough so that they always leave enough
empty space for the buttons to appear? This would still fix all the mentioned
problems, but wouldn't encroach into the seen icon area, if that is unacceptable
for some reason.

The above was written with Riot 1.1.2 in mind.

[jryans]

Thanks for writing this up. I would suggest testing on https://riot.im/develop instead of a released version for this bit of the UI, as we are continuing to evolve and rework the design, and it already behaves differently there than your screenshots.

[dkasak]

Okay, thanks. I'll take a look at develop.

[dkasak]

Just wanted to say I took a look at the develop version and everything mentioned still applies as far as I can see. The changes I noticed are that the Reply icon is different and the buttons stick into the previous message a bit further than before.

[jryans]

2. The buttons overlap with the text when the message is long.

This issue shouldn't be present on develop. The button bar has been raised up (as you say "sticks into the previous message further") to avoid covering long lines in the current message.

[dkasak]

You're right, this particular issue isn't present anymore. I messed up while testing this one because

1. The button of the highlighted message can overlap the previous message

   

2. The button's border still almost touches the tips of high letters, like t here:

   

I'd argue 1 is still problematic (but less so), while 2 is minor but still looks wrong to me.

Here's a "mockup" of how putting the buttons at the far right end of the message would look (achieved by highlighting an empty message just below the target message):

[ara4n]

fwiw, the UI is about to completely change here; it's very much WIP still:

[jryans]

It is still changing yes, but at the moment we aren't planning to move the message action bar up to the sender line like that Zeplin screenshot, so the issues mentioned here would still apply.

[nadonomy]

Hey @dkasak— thanks for the detailed feedback. Design lead on Riot here, wanted to expand on the replies so far and our rationale behind some of these decisions. To go point by point:

1. They are hard to click since they straddle the previous message. This makes
   it easy to miss them with the mouse pointer, which moves the highlight to the
   previous message and makes the buttons disappear. This is basically the same as
   Unable to easily click reply or [...] buttons #9650.

Agree on this. The fix for this likely involves some invisible-to-the-user magic to prevent unwanted dismissals, perhaps inspired by these techniques.

2. The buttons overlap with the text when the message is long.
3. It often happens that the topmost message is completely in view, but its
   buttons are only partially visible because they are too high. This then
   necessitates scrolling up the thread. However, that also moves the message
   highlight which makes the button disappear, so you have to reposition the
   mouse.

Couple of things of note here. We found during testing & dogfooding that it's important for the actions to physically impose themselves on the message they relate to, or else their function is more ambiguous. With that in mind, we had to choose a tradeoff between overlapping the message you're interacting with, or the one before it, and we settled on overlapping the message before it, which I maintain is correct.

4. This one may be the most subjective, but I think the intersection of the
   lines of the message highlight and the thick button lines is very jarring.
   This is exacerbated by the buttons being quite larger in comparison to other
   features of the UI (for instance, in relation to the height a single-line
   message).

Agree that it's subjective. I'd also (subjectively) note that the borders aren't thick— considering they're interacted with contextually and their purpose is to draw attention to the actions you can perform, competing with with the rest of the UI for your eyes attention.

The buttons also aren't that large, a better benchmark than text/line height to compare them to would be the icons in the composer, which comparatively they're much smaller than.

Perhaps the buttons should be moved into the seen notification area on the
right? It's better to temporarily obscure the seen icons than the content.
This is especially true because the button actions concern the content, so it
is useful to be able to review it while you are hovering over the message in
preparation for the click.

Interesting idea! The bar itself has to be scaleable as we're actively removing/adding buttons to it (for example, you don't have emoji quick reactions or message edits enabled, which you can enable in Labs on develop) and in future we have plans to expose things like threading through it, so I'm apprehensive about exploring this while all of the above is in flux, but will keep it in mind for future.

Alternatively, since the message highlight often extends quite a bit further
that the line length due to wrapping, there is usually some empty space at the
right edge of each message (such as in the screenshot for point 4). Perhaps the
messages could be made to wrap early enough so that they always leave enough
empty space for the buttons to appear? This would still fix all the mentioned
problems, but wouldn't encroach into the seen icon area, if that is unacceptable
for some reason.

We wouldn't want text to jump when hovering, so effectively we'd need to reduce the measure for all messages at all time to prevent the timeline relaying out upon hover, so I'm not sure this is the right tradeoff to make. It works ok in specific short messages (like your comp here) but I'm not convinced this proposal would scale to all types and lengths of messages.

[dkasak]

@nadonomy, thank you for the thoughtful reply.

We found during testing & dogfooding that it's important for the actions to physically impose themselves on the message they relate to, or else their function is more ambiguous.

I agree. That's why I'm a bit wary about the buttons being positioned so high up in the area of the previous message, but I understand your concern.

Agree that it's subjective. I'd also (subjectively) note that the borders aren't thick— considering they're interacted with contextually and their purpose is to draw attention to the actions you can perform, competing with with the rest of the UI for your eyes attention.

FWIW, also subjectively, the buttons' borders look better in the screenshot Matthew gave above, so this might be something related to the contrast between the border and the normal/highlighted background due to the colours in the dark theme.

The bar itself has to be scaleable as we're actively removing/adding buttons to it [...] so I'm apprehensive about exploring this while all of the above is in flux, but will keep it in mind for future.

Agreed.

It works ok in specific short messages (like your comp here) but I'm not convinced this proposal would scale to all types and lengths of messages.

Fair enough.

[nadonomy]

Just closing this out as there's little to action while the feature is under heavy dev.

Feel free to re-open if there are outstanding concerns after all UI related issues with the feature:aggregations label are closed.