[Freeipa-devel] Paging in Web UI

[Petr Vobornik]

On 08/29/2012 06:50 PM, Endi Sukma Dewata wrote:
> On 8/29/2012 8:49 AM, Petr Vobornik wrote:
>>> Another possibility is to use VLV, but it seems to require open
>>> connection too and only works with a predefined filter.
>>
>> Apart from the possible connection problem I think it is very usable for
>> default views of search pages. User can freely page. I don't understand
>> from the wiki page if it can reasonably obtain total record count.
>
> Correction, VLV doesn't seem to require a continuous connection.
>
> The server will return a 'contentCount' in the VLV response:
> http://www.ietf.org/proceedings/55/I-D/draft-ietf-ldapext-ldapv3-vlv-09.txt
>
>> IMO a modification of a hybrid solution may be best:
>>
>> When user opens page a VLV result would be shown. User can page and see
>> all the data. Currently we don't support custom sorting so disability of
>> custom sorting isn't an issue. With predefined sorts we can even
>> improved these possibilities.
>>
>> If there is many records and user don't want to go through pages he will
>> use search. If the search string is good he should fit to search limit
>> so I wouldn't use paging at this moment. If not the case and he really
>> don't know how to improve the filter he should have option to enable
>> paging (current implementation) and go through the records by hand. Such
>> record set should fit to limit of 2000 records. If not the filter is
>> really bad.
>
> The thing is the filter is only used on certain attributes only. For
> example I have a user with full name "Test User". Searching the "Test
> User" in the filter doesn't return anything because the server doesn't
> search the cn or displayName attributes. In that case I'd have to search
> with first name or last name only, which may return too many results.
>
>> If we don't want to implement VLV or until that time I would set
>> not-paging as default setting.
>
> How about this, when you open the search page for the first time it will
> do a regular search, no paging. Instead of showing the paging controls
> (Prev & Next buttons) we show "See more results..." If you click that it
> will rerun the search with paging (which will give us the total number
> of entries) and show the paging control.

I think we are in an agreement. It's basically what I wrote in different 
words. I just mentioned current size limit.

User workflow when searching for record (the same thing reworded):
1) open search page: VLV or normal search with empty filter
   1a) when VLV: user would see paging ui
   1b) when normal search: not sure if to show 'see more results' link 
for switching to paging. For smaller setups (<2000) it might be there, 
for larger rather not - pkey list would be truncated.
2) search for record: enter filter to textbox, normal search would be used
3) record not listed: switch to paging by clicking on 'see more results' 
Paging should be OK because most likely we would get less than 2000 
records. Otherwise filter should be improved. I guess we can't go around 
this unless we increase the limit or use other mean of paging.
4) record still not listed: page to find the record using current paging 
UI or some improved

>
>>> Agreed, but if we implement the single continuous page I described in
>>> the earlier email the page size won't be much of an issue anymore.
>>>
>> It may matter. For example when testing Web UI permissions. It often
>> requires to navigate to the last page. I can enter the number directly
>> and press enter or extend it for times (hypothetically) but I would
>> rather see those 90 permissions right away because I can be at the list
>> end in 0.5s.
>
> If we use a continuous page we can use a bigger default page size, say
> 100 entries. We probably could optimize it such that if you scroll
> directly to the bottom it will load just the last page.

Comments below.

> We probably could also combine it with initial non-paging search like above, so
> you'll need to click "See more results...", then the page will extend
> and you can scroll to the last entry.

Yes as I wrote above.

>
>> We can also improve pager to offer some subset of pages. For example:
>>
>> First Prev 22 23 *24* 25 26 Next Last Page [   ]
>> where 24 is current page.
>
> Yes, that will work too.
>
>> Regarding the continuous paging: I would extend the page by clicking at
>> a bar at the end of the list and/or by mouse-scrolling at the end of the
>> list?
>
> Ideally the scroll bar size should correspond to the visible part of the
> entire page. So you should be able to go anywhere in the entire page by
> moving the scroll bar around (either by keyboard, mouse click, mouse
> drag, or mouse scroll). In this case no need to extend the page.
> The thing is that we might have to create a table with many empty rows,
> which could be big, and populate them if they become visible. Maybe
> there's a way to avoid creating empty rows, we'll need to investigate.

Did you meant by 'continuous paging' this solution or the one when you 
click on 'see more results' (or scroll to last 10% of a scrollbar) and 
it would show you next page? I originally understood it as the latter 
but now I'm not sure.

This solution seems challenging to implement right. I'm also not sure 
how usable it is because I don't remember if I ever used it somewhere.

Anyway empty rows can be also replaced by rows with huge height.

>
> Alternatively we could do like image search on bing.com. If you bring
> the scroll bar say within 10% from the bottom it will load the next
> page. The thing is it will load the page sequentially, and if you
> continue to the bottom you'll end up with a very big table.
>

I like this with the Prev extension mentioned below.

> Another possibility, we can use the top 10% of the scroll bar as a Prev
> button, and the bottom %10 as the Next button, and we remove the pages
> that aren't visible anymore. But this is not much different than the
> current implementation, only different presentation.
>

I can image to use each of these 3 solutions for enabled paging. Also 
switching between second and third solution might be configurable.

Anyway. First I would like to make paging/not paging configurable and 
switchable when needed. Then we can proceed to improving paging ui 
(better pager, continuous paging and such).
-- 
Petr Vobornik