Re: New 'Resize by data?' Maximum Width Feature

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(dot)joshi(at)enterprisedb(dot)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(dot)douglas(dot)reed(at)gmail(dot)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 <http://edbpostgres.com>*
>
> *Mobile: +91 976-788-8246*
>