Assign table variants based upon breakpoints

The only option the optimize screens for you type of device is to create a separate menu for each device and in this menu assign a table variant.

Hi Arjan,

While it is true that a variant would be able to adjust the visible columns in the grid and the form, variants also allow you to change the prefilters, editing possibilities, available details and such.

It would be very easy for a developer to mess up the user experience like this.

The idea is that the individual components are reactive to their available space within the screen type. The breakpoints of the screen type ensure re-ordering of the components, since the individual components cannot do this. This mechanism should not only kick in for certain devices as apps but also when a browser or PWA desktop window is tiny. Or when a nested detail has limited horizontal space.

Can you provide some examples where individual components do not meet expectations here while trying to visualise the subject on a device with limited space?

I am unable to provide you with a good example at this time. The client for which I was working that requested this feature has not replied to my question to provide an example. I have asked them multiple times.

@mperrott can you guys please provide a few examples?

Hi,

This item popped up when we initially designed our interface with the Universal GUI. We have a lot of users from our Legacy system having various screen resolutions. We have grouped them to 3 different resolutions from small, medium, large screens.

We wanted to limit the number of fields on the screen by using variant tables / screen types / breakpoints. Having separate table variant to control the visible and hidden columns for the particular screen component as per the selected screen type of the variant.

It would provide more flexibility but also more risk in messing it up as Anne mentioned.

Currently we have redesigned the screen layout and along with the Compact mode and further CSS styling we have achieved a single view that handles our needs. The idea is a nice to have feature.

We are glad to hear that the screen itself has been designed in a way that suits your needs.

And thank you for your input. This narrows down the core of this idea to dynamically hiding fields or columns within the components when the available space becomes more limited. Which components do you intend to use such a strategy for? The form, grid, card list?

The components are all designed to flexibly position the information depending on the available space. Granted, this might result in some information being scrolled out of initial view. However, this does allow any device, resolution or resized desktop or browser window to access and/or enter the required data.

I’m interested to hear on how those users with limited resolutions deal with the fact that they are presented with less information. Wouldn’t they rather have it available in a scrolling container?

Or is the information that is hidden really not that important?

As an FYI, for the large / medium / small user devices by default we respectively use Grid+Form (vertically split 50-50%) as default screen type / Grid (and Form in separate tab) as breakpoint screen type / Cardlist with 3-5 fields (and Form in separate tab) as 2nd breakpoint screen type. This generally prevents users from having to scroll sideways on their device.

I am strongly against hiding columns based on device/screen size. The strength of Universal GUI with Breakpoint screens is that we don’t need to limit functionality/data availability for end users, but only have to think about how to display it smartly.