Re: Query tool data grid - Infinite scroll vs Pagination

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Khushboo Vashi <[email protected]>
To: Dave Page <[email protected]>
Cc: Akshay Joshi <[email protected]>
Cc: Aditya Toshniwal <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: Query tool data grid - Infinite scroll vs Pagination
Date: Thu, 8 Aug 2024 18:37:48 +0530
Message-ID: <CAFOhELfdA6YUfy+hRoOYZSx7u0hdFFc0PyKqn7KQc_kR83PMcA@mail.gmail.com> (raw)
In-Reply-To: <CA+OCxoxXg2q_H9ZS-7Ae8x65uH5hLTKGtQgqq9oLbmAJCpQWKA@mail.gmail.com>
References: <CAM9w-_mJkHpqE2BSdBsLqOVO4ARaWPDXZGYb5Hn3eMh+sDcOrg@mail.gmail.com>
	<CA+OCxozbRmSmRytM2_4_gNvbpqrX0fEyfFVzYPVWH8ftxHchrQ@mail.gmail.com>
	<CAM9w-_n6Eo2SBPMjF-SD1NoWD7_RkhKk+=bPC4sYf3QYOP1wog@mail.gmail.com>
	<CAM9w-_n2zyK-fGYKedi59Z_t3-6LTfZeD0_Bgz4EWXhrS6=Zuw@mail.gmail.com>
	<CANVC+REpfUds0p7intQAwg64=NDk=TQK4HYjri68sy1QqKKDWg@mail.gmail.com>
	<CAAj2gHxghgC1Q7XyyzprNjxuXkLJ3_OZH83dN6w33sXOQEyO3A@mail.gmail.com>
	<CAM9w-_n+Bw_LULacX9CSDzdUK4Rm0QgqnpThiAa53W-0rqV0pg@mail.gmail.com>
	<CAM9w-_mWgZZJskhxr7p3ABvDwdEM=FfGPKfkuBK8jom7wuzrVQ@mail.gmail.com>
	<CPVP215MB18231B703A8AAA097C74D49FCFB32@CPVP215MB1823.LAMP215.PROD.OUTLOOK.COM>
	<CAG8xnicRwc5JyCBHgsDi-kD5w-AYBt86-C-yQeZBmuYjsy1Lmg@mail.gmail.com>
	<CAM9w-_kB2ym2RoU==1=kmBHtABbVJv5azxFwioEnMZVZ6iehSw@mail.gmail.com>
	<CANxoLDexeQwhsOrsV83WjwmU8znr+yQrLYriFgqRTVygJbWrPw@mail.gmail.com>
	<CA+OCxoxXg2q_H9ZS-7Ae8x65uH5hLTKGtQgqq9oLbmAJCpQWKA@mail.gmail.com>

On Thu, Aug 8, 2024 at 6:31 PM Dave Page <[email protected]> wrote:

>
>
> On Thu, 8 Aug 2024 at 13:53, Akshay Joshi <[email protected]>
> wrote:
>
>>
>>
>> On Thu, Aug 8, 2024 at 6:17 PM Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hello Everyone,
>>>
>>> Just want to share the progress on this. Attached is a quick demo. It is
>>> not complete yet, but I just want to make sure I'm in the right direction.
>>>
>>> https://drive.google.com/file/d/1B7DuD2Wx2SABGPEEjc8o4RwYcNgu1t_s/view?usp=sharing
>>>
>>>     Excellent, I like the new design.
>>
>
> As do I. I do wonder if the ability to enter numbers for the page and the
> from/to rows is necessary. I guess it doesn't hurt.
>
It is not necessary but nice to have it.

>
>
>>
>>
>>> On Sat, Aug 3, 2024 at 7:39 PM Gus Spier <[email protected]> wrote:
>>>
>>>> I like the idea of gmail behavior.
>>>>
>>>> Regards,
>>>>
>>>> Gus Spier
>>>>
>>>> On Sat, Aug 3, 2024 at 5:45 AM Edson Richter <[email protected]>
>>>> wrote:
>>>>
>>>>> Love it!
>>>>> I believe the Gmail behavior is a good approach.
>>>>>
>>>>> Regards,
>>>>>
>>>>> ER
>>>>>
>>>>>
>>>>> Obter o Outlook para Android <https://aka.ms/AAb9ysg;
>>>>> ------------------------------
>>>>> *From:* Aditya Toshniwal <[email protected]>
>>>>> *Sent:* Friday, August 2, 2024 3:53:33 AM
>>>>> *To:* pgadmin-hackers <[email protected]>
>>>>> *Cc:* Usman Khan <[email protected]>; pgAdmin Support <
>>>>> [email protected]>; Dave Page <[email protected]>; Dave
>>>>> Caughey <[email protected]>
>>>>> *Subject:* Re: Query tool data grid - Infinite scroll vs Pagination
>>>>>
>>>>>
>>>>> Hi Hackers,
>>>>>
>>>>>
>>>>> I have come up with the following design, which allows:
>>>>>
>>>>> 1. Adjust the range of rows visible, aka Window.
>>>>>
>>>>> 2. Jump to a page number directly based on rows window size.
>>>>>
>>>>> 3. Pagination buttons to move forward and backward.
>>>>>
>>>>>
>>>>> My question is, how should "select all" behave now? Previously we used
>>>>> to fetch all the rows when select all was clicked which actually slowed
>>>>> down as it took time for large data.
>>>>>
>>>>> Maybe add a new button to virtually "Select All Rows".
>>>>>
>>>>>
>>>>> [image: image (15).png]
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 2, 2024 at 6:16 PM Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>> Thank you Dave and others for your valuable feedback.
>>>>> We'll try to achieve what is best for the users.
>>>>>
>>>>> On Tue, Jul 2, 2024 at 5:46 PM Dave Caughey <[email protected]>
>>>>> wrote:
>>>>>
>>>>> I think there's a nice blend between pagination and infinite scrolling.
>>>>>
>>>>> The problem with the *current *infinite scrolling implementation is
>>>>> that the scroll baris scaled to the number of *rendered* rows, so as you
>>>>> scroll down (which renders another bunch of records), it keeps
>>>>> rescaling the scrollbar, so to get the next "page", you have to continually
>>>>> move to the scrollbar (as Aditya says, "*Many users who want access
>>>>> in between rows or last row struggle to do it as the user has to scroll and
>>>>> scroll.*")
>>>>>
>>>>> If instead the scrollbar were scaled to the total number of rows,
>>>>> (e.g., 1000 rather than the initial 25 rows that were rendered), then
>>>>> clicking (say) in the lower third of the scrollbar would would do enough
>>>>> fetching/rendering to display rows 601-625 (or such).  Problem solved.
>>>>>
>>>>> Alternatively (or additionally), provide a "jump to row..." button
>>>>> (similar to what Usman is suggesting re pagination) that gives the user
>>>>> control to see a specific bunch of records quickly.
>>>>>
>>>>> But if the issue is that people don't like infinite scrolling because
>>>>> "the user has to scroll and scroll", then fix that specific UE issue, and
>>>>> people will be happy.
>>>>>
>>>>> The concern I have with a paginated solution is if the page represents
>>>>> the maximum number of rows rendered in the results pane, at any one time.
>>>>> Assume I can see 25 rows in the result pane.  I.e., you show rows 1-25 for
>>>>> the first page, then you *only *show rows 26-50 for the second page,
>>>>> then *only *show rows 27-50, etc. But when there is a cluster of
>>>>> records of interest between rows 640 and 655, then those records of
>>>>> interest are going to be spread between pages 25 and 26, and will
>>>>> constantly require flipping back and forth between pages.  This would be
>>>>> possibly worse UE than the current "user has to scroll and scroll" issue.
>>>>> On the other hand, if your pagination solution includes letting someone
>>>>> nudge the rendered rows up or down a bit so that I can see rows 640-655 all
>>>>> at once (e.g., there's a field where I can type in that the current page
>>>>> should start at row 635, so I can see rows 640-655 all together), then I'm
>>>>> fine with that.
>>>>>
>>>>> However, if ultimately you decide to toss out infinite scrolling for
>>>>> pagination, then please make the (default?) page size be the number of rows
>>>>> you can actually see in the result pane, rather than some arbitrary number
>>>>> (e.g., 50).  Having the page size equal to the number of rendered rows
>>>>> means I can quickly step through the pages and hopefully notice a record of
>>>>> interest.... If the page size is larger than the number of rendered rows,
>>>>> then as I step to the next page I *still *have to scroll down to see
>>>>> the last few rows, then step to the next page, then scroll down again,
>>>>> I.e., that would be hideous UE!
>>>>>
>>>>> So my vote preferences are:
>>>>>
>>>>> First choice: keep infinite scrolling, but simply fix the scrollbar
>>>>> scaling and/or give the user the means to quickly jump down by a page or to
>>>>> a specific page
>>>>> Second choice: use pagination, but *only *if there's the ability to
>>>>> see a specific chunk of records on a single page (rather than spread across
>>>>> two), and make the pagination size default to the number of records visible
>>>>> given the height of the result pane
>>>>>
>>>>> Cheers,
>>>>> Dave
>>>>>
>>>>>
>>>>> On Mon, 1 Jul 2024 at 04:35, Usman Khan <[email protected]> wrote:
>>>>>
>>>>> Hi Aditya
>>>>> I vote for pagination, it would really be helpful for end users.
>>>>> In addition to giving the user the ability to set page size, if he can
>>>>> also select or enter what page he can jump to say 501, 990 etc it would be
>>>>> helpful.
>>>>>
>>>>> On Fri, Jun 28, 2024 at 3:44 PM Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Unfortunately, there were only 3 responses to this.
>>>>> In that case, we will discuss internally and decide what to do.
>>>>>
>>>>> On Thu, Jun 20, 2024 at 2:46 PM Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> Request you to share your opinion on this and respond on:
>>>>>
>>>>> https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?...
>>>>>
>>>>> On Thu, Jun 20, 2024 at 1:36 PM Dave Page <[email protected]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>> Hi Hackers,
>>>>>
>>>>> Query tool data grid currently pulls the data on load basis in
>>>>> batches. For example, it will initially load only 1000 rows and once a user
>>>>> scrolls to the 1000th row, it will fetch the next batch of 1000.
>>>>> Many users who want access in between rows or last row struggle to do
>>>>> it as the user has to scroll and scroll. If someone grabs the scroller and
>>>>> pulls it down still it will be a good UX and the scrollbar may jump. One
>>>>> reported here - https://github.com/pgadmin-org/pgadmin4/issues/1780
>>>>> One more aspect to this is the in memory data of the query tool which
>>>>> keep on increasing on each scroll, it affects the performance.
>>>>>
>>>>> I propose we should use pagination instead of infinite scroll with the
>>>>> following advantages:
>>>>> 1. Users can jump to any page they want.
>>>>> 2. Users can change the page size on the grid directly.
>>>>> 3. Memory will be used only for visible rows so performance
>>>>> improvement.
>>>>> 4. Predictable UI, no jumping scrollbars.
>>>>>
>>>>> Let me know what you think.
>>>>>
>>>>>
>>>>>
>>>>> I think there are definite benefits, but there is the downside of
>>>>> having to scroll and click to browse results. Personally I'm fine with
>>>>> that, but I think you should probably poll pgadmin-support for opinions
>>>>> from more users.
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> pgAdmin: https://www.pgadmin.org
>>>>> PostgreSQL: https://www.postgresql.org
>>>>> EDB: https://www.enterprisedb.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Aditya Toshniwal
>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>> <https://www.enterprisedb.com/;
>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Aditya Toshniwal
>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>> <https://www.enterprisedb.com/;
>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Aditya Toshniwal
>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>> <https://www.enterprisedb.com/;
>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Aditya Toshniwal
>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>> <https://www.enterprisedb.com/;
>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>
>>>>
>>>
>>> --
>>> Thanks,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>> <https://www.enterprisedb.com/;
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> EDB: https://www.enterprisedb.com
>
> PGDay UK 2024, 11th September, London: https://2024.pgday.uk/
>
>


Attachments:

  [image/png] image (15).png (172.0K, 3-image%20%2815%29.png)
  download | view image

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Query tool data grid - Infinite scroll vs Pagination
  In-Reply-To: <CAFOhELfdA6YUfy+hRoOYZSx7u0hdFFc0PyKqn7KQc_kR83PMcA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox