Grouper Developers Forum

[Chris Hyzer <>]

If the UI had the total number, I would display it on the screen, but I would 
also tell the user to refine their search.  If they wanted to page they 
could, if they wanted to refine, they could.  But the UI doesn't have the 
total number, and wont for the foreseeable future, so we don't have to worry 
about this case.  The UI does not have the total number.

So do you agree that we should remove the paging buttons by default?

Thanks,
Chris




-----Original Message-----
From: Tom Barton 
[mailto:]
 
Sent: Monday, December 12, 2011 12:14 PM
To: Chris Hyzer
Cc: 

Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011

If I understand correctly, if the UI had the total number you would
allow the user to page through that result set and not ask the user to
refine their search? I thought we established that it's good to limit
result set sizes and require users to refine searches when that limit is
exceeded? Among other reasons why, that's probably the only workable
solution with an ldap subject source, which will be common among
deployments. And also a very common user experience, or at least common
to *this* user's experience!

If you agree with the need to limit result set size, then how would you
handle a max exceeded in the UI if the UI also had the actual result set
size?

Thanks,
Tom

On 12/12/2011 10:51 AM, Chris Hyzer wrote:
> Then I would show it on the screen, and if there were a capability to go to 
> the nth page, then I would have paging buttons :)
>
> I don't think this is easy/possible with ldap or it would be in there :)
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Monday, December 12, 2011 11:11 AM
> To: Chris Hyzer
> Cc: 
> 
> Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>
> Chris,
>
> What would you do if the fact that there are actually 5278 results was
> available to the UI?
>
> Tom
>
> On 12/12/2011 10:05 AM, Chris Hyzer wrote:
>> Let me explain again.
>>
>> If you search for something that returns a lot of results, lets say "th".
>>
>> The subject source will now return the max page size, which you configure, 
>> lets say it is set to 100.  Maybe of your 4 sources, you get a combined 
>> 137 results.  Lets say your page size on the UI is set to 50.  The UI will 
>> say:
>>
>> Please narrow your search, too many results, showing a partial listing of 
>> results 1-50 of 137 items.
>>
>> However, there are actually 5278 items that match "th"... but there is 
>> nothing in the subject API to tell the API the actual number.  All the 
>> API/UI knows is that there is more than 137.  Also, when you page through 
>> on the UI, you will only be able to see the 137.  So it looks like to the 
>> user there are 137 results, and it seems like they can page through all 
>> the results.  This is misleading and wrong, so we need to remove paging 
>> buttons from the UI, and if you want to have an option to keep them, feel 
>> free.
>>
>> Thanks,
>> Chris
>>
>> -----Original Message-----
>> From: 
>> 
>>  
>> [mailto:]
>>  On Behalf Of Tom Barton
>> Sent: Monday, December 12, 2011 10:21 AM
>> To: 
>> 
>> Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>
>> I agree that the UI should enable the partial result to be viewed, and
>> that the user may want to alter page size for viewing the partial result
>> set. It seems the rest of the concern is what text and numbers are
>> displayed on screen how, to ensure that the user has the right idea. It
>> sounds like Gary's got the right places and controls - is there a
>> wording issue? Here's what I think Gary said is there now:
>>
>> Error: Too many results returned by one or more data sources -
>> displaying  truncated result set. Please narrow your search
>>
>> Showing 1-50 of 74 items (truncated result set)
>>
>> That's pretty good. Maybe reword slightly?
>>
>> Note: Too many results were found. Please refine your search. Displaying 
>> partial result set.
>>
>> Showing 1-50 of 74 items (partial result set)
>>
>> On the point about max results per subject source or max results across
>> subject sources, from a user perspective I think max overall is what is
>> simplest, though I know source adapters don't work that way. But I
>> wonder if the distinction is largely immaterial for deployments that
>> rely primarily on a single subject source (beyond GSA), and so not a top
>> priority for us to deal with right away.
>>
>> I think that the difficulty we're having with search & display is a
>> consequence of how we've structured the source and subject interfaces,
>> as Gary will recognize going back a long ways. Until we find time to
>> redo all that in some presumably better way (which isn't easy - we've
>> tried before!), we'll have to do our best with an imperfect situation.
>>
>> Tom
>>
>> On 12/12/2011 8:51 AM, GW Brown, Information Systems and Computing wrote:
>>> --On 12 December 2011 08:31 -0600 Tom Barton 
>>> <>
>>>  wrote:
>>>
>>>> Gary & Chris,
>>>>
>>>> From here on the sideline it seems as though something is missing from
>>>> your approach to this problem. Are you working on the same underlying
>>>> data set, ie, does Gary's have 74 Jo*'s and Chris' 8125 (or 8435)? Or
>>>> why are you each seeing two such different numbers?
>>> I'm working against the QuickStart database, but I don't think the numbers
>>> are that critical. I'm sure on screen text can do away with any ambiguity.
>>>
>>> By default the UI pages 50 results at a time - user can change to 10, 25,
>>> 50, 100. Independently, a source can be configured for a maximum number of
>>> results it will return (new feature). I don't see any problem with 
>>> allowing
>>> a user to page up to that maximum - it is what I would expect.
>>>
>>> The JIRA description is:
>>>
>>> We need to remove paging buttons from subject search in admin ui, and if
>>> there are too many members (the SubjectFinder.findPage() method will tell
>>> you), then perhaps a message could be displayed that the user should 
>>> narrow
>>> their search, and it should also show whatever members it found (e.g. the
>>> first 200 or whatever number is configured in the source).
>>>
>>> I agree that it is worth letting the user see however many results are
>>> returned - but it would, in that example, be wrong to show all 200 in one
>>> page if the UI page size is set at 50.
>>>
>>> If you search across all sources (the default) you could have too many
>>> results from only one of the sources, but not get to see the results from
>>> it.
>>>
>>> Gary
>>>> Tom
>>>>
>>>> On 12/12/2011 6:45 AM, Chris Hyzer wrote:
>>>>> Is the resultset truncated because it is showing 50 of 74 items, or is
>>>>> it truncated because it is showing 50 of 8125 items?  When you click
>>>>> "next", are you going to the next page of all results, or are you going
>>>>> to the next page of a partial result set?  It is misleading and we need
>>>>> it removed (though as I said, if you want it there, leave an option so
>>>>> that you can enable it no problem)...  :)
>>>>>
>>>>> Thanks,
>>>>> Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: GW Brown, Information Systems and Computing
>>>>> [mailto:]
>>>>>   Sent: Monday, December 12, 2011 4:01
>>>>> AM
>>>>> To: Chris Hyzer; Emily Eisbruch; Grouper Dev
>>>>> Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>>>>
>>>>> The changes I checked in lead to the following:
>>>>>
>>>>> Top of screen
>>>>> -------------
>>>>> Error: Too many results returned by one or more data sources -
>>>>> displaying  truncated result set. Please narrow your search
>>>>>
>>>>> The summary
>>>>> -----------
>>>>> Showing 1-50 of 74 items (truncated result set)
>>>>>
>>>>> I would have thought that was pretty clear...
>>>>>
>>>>> Gary
>>>>>
>>>>> --On 11 December 2011 20:24 +0000 Chris Hyzer 
>>>>> <>
>>>>> wrote:
>>>>>
>>>>>> IF you do a search for "jo", and there are 8435 results, and the UI 
>>>>>> says
>>>>>> "There are too many results", and it say "displaying 1-50 of 149
>>>>>> results", that is misleading and incorrect.  If there are really 8435
>>>>>> results, and the user sees that there are 149 results, and pages
>>>>>> through, and doesn't see the one they are looking for, it is really
>>>>>> bad.  There is no reason to show the paging if we don't know how many
>>>>>> results there are (we got 149 results, but we don't know there are 8435
>>>>>> since that is not in the subject API), and if we cant page through all
>>>>>> the results.  IF you disagree, then we need an option to not show the
>>>>>> paging on the screen, and it must default to not show the paging.  We
>>>>>> do not want something on the UI that we know is misleading and
>>>>>> incorrect, but if you want to show it at your school, you have the
>>>>>> option to do that.  Ok?  :)
>>>>>>
>>>>>> Thanks,
>>>>>> Chris
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: GW Brown, Information Systems and Computing
>>>>>> [mailto:]
>>>>>>   Sent: Saturday, December 10, 2011
>>>>>> 11:23 AM
>>>>>> To: Chris Hyzer; Emily Eisbruch; Grouper Dev
>>>>>> Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>>>>>
>>>>>> --On 09 December 2011 22:02 +0000 Chris Hyzer 
>>>>>> <>
>>>>>> wrote:
>>>>>>
>>>>>>> Also, in addition to my previous email, I forgot to respond to your
>>>>>>> email below:
>>>>>>>
>>>>>>>> I think Chris was saying to ignore maxResults - in which case it
>>>>>>>> should be  removed from the sample sources.xml. I can then see that
>>>>>>>> you can do:
>>>>>>> Well, maxResults is useful if people do a SubjectFinder.findAll() as
>>>>>>> opposed to SubjectFinder.findPage().  Since the UI and WS will do the
>>>>>>> paging one, we can essentially ignore the masResults and focus on
>>>>>>> maxPageSize, though I think it should still be in the
>>>>>>> sources.example.properties in case people do the API findAll and in
>>>>>>> general for belts and suspenders (if a subject source returns too many
>>>>>>> results you can run out of memory on the server).
>>>>>> I haven't delved into the code to se where and how you are doing the
>>>>>> cutoffs, but is maxResults configured at the wrong level? i.e shouldn't
>>>>>> it  relate to 'sources' rather than a specific subject source?
>>>>>>
>>>>>> Gary
>>>>>>> Thanks,
>>>>>>> Chris
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: 
>>>>>>> 
>>>>>>> [mailto:]
>>>>>>>  On Behalf Of GW Brown,
>>>>>>> Information Systems and Computing Sent: Thursday, December 08, 2011
>>>>>>> 4:16 PM
>>>>>>> To: Emily Eisbruch; Grouper Dev
>>>>>>> Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>>>>>>
>>>>>>> --On 07 December 2011 16:07 -0500 Emily Eisbruch 
>>>>>>> <>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> [AI] (Gary) will look at the issue of paging in the Admin UI
>>>>>>>> https://bugs.internet2.edu/jira/browse/GRP-716
>>>>>>> I've looked at this again and still don't see a *paging* issue - The 
>>>>>>> UI
>>>>>>> appears to correctly page based on whatever number of results are
>>>>>>> returned  by the API - it doesn't care about what may have been
>>>>>>> discarded.
>>>>>>>
>>>>>>> I did find one inconsistency in the code. The UI does subject searches
>>>>>>> in two classes:
>>>>>>> 1) DoSearchSubjectAction
>>>>>>> 2) SearchNewMembersAction
>>>>>>>
>>>>>>> The former has:
>>>>>>>   results=source.search(processedSearchTerm);
>>>>>>> but should have:
>>>>>>>
>>>>>>> results=SubjectFinder.findPage(processedSearchTerm,sourceId).getResult
>>>>>>> s( );
>>>>>>>
>>>>>>> I'm not convinced by the semantics of:
>>>>>>>
>>>>>>> <!-- if more than this many results are returned, then throw a too 
>>>>>>> many
>>>>>>> subjects exception -->
>>>>>>>      <init-param>
>>>>>>>        <param-name>maxResults</param-name>
>>>>>>>        <param-value>1000</param-value>
>>>>>>>      </init-param>
>>>>>>>
>>>>>>>     <!-- on a findPage() this is the most results returned -->
>>>>>>>     <init-param>
>>>>>>>       <param-name>maxPageSize</param-name>
>>>>>>>       <param-value>40</param-value>
>>>>>>>     </init-param>
>>>>>>>
>>>>>>> (I set maxPageSize to 40 down from 100 for testing.)
>>>>>>>
>>>>>>> I think Chris was saying to ignore maxResults - in which case it 
>>>>>>> should
>>>>>>> be  removed from the sample sources.xml. I can then see that you can
>>>>>>> do:
>>>>>>>
>>>>>>> SearchPageResult spr = null;
>>>>>>> spr = SubjectFinder.findPage(searchTerm);
>>>>>>> results = spr.getResults();
>>>>>>> if(spr.isTooManyResults()) {
>>>>>>>   request.setAttribute("message",
>>>>>>>  new Message("error.too.many.subject.results",true));
>>>>>>> }
>>>>>>>
>>>>>>> That way the retrieved results are shown but the user is alerted to 
>>>>>>> the
>>>>>>> fact the result set was truncated (error message might make that
>>>>>>> clearer)
>>>>>>>
>>>>>>> Chris: if that is what you want it is an easy enough change. If you
>>>>>>> still think there is a UI paging issue you'll have to come up with a
>>>>>>> screenshot...
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>> ----------------------
>>>>>>> GW Brown, IT Services
>>>>>>> 
>>>>>> ----------------------
>>>>>> GW Brown, IT Services
>>>>>> 
>>>>> ----------------------
>>>>> GW Brown, IT Services
>>>>> 
>>> ----------------------
>>> GW Brown, IT Services
>>>