message threading in the web UI

message threading in the web UI

[Ralph Siemsen]

The way that threads are displayed seems to differ between the 
"frontpage" (eg. https://public-inbox.org/meta/) versus how they are 
shown in the "Thread Overview" (at the bottom of the page when viewing a 
specific thread).

On the frontpage, it seems only a subset of messages are displayed 
(maybe only the direct replies?). The only indication that there are 
additional hidden messages is the "+" sign, e.g. "(5+ messages)".

In contrast when viewing a message thread, the "Thread Overview" at the 
bottom shows quite clearly the full thread (nothing seems to be hidden).

Would it be possible to either:
* unify the behaviour so it is the same in all places, or
* in the "frontpage" make it more clear that threads are hidden,
  for example change "(5+ messages)" to "N/M messages". Consider adding
  a link ("rest of thread" or "additional replies") as a final element
  for any "abbreviated" threads.

One might argue that "+" sign is sufficient indicator, but until you 
realize its significance, it is just noise. When I first saw it, I 
manually counted the messages, and compared that with "(5+ messages"). 
They nearly matched, so I assumed the "+" indicated that an exact value 
was not possible, for whatever reason.

Anyhow, this is just my $0.02, but I though I'd pass it along.

-Ralph

Re: message threading in the web UI

[Eric Wong]

Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
> The way that threads are displayed seems to differ between the "frontpage"
> (eg. https://public-inbox.org/meta/) versus how they are shown in the
> "Thread Overview" (at the bottom of the page when viewing a specific
> thread).
> 
> On the frontpage, it seems only a subset of messages are displayed (maybe
> only the direct replies?). The only indication that there are additional
> hidden messages is the "+" sign, e.g. "(5+ messages)".

Yes, the frontpage only grabs the 200 most recent messages
(a "time window").

> In contrast when viewing a message thread, the "Thread Overview" at the
> bottom shows quite clearly the full thread (nothing seems to be hidden).

Right.  That's a separate SQLite query for every thread.

> Would it be possible to either:
> * unify the behaviour so it is the same in all places, or
> * in the "frontpage" make it more clear that threads are hidden,
>  for example change "(5+ messages)" to "N/M messages". Consider adding
>  a link ("rest of thread" or "additional replies") as a final element
>  for any "abbreviated" threads.
> 
> One might argue that "+" sign is sufficient indicator, but until you realize
> its significance, it is just noise. When I first saw it, I manually counted
> the messages, and compared that with "(5+ messages"). They nearly matched,
> so I assumed the "+" indicated that an exact value was not possible, for
> whatever reason.

Getting the exact value is possible, just more expensive...

> Anyhow, this is just my $0.02, but I though I'd pass it along.

Thanks for the feedback; and I agree, it's sometimes confusing :x

Getting the full count ("M") can be expensive since it needs an
SQLite COUNT query for every thread...

I'm not sure how feasable that is since frontpage performance is
critical and I spent a fair amount of time making it perform
acceptably for giant inboxes like LKML.

(Optionally) supporting Cache::FastMmap or other caching
mechanisms may help, but that's still extra install overhead and
initial load performance still needs to be taken into account.

Perhaps as an interim solution is to change the "+" for
something more obvious:

"5 or more messages"
"5 messages in current time window"
">= 5 messages"
"at least 5 messages"
...

Thoughts?

Re: message threading in the web UI

[Ralph Siemsen]

On Fri, Nov 15, 2019 at 11:52:35PM +0000, Eric Wong wrote:
>Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>> The way that threads are displayed seems to differ between the "frontpage"
>> (eg. https://public-inbox.org/meta/) versus how they are shown in the
>> "Thread Overview" (at the bottom of the page when viewing a specific
>> thread).
>>
>> On the frontpage, it seems only a subset of messages are displayed (maybe
>> only the direct replies?). The only indication that there are additional
>> hidden messages is the "+" sign, e.g. "(5+ messages)".
>
>Yes, the frontpage only grabs the 200 most recent messages
>(a "time window").

Ah, I see. Makes sense from a programmers point of view of course. 
However as an end user, based on what is shown in the UI, it looks like 
each thread is complete -- the number of messages in each thread varies 
(not artificially capped at say 5 messages per thread). When the thread 
consists of a patch series, the whole series seems to be displayed 
(likely because they are all posted together at the same time).

It is not very obvious that some additional messages (such as replies to 
the individual patches in a series) have been hidden. I only discovered 
it when I used my browser "Find in Page", and it did not find all the 
occurrences (but using "search" box on PI did find them).

>Getting the full count ("M") can be expensive since it needs an
>SQLite COUNT query for every thread...

Understood.

>Perhaps as an interim solution is to change the "+" for
>something more obvious:
>
>"5 or more messages"
>"5 messages in current time window"
>">= 5 messages"
>"at least 5 messages"

While those are a bit more obvious than just a "+" sign, to me at least, 
they are all ambiguous. The number itself is not really helping, since 
it is just a count of the number of lines that are displayed immediately 
below. In other words, the count does not add any information.

So perhaps just remove it entirely? For example:

[PATCH 0/3] start tidying up gzip-related code
 2019-11-16  2:34 UTC
` [PATCH 1/3] mbox: unused mid_clean import
` [PATCH 2/3] mbox: split mboxgz out into a separate file
` [PATCH 3/3] mboxgz: use Compress::Raw::Zlib instead of IO::Compress::Gzip
` <additional replies>

Note the extra line at the end, containing a link to the full thread. 
This essentially replaces the "+" with a more obvious indication that
messages have been omitted from the summary.

>I'm not sure how feasable that is since frontpage performance is
>critical and I spent a fair amount of time making it perform
>acceptably for giant inboxes like LKML.
>
>(Optionally) supporting Cache::FastMmap or other caching
>mechanisms may help, but that's still extra install overhead and
>initial load performance still needs to be taken into account.

Caching the whole page, esp for LKML and the like, certainly makes 
sense, but that is a bigger task for sure.

Thanks for your reply!
-Ralph