[Patternfly] Pagination - Conceptual Design

Mon Oct 24 09:40:59 UTC 2016

Here’s how we handled the pagination, based on this discussion.

> On Oct 20, 2016, at 11:07 AM, Thomas Maas <tmaas at redhat.com> wrote:
> 
> Not sure I follow:
> 
> “select all x items” is just a flag that tells the server to perform the action on all items if the user decides to perform such an action:
> 
> - Normally you immediately loose the selection once you navigate to another/next page.  
> - Deselecting 1 item on the current page would also reset the select all x items and lead to selecting just the items on the current page minus 1. 
> 
> It’s only when the user performs a bulk action on all items that you need to take care of asynchronously handling such a request…but that doesn’t depend on the user interface.
> 
> -Thomas
> 
>> On 20 Oct 2016, at 16:09, mike thompson <mithomps at redhat.com> wrote:
>> 
>> 
>>> On Oct 20, 2016, at 3:31 AM, Ken Wilson <ken at dynamicsitedesign.com> wrote:
>>> 
>>> Agreed. If You deliver the record count with the pagesize info.
>> 
>> Correct. That is why I was not addressing the page count but the record selections across pages (very stateful):
>> 
>> "The Select All 90 Items type of operations require these large result sets to be in memory.”
>> 
>> 
>> — Mike
>> 
>> 
>>> 
>>> -Ken
>>> 
>>>> On Oct 20, 2016, at 6:26 AM, Thomas Maas <tmaas at redhat.com> wrote:
>>>> 
>>>> But having a count of the total number of items doesn’t need to load all those items in memory, does it?
>>>> 
>>>>> On 20 Oct 2016, at 10:59, Ken Wilson <ken at dynamicsitedesign.com> wrote:
>>>>> 
>>>>> I have to agree with Mike T. … we deliver one page at a time also, using Angular and REST api calls. … performance is very important.
>>>>> 
>>>>> sincerely
>>>>> Ken
>>>>> 
>>>>> 
>>>>>> On Oct 19, 2016, at 4:04 PM, mike thompson <mithomps at redhat.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Oct 18, 2016, at 11:36 AM, SJ Cox <sjcox at redhat.com> wrote:
>>>>>>> 
>>>>>>> Hello fellow PatternFlyers!
>>>>>>> 
>>>>>>> This sprint I'm working on the conceptual design for pagination across data tables (includes card and list view)
>>>>>>> 
>>>>>>> I wanted to share my thoughts and progress and see if anyone had any concerns or feedback based on what is being done with tables in products to date.  What works, what doesn't?
>>>>>>> 
>>>>>>> With the addition of pagination, all elements/controls related to pagination would be found on the bottom of the table.  This includes:
>>>>>>> 	• See the number of items on a page and total number of pages
>>>>>>> 	• See how many pages of data there is.
>>>>>>> 	• View which page you are on (current location)
>>>>>>> 	• Modify how many pages are being displayed.
>>>>>>> 	• Skip to the next or previous page.
>>>>>>> 	• Skip multiple pages.
>>>>>>> 	• Navigate to the first/last page.
>>>>>>> With this story we wanted to add the ability to select all items across multiple pages. Initially, if you select all on a page, it will select all items only on that page. Then it would prompt the user to select all items across the table. I came up with two options for the "select all" option.
>>>>>>> 
>>>>>>> OPTION 1
>>>>>>> 
>>>>>>> <Screen Shot 2016-10-18 at 11.07.41 AM.png> <Screen Shot 2016-10-18 at 11.07.49 AM.png>
>>>>>>> The first option above shows a new row appearing within the table under the row headers, in the form of a message. This message informs you of how many items are selected and gives you the ability to select all.  Once all are selected, you have the ability to clear selection from the within the same message. 
>>>>>>> 
>>>>>>> Also, what would happen as you page through the table? I've seen it behave differently.  In google, as you page through, the selection is cleared. In this design I didn't think that would be a great experience. 
>>>>>>> 
>>>>>>> Option 1 Pros:  the addition of the message row is obvious and will draw the users attention.
>>>>>>> Option 1 Cons: Table height would have to adjust to accommodate new message row.  Also, does the placement of the message make sense under the row headers?  Furthermore, it's redundant to show the number of items shown twice (upper right, and in message)
>>>>>>> 
>>>>>>> 
>>>>>>> OPTION 2
>>>>>>> 
>>>>>>> Option two addresses the cons of option 1.   When selecting all items within a page, you get prompted to select all items within the table next to where it shows you total number of items selected. Same with clearing selection.
>>>>>>> 
>>>>>>> <Screen Shot 2016-10-18 at 11.08.03 AM.png>
>>>>>>> <Screen Shot 2016-10-18 at 11.08.11 AM.png>
>>>>>>> 
>>>>>>> Option 2 Pros: No need for creating a new message row and shifting the table down.  No redundant info.
>>>>>>> Option 3 Cons:  Might not be obvious that you can select all items. Does is seem hidden?
>>>>>>> 
>>>>>>> 
>>>>>>> Let me know your thoughts, thank you!
>>>>>> 
>>>>>> Another perspective of the pagination is not only for perusing visual sets of data. But also, for technical reasons (i.e., Memory constraints) the pages are fetched one page at a time, to conserve memory. Thousands of users with hundred of records in memory quickly bog down an application. 
>>>>>> 
>>>>>> The Select All 90 Items type of operations require these large result sets to be in memory.
>>>>>> 
>>>>>> Sorry, if I’m bringing implementation details into conceptual design, but it might alter the conceptual design.
>>>>>> 
>>>>>> 
>>>>>> — Mike
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Sarah Jane Cox 
>>>>>>> User Interaction Designer 
>>>>>>> User Experience Design Team
>>>>>>> 
>>>>>>> Red Hat, Inc.
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Patternfly mailing list
>>>>>>> Patternfly at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Patternfly mailing list
>>>>>> Patternfly at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>> 
>>>>> _______________________________________________
>>>>> Patternfly mailing list
>>>>> Patternfly at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Patternfly mailing list
>>> Patternfly at redhat.com
>>> https://www.redhat.com/mailman/listinfo/patternfly
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20161024/a0b5d552/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-10-22 at 9.52.56 AM.png
Type: image/png
Size: 457614 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20161024/a0b5d552/attachment.png>