Re: New 'Resize by data?' Maximum Width Feature - Mailing list pgadmin-support

The UI is indeed a bit confusing...

The explanatory text says "If set to True then data columns will auto-size to the maximum width of the data in the column as loaded in the first batch. If False, the column will be sized to the widest of the data type or column name."

What does "as loaded in the first batch" mean?   As the developers, I have no doubt that you guys understand what "first batch" is... but will users?  And does it matter (i.e., will the user make any different decisions based on the addition of "as loaded in the first batch"?)  And, what's the difference between "maximum width of the data in the column" vs "widest of the data type"?  I'm going to *guess* that "data type" implies some width governed by the number of characters required to display a BIGINT or a TIMESTAMP?   But if that's the case, then that's not really obvious from the explanatory text.  Also, I'd argue that most of the time when you have really wide columns that you want to constrain with a "Max col width" feature, it's because you have TEXT or blobs... and what is the width of that data type, in those cases?  And so if it boils down to just the width of the column name in the case of TEXT or blobs, and if this is the use case when people are most likely to want the maximum width, then why not just say "width of the column name", which is mostly accurate in cases where people are interested in this setting (it'll overlook the case when you have a short column name like "id" that holds a BIGINT, but likely no one will ever care that the column is actually wider than required by the name "id").   Don't introduce confusion in explanatory text to ensure that you're accurately describing corner cases.

Furthermore, the "Resize by data?" and "Maximum column width" controls should be swapped.   I.e., "Resize by data?" is the governing control, and "Max col width" *only* applies when "Resize?" is True.   So one would normally expect "Resize?" to be above "Max col width".  And, typically when a control is only applicable based on the state of a governing control, it's better to disable the control entirely, so users will clearly see that the subordinate control's value is not applicable.   E.g., when "Resize?" is false, then "Max col width" should be greyed-out.   Then you don't need explanatory text saying "If 'Resize by data?' is set to False then this setting won't take any effect."   Alternatively, you could entirely hide/show the subordinate control based on the value of the governing control, but this then creates discoverability issues.  I.e., imagine if support or documentation tells a user "just specify a value for 'Maximum column width'", but because the user has "Resize by data?" set to false, they can't find the control they're being told to change.  So in general, leaving a control visible (but disabled) is preferred.   And to make it obvious that a control is subordinate, it's ideal to indent it from the governing control, or put a group box around it, etc. (but this last point is mostly just "nice to have" usability, and has to fit in with how all the other settings and controls are being presented, because consistency is important, too).

(This is nitpicking... "this setting won't take any effect" is a (minor) translation issue.  In North American English, one would normally say "this setting won't *have* any effect", or more succinctly "this setting has no effect".)

Other options to consider: you could replace the "Resize by data?" and all the explanatory text by a toggle control like "Columns sized by [column name|data]", or by radio buttons that offer the same choice.   This way you don't have to explain what effect "True" and "False" have.

Cheers,

Dave

On Fri, Jul 16, 2021 at 2:42 AM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Doug

Maximum Width feature will only work when "Resize by data?'" is set to true, but if it is set to false then you will see the old behaviour where the column will be sized to the widest of the data type or column name. Maximum width is in pixel when it is set to 0 then columns will auto-size to the maximum width of the data in the column.

Changes to the maximum width in the preferences won't reflect in the currently opened tab. You have to open the new View/Data or Query Tool tab.

I have tested it so many times and working absolutely fine for me.

On Fri, Jul 16, 2021 at 12:31 AM Doug Reed <r.douglas.reed@gmail.com> wrote:

All,

The Maximum width feature produces strange behavior on a Mac.

Changing the value alone does not seem to work.  There is very strange behavior when setting the length.  It seems to only take effect if it is set before the 'Resize by data?' column is enabled, and any currently open Query Tools don't seem to honor it.

I cannot be too specific because the behavior is so erratic.  I have one table with a VERY WIDE column, so I was glad to see this feature.  I set it, enabled the flag and all of my columns became very narrow.  I thought maybe it was in pixels???  so I set it much bigger and nothing happened.  I exited the application and restarted it to no effect... narrow columns  I turned off the flag and enabled it, and my columns were HUGE!  ...  not in pixels!  I set the value smaller to no effect.  I then turned the flag off and back on, and a View Data -> All Rows was what I wanted on a refresh, but re-running the query in the Query Tool saw no change.

The feature is nice and seems to work, but setting it is confusing.  It seems that one needs to set it with the flag off, then enable the flag, and restart pgAdmin, or at least re-open any Query Tool Windows to get it to fully function???

Thanque to all the developers working on this tool.  Hopefully you guys will appreciate feedback on your work.  Hopefully it is nice to know someone actually uses the stuff you provide?

--

Regards,

Doug

--

Thanks & Regards

Akshay Joshi

pgAdmin Hacker | Principal Software Architect

EDB Postgres

Mobile: +91 976-788-8246