Re: Query tool data grid - Infinite scroll vs Pagination

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 <caugheyd(at)gmail(dot)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 <umk555(at)gmail(dot)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(dot)toshniwal(at)enterprisedb(dot)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(dot)toshniwal(at)enterprisedb(dot)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 <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <
>>>>> aditya(dot)toshniwal(at)enterprisedb(dot)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"