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
