Improve UX in chat window

[axpoems]

• Set max size to the chat window to improve readability and overall UX of the chat on large/wide screens.
• Reduce size of the chat message and input text to achieve consistency with the rest of the font sizes.

[HenrikJannsen]

Hmm... It does feel a bit strange to me to have those flexible paddings in large width cases. I find it better to fill the available width as it is now.

[axpoems]

@HenrikJannsen - This PR addresses and implements a standard design issue related to the maximum width of a content window. The scenarios below appear particularly more unusual to me, reflecting the current situation and the problem being tackled—wide screens.

Even on the much more common standard 27" 3840x2160 screen, the window still doesn't look good:

Having a maximum width for the main internal content window in a desktop application, such as a chat interface, can be justified for several reasons, amongst others:

1. Readability and Focus:

A limited width prevents content from extending too far horizontally, making it easier for users to read and focus on the chat messages. Long lines of text can be challenging to read, and a controlled width improves readability.
You can also make a quick check on how well-designed applications implement this. For example the one you're looking now.

2. Avoiding Eye Fatigue:

Wide content areas may require users to consistently move their eyes across the screen, leading to eye fatigue. A constrained width helps maintain a comfortable reading experience without excessive eye movement.

3. Optimal Line Length:

Studies have shown that an optimal line length for reading is around 50-75 characters per line. Restricting the width helps maintain this optimal line length, ensuring that users can absorb information efficiently.

4. Aesthetic Considerations:

A controlled width contributes to a cleaner and more aesthetically pleasing design. It prevents content from spreading too far, maintaining a visually balanced and harmonious layout.

[HenrikJannsen]

I agree that it looks weird on such large screen sizes. But when I use the app on such a large screen I do not display it full screen or that wide, but rather a bit larger as the default size.

To me the centered layout in your suggestion does not work well with the tabs and the header as there the items are filling the width. If then it should be left aligned but not centered. But still I think that making it worse for 90% of users with an average screen size is not worth to serve the few who use a large width (as said I personally and I guess many others would not scale the width on a large screen that wide).

[axpoems]

@HenrikJannsen Can you show a screenshot of how it looks on your screen? because I don't see how this makes the experience worst for smaller screens. I have tested this with several, including laptops.

[axpoems]

I agree that it looks weird on such large screen sizes. But when I use the app on such a large screen I do not display it full screen or that wide, but rather a bit larger as the default size.

I shared a screenshot of the application on a 27-inch screen, which is considered a standard size nowadays, and I might even say it's a bit on the smaller side. The display appears not good. Failing to utilize the full screen size on a monitor of this scale suggests a design flaw. The nature of bisq2 as for now, in contrast to bisq1, is more oriented towards portrait than landscape, which is why we naturally (for the moment ) don't employ a full-size screen and so this would not even be perceived currently.

But still I think that making it worse for 90% of users with an average screen size is not worth to serve the few who use a large width (as said I personally and I guess many others would not scale the width on a large screen that wide).

Do we have concrete statistics on users' screen sizes? My assumption is that the majority of users utilize laptops. As mentioned earlier, I've conducted tests from the widest to the smaller, and the application looks good with no limit applied to the medium
to smaller sizes. This isn't about a trade-off; it's about rectifying the extreme widest cases without impacting the smaller window size cases.

This is also part of several design improvements, not all of which have been implemented yet, aiming to enhance Bisq2 significantly. Also certain adjustments can still be implemented to address what you've considered as not ok, but to better comprehend that, I would need the screenshots with what you see.

Finally and to move on I would suggest merging this into main and testing it out. If the implemented changes result in a less favourable experience (although I really doubt that), then we revert the changes.

[HenrikJannsen]

When switching the tabs to Getting started or open trades the full width is used again. Also when switching to other screens... I find that not coherent.

And as said the top header is also using the full width and it feels weird to have the main content limited in width but the rest of the screen not.

Thats the near max width of my 1920/1200 resolution macbook.

With that PR it starts to apply the max width on the chat container at that size:

I would consider the width until about that size as not problematic to need to be limited:

As a compromise, why not align it left and increase the limit width? As it is now it would feel wrong to me.
Left alignment would at least be in line with the tab menu.

[HenrikJannsen]

Thinking further about that issue:
I think your approach is influenced from webpages having content centered and width limited (like the GH page or Twitter). But I think the reason there is different as in a desktop app. A web browser need to serve many different layouts, thus having it fullscreen is very common and on large screens that would render a bad layout on many pages.
For a desktop app I don't consider fullscreen mode (at least on large screens) as a commonly used mode, thus the user will adjust the window size to what they consider useful (at least thats how I do it).
Also looked at some OSX desktop apps like Whatsapp, Signal, Messages, Spotify,... and they all scale up to the available size without limiting the content. Also some standard OSX apps use that model. Actually I have not found any desktop app which follows the web browser model with centered limited content.

