mhonarc-users

Re: patch: improved TSLICE, thread navigation, ...

2001-06-25 14:32:56
In sum, the current behavior for the nav-related
variables is to follow *index listing order*.

Are you sure? I don't think so... For everything *except* thread sorting,
the $flip variable in compute_msg_pos (mhrcvars.pl) makes NEXT and PREV
correspond to the *normally-sorted* next or previous message. So in a date
listing, NEXT always corresponds to the chronologically next message, even
if REVERSE is on. This is the opposite of index listing order.

My patch brings TNEXT and TPREV in line with NEXT and PREV.

BTW, technically, the current behavior can be "hidden" by use of
layout resources.  The issue really only deals with default behavior.

I don't think this is true either.

Currently, if TREVERSE is true, TNEXT behaves as follows:

    (1) If there is a chronologically next message in the current thread,
        jump to it.
    (2) Otherwise, jump to the chronologically PREVIOUS thread.

This seems inconsistent to me. And I don't think there's any way, using
layout resources, to get the following behavior, which I want:

    (1) If there is a chronologically next message in the current thread,
        jump to it.
    (2) Otherwise, jump to the chronologically NEXT thread.

But maybe I'm wrong?

BTW, this would affect the "intuitiveness" of the NEXT/PREV links.
If you consider all possible combinations on how messages can be
ordered on index pages, you will start to understand the problem on
relying on "intuition".  Luckily, with page layout resources, you
can "force" the generated output to follow whatever you desire.

I understand your point. Rather than referring to intuition, let me explain
the principle that I want NEXT/PREV links to follow:

         By default, NEXT/PREV links should behave independently of how the
         indexes are sorted.

Reasons: 1. The index is not visible when looking at a message page. The
            user should not have to remember how the index is arranged when
            she clicks on a link.

         2. The index helps users to locate messages. It is at least
            partially independent from messages' sorting order. (For
            example, Glimpse makes a great "index", but imposes no sorting
            order.)

         3. There are good reasons to reverse a listing (newest items
            appear first on the page) or to keep the listing in normal
            order (time flows downward). People should be able to
            experiment with different index orders without changing the
            meaning of the links on every message page.

         4. Dates, in particular, have a clear ordering: chronological
            order. If we agree that users should not have to remember how
            the index is arranged to understand a link, then "Next By Date"
            should mean "Next By Chronological Order". In fact, the code
            currently works exactly this way.

         5. Other orderings should follow the date ordering behavior lest
            link behavior become inconsistent depending on index choice.

If people WANTED the NEXT/PREV/etc. links to behave differently depending
on the index sorting order, they could do so with layout resources (except
that the TNEXT/TPREV order is currently internally inconsistent, as I said
above).

This is a lot of text; sorry :)

love,
ed