Replies: 6 comments 20 replies
-
|
Ideas always appreciated! This type of layout seems to be pretty standard for the IRC clients. Would be nice to have an option to reproduce (or approximate) it.
Personally, I like a somewhat spacious, vertically-separated layout, so that the messages are not packed too tightly against each other. But for those whose tastes run in the opposite direction of mine (which are probably the majority of users :), perhaps we can have a 'compact' / 'single-line' mode setting. With it, all of the messages' components will be printed in a single line, like Where the emoji in square brackets is the reaction. Adding a quoted message to the same line will probably look unwieldy, so best keep them multi-line. Also, some messages have explicit newlines. With the above implementations in place, we can have an "IRC-like" mode (except for its three-column aligned layout: time - sender - message text), with the combination of I think it should be doable. In fact, changing a single separator from |
Beta Was this translation helpful? Give feedback.
-
Not straightforward but worst case just computing and padding the names manually with spaces, given a known target width, shouldn't be too difficult 🙂 I do believe it can increase readability, so lets at least try to explore - I am happy to help 😉
I think in a group it could be quite useful, no? Of course we only pad the left side:
That is true in many cases, but quite useful when you are catching up on backlog, if you have chatty friends while you are asleep 😁 Also, a general point, with the modern wide screen we usually can fit more horizontally than vertically, so I am not too worried about having to use ~10 extra chars for time... As you can see in this thread I'm quite more interested to save vertical space 😁
That's an interesting idea! I initially thought that with multi-line messages this would look bad (especially if lots of other emoji symbols are involved, e.g. with the currently popular wordle), but it doesn't look bad at all!
Absolutely agree
Haha, indeed! 😁 To me it also very quickly proves that tab-aligning names would be very important, otherwise my eyes get tired jumping left and right trying to identify where messages begin...
The only downside I can think of is that it can be quite complex to keep all possible UI configurations stable and without bugs... as demonstrated by my recent PR where I was discovering on the go which other combinations I forgot to account for 😅 |
Beta Was this translation helpful? Give feedback.
-
The complication I was thinking about was determining and adjusting the target length itself, on the fly, given the available screen space and the names in the view (and adjacent). But that might be over-complicating it. As a first step, we can just have a hard-coded length.
I'll look at this again soon-ish. It might indeed turn out to be not hard. Contributions welcome, of course!
Yep, I can see the utility of this. We can always pad the names when they are shown on the left.
True, vertical space is likely more valuable for most users.
We could also check whether a message itself contains newlines, and place reactions on a new line in that case. Bonus points: adding a
Makes sense. However, the names are shown in bold, unlike messages. And we could add other separating markers.
Exactly what I was thinking! We don't yet have a test suite, so unfortunately the permutations have to be tried manually. |
Beta Was this translation helpful? Give feedback.
-
|
I have added options results in an interface similar to the one in the screenshot above. Some differences: reactions are still shown on a separate line; the Let me know if there are any comments! |
Beta Was this translation helpful? Give feedback.
-
|
That's quite interesting! Thanks for working on it! The most important thing that negatively stood out to me is how multi-line messages are currently displayed: I'd much prefer for the message contents to not be blended with author names, e.g. like so: Even better, if we can have some visual separation for the two columns, people and messages, something that is easier for the eye to "catch on" than just the bold font of the author names. Perhaps like this? This way, I feel like I can more easily glance at the messages alone, I make less mental effort to visually distinguish where do messages begin. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! I agree, it'll look better with a separate vertical column for the message's text. I'll add it. Although for messages that are longer, the current layout is also readable:
and it uses up less space than the columns-based alternative. But most of the potential users of the |
Beta Was this translation helpful? Give feedback.
-
|
Yeah! Regardless of a screen size, I feel like I would definitely at least keep Have you considered showing the time before I don't disagree that the current layout is readable, but for some reason I still feel like a column-based UI would still be easier to spot at a glance, skim to the next message, etc... On a smaller screens, I would maybe omit the author names and at least try to include |
Beta Was this translation helpful? Give feedback.
-
|
With the added options the number of possible combinations becomes quite large. I have considered allowing instead to specify the included items and their layout through a format string to So for the options and their combinations I'll have to pick some best "middle-of-the-road" results that would be acceptable to most of the people. |
Beta Was this translation helpful? Give feedback.
-
|
I've pushed some more changes to feature/167-ui-inline. The quoted message text is now in italics (thanks again for the suggestion!). Would be nice to have a better visual separation method, but in a terminal app the options are more limited than in a typical GUI.. Using color is a good idea, but it should only be applied when
That would create a better separation in that case, but I think in general it's better to keep the existing ordering:
WRT columns: I agree, the column-based layout is better for inline mode. It's now a default when Let me know if that sounds (and looks) reasonable! |
Beta Was this translation helpful? Give feedback.
-
|
I like it a lot, and agree with everything you said 👍 I do not quite understand one part, maybe you can help me here:
In other words, quote placement is equal both with and without vs |
Beta Was this translation helpful? Give feedback.
-
|
With A line break is included between the quoted message and the reply (i.e. the main message text), even with the The |
Beta Was this translation helpful? Give feedback.
-
|
Ah that makes sense! I can see that in the regular mode, the quote can take up to two lines (name + 1 line of content), after which it's clipped, and in the inline mode it is also clipped but it "slips" a little bit on the second line, so the max number of lines it can take is still two. Is there some specific math going on, or is it just a coincidence? I'm asking because, if in both display types, the quote is allowed to take at most two lines, maybe it will still make it easier for you to keep just one way of representing the quote? I don't have any particular preference for Whether we use |
Beta Was this translation helpful? Give feedback.
-
|
The quoted text is currently clipped at 70 symbols. That is, it is limited in length, rather than in the number of lines it can use. Number 70 is also somewhat arbitrarily, of course. In normal mode it should be able to fit on a single line of a typical terminal window. However, when run with Limiting the quote's text to a single line is unfortunately not straightforward, because the quote is only one part of a markup string supplied to an
That's a good point, I might remove the trailing |
Beta Was this translation helpful? Give feedback.
-
|
I see, thanks for clarifying! |
Beta Was this translation helpful? Give feedback.
-
|
I seem to have a lot of friends with long names 😅 For me It's not that I think one number is more correct than another, I totally realize it's hard to come up with one perfect hardcoded number, and I do like that the column is "fixed" across all chats, so the layout doesnt become wider and narrower all the time as I switch between people. However, I don't like that when the author name wraps, it basically results in 50% of vertical space being lost, as now there's empty line between each message. This entire discussion, after all, is about conserving vertical space at the expense of horizontal one 😁 What do you think is the best way to handle it? |
Beta Was this translation helpful? Give feedback.
-
|
I agree entirely, and besides, as a user I don't want to make the decision about the names column length. I think clipping with some sensible default is a valid strategy, but I find it really difficult to come up with arguments for or against |
Beta Was this translation helpful? Give feedback.
-
Something like that is possible, but probably not really necessary: in one-to-one chats, the name of the contact is not needed on every message (after all, it's known whom a given chat is with); it would really suffice to just have "me" and "them" indicators. And 12 symbols would be enough to fit a meaningful amount of the name (in many cases - fit completely). |
Beta Was this translation helpful? Give feedback.
-
|
I actually agree with you, after using Even in the original screenshot in this thread, the names are shown there exactly because it's a group conversation! So a big question is now, do we really need A side-note: in a group conversation, currently Whether or not we keep |
Beta Was this translation helpful? Give feedback.
-
It's a "pre-existing" option in
Indeed, this does not look right. Without |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense, and thanks, it looks good now in the group channel! 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Another change pushed to the |
Beta Was this translation helpful? Give feedback.
-
|
Exciting! On the one hand, I'm loving that it saves some space - in one of my groups in particular, there are a ton of reactions going, so this change literally allows me to fit twice as much content on the screen in that channel! snip
On the other hand, especially in a "normal" chat with only occasional reactions, because it is aligned by the right side, there is so much space between the message and the reactions, it's really difficult to match a specific message to a reaction - I can see somewhere on the right side that some message had a reaction, but I almost have to take a ruler to find out which message it corresponds to... I don't think there's particular need to have the reactions be aligned in a column, like names and message content is... What do you think about adding reactions to the end of the message? In the same format, just not as a column aligned to the right, but appended to the end of the message - have you tried it already, perhaps? On a side-note, it may be a bit too early to report this kind of stuff, but there's a crash if you try to add, change and remove reaction on a message (I tried on a message in "Note to Self" channel): snip |
Beta Was this translation helpful? Give feedback.
-
That's the most straightforward approach; the problem with it is that it makes it hard to distinguish between a message and a reaction to it. I have put together some changes that accomplish this in 0e2d84e, just to check what that would look like. Having reaction in a separate column seems like a better idea, as it gives a clearer visual separation. But I can see how with a wide terminal window the gap between the reactions and the message text becomes too wide. One solution to this is to bring the columns closer together. I have made some changes that do that in the latest commit. Let me know whether that works for your case. Also, you can try to play with the number in this line to see if some value of the reactions column's weight works better than the current one.
Not too early at all! Thanks, should be fixed now. |
Beta Was this translation helpful? Give feedback.
-
|
I tried using both versions for a significant amount of time, I think the 0e2d84e looks a lot better, even compared with a reduced column width of the alternative idea. At the same time I have to admit that for my taste, the reactions shown on a separate line (as in the release) are prettier than any of the two inline options... Probably because of what you said is true, that when reactions are on the same line, they are somehow mentally mixed with the message itself. I was considering if something like this could be possible, but it has a lot of challenges, such as when reactions don't fit in that space, or without |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! I think it should be doable to implement something like your example above. It does look like a very nice way to show reactions for this case: if the second column exists (containing time or sender's name), and if the message is long enough to span several lines. But, like you said, if the Reactions appended to the end of the message text might be hard to notice at all. A message text itself might well contain the very same emoji; and the message widget does not get noticeably transformed when a reaction arrives and an emoji is appended this way. So, it seems like the column layout is the best option for a general case. Maybe there are ways to make it more visually appealing; if I think of something (or if there are any suggestions) I'll be sure to make improvements! |
Beta Was this translation helpful? Give feedback.
-
I like the current UI, but as things can always be improved, I was curious to see if you are on a lookout for ideas how to optimize the look and feel 🙂
I really like the UI of thelounge.chat - a screenshot is below, of a public channel, so hopefully nobody will get offended 😄
Things to note:
show_names=true) and yet double the amount of messages shown on a single page, as username no longer takes a line, but is shown on a side to the message. Real estate is expensive!What do you think overall? Interesting? Dislike? Too much work to change?
Beta Was this translation helpful? Give feedback.
All reactions