So I have started an etherpad to summarize the views expressed over this email chain: https://etherpad.openstack.org/pagination
Feel free to add to (and correct) this. Henry On 14 Aug 2013, at 17:25, Mac Innes, Kiall wrote: > So, Are we saying that UIs built on OpenStack APIs shouldn't be able to > show traditional pagination controls? Or am I missing how this should > work with marker/limit? > > e.g. for 11 pages of content, something like: 1 2 3 .. 10 11 > > Thanks, > Kiall > > On 13/08/13 22:45, Jay Pipes wrote: >> On 08/13/2013 05:04 PM, Gabriel Hurley wrote: >>> I have been one of the earliest, loudest, and most consistent PITA's about >>> pagination, so I probably oughta speak up. I would like to state three >>> facts: >>> >>> 1. Marker + limit (e.g. forward-only) pagination is horrific for building a >>> user interface. >>> 2. Pagination doesn't scale. >>> 3. OpenStack's APIs have historically had useless filtering capabilities. >>> >>> In a world where pagination is a "must-have" feature we need to have page >>> number + limit pagination in order to build a reasonable UI. Ironically >>> though, I'm in favor of ditching pagination altogether. It's the >>> lowest-common denominator, used because we as a community haven't buckled >>> down and built meaningful ways for our users to get to the data they really >>> want. >>> >>> Filtering is great, but it's only 1/3 of the solution. Let me break it down >>> with problems and high level "solutions": >>> >>> Problem 1: I know what I want and I need to find it. >>> Solution: filtering/search systems. >> >> This is a good place to start. Glance has excellent filtering/search >> capabilities -- built in to the API from early on in the Essex >> timeframe, and only expanded over the last few releases. >> >> Pagination solutions should build on a solid filtering/search >> functionality in the API, where there is a consistent sort key and >> direction (either hard-coded or user-determined, doesn't matter). >> >> Limit/offset pagination solutions (forward and backwards paging, random >> skip-to-a-page) are inefficient from a SQL query perspective and should >> be a last resort, IMO, compared to limit/marker. With some smart >> session-storage of a page's markers, backwards paging with limit/marker >> APIs is certainly possible -- just store the previous page's marker. >> >>> Problem 2: I don't know what I want, and it may or may not exist. >>> Solution: tailored discovery mechanisms. >> >> This should not be a use case that we spend much time on. Frankly, this >> use case can be summarized as "the window shopper scenario". Providing a >> quality search/filtering mechanism, including the *API* itself providing >> REST-ful discovery of the filters and search criteria the API supports, >> is way more important... >> >>> Problem 3: I need to know something about *all* the data in my system. >>> Solution: reporting systems. >> >> Sure, no disagreement there. >> >>> We've got the better part of none of that. >> >> I disagree. Some of the APIs have support for a good bit of >> search/filtering. We just need to bring all the projects up to search >> speed, Captain. >> >> Best, >> -jay >> >> p.s. I very often go to the second and third pages of Google searches. >> :) But I never skip to the 127th page of results. >> >>> But I'd like to solve these issues. I have lots of thoughts on all of >> those, and I think the UX and design communities can offer a lot in >> terms of the usability of the solutions we come up with. Even more, I >> think this would be an awesome working group session at the next summit >> to talk about nothing other than "how can we get rid of pagination?" >>> >>> As a parting thought, what percentage of the time do you click to the >>> second page of results in Google? >>> >>> All the best, >>> >>> - Gabriel >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
