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

Hi Dave

On Fri, Jul 16, 2021 at 6:36 PM Dave Caughey <caugheyd(at)gmail(dot)com> wrote:

> 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.
>

Here "as loaded in the first batch" means we load the data on demand,
and it is based on the ON_DEMAND_RECORD_COUNT setting.

>
> 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).
>

By default, in preferences controls(label) are sorted alphabetically,
so because of that reason "Maximum column width" is placed above "Resize by
data?". We will try to incorporate your suggestions in the upcoming
releases.

>
> (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.
>

Will try to incorporate the above suggestions in the upcoming releases.

>
> 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*
>>
>

--
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres <http://edbpostgres.com>*

*Mobile: +91 976-788-8246*