Responsive Desktop Quick Fixes

[jagabomb]

Description

This PR is a proof of concept to demonstrate how the Trento Web could display its table content for smaller desktop screen widths of 1024px to 960px. The reason this becomes important is that enables a better responsive experience and it allows there to be space for a right hand side component, (e.g: Chat window, Filter sidebar, etc).

Example of 1440x900 Screen with Right Hand Sidebar Component (Not included in PR)

To summarize the changes it boils down two directions below:

Direction 1: (Refer to Home and Hosts View):
Tables are cropped to the size of the main content. Then a scrollbar is appears at the bottom to indicate that content is scrollable. While this has usability improvements for the table, it maybe be unclear that the content is scrollable at first especially if the scroll bar is below the viewport.

Direction 2: (Refer Clusters View)
Tables have their content reduced by either scaling down or hiding it. This makes it easier to remove content that is too long but it can impact usability if we find more users prefer using smaller devices like tablets and mobile phones eventually.

Benefits of these changes is that it opens conversation to establish principles on how we want to approach responsive views. It also enables the ability to view Trento in a multiple window view (console + docs or cluster+host detail).

Example of Multitasking Trento Web and Docs

P.S: None of the other tables/pages have been modified yet.

How was this tested?

Describe the tests that have been added/changed for this new behavior.

• DONE Visually

[github-actions]

The preview environment for this pull request is ready at 4042.prenv.trento.suse.com.

[antgamdia]

Thanks a lot for this. TBH, the lack of responsiveness was driving me crazy. Will check once it's marked as ready, but looks really promising!

[nelsonkopliku]

Hey Jurgen, thanks a lot for this!

I mainly have one question: what's the lowest lowest resolution we're targeting where the UI "does not break"? The mentioned 1024px to 960px?
Asking because I want to understand whether we are targeting making trento usable on smartphones, or whether we'd be good with tablets and smaller screens (I hope it is this second 😄 )

With regards to the proposed directions the only thing I can think of, now, is carefully deciding which content should disappear when available space is reduced.

I trust that our Analytics integration will bring valuable data on top of which we can move forward, but the changes in this specific PR could be already a quick win in responsiveness improvements.

Thanks!

[jagabomb]

@nelsonkopliku Thanks so much for your feedback. Regarding your first question, based on the current Trento implementation I would say we are catering for screens of 1440px (with full side menu) and 1280px (with collapsed side menu).

Then in general, no decisions have been made on how we want to solve smaller devices like tablets and mobile phones. At this stage, based on the PR even, I don't think we are ready to discuss mobile yet. But I did want to start showing a couple of directions that we could use to solve how we provide usability for smaller devices.

For now, I just wanted to create this PR so that we have a point of reference when it comes to the discussion of how we would like Trento to look and function. Ideally we will be able to start using Analytics to inform these decisions too. 😅

[abravosuse]

Thanks a lot for this @jagabomb.

I lean towards solution 1 because it does not distort the UI yet allows me, at the same time, to exploit its full functionality. My experience with certain "mobile" versions of full blown UIs (for example, Azure) is that access to functionality is very limited and I end up, more often than not, accessing the full UI through the browser to do what I need to do.

[jagabomb]

@abravosuse Thanks for your feedback. I hear you, ideally it would be nice to always have full functionality on mobile devices but sometimes there are UI/UX limitations because of screen size, storage, ram and even network limitations. Essentially, I think its about seeing how far we can implement features and then make adaptations based on the limitations.

But coming back to the simple approach to this PR, I think direction 1 is proving that will be more aligned to how we want users to be able to access Trento.