Open Stack

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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>