> On Oct 20, 2016, at 3:31 AM, Ken Wilson <[email protected]> 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 <[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
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
