Open Stack

Hey there, Jay-

The use case is telling someone where they are in a result set, not
necessarily the ability to jump pages. Say, for example, a PTL who is
reviewing all the stories in their project to determine which of them are
no longer relevant. To them, a very simple "You are on #X of #YYY" gives
them an idea of how much work they have left, and allows them to split
their work with other cores: "Hey, can you go review 100-200 please?". A
good example is the Infra Bug Day that happens fairly frequently. A
different, but similar case is a hidden influencer trying to keep tabs on
their own team's work backlog, which stretches across different projects. I
encourage everyone to brainstorm more, I'm sure you can find them.

There is a rule in UX, which is quite simple: Always tell the user exactly
where they are. This rule was first clearly stated in "Don't make me
think", and there's been quite a bit of development on the concept since. A
TL/DR version: There's a nuanced difference between "paging through data"
 and "consuming a feed". In the former, a location indicator is critical.
In the latter, less so. This is the case no matter how large the data set
gets - Google still provides pages, even though they don't mean much given
the size of their results. The best way I've found to conceptualize these
two is as follows: If you put all your data into a spreadsheet, and removed
the row labels, would your user care?

I would characterize your use case as an individual contributor who prefers
to treat their task list like a queue. This is one valid use case, and
marker based paging solves your problem. However, the other use cases above
think of stories more like a spreadsheet, and they require an indicator of
where they are relative to the rest of entire set. From a practical
perspective, most usage would never go past the second page, so I am not
really concerned about the performance implications of simply passing
offset straight through to the SQL query, and I would hope that
storyboard's filtering capabilities are powerful enough that our users can
reduce the size of the result set to a manageable size. However, we ALSO
get all that with offset based paging, and we win the the ability to
support all the other use cases without sacrificing anything.

In short, using offset based paging requires a small investment of time,
costs a performance hit for a small subset of users, and allows us to meet
the needs of all of our use cases.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20141120/4f0f8fba/attachment.html>