Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOdTV-000Lmf-6l for pgadmin-hackers@arkaria.postgresql.org; Tue, 02 Jul 2024 13:23:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sOdTT-001wlQ-6B for pgadmin-hackers@arkaria.postgresql.org; Tue, 02 Jul 2024 13:23:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOcuJ-001kQK-BW for pgadmin-hackers@lists.postgresql.org; Tue, 02 Jul 2024 12:46:52 +0000 Received: from mail-ot1-x334.google.com ([2607:f8b0:4864:20::334]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sOcuE-0002H0-O9 for pgadmin-hackers@postgresql.org; Tue, 02 Jul 2024 12:46:50 +0000 Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-70223330a73so196346a34.0 for ; Tue, 02 Jul 2024 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1719924406; x=1720529206; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SAatpdZWE66D2ug2yir9JkMNOfcpG1TRVAUN0XmhTlM=; b=Sn6Nq3Y19FHUiqBraNk2Pde1XNec7Irxtlgx8D4C/qa2zRQHtY/Y+waKPPUK3aKWJo I1AImDknaBU1e0SFQPUPcYPQHubkyPf3freg2WeVS8Hx5JeVKjqUhECKyk6bUV1lfpm9 C1E6clnMzetlohL82mThpksTJ00SiOETWVU+1KOtx9UYQYwjW2AnRn0LLE8RPVlyz+wo z42h2Xo6K0BES738ih6FURFEoLECuRplG5UNbqaPDWJutimlmpACYwQYV7WU4TvzNrVQ 6jPv0dPIlFWySNg6z+hgzvFhR1w8TjrVbi8F6tnRP7PiOUzTz9QDROQBH1YO9bRGmzPi gbuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719924406; x=1720529206; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SAatpdZWE66D2ug2yir9JkMNOfcpG1TRVAUN0XmhTlM=; b=lXVRZYcOiGJy6mFWh+iJ/LRYKciqLb2Rw+Y2Qg8sc0WNzjvvNgXBKgRZj9ZkgwHE0n EN4cQQvL65oi5KQc4rkWuF12xkErOlAbqdBzIeLjSbWhSQ1f/RxZHr1bhCSE5wY16Oc7 7ygSppZYtE9CV+7/Hb0eTMACscibuLNMfEx1Zo33nhuKmMT01KOCENWXoeYagtXHvC3v kM/91wpyfrtEIypag30bWlXB5/Kq78o3XRn88cm5HzQzlAGF4DJid4CHabZU6zhZLUFa OsvFqq0ZpindDzvSNZ2xpfgDrinE5ughpB9DwVMHjVysQsja+L1yd6tHRW1qQ1iWoP/a WrgQ== X-Forwarded-Encrypted: i=1; AJvYcCVaaz6QMKrCE7cKcQp7qkx5rQmEvseKHKsEXzI3f979pb374x97hFJnoYCUOsO/gd9sTCe9rRZKKeA9/wQ1gK12NJvGWAPbVtUa0p0AeTY= X-Gm-Message-State: AOJu0YwghaDugTr8/iWtnH43+kGBYz/akhwKZSZv8lEhzUR11Ek1r3k9 dlTGdgXkZ1T4o29Zv0c23WzdS1EYTVAGl/EFiGEJxxzkq7fH9redJeraXJP7BwWB7Sfcvyzw1+c 8jdHEPdVwstJakQhszJ3BpfuKN1q1gJqp1sYf X-Google-Smtp-Source: AGHT+IEfWWPp+JDF5ckFlEP9JxB/GNsqEypyJF8nOBQLejZPJUnmHkCH7vCkban3ea8KeD2IRiSZvu4Mr0Jr83DYLQE= X-Received: by 2002:a9d:7506:0:b0:6f9:9a5a:662 with SMTP id 46e09a7af769-701fa98a583mr5315027a34.3.1719924405550; Tue, 02 Jul 2024 05:46:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Tue, 2 Jul 2024 18:16:09 +0530 Message-ID: Subject: Re: Query tool data grid - Infinite scroll vs Pagination To: Dave Caughey Cc: Usman Khan , pgAdmin Support , pgadmin-hackers , Dave Page Content-Type: multipart/alternative; boundary="0000000000003bdcdb061c431bea" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003bdcdb061c431bea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Dave Caughey wr= ote: > 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 scrol= l > 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 "th= e > user has to scroll and scroll", then fix that specific UE issue, and peop= le > will be happy. > > The concern I have with a paginated solution is if the page represents th= e > 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 fo= r > 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 curren= t > "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 ro= ws > you can actually see in the result pane, rather than some arbitrary numbe= r > (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 giv= en > the height of the result pane > > Cheers, > Dave > > > On Mon, 1 Jul 2024 at 04:35, Usman Khan 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=E2=80=AFPM Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> 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=E2=80=AFPM Aditya Toshniwal < >>> aditya.toshniwal@enterprisedb.com> wrote: >>> >>>> Hi Everyone, >>>> >>>> Request you to share your opinion on this and respond on: >>>> >>>> https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hi= ZVxhv6GGJo8WJcYc27ug/viewform?usp=3Dsharing >>>> >>>> On Thu, Jun 20, 2024 at 1:36=E2=80=AFPM Dave Page = wrote: >>>> >>>>> Hi >>>>> >>>>> On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal < >>>>> aditya.toshniwal@enterprisedb.com> 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 d= o >>>>>> it as the user has to scroll and scroll. If someone grabs the scroll= er 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 whic= h >>>>>> 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 wit= h >>>>> that, but I think you should probably poll pgadmin-support for opinio= ns >>>>> 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* >>>> >>>> "Don't Complain about Heat, Plant a TREE" >>>> >>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* >>> >>> "Don't Complain about Heat, Plant a TREE" >>> >> --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --0000000000003bdcdb061c431bea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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:4= 6=E2=80=AFPM Dave Caughey <caughey= d@gmail.com> wrote:
I think there's a nice ble= nd between pagination=C2=A0and infinite scrolling.
The problem with the current infinite scrol= ling implementation is that the scroll baris scaled to the number of *rende= red* rows, so as you scroll down (which renders another bunch of records), = it keeps rescaling=C2=A0the 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 sc= roll.")

If instead the scrollbar were s= caled to the total number of rows, (e.g., 1000 rather than the initial 25 r= ows that were rendered), then clicking (say) in the lower third of the scro= llbar would would do enough fetching/rendering to display rows 601-625 (or = such).=C2=A0 Problem solved.

Alternati= vely (or additionally), provide a "jump to row..." button (simila= r to what Usman is suggesting re pagination) that gives the user control to= see a specific bunch of records quickly.

<= div>But if the issue is that people don't like infinite scrolling becau= se "the user has to scroll and scroll", then fix that specific UE= issue, and people will be happy.

The concern I ha= ve with a paginated solution is if the page represents the maximum number o= f rows rendered in the results pane, at any one time.=C2=A0 Assume I can se= e 25 rows in the result pane.=C2=A0 I.e., you show rows 1-25 for the first = page, then you only show rows 26-50 for the second page, then onl= y show rows 27-50, etc. But when there is a cluster of records of inter= est between rows 640 and 655, then those records of interest are going to b= e spread between pages 25 and 26, and will constantly require flipping back= and forth between pages.=C2=A0 This would be possibly worse UE than the cu= rrent "user has to scroll and scroll" issue.=C2=A0 On the other h= and, if your=C2=A0pagination solution includes letting someone nudge the re= ndered 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 st= art at row 635, so I can see rows 640-655 all together), then I'm fine = with that.

However, if ultimately=C2=A0you decide = to toss out infinite scrolling for pagination, then please make the (defaul= t?) page size be the number of rows you can actually see in the result pane= , rather than some arbitrary number (e.g., 50).=C2=A0 Having the page size = equal to the number of rendered rows means I can quickly step through the p= ages and hopefully notice a record of interest.... If the page size is larg= er than the number of rendered rows, then as I step to the next page I s= till have to scroll down to see the last few rows, then step to the nex= t page, then scroll down again,=C2=A0 I.e., that would be hideous UE!
=

So my vote preferences are:

Fi= rst choice: keep infinite scrolling, but simply fix the scrollbar scaling a= nd/or give the user the means to quickly jump down by a page or to a specif= ic page
Second choice: use pagination, but only if there&#= 39;s the ability to see a specific chunk of records on a single page (rathe= r than spread across two), and make the pagination size default to the numb= er of records visible given the height of the result pane

Cheers,
Dave


=
On Mon, 1 = Jul 2024 at 04:35, Usman Khan <umk555@gmail.com> wrote:
Hi Aditya
I vote for pagi= nation, 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 ente= r what page he can jump to say 501, 990 etc it would be helpful.=C2=A0
<= /div>

On Fri, Jun 28, 2024 at 3:44=E2=80=AFPM Aditya Toshniwal <aditya.tosh= niwal@enterprisedb.com> wrote:
Hi,

=
Unfortunately, there were onl= y 3 responses to this.
I= n that case, we will discuss=C2=A0internally and decide what to do.

On= Thu, Jun 20, 2024 at 2:46=E2=80=AFPM Aditya Toshniwal <aditya.toshniwal@ent= erprisedb.com> wrote:

On Thu, Jun 20, 2024 at 1:36= =E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Wed, 19 Jun 2024 at 13:42= , Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Hackers,

Query tool data grid currently pulls the data on load basis in bat= ches. For example, it will initially load only 1000 rows and once a user sc= rolls to the 1000th row, it will fetch the next batch of 1000.
Many users who want access in betwee= n 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 -=C2=A0https://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 performa= nce.

I propose we should use pagination ins= tead of infinite scroll with the following advantages:
1. Users can jump to any page they want.
2. Users can change the pag= e size on the grid directly.
3. Memory will be used only for visible rows so performance improvemen= t.
4. Predictable UI, no= jumping scrollbars.
Let me know what=C2=A0= you think.


I think there are definite benefits, but there is the downside of ha= ving to scroll and click to browse results. Personally I'm fine with th= at, but I think you should probably poll pgadmin-support for opinions from = more users.

-- <= /span>


--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com

--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com

--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com