Re: Proposal Dashboard design for system of pgadmin

On Mon, Jun 27, 2022 at 1:59 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Sun, 26 Jun 2022 at 12:40, Kunal Garg <gargkunal02(at)gmail(dot)com> wrote:
>
>> Plan:-
>>
>> To integrate a detailed view of system activity into the existing pgAdmin
>> dashboard following a consistent design that matches the existing UI/UX and
>> meets User Acceptance Testing Standards.
>>
>> Proposed Layout Design:-
>>
>>
>>
>>
> Some initial thoughts on what you propose to display:
>
> - OS Uptime should not be a graph. It's not overly useful, and will just
> trend upwards linearly before resetting to zero if there's a restart. Just
> make it a text label.
>
> - Thread count is probably less important than process count on a
> PostgreSQL server. I would probably show both, in a small chart as those
> are values that do change over time in response to system activity.
>
> - I would put the "system info" data (Host name, architecture, kernel,
> thread/process count etc) at the top as it's what you might consider
> overview or meta data. Then have the rest of the info below that, probably
> 2 full width columns with two rows for CPU, memory, disk, and network.
>
> - Consider what to display if there are multiple NICs on the system.
>
> - Consider what to display if there are multiple disks on the system - and
> there alway will be on a Linux machine for example. Many of them will be
> hidden here (e.g. /proc, /sys, tmpfs's), whilst others should be displayed.
> We cannot assume stats on only one disk are important, as the system might
> be configured with tablespaces or the WAL on different devices.
>
> Data fetched from queries:-
>>
>> Details of different queries will be shown on a given component/card as
>> shown in the design.
>>
>
> <snip data source info - that's more an implementation detail at this
> stage>
>
>
>>
>>
>> Impact on the existing layout:-
>>
>> Existing layout will remain the same for most of the part. Here are some
>> options for showing the system stats dashboard option to the users.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 1.
>>
>> New button for system statistics on the Dashboard Navbar (refer to
>> the red box in the image for the location of this button)
>>
>>
>>
>> UI impact when the system_stats extension is not present in the
>> PostgreSQL instance:
>>
>> The page will open as usual with the following message,
>>
>> “No system statistics information is available for the selected object”
>>
>>
>>
>> 1.
>>
>> On hovering over the Dashboard tab, a dropdown will come, giving the
>> user an option to select either the already existing pgadmin dashboard or
>> the system statistics dashboard. (refer to the green box in the image
>> for the location of this button)
>>
>>
>>
>> UI impact when the system_stats extension is not present in the
>> PostgreSQL instance:
>>
>> This will happen only when the user has not selected any server, then the
>> dashboard will open as usual as shown in the image.
>>
>>
>>
>> 1.
>>
>> On Selecting the Dashboard tab, 2 new buttons will be displayed under
>> the dashboard tab, clicking any one will show the respective dashboard.
>> (refer to the blue box in the image for the location of this button)
>>
>>
>>
>> UI impact when the system_stats extension is not present in the
>> PostgreSQL instance:
>>
>> This will happen only when the user has not selected any server, then the
>> dashboard will open as usual as shown in the image
>>
>>
>>
>> Note: The dashboards are contextual, they're dependent on the node
>> selected on the left-hand side tree, that is, the values change as per the
>> server node selected. Similarly, the system statistics dashboard will also
>> be contextual and change with the selected server.
>>
>
> I'm 90% sure I wouldn't want to see an additional dashboard (option 1),
> and option 3 would almost certainly require modifying the wcDocker library
> which I think is a bad idea. I would consider how to accommodate the
> additional information on the existing dashboard. A couple of ideas:
>
> 1) Move all the existing elements and the new elements into collapsible
> horizontal regions. Then you can display as much or as little as the user
> wants. This is essentially how it would work in Grafana.
>
> 2) Add sub tabs inside the dashboard. If (and only if) system_stats is
> present on a server, have a top-level tabset within the dashboard with tabs
> for "Database Info" (with the existing display) and "System Info". By
> default, the user is shown what they see now, but they can click the System
> Info tab to see that data. Remember the user's choice, so the same tab can
> be displayed first in the future. This is essentially your option 3, but
> using tabsets instead of buttons.
>
+1 for this approach.

>
>
>>
>>
>>
>>
>> Filters available in the preferences:-
>>
>> Under the files tab -> Preferences
>>
>> In preferences there are multiple dropdowns for different parts of the
>> dashboard, giving the user power to customize the dashboard as per their
>> need by enabling or disabling certain graphs and changing the refresh rate
>> of the graphs.
>>
>> In the preferences tab, there is a drop-down by the name of “dashboard”,
>> which gives 2 options for selecting “graphs” and “display”. A similar
>> layout will be followed for the “system statistics” dashboard.
>>
>
> Yes.
>
> Thanks!
>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>