Agreed. If You deliver the record count with the pagesize info. -Ken
> On Oct 20, 2016, at 6:26 AM, Thomas Maas <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> >>>> On Oct 18, 2016, at 11:36 AM, SJ Cox <[email protected]> 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 >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/patternfly >>> >>> _______________________________________________ >>> Patternfly mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/patternfly >> >> _______________________________________________ >> Patternfly mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/patternfly > > _______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
