On 9/29/20 3:00 PM, Tom Lane wrote:
> Niels Andersen <niels@thinkiq.com> writes:
>> 2. Is there a middle ground?
>> * Version 12 had 6 columns, version 13 has one.
>> * Could we have fewer columns? What if we had 3 columns: One for operator or function, one for the details
anddescription, and one for an example with the results.
>
> A lot of these tables *did* have three columns before. They were still too
> wide. See e.g. "Table 9.88 Replication SQL Functions" in the v12 docs.
>
> Moreover, in a lot of places functions were just ridiculously
> under-documented because of the tiny amount of space available.
> If you compare v12 and v13 closely you'll notice that there's more
> text for many functions (9.35 Geometric Operators is a handy example);
> and there's room to add more now, wherever we need to.
>
> Note that another reason for making these changes was so that the
> tables would render in a less-than-completely-unreadable fashion in PDF
> output, which is a good deal narrower than what most people use for
> web browser windows (and a good deal less forgiving of overruns, too).
> But I think it's a net benefit for HTML output as well, in that the
> output does adapt much better than before to smaller window sizes.
> Not everybody wants to dedicate their whole screen to Postgres docs.
I'll also note it helps on mobile viewing as well. We (likely the royal
"we" in this case) still need to figure out some things with the font
size on mobile to make it a bit easier to read, but the measurable
readability of the tables in the v13 docs is better than v12 on smaller
browsing windows.
> Anyway, a very large amount of effort went into this redesign this
> past spring, and we already tried a lot of variants, and already went
> through the predictable complaints within the developer community.
> I'm disinclined to redesign it again right now. If people are still
> unhappy in a year or so, maybe there will be some appetite for a revisit.
I would say on this particular page, the only thing I find slightly
confusing is when the "->" operator is being described ("json -> integer
-> json"), but I think that may just be an unfortunate happenstance and
not grounds for redesign, at least at this time.
In recent times (which likely extends to the before times), I've found
when we've rolled out any UI/UX changes across pgweb properties there is
a mix of love/hate that is based on personal preference, which may or
may not coincide with what the overall goal of the change was.
If there is something that in a defined way is hampering usability, then
we should address it, but otherwise, per Tom's analysis, I would let
this bake a bit more and see if we want to make improvements towards the
end of the v14 development cycle.
Jonathan