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 <caugh...@gmail.com> 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 <umk...@gmail.com> 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 < >> aditya.toshni...@enterprisedb.com> wrote: >> >>> Hi, >>> >>> Unfortunately, there were only 3 responses to this. >>> In that case, we will discuss internally and decide what to do. >>> >>> On Thu, Jun 20, 2024 at 2:46 PM Aditya Toshniwal < >>> aditya.toshni...@enterprisedb.com> wrote: >>> >>>> Hi Everyone, >>>> >>>> Request you to share your opinion on this and respond on: >>>> >>>> https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing >>>> >>>> On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dp...@pgadmin.org> wrote: >>>> >>>>> Hi >>>>> >>>>> On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal < >>>>> aditya.toshni...@enterprisedb.com> wrote: >>>>> >>>>>> Hi Hackers, >>>>>> >>>>>> Query tool data grid currently pulls the data on load basis in >>>>>> batches. For example, it will initially load only 1000 rows and once a >>>>>> user >>>>>> scrolls to the 1000th row, it will fetch the next batch of 1000. >>>>>> Many users who want access in between rows or last row struggle to 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"
