public inbox for [email protected]help / color / mirror / Atom feed
Query tool data grid - Infinite scroll vs Pagination 28+ messages / 10 participants [nested] [flat]
* Query tool data grid - Infinite scroll vs Pagination @ 2024-06-19 12:41 Aditya Toshniwal <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-06-19 12:41 UTC (permalink / raw) To: pgadmin-hackers 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. -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* <https://www.enterprisedb.com/; "Don't Complain about Heat, Plant a TREE" ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-20 08:06 Dave Page <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Dave Page @ 2024-06-20 08:06 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgadmin-hackers 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 ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-20 09:16 Aditya Toshniwal <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-06-20 09:16 UTC (permalink / raw) To: pgAdmin Support <[email protected]>; +Cc: pgadmin-hackers; Dave Page <[email protected]> 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" ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-28 08:33 Aditya Toshniwal <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 3 replies; 28+ messages in thread From: Aditya Toshniwal @ 2024-06-28 08:33 UTC (permalink / raw) To: pgAdmin Support <[email protected]>; +Cc: pgadmin-hackers; Dave Page <[email protected]> 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" ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-28 12:09 Muhammad Ikram <[email protected]> parent: Aditya Toshniwal <[email protected]> 2 siblings, 0 replies; 28+ messages in thread From: Muhammad Ikram @ 2024-06-28 12:09 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: Dave Page <[email protected]>; pgAdmin Support <[email protected]>; pgadmin-hackers Hi Aditya, Pagination approach has my vote Muhammad Ikram On Fri, 28 Jun 2024 at 15:44, 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" > ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-28 13:17 Edson Richter <[email protected]> parent: Aditya Toshniwal <[email protected]> 2 siblings, 1 reply; 28+ messages in thread From: Edson Richter @ 2024-06-28 13:17 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; pgAdmin Support <[email protected]>; +Cc: pgadmin-hackers; Dave Page <[email protected]> Infinite scroll usually consume a lot of memory, and generate additional overhead in case of copy data, export, etc. In my humble opinion, if anything then paginated would work better without additional memory consumption. In case of implementing infinite scroll, please give users a option to disable it. Thanks, Edson Obter o Outlook para Android<https://aka.ms/AAb9ysg; ________________________________ From: Aditya Toshniwal <[email protected]> Sent: Friday, June 28, 2024 5:33:45 AM To: pgAdmin Support <[email protected]> Cc: pgadmin-hackers <[email protected]>; Dave Page <[email protected]> Subject: Re: Query tool data grid - Infinite scroll vs Pagination 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]<mailto:[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]<mailto:[email protected]>> wrote: Hi On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <[email protected]<mailto:[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" ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-28 16:42 Aditya Toshniwal <[email protected]> parent: Edson Richter <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-06-28 16:42 UTC (permalink / raw) To: Edson Richter <[email protected]>; +Cc: pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> Hi Edson, The current implementation is infinite scroll. We're planning to replace/improve it. On Fri, Jun 28, 2024 at 6:48 PM Edson Richter <[email protected]> wrote: > Infinite scroll usually consume a lot of memory, and generate additional > overhead in case of copy data, export, etc. In my humble opinion, if > anything then paginated would work better without additional memory > consumption. > In case of implementing infinite scroll, please give users a option to > disable it. > > Thanks, > > Edson > > Obter o Outlook para Android <https://aka.ms/AAb9ysg; > ------------------------------ > *From:* Aditya Toshniwal <[email protected]> > *Sent:* Friday, June 28, 2024 5:33:45 AM > *To:* pgAdmin Support <[email protected]> > *Cc:* pgadmin-hackers <[email protected]>; Dave Page < > [email protected]> > *Subject:* Re: Query tool data grid - Infinite scroll vs Pagination > > 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" ^ permalink raw reply [nested|flat] 28+ messages in thread
* RES: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-28 17:30 Edson Richter <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 0 replies; 28+ messages in thread From: Edson Richter @ 2024-06-28 17:30 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> 😊 Sorry – I’ve never used it as infinite scroll, I always use “limit n” in my queries (where n is tipically 10) just to develop and test my queries, and use for larger datasets some scripting tool (like Go or Python). I’ve tables with 2 bi rows, and forgetting to use “limit” is deadly slow. I love the way you guys deal with those improvements, they are always welcome. Kind regards, Edson De: Aditya Toshniwal <[email protected]> Enviada em: sexta-feira, 28 de junho de 2024 13:42 Para: Edson Richter <[email protected]> Cc: pgAdmin Support <[email protected]>; pgadmin-hackers <[email protected]>; Dave Page <[email protected]> Assunto: Re: Query tool data grid - Infinite scroll vs Pagination Hi Edson, The current implementation is infinite scroll. We're planning to replace/improve it. On Fri, Jun 28, 2024 at 6:48 PM Edson Richter <[email protected]<mailto:[email protected]>> wrote: Infinite scroll usually consume a lot of memory, and generate additional overhead in case of copy data, export, etc. In my humble opinion, if anything then paginated would work better without additional memory consumption. In case of implementing infinite scroll, please give users a option to disable it. Thanks, Edson Obter o Outlook para Android<https://aka.ms/AAb9ysg; ________________________________ From: Aditya Toshniwal <[email protected]<mailto:[email protected]>> Sent: Friday, June 28, 2024 5:33:45 AM To: pgAdmin Support <[email protected]<mailto:[email protected]>> Cc: pgadmin-hackers <[email protected]<mailto:[email protected]>>; Dave Page <[email protected]<mailto:[email protected]>> Subject: Re: Query tool data grid - Infinite scroll vs Pagination 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]<mailto:[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]<mailto:[email protected]>> wrote: Hi On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <[email protected]<mailto:[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" ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-06-28 19:53 Usman Khan <[email protected]> parent: Aditya Toshniwal <[email protected]> 2 siblings, 2 replies; 28+ messages in thread From: Usman Khan @ 2024-06-28 19:53 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> 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" > ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-07-01 12:42 Anthony DeBarros <[email protected]> parent: Usman Khan <[email protected]> 1 sibling, 1 reply; 28+ messages in thread From: Anthony DeBarros @ 2024-07-01 12:42 UTC (permalink / raw) To: Usman Khan <[email protected]>; +Cc: Aditya Toshniwal <[email protected]>; pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> If I may add, please have pgAdmin display the total number of rows in the result set regardless of pagination page size. On Mon, Jul 1, 2024 at 4:35 AM 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" >> > ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-07-01 12:57 Aditya Toshniwal <[email protected]> parent: Anthony DeBarros <[email protected]> 0 siblings, 0 replies; 28+ messages in thread From: Aditya Toshniwal @ 2024-07-01 12:57 UTC (permalink / raw) To: Anthony DeBarros <[email protected]>; +Cc: Usman Khan <[email protected]>; pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> Hi Anthony, We already do that. It says - 464 fetched out of the total 464 rows. [image: image.png] On Mon, Jul 1, 2024 at 6:12 PM Anthony DeBarros <[email protected]> wrote: > If I may add, please have pgAdmin display the total number of rows in the > result set regardless of pagination page size. > > On Mon, Jul 1, 2024 at 4:35 AM 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" Attachments: [image/png] image.png (11.6K, 3-image.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-07-02 12:16 Dave Caughey <[email protected]> parent: Usman Khan <[email protected]> 1 sibling, 1 reply; 28+ messages in thread From: Dave Caughey @ 2024-07-02 12:16 UTC (permalink / raw) To: Usman Khan <[email protected]>; +Cc: Aditya Toshniwal <[email protected]>; pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> 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" >> > ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-07-02 12:46 Aditya Toshniwal <[email protected]> parent: Dave Caughey <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-07-02 12:46 UTC (permalink / raw) To: Dave Caughey <[email protected]>; +Cc: Usman Khan <[email protected]>; pgAdmin Support <[email protected]>; pgadmin-hackers; Dave Page <[email protected]> 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" ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-02 06:53 Aditya Toshniwal <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 2 replies; 28+ messages in thread From: Aditya Toshniwal @ 2024-08-02 06:53 UTC (permalink / raw) To: pgadmin-hackers; +Cc: Usman Khan <[email protected]>; pgAdmin Support <[email protected]>; Dave Page <[email protected]>; Dave Caughey <[email protected]> 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" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-02 09:05 Dave Page <[email protected]> parent: Aditya Toshniwal <[email protected]> 1 sibling, 1 reply; 28+ messages in thread From: Dave Page @ 2024-08-02 09:05 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgadmin-hackers; Usman Khan <[email protected]>; pgAdmin Support <[email protected]>; Dave Caughey <[email protected]> On Fri, 2 Aug 2024 at 07:54, Aditya Toshniwal < [email protected]> wrote: > 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". > I'm reminded of how Gmail handles that. Maybe do something similar to that - Select All selects all the current page's rows, but then offers the option to select all rows from every page. > > [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" > -- 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 ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-02 10:04 Aditya Toshniwal <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 0 replies; 28+ messages in thread From: Aditya Toshniwal @ 2024-08-02 10:04 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: pgadmin-hackers; Usman Khan <[email protected]>; pgAdmin Support <[email protected]>; Dave Caughey <[email protected]> Hi Dave, On Fri, Aug 2, 2024 at 2:36 PM Dave Page <[email protected]> wrote: > > > On Fri, 2 Aug 2024 at 07:54, Aditya Toshniwal < > [email protected]> wrote: > >> 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". >> > > I'm reminded of how Gmail handles that. Maybe do something similar to that > - Select All selects all the current page's rows, but then offers the > option to select all rows from every page. > Yeah, I was thinking on similar lines. Thanks. > > >> >> [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" >> > > > -- > 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/ > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* <https://www.enterprisedb.com/; "Don't Complain about Heat, Plant a TREE" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-02 18:41 Edson Richter <[email protected]> parent: Aditya Toshniwal <[email protected]> 1 sibling, 1 reply; 28+ messages in thread From: Edson Richter @ 2024-08-02 18:41 UTC (permalink / raw) To: [email protected] <[email protected]>; pgadmin-hackers 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 (15).png] On Tue, Jul 2, 2024 at 6:16 PM Aditya Toshniwal <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: Hi On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <[email protected]<mailto:[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" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-03 12:32 Gus Spier <[email protected]> parent: Edson Richter <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Gus Spier @ 2024-08-03 12:32 UTC (permalink / raw) To: Edson Richter <[email protected]>; +Cc: [email protected] <[email protected]>; pgadmin-hackers 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" > Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-08 12:46 Aditya Toshniwal <[email protected]> parent: Gus Spier <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-08-08 12:46 UTC (permalink / raw) To: pgadmin-hackers 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 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" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-08 12:52 Akshay Joshi <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Akshay Joshi @ 2024-08-08 12:52 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgadmin-hackers 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. > 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" > Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-08 13:00 Dave Page <[email protected]> parent: Akshay Joshi <[email protected]> 0 siblings, 2 replies; 28+ messages in thread From: Dave Page @ 2024-08-08 13:00 UTC (permalink / raw) To: Akshay Joshi <[email protected]>; +Cc: Aditya Toshniwal <[email protected]>; pgadmin-hackers 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. > > >> 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 ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-08 13:07 Khushboo Vashi <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 0 replies; 28+ messages in thread From: Khushboo Vashi @ 2024-08-08 13:07 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Akshay Joshi <[email protected]>; Aditya Toshniwal <[email protected]>; pgadmin-hackers 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 ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-08 13:09 Aditya Toshniwal <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-08-08 13:09 UTC (permalink / raw) To: Dave Page <[email protected]>; Dave Caughey <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers Hi Dave, 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. > There was a suggestion from @Dave Caughey <[email protected]> to consider if a user wants to view rows from different pages together. So I thought of giving some flexibility. Since it will not be used by most of the users, it is collapsed under an edit button to save space. > > >> >> >>> 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/ > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* <https://www.enterprisedb.com/; "Don't Complain about Heat, Plant a TREE" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-22 10:11 Aditya Toshniwal <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 2 replies; 28+ messages in thread From: Aditya Toshniwal @ 2024-08-22 10:11 UTC (permalink / raw) To: pgadmin-hackers; +Cc: Dave Page <[email protected]> Hi All, I'm facing a problem here so request for suggestions. When I select rows, delete them and save the results - the rows are removed from the UI and from the DB. But, the cursor of the select query still has the result. When the page is changed, the rows come back again as they're still in the cursor memory. Same issue when a new row is added or any update is done. One way to tackle this problem is to execute the query again to refresh the data. What do you suggest? On Thu, Aug 8, 2024 at 6:39 PM Aditya Toshniwal < [email protected]> wrote: > Hi Dave, > > 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. >> > There was a suggestion from @Dave Caughey <[email protected]> to > consider if a user wants to view rows from different pages together. So > I thought of giving some flexibility. Since it will not be used by most of > the users, it is collapsed under an edit button to save space. > >> >> >>> >>> >>>> 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/ >> >> > > -- > 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" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-22 10:18 Dave Page <[email protected]> parent: Aditya Toshniwal <[email protected]> 1 sibling, 0 replies; 28+ messages in thread From: Dave Page @ 2024-08-22 10:18 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgadmin-hackers On Thu, 22 Aug 2024 at 11:12, Aditya Toshniwal < [email protected]> wrote: > Hi All, > > I'm facing a problem here so request for suggestions. > When I select rows, delete them and save the results - the rows are > removed from the UI and from the DB. But, the cursor of the select query > still has the result. > When the page is changed, the rows come back again as they're still in the > cursor memory. Same issue when a new row is added or any update is done. > One way to tackle this problem is to execute the query again to refresh > the data. > > What do you suggest? > That's really all you can do I think. > > On Thu, Aug 8, 2024 at 6:39 PM Aditya Toshniwal < > [email protected]> wrote: > >> Hi Dave, >> >> 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. >>> >> There was a suggestion from @Dave Caughey <[email protected]> to >> consider if a user wants to view rows from different pages together. So >> I thought of giving some flexibility. Since it will not be used by most of >> the users, it is collapsed under an edit button to save space. >> >>> >>> >>>> >>>> >>>>> 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/ >>> >>> >> >> -- >> 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 ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-22 10:26 Khushboo Vashi <[email protected]> parent: Aditya Toshniwal <[email protected]> 1 sibling, 1 reply; 28+ messages in thread From: Khushboo Vashi @ 2024-08-22 10:26 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgadmin-hackers; Dave Page <[email protected]> On Thu, Aug 22, 2024 at 3:42 PM Aditya Toshniwal < [email protected]> wrote: > Hi All, > > I'm facing a problem here so request for suggestions. > When I select rows, delete them and save the results - the rows are > removed from the UI and from the DB. But, the cursor of the select query > still has the result. > When the page is changed, the rows come back again as they're still in the > cursor memory. Same issue when a new row is added or any update is done. > One way to tackle this problem is to execute the query again to refresh > the data. > > What do you suggest? > > For delete, you can use scroll <https://www.psycopg.org/psycopg3/docs/api/cursors.html#psycopg.ServerCursor.scroll; method of the cursor as it takes relative and absolute both the positions but for add and update, executing a query is the option. On Thu, Aug 8, 2024 at 6:39 PM Aditya Toshniwal < > [email protected]> wrote: > >> Hi Dave, >> >> 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. >>> >> There was a suggestion from @Dave Caughey <[email protected]> to >> consider if a user wants to view rows from different pages together. So >> I thought of giving some flexibility. Since it will not be used by most of >> the users, it is collapsed under an edit button to save space. >> >>> >>> >>>> >>>> >>>>> 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/ >>> >>> >> >> -- >> 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" > Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-22 10:30 Aditya Toshniwal <[email protected]> parent: Khushboo Vashi <[email protected]> 0 siblings, 1 reply; 28+ messages in thread From: Aditya Toshniwal @ 2024-08-22 10:30 UTC (permalink / raw) To: Khushboo Vashi <[email protected]>; +Cc: pgadmin-hackers; Dave Page <[email protected]> Hi Khushboo, On Thu, Aug 22, 2024 at 3:56 PM Khushboo Vashi < [email protected]> wrote: > > > On Thu, Aug 22, 2024 at 3:42 PM Aditya Toshniwal < > [email protected]> wrote: > >> Hi All, >> >> I'm facing a problem here so request for suggestions. >> When I select rows, delete them and save the results - the rows are >> removed from the UI and from the DB. But, the cursor of the select query >> still has the result. >> When the page is changed, the rows come back again as they're still in >> the cursor memory. Same issue when a new row is added or any update is done. >> One way to tackle this problem is to execute the query again to refresh >> the data. >> >> What do you suggest? >> >> > For delete, you can use scroll > <https://www.psycopg.org/psycopg3/docs/api/cursors.html#psycopg.ServerCursor.scroll; method > of the cursor as it takes relative and absolute both the positions but for > add and update, executing a query is the option. > User may decide to delete in between rows. We'll have to keep track of those rows and skip them manually. It will make things odd and complex. > > On Thu, Aug 8, 2024 at 6:39 PM Aditya Toshniwal < >> [email protected]> wrote: >> >>> Hi Dave, >>> >>> 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. >>>> >>> There was a suggestion from @Dave Caughey <[email protected]> to >>> consider if a user wants to view rows from different pages together. So >>> I thought of giving some flexibility. Since it will not be used by most of >>> the users, it is collapsed under an edit button to save space. >>> >>>> >>>> >>>>> >>>>> >>>>>> 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/ >>>> >>>> >>> >>> -- >>> 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" Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Query tool data grid - Infinite scroll vs Pagination @ 2024-08-22 10:35 Khushboo Vashi <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 0 replies; 28+ messages in thread From: Khushboo Vashi @ 2024-08-22 10:35 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: pgadmin-hackers; Dave Page <[email protected]> On Thu, Aug 22, 2024 at 4:00 PM Aditya Toshniwal < [email protected]> wrote: > Hi Khushboo, > > On Thu, Aug 22, 2024 at 3:56 PM Khushboo Vashi < > [email protected]> wrote: > >> >> >> On Thu, Aug 22, 2024 at 3:42 PM Aditya Toshniwal < >> [email protected]> wrote: >> >>> Hi All, >>> >>> I'm facing a problem here so request for suggestions. >>> When I select rows, delete them and save the results - the rows are >>> removed from the UI and from the DB. But, the cursor of the select query >>> still has the result. >>> When the page is changed, the rows come back again as they're still in >>> the cursor memory. Same issue when a new row is added or any update is done. >>> One way to tackle this problem is to execute the query again to refresh >>> the data. >>> >>> What do you suggest? >>> >>> >> For delete, you can use scroll >> <https://www.psycopg.org/psycopg3/docs/api/cursors.html#psycopg.ServerCursor.scroll; method >> of the cursor as it takes relative and absolute both the positions but for >> add and update, executing a query is the option. >> > User may decide to delete in between rows. We'll have to keep track of > those rows and skip them manually. It will make things odd and complex. > Yes, manual tracking will be required. > >> On Thu, Aug 8, 2024 at 6:39 PM Aditya Toshniwal < >>> [email protected]> wrote: >>> >>>> Hi Dave, >>>> >>>> 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. >>>>> >>>> There was a suggestion from @Dave Caughey <[email protected]> to >>>> consider if a user wants to view rows from different pages together. So >>>> I thought of giving some flexibility. Since it will not be used by most of >>>> the users, it is collapsed under an edit button to save space. >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> 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/ >>>>> >>>>> >>>> >>>> -- >>>> 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" > Attachments: [image/png] image (15).png (172.0K, 3-image%20%2815%29.png) download | view image ^ permalink raw reply [nested|flat] 28+ messages in thread
end of thread, other threads:[~2024-08-22 10:35 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-19 12:41 Query tool data grid - Infinite scroll vs Pagination Aditya Toshniwal <[email protected]> 2024-06-20 08:06 ` Dave Page <[email protected]> 2024-06-20 09:16 ` Aditya Toshniwal <[email protected]> 2024-06-28 08:33 ` Aditya Toshniwal <[email protected]> 2024-06-28 12:09 ` Muhammad Ikram <[email protected]> 2024-06-28 13:17 ` Edson Richter <[email protected]> 2024-06-28 16:42 ` Aditya Toshniwal <[email protected]> 2024-06-28 17:30 ` RES: Query tool data grid - Infinite scroll vs Pagination Edson Richter <[email protected]> 2024-06-28 19:53 ` Usman Khan <[email protected]> 2024-07-01 12:42 ` Anthony DeBarros <[email protected]> 2024-07-01 12:57 ` Aditya Toshniwal <[email protected]> 2024-07-02 12:16 ` Dave Caughey <[email protected]> 2024-07-02 12:46 ` Aditya Toshniwal <[email protected]> 2024-08-02 06:53 ` Aditya Toshniwal <[email protected]> 2024-08-02 09:05 ` Dave Page <[email protected]> 2024-08-02 10:04 ` Aditya Toshniwal <[email protected]> 2024-08-02 18:41 ` Edson Richter <[email protected]> 2024-08-03 12:32 ` Gus Spier <[email protected]> 2024-08-08 12:46 ` Aditya Toshniwal <[email protected]> 2024-08-08 12:52 ` Akshay Joshi <[email protected]> 2024-08-08 13:00 ` Dave Page <[email protected]> 2024-08-08 13:07 ` Khushboo Vashi <[email protected]> 2024-08-08 13:09 ` Aditya Toshniwal <[email protected]> 2024-08-22 10:11 ` Aditya Toshniwal <[email protected]> 2024-08-22 10:18 ` Dave Page <[email protected]> 2024-08-22 10:26 ` Khushboo Vashi <[email protected]> 2024-08-22 10:30 ` Aditya Toshniwal <[email protected]> 2024-08-22 10:35 ` Khushboo Vashi <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox