(feat) Implement a two column layout for large desktops

[jayasanka-sack]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
• My work includes tests or is validated by existing tests.

Summary

This pull request enhances the patient chart display to optimize space utilization on large desktop screens. The current implementation displays widgets in a single column, resulting in underutilized space. The proposed changes introduce a 2-column layout for widgets, ensuring better use of available screen real estate.

Key Changes:

• 2-Column Layout: Widgets are now displayed in a 2-column layout on large desktop screens, enhancing space utilization.
• Workspace View Compatibility: Adjustments have been made to ensure proper spacing and layout integrity, especially when the workspace view is open.
• Widget Ordering: Widgets are ordered from left to right and top down, as per the specified sequence, facilitating a logical flow of information.
• Minimum Vertical Height: Technical adjustments enforce a minimum vertical height for each widget card, providing adequate white space and maintaining layout consistency.
• Flexibility and Responsiveness: Widget heights are flexible and responsive, ensuring an optimal user experience across various screen sizes.

🎾 Demo

Quick Demo and Overview of Layout Functionality - Watch Video

## Related Issue

https://openmrs.atlassian.net/browse/O3-3024

Other

[gracepotma]

Thanks so much Jayasanka, great to see this taking shape! I've asked Paul Adams to have a look here for quick design-intent double-check.
My 2 concerns are:

1. Info gets hidden behind horizontal scroll (eg in Vital Signs, which is clinically concerning / a safety issue). Perhaps we can get the Vital Signs widget dates to adjust the way the dates do in Biometrics.
2. Info gets hidden a little bit when workspace opens (maybe not a big issue but I thought as a general rule we wanted the body content to adjust with the workspace?)

[paulsonder]

Hi @jayasanka-sack. Thanks for sharing the video of the progress so far, it's good to see the two column view taking shape and utilising the space more effectively for those users with bigger monitors!

I have a couple of immediate thoughts on the behaviour of the UI so far...

1. In a Summary screen, a user shouldn't need to interact with a card to view all the recent data, such as vital signs. My suggestion would be that if a widget / card requires horizontal scrolling due to the number of columns, the widget should occupy the full available width (in a single column) to ensure this level of interaction from a user is not required.
2. That said, we should make use of all the screen real-estate if the objective is to get as much information in the viewport as possible, so let's try using the margins that are empty and maintain a 16px padding in that part of the screen.
3. For maximum utilisation of space on screen, a goal of this work, it may be worth exploring how we might render the widgets without minimum heights but still allow for a logical flow of the widgets on the page. I've included a couple of examples for illustration below:

[CynthiaKamau]

Thanks @jayasanka-sack , please address the conflicts

[jayasanka-sack]

I had a chat with @ibacher about this matter. The idea was to make the column width configurable (as it was previously). Unlike the previous, I added a new widget meta "fullWidth": true to make an extension full width. Another suggestion was to pass some context to the component regarding whether it was mounted in a single column or at full width so that the component could adapt accordingly. I will address it separately. Making it auto-adaptable is a bit complex as we need to wait until the data is loaded, and we think this solution is practical as the behavior is predictable.

Regarding masonry layout, I highly agree that would be the best way to arrange tiles. The masonry layout for grids is only an experimental feature on browsers, so we should think of an alternative way. but it's doable. I will address it separately.

I chatted with @ibacher about tweaking column widths. We've decided to bring back the option to adjust them, and I've also added a new widget meta "fullWidth": true to let an extension take up full width. Another cool idea was to give some context to the component about whether it's sitting in a single column or stretching across full width, so it can adjust on the fly. I'll look into that part later. Making it auto-adjust based on the data loading is a bit tricky, we think this option is much simpler and should work better since the behavior is more predictable.

On the masonry layout, I totally agree it's the best way to arrange tiles. Masonry layout on grids is still an experimental feature in browsers, so we might need to think of other ways, but I'm confident we can figure something out. I'll dive deeper into this one separately.

Ian's comment:

I do recall there being a PR somewhere to try to use concept short names rather than the full text, and that probably makes sense. It may be ideal if the chart passed some context to the extensions mounted in it about whether it was rendering in one-column or two-column mode to allow widgets themselves to adapt to the more "squashed" mode. This could be part of the state that gets passed in to each dashboard.
I think between that and the widget meta, we have a decent way of communicating both capabilities and whether those are actually used, which should give us the necessary flexibility.