[PATCH] changelog: repeat pager links on top of changelog

[Mads Kiilerich]

On 03/07/2015 08:50 PM, Thomas De Schampheleire wrote:
> On Fri, Mar 6, 2015 at 5:29 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> On 03/04/2015 10:06 PM, Thomas De Schampheleire wrote:
>>> # HG changeset patch
>>> # User Thomas De Schampheleire <thomas.de.schampheleire at gmail.com>
>>> # Date 1425503195 -3600
>>> #      Wed Mar 04 22:06:35 2015 +0100
>>> # Node ID ed66618ffb23900e1cf56add90f54801e455a0eb
>>> # Parent  297d798bd5b22ea562d0813bed7e5eb6bc646c1b
>>> changelog: repeat pager links on top of changelog
>>>
>>> In particular since the default number of entries in the changelog has
>>> been
>>> increased to 100, having the pager links both above and below the
>>> changelog
>>> is more user-friendly.
>>
>> When will the user ever be looking at the top of a multi-page listing of
>> changesets and without seeing the end of the current page know that he has
>> to navigate to the next one ... or 4 pages forward?
> For example because he is trying to find something around a given
> revision number, and uses the first few entries as a key. Based on
> that he can guess how many pages to advance.

Mercurial revision numbers are local. Git doesn't really have revision 
numbers. Kallithea can be configured to show the server's local revision 
numbers but I think these revision numbers are misleading and barely useful.

Please consider your example in more details: How did the user end up 
with a revision number? Was it the right one - and by which definition? 
Wouldn't it be better to not show the revision number and thus prevent 
the user from being hit by these wrong expectations?

> Or, maybe the user went too far and remembered that on page 3 he had
> seen the entry he was looking for but didn't realize it at that time.
> Then he could click on '3' from the top.

- but paging is usually/always going backwards from the latest revision. 
The pages are thus a moving target. What was on page 3 will soon be on 
page 4. And obviously, the page numbers depends on what kind of 
filtering you are using (currently either everything or just one branch).

>
>> (I dislike paging - especially when the items on pages don't have "primary
>> keys" that gives a natural paging. I would much rather have automatic
>> loading of an extra chunk when scrolling to the bottom of the page.)
> I consider this 'an incremental improvement' while we don't yet have
> infinite scroll.
>
> Note that what I dislike about certain implementations of infinite
> scroll is the following scenario:
>
> - scroll through a list using infinite scroll
> - click an item and go to a different page
> - click 'back' in the browser
> - one expects to see the list at the place where we left it, but often
> one just gets back the initial list and one has to scroll completely
> back, losing track of what you already looked at. Especially for long
> lists this is a problem.
>
> Without a solution to this problem, I prefer paging over infinite
> scroll, but if it is possible to handle this problem then I'm fine
> with infinite scroll.

Good point.

I guess clever web / frontend developers could implement a solution to 
that. Perhaps something with rewriting the URL when loading more entries 
so going back to it would make sure the same entries are loaded and shown.

/Mads