session-desktop
session-desktop copied to clipboard
Left-align outgoing messages with incoming messages.
Contributor checklist:
- [x] My commits are in nice logical chunks with good commit messages
- [x] My changes are rebased on the latest
clearnet
branch - [x] A
yarn ready
run passes successfully (more about tests here) - [x] My changes are ready to be shipped to users
Description
The paradigm of displaying incoming messages on the left-hand side of the screen and outgoing on the right is the legacy of Session's origin as a fork of Signal.
Not only does this consume a lot of screen space, it's also unnecessary, as outgoing messages are already distinguished from incoming by their colour, i.e. a green background vs. a grey one. Outgoing messages also omit the avatar, which deprives the sender of a quick visual confirmation that his avatar is as expected. (Session has been known to reset a sender's avatar on occasion).
To add the sender's avatar on the right, a vertical margin would have to be reserved, leading to even poorer utilisation of the available screen space.
This patch moves outgoing messages to the right-hand side of the screen, aligning them with incoming messages, and displays the sender's avatar alongside them for consistency.
Additionally, I dispense with the distinction between groups and 1-to-1 chats, displaying avatars in all cases.

This patch not only provides more useable space and aesthetically provides a more organized appearance but as mentioned includes the posters avatar. The avatar conveys information regarding the attributes of the user within the context of the group they are posting in. Additionally if attributes are a part of future monetization plans, seeing ones paid for attributes as they appear to others when posting is a reminder of the value of the attribute that they have added.
The avatar conveys information regarding the attributes of the user within the context of the group they are posting in.
Good point. It's a visual reminder that one is, for example, a group moderator, not just a normal user. The user currently has no visual cue for that.
We are interested in this change; however, I don't think enforcing it for all clients across all screen sizes is optimal, as this change proposes. There seem to be a few approaches taken by other messaging clients:
- Discord (Desktop): Left-aligns everything, but messages span the entire width of the screen.
- Telegram (Desktop Windows): Left-aligns all messages below a specific screen width. Above that width, messages appear on both sides of the screen.
- Signal: Displays messages on both sides, with no option to support single-side/left alignment.
Of these approaches, I think the Telegram approach could be the best. It ensures that when a larger width window is available, messages appear on both sides of the screen, allowing chat participants to easily identify their own messages from others'. However, when the screen width is limited, all messages are left-aligned to optimize screen real estate.
Happy for anyone/author to make additions this PR to implement that approach otherwise will close this after some time and raise as a good first issue with some more specifics.
Upon reviewing Telegram's logic, I realised my initial understanding was incorrect. What Telegram actually does is align other users' messages to the left and your messages to the right on smaller window widths. On larger window widths, all messages are left-aligned. On mobile, messages are always split between left and right alignment depending on the sender, so desktop Telegram essentially mimics mobile behavior when the screen size is small enough.
The only reason I can think of for this behavior is that as screens get wider, it's more visually taxing to move your eyes between both sides of the screen to read messages. In contrast, on smaller screens, the entire conversation is consistently visible, and having messages on both sides allows for more efficient message distinction.
I think we should conduct user testing to discover which format users prefer on different screen sizes before implementing anything here. If anyone can link previous research on this topic that would be useful