<div dir="ltr"><div class="gmail_extra">Hey there, Jay-</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Michael</div></div>