I think its best to leave it to the user when they feel the layout gets uncomfortable wide by reducing the window size.

[axpoems]

When switching the tabs to Getting started or open trades the full width is used again. Also when switching to other screens... I find that not coherent.

That's because it hasn't been implemented yet; I was planning to do that. In this case each container would have a max-width.

I would consider the width until about that size as not problematic to need to be limited:
As a compromise, why not align it left and increase the limit width? As it is now it would feel wrong to me.
Left alignment would at least be in line with the tab menu.

What could be done is increase the max-width, maybe up to 1400px, but we would need to test it to find the optimal. The alignment is also something we can explore. I strongly believe there's a solution that suits all needs.

I think your approach is influenced from webpages having content centered and width limited (like the GH page or Twitter). But I think the reason there is different as in a desktop app. A web browser need to serve many different layouts, thus having it fullscreen is very common and on large screens that would render a bad layout on many pages.

Not at all, but webpages are indeed a common scenario where this issue arises. My point is that it doesn't look good and isn't functional on wide screens/windows. Reading feels like watching a tennis match.

For a desktop app I don't consider fullscreen mode (at least on large screens) as a commonly used mode, thus the user will adjust the window size to what they consider useful (at least thats how I do it).

I agree; we shouldn't encounter many issues because users will adjust the window size to their preferred layout. The goal here is to ensure that content remains legible at various sizes.

Also looked at some OSX desktop apps like Whatsapp, Signal, Messages, Spotify,... and they all scale up to the available size without limiting the content. Also some standard OSX apps use that model. Actually I have not found any desktop app which follows the web browser model with centered limited content.

I can provide examples of windows desktop applications that do limit the maximum width of their content: Skype (centered), Telegram (aligned to the left), Threema (centered). While Spotify's desktop app for Windows is diverse in its content type, for text-heavy elements like podcast where there is a list and description of episodes, there is a maximum width applied. In the case of Music albums, there is no limit imposed, primarily because the information is more effectively organized in a tabular format.
I would like to repeat that this isn't a proposal to limit the max-width of all content, but rather to address the cases where widening the application window makes the content seems impractical to read/use.

I think its best to leave it to the user when they feel the layout gets uncomfortable wide by reducing the window size.

I agree with what you're saying while I still believe that implementing a max-width limit for chat/text containers in the specificity discussed is needed. It's not just about aesthetics but also about ensuring a comfortable reading experience for all users. Without a max-width, users who prefer a full-screen view (for example in common 27" screens) will find the content stretched out and difficult to read.

With all my argumentation made I don't see how prolonging it would add anything new.
However, testing new changes may do. I've made a couple of them (among many that can still be done). I've increased the max with to 1440px and the message box to 720px. How do you experience it now?

[HenrikJannsen]

ACK

[HenrikJannsen]

Maybe to limit the width of the tab navigation as well would be an option to consider? Then the tab navigation stays more connected to the content below. With 1440 it looks ok on my screen but I have 15 inch so on 27 inch the left/right padding will be larger and thus the distance to the above tab navigation.

[axpoems]

Maybe to limit the width of the tab navigation as well would be an option to consider?

Yes, I also thought about this. If we go with this solution perhaps worth doing that.

When thinking about your feedback and input here, and also from looking at other desktop applications, I came up with this possibility (these are not mock-ups, but rather a test I made to see):

This gives the impression that it's adjusting to full screen but at the same time gives the good UX experience for reading.
The bottom bar with input field and send button could then be adjusted to fit better this design.
This solution though, implies more development since the bar looks bad where it is, besides other small details.
What are your thoughts here?

[HenrikJannsen]

Yes keeping the same bg color (as in GH page) feels better to me. The bottom input field bar could maybe be full width like the top header (in the left aligned version)? The send button on the right is not that essential as "enter" always sends the message and i guess most ppl are familiar with that standard chat behavior.

[axpoems]

Yes keeping the same bg color (as in GH page) feels better to me. The bottom input field bar could maybe be full width like the top header (in the left aligned version)? The send button on the right is not that essential as "enter" always sends the message and i guess most ppl are familiar with that standard chat behavior.

I will work on a solution in this direction. Will post details about this soon.
Let's keep the changes in this PR for the time being as the first iteration towards the final version.

[alvasw]

utACK