13.0p+ ListGrid savingPreferences question/feedback

[Blama]

Hi Isomorphic,

please see this sample (v13.0p_2024-09-06, also 13.1d) and do the following steps:

1. Start sample
2. Make the "Capital" column very wide, introducing a horizontal scrollbar
3. Save this setting as "Wide with scrollbar"
4. Switch to "Default" view
5. Switch to "Wide with scrollbar" view
6. You will notice that the ListGrid does not have a scrollbar, the "Capital" column is very wide and all the other columns are unreadable-narrow

This is IMHO not what the user wants. The user wants to save the ListGrid in its current state, this includes the width of the columns that very not manually set.
And when one goes back to the saved setting it should like it looked before.

What do you think?

Best regards
Blama

[Isomorphic]

It's not quite so simple. If the user saves those settings, then returns later with a device with a much wider screen, what then? It's clearly not that we want to introduce a scrollbar even with plenty of room... it's also not right to freeze every column at the width they ended up after the resize, as that would mean that columns that could take advantage of the additional space would not.

So, the correct solution here is not for the framework's viewState system to change, but for the application developer to intelligently apply minWidth & autoFit settings. This will mean that if the user has resized a column very wide, horizontal scrolling will occur if it is needed, and if the user arrives with a much wider screen (or collapses an adjacent element to make more room on the existing screen) then "*"- or "%"-sized columns will take advantage of the extra space, once minimums have been satisfied.

[Blama]

Hi Isomorphic,

thanks for the hint on "but for the application developer to intelligently apply minWidth & autoFit settings". I think what you are saying makes sense, even though most likely the typical user one doesn't often use multiple computers with severely different settings. But it is good to be prepared for this anyway.

What would IMHO really already help the default case is a higher setting of minFieldWidth, which is 15 right now. Set to 100, the steps from #1 directly produce a nice result, even without the developer setting anything per-column. So unless there is a good reason for this default, I think a lot of people would benefit from this being set to a higher value.
Of course I know I can easily set this myself application-wide, but again, as value higher than 15 might be better.

Best regards
Blama

[Isomorphic]

We wouldn't recommend this because there are many fields that cannot use 100px, such as fields that show just an icon, fields that show just part of date, fields that show small numbers or short textual codes (like country codes).

[Blama]

Hi Isomorphic,

in the end it is the developer's task to tweak this. I'm just thinking of a better default (that could also be lowered be the developer for specific fields). Perhaps 100 is too much, but even your flag field in the sample has a defined width of 60.
15 is not enough for any sensible data display and will only let the user know "here is a column".

Best regards
Blama

[Isomorphic]

Yes, that is exactly what it is designed to do. Some combination of the app developer not thinking through sizes, or the end user doing something odd, has resulted in basically no space for a field. At that point, the 15px minimum makes it possible to recover - and that's what it's for.

[Blama]

Hi Isomorphic,

OK, thanks. My takeaway from this is: "Do set a sensible minWidth on every field and perhaps change the minFieldWidth and autoFitWidthApproach per ListGrid in order for the autoFit system to always produce nice results".

Best regards
Blama

[Isomorphic]

No, that's just about the exact opposite of what we recommend from a UE perspective.

The problem is, you're thinking like a developer who always wants the screen to "look reasonable", and you are not thinking like an end user, who wants to get a specific task done.

When the end user has resized a particular field within a particular view to be larger, that means that field is salient to them for that specific task. If, due to resizing the browser window, or perhaps expanding a side panel, other fields shrink down to what is effectively a "minimized" state (15px across), that's fine for the end user - the salient fields are still visible, and the rest of the fields are still easily accessible.

Specifically, they can get to the other fields by giving the grid more horizontal space. If they instead want to fit them into the current space, those other fields can be identified quickly via hover (on header or values) and are just a double-click or resize away from being made readable. Forcing horizontal scrolling makes this interaction take more clicks, and once horizontal scrolling has been introduced, resizing fields to fit the viewport becomes a bit awkward.

Further, realize that the system already auto-sizes fields of type "icon", type "date"/"time"/"datetime", certain non-FK numeric fields, and also fields with a small specified dataSourceField.length and no valueMap. The rest of the fields split space.

With all this in mind, our general advice is actually: do nothing, unless you have absolute certainty about the sole purpose for which end users use the grid, and even then, be very careful.

At most, set an initial width (not minWidth) for fields where you know it has a fixed width that it needs but the system can't figure that out. Or consider setting percents for a 30/70 ratio between the two text fields that aren't auto-sized.

Most of the rest of what you might think you should do is actually going to end up infuriating end users at some point, because from the user's perspective, they just told the software exactly what they want in the view, and it keeps making assumptions, keeps forcing data into their way that they don't need to see for their current task.

In a nutshell: trust the end user. They will often end up using your software in a way you didn't envision, especially if your software has some longevity to it. The less assumptions you make, the most power you give to the end user, the more effective they will be when their tasks drift out of the narrow set of tasks envisioned during initial design.

[Blama]

Hi Isomorphic,

thank you for the detailed explanation. I'll continue to go with the default then.

Best regards
Blama