Add the option to display threads as trees

tusooa commented

2021-08-08 19:22:34 +00:00

Owner

As https://kazv.moe/notice/AA65vCFFCEmzichcVU .

The site itself may be a better demo than the video in it.

As https://kazv.moe/notice/AA65vCFFCEmzichcVU . The site itself may be a better demo than the video in it.

hj commented

2021-08-08 20:53:32 +00:00

Owner

first impressions:

status borders make it look very busy and confusing. maybe use different styles for tree mode, i.e. no top/bottom borders and thicker left border? also feels like bottom padding is missing.
non-simplified tree mode/chevron buttons as well as "return to last position"/"show full conversation" are very confusing, especially when you combine it with browser navigation, also there are no links to specific part of conversation. Overall it looks and feels more confusing than reddit's trees. I mean at least reddit has stuff in plain text.
"Maximum number of levels in thread to display by default" doesn't seem to work at all
using tree modes breaks cat ears mod (just FYI)
icons in show full conversation/return to last position are not aligned
state of opened thread is preserved when conversation is opened/closed, it probably should reset.

first impressions: - status borders make it look very busy and confusing. maybe use different styles for tree mode, i.e. no top/bottom borders and thicker left border? also feels like bottom padding is missing. - non-simplified tree mode/chevron buttons as well as "return to last position"/"show full conversation" are very confusing, especially when you combine it with browser navigation, also there are no links to specific part of conversation. Overall it looks and feels more confusing than reddit's trees. I mean at least reddit has stuff in plain text. - "Maximum number of levels in thread to display by default" doesn't seem to work at all - using tree modes breaks cat ears mod (just FYI) - icons in show full conversation/return to last position are not aligned - state of opened thread is preserved when conversation is opened/closed, it probably should reset.

tusooa commented

2021-08-09 03:11:31 +00:00

Author

Owner

status borders make it look very busy and confusing. maybe use different styles for tree mode, i.e. no top/bottom borders and thicker left border? also feels like bottom padding is missing.

Legit. This can be done.

non-simplified tree mode/chevron buttons as well as "return to last position"/"show full conversation" are very confusing, especially when you combine it with browser navigation, also there are no links to specific part of conversation. Overall it looks and feels more confusing than reddit's trees. I mean at least reddit has stuff in plain text.

I'm aware of it, and that's why I made "simplified tree-style" the default.
"there are no links to specific part of conversation," what does that mean? What is reddit's behaviour?

"Maximum number of levels in thread to display by default" doesn't seem to work at all

None of the numeric settings in vanilla Pleroma FE, like "max number of attachments." I am not sure what the solution would be though.

using tree modes breaks cat ears mod (just FYI)
icons in show full conversation/return to last position are not aligned

Will try to look into it.

state of opened thread is preserved when conversation is opened/closed, it probably should reset.

Will add a pref.

> status borders make it look very busy and confusing. maybe use different styles for tree mode, i.e. no top/bottom borders and thicker left border? also feels like bottom padding is missing. Legit. This can be done. > non-simplified tree mode/chevron buttons as well as "return to last position"/"show full conversation" are very confusing, especially when you combine it with browser navigation, also there are no links to specific part of conversation. Overall it looks and feels more confusing than reddit's trees. I mean at least reddit has stuff in plain text. I'm aware of it, and that's why I made "simplified tree-style" the default. "there are no links to specific part of conversation," what does that mean? What is reddit's behaviour? > "Maximum number of levels in thread to display by default" doesn't seem to work at all None of the numeric settings in vanilla Pleroma FE, like "max number of attachments." I am not sure what the solution would be though. > using tree modes breaks cat ears mod (just FYI) > icons in show full conversation/return to last position are not aligned Will try to look into it. > state of opened thread is preserved when conversation is opened/closed, it probably should reset. Will add a pref.

hj commented

2021-08-09 13:00:34 +00:00

Owner

"there are no links to specific part of conversation," what does that mean? What is reddit's behaviour?

What I really meant is that selecting a post and tree state are disjointed.

Here's what reddit comment thread looks like when opened permalink of one comment (2nd level):

Here's how it works:
opening one specific comment will show only that comment and its children. Clicking "view full context" will also show that comment's parent posts, clicking "view the rest of the comments" brings you back to full comments view, all of these cause page refresh and change of url (i.e. "show full context" adds &context=10000 to url), so you can always link to specific part of conversation, including parents or not including them. In your MR opening post by link might or might not show "only replies" depending on whether that post is deep enough or not.

This brings me to two bugs/missing features:

"Show everything under this thread" should always expand thread inline instead of opening replies view. (currently it only does that in simplified mode for some reason?)
Open up replies view, hit "back" in browser - you're still in replies view, but should've exit it.

None of the numeric settings in vanilla Pleroma FE, like "max number of attachments." I am not sure what the solution would be though.

can you open an issue if it doesn't work in develop branch?

>"there are no links to specific part of conversation," what does that mean? What is reddit's behaviour? What I really meant is that selecting a post and tree state are disjointed. Here's what reddit comment thread looks like when opened permalink of one comment (2nd level): ![image](/attachments/4e9d79a3-3663-4398-9e3d-6056da9f7090) Here's how it works: opening one specific comment will show only that comment and its children. Clicking "view full context" will also show that comment's parent posts, clicking "view the rest of the comments" brings you back to full comments view, all of these cause page refresh and change of url (i.e. "show full context" adds &context=10000 to url), so you can always link to specific part of conversation, including parents or not including them. In your MR opening post by link might or might not show "only replies" depending on whether that post is deep enough or not. This brings me to two bugs/missing features: - "Show everything under this thread" should always expand thread inline instead of opening replies view. (currently it only does that in simplified mode for some reason?) - Open up replies view, hit "back" in browser - you're still in replies view, but should've exit it. >None of the numeric settings in vanilla Pleroma FE, like "max number of attachments." I am not sure what the solution would be though. can you open an issue if it doesn't work in develop branch?

image.png

99 KiB

tusooa commented

2021-08-10 02:28:54 +00:00

Author

Owner

can you open an issue if it doesn't work in develop branch?

https://git.pleroma.social/pleroma/pleroma-fe/-/issues/1104

>can you open an issue if it doesn't work in develop branch? https://git.pleroma.social/pleroma/pleroma-fe/-/issues/1104

tusooa commented

2021-08-10 04:33:03 +00:00

Author

Owner

Thank you very much for reviewing this and providing such information.

Let me reason about some of the behaviour here:

"Show everything under this thread" should always expand thread inline instead of opening replies view. (currently it only does that in simplified mode for some reason?)

The actions in simplified tree-style and non-simplified are different --- the simplified one is "See the remaining part of the thread," different from the non-simplified action, which is actually "(recursively) expand everything under this." The >> icon indicates it is the same action as the >> button in non-simplified view. That is, making that as the root post ("going into the 'replies view' as you said").

I do get it now that it may be confusing for users, and is not intuitive enough. And I agree on the link as state pattern; that should be implemented.

The whole conversation view

My initial idea was to keep the ability to see the whole conversation (not just the current status's ancestors and descendents) in timeline, which I think is Pleroma-FE specific. This includes "orphaned" status in a conversation.

For example, think of a case where everyone posts their statuses as follower-only, as follows:

A1
|--B1
   |--C1
      |-- A2
|--B2
   |--A3

Where An, Bn, Cn's are statuses posted by A, B, and C, respectively.

Suppose I followed A and B, but not C, here is how it will roughly be displayed in the linear view on develop:

A1
B1 (in reply to A1)
A2 (maybe shown as in reply to C, but we do not know C1 here)
B2 (in reply to A1)
A3 (in reply to B2)

Currently, the tree view is like

A1
|--B1
|--B2
   |--A3
A2 (orphaned status, displayed at the top level)

In Misskey, orphaned statuses are not shown at all (even at the top level https://mk.absturztau.be/notes/8p3uwie0g5 ).

Here is the kazv.moe view of the same thread: https://kazv.moe/notice/AA341sBTOihy967B5M . Note that the highlighted status is replying to a private one, and thus it is shown as orphaned (at the top level).

In Pleroma we may know A2 is replying to something else, but we do not know where to place its parent in the whole thread. For now, I think this forest display (full-thread overview) is reasonable.

"Replies view"

But at the end we do not want too much tree indentation, or the user's screen won't fit it. So we should be able to change which status we place in the root position. For example, if we set B2 as the new root, it looks like:

B2
|--A3

(The following content is deviated from the current implementation.) But this gives too little context about B2. It is a reply to A1, but we have no way to know except to hover on the "In reply to" text, and this is hard to do on a mobile device.

I think Misskey does a good job here, showing all ancestor statuses of B2 (see for example https://mk.absturztau.be/notes/8p3wn15s9i ):

(If A1 is again a reply to something else, its ancestors are here)
A1 (in faded text)

B2 (different style to make it stand out)
|--A3

However, this is not a full conversation. A1's replies are not shown and we cannot see them without going to a new page by clicking on the timestamp of that status.

So the question now is how we should strike a balance between displaying as much information as possible and preventing too many levels of nesting.

Maybe we can display it as something like

-- << Full conversation (U (number of orphaned statuses, U > 0) other statuses)
Ancestor3
-- >> X (X > 0) other replies, continue the thread here
Ancestor2 (uf there are no other replies, don't display a navigation link)
Ancestor1
-- >> Y (Y > 0) other replies, continue the thread here
Root of the tree (`:id` parameter in url) (maybe shown as a different, strengthened style)
|--Direct reply 1
   |--...
      |--A somewhat deep level
         -- >> Z (Z > 0) replies not shown, continue the thread here
|--Direct reply 2

And in non-simplified view we can keep the toggle showing button and >> button on all statuses to allow users make any status as the root within one click. Maybe the toggle showing button should be placed somewhere farther from >> to prevent misclicks.

How does this display style look to you?

Url routing

If we, like Misskey, are to allow only to root the tree at the current selected status, the :id parameter suffice for the purpose of keeping some state (i.e. the root of the tree).

However, another thing to deal with is the top-level statuses (either the real root, or orphaned statuses): when I GET /notice/<top-level id>, should we always display the full conversation, or should we have another parameter to control whether it shows the full conversation (e.g. /notice/<top-level id>/full -- will this break remote actions like mastodon's /authorize_interaction?uri=....?). Or rather, when displaying a thread rooted at any status, always show its siblings (in the case of top-level statuses, the real root and all orphaned statuses are also shown) besides it to make it uniform?

Thank you very much for reviewing this and providing such information. Let me reason about some of the behaviour here: >"Show everything under this thread" should always expand thread inline instead of opening replies view. (currently it only does that in simplified mode for some reason?) The actions in simplified tree-style and non-simplified are different --- the simplified one is "See the remaining part of the thread," different from the non-simplified action, which is actually "(recursively) expand everything under this." The `>>` icon indicates it is the same action as the `>>` button in non-simplified view. That is, making that as the root post ("going into the 'replies view' as you said"). I do get it now that it may be confusing for users, and is not intuitive enough. And I agree on the link as state pattern; that should be implemented. ## The whole conversation view My initial idea was to keep the ability to see the whole conversation (not just the current status's ancestors and descendents) in timeline, which I think is Pleroma-FE specific. This includes "orphaned" status in a conversation. For example, think of a case where everyone posts their statuses as follower-only, as follows: ``` A1 |--B1 |--C1 |-- A2 |--B2 |--A3 ``` Where An, Bn, Cn's are statuses posted by A, B, and C, respectively. Suppose I followed A and B, but not C, here is how it will roughly be displayed in the linear view on `develop`: ``` A1 B1 (in reply to A1) A2 (maybe shown as in reply to C, but we do not know C1 here) B2 (in reply to A1) A3 (in reply to B2) ``` Currently, the tree view is like ``` A1 |--B1 |--B2 |--A3 A2 (orphaned status, displayed at the top level) ``` In Misskey, orphaned statuses are not shown at all (even at the top level https://mk.absturztau.be/notes/8p3uwie0g5 ). Here is the kazv.moe view of the same thread: https://kazv.moe/notice/AA341sBTOihy967B5M . Note that the highlighted status is replying to a private one, and thus it is shown as orphaned (at the top level). ![Screenshot_20210809_234719](/attachments/0fe38bac-fe42-48b7-8fc9-42d9e6ab33e7) In Pleroma we may know A2 is replying to something else, but we do not know where to place its parent in the whole thread. For now, I think this forest display (full-thread overview) is reasonable. ## "Replies view" But at the end we do not want too much tree indentation, or the user's screen won't fit it. So we should be able to change which status we place in the root position. For example, if we set B2 as the new root, it looks like: ``` B2 |--A3 ``` (The following content is deviated from the current implementation.) But this gives too little context about B2. It is a reply to A1, but we have no way to know except to hover on the "In reply to" text, and this is hard to do on a mobile device. I think Misskey does a good job here, showing all ancestor statuses of B2 (see for example https://mk.absturztau.be/notes/8p3wn15s9i ): ``` (If A1 is again a reply to something else, its ancestors are here) A1 (in faded text) B2 (different style to make it stand out) |--A3 ``` However, this is not a full conversation. A1's replies are not shown and we cannot see them without going to a new page by clicking on the timestamp of that status. So the question now is how we should strike a balance between displaying as much information as possible and preventing too many levels of nesting. Maybe we can display it as something like ``` -- << Full conversation (U (number of orphaned statuses, U > 0) other statuses) Ancestor3 -- >> X (X > 0) other replies, continue the thread here Ancestor2 (uf there are no other replies, don't display a navigation link) Ancestor1 -- >> Y (Y > 0) other replies, continue the thread here Root of the tree (`:id` parameter in url) (maybe shown as a different, strengthened style) |--Direct reply 1 |--... |--A somewhat deep level -- >> Z (Z > 0) replies not shown, continue the thread here |--Direct reply 2 ``` And in non-simplified view we can keep the toggle showing button and `>>` button on all statuses to allow users make any status as the root within one click. Maybe the toggle showing button should be placed somewhere farther from `>>` to prevent misclicks. How does this display style look to you? ## Url routing If we, like Misskey, are to allow only to root the tree at the current selected status, the `:id` parameter suffice for the purpose of keeping some state (i.e. the root of the tree). However, another thing to deal with is the top-level statuses (either the real root, or orphaned statuses): when I `GET /notice/<top-level id>`, should we always display the full conversation, or should we have another parameter to control whether it shows the full conversation (e.g. `/notice/<top-level id>/full` -- will this break remote actions like mastodon's `/authorize_interaction?uri=....`?). Or rather, when displaying a thread rooted at any status, always show its siblings (in the case of top-level statuses, the real root and all orphaned statuses are also shown) besides it to make it uniform?

Screenshot_20210809_234719.png

944 KiB

tusooa commented

2021-08-11 05:02:32 +00:00

Author

Owner

status borders make it look very busy and confusing. maybe use different styles for tree mode, i.e. no top/bottom borders and thicker left border? also feels like bottom padding is missing.
(Implemented misskeyish threading) non-simplified tree mode/chevron buttons as well as "return to last position"/"show full conversation" are very confusing, especially when you combine it with browser navigation, also there are no links to specific part of conversation. Overall it looks and feels more confusing than reddit's trees. I mean at least reddit has stuff in plain text.
(Bug on develop) "Maximum number of levels in thread to display by default" doesn't seem to work at all
[N/A] using tree modes breaks cat ears mod (just FYI)
[N/A] (No longer applies, removed "return to last position" link) icons in show full conversation/return to last position are not aligned
(Is reset now) state of opened thread is preserved when conversation is opened/closed, it probably should reset.
[N/A] (Intended) "Show everything under this thread" should always expand thread inline instead of opening replies view. (currently it only does that in simplified mode for some reason?)
(Fixed) Open up replies view, hit "back" in browser - you're still in replies view, but should've exit it.

Changes are also online on kazv.moe .

- [X] status borders make it look very busy and confusing. maybe use different styles for tree mode, i.e. no top/bottom borders and thicker left border? also feels like bottom padding is missing. - [X] (Implemented misskeyish threading) non-simplified tree mode/chevron buttons as well as "return to last position"/"show full conversation" are very confusing, especially when you combine it with browser navigation, also there are no links to specific part of conversation. Overall it looks and feels more confusing than reddit's trees. I mean at least reddit has stuff in plain text. - [ ] (Bug on develop) "Maximum number of levels in thread to display by default" doesn't seem to work at all - [N/A] using tree modes breaks cat ears mod (just FYI) - [N/A] (No longer applies, removed "return to last position" link) icons in show full conversation/return to last position are not aligned - [X] (Is reset now) state of opened thread is preserved when conversation is opened/closed, it probably should reset. - [N/A] (Intended) "Show everything under this thread" should always expand thread inline instead of opening replies view. (currently it only does that in simplified mode for some reason?) - [X] (Fixed) Open up replies view, hit "back" in browser - you're still in replies view, but should've exit it. Changes are also online on kazv.moe .

hj commented

2021-08-17 13:22:46 +00:00

Owner

Here's what I think:

We should somewhat copy what misskey is doing, it seems to be very clear and intuitive.

When showing a post we render its direct parents chain above in linear way with faded style (how exactly is to be determined) and its children in tree style. If some parent has other replies that we hidden - we provide a link that opens up that status. Same if some branch goes too deep - status with hidden children gets a link that opens up that status.

I guess it's pretty much the same as it is on kazv.moe now? The linear parents look weird with indentation. Nice job overall.

Also I think there should be only one tree style, which is simplified one. There's no need for increased complexity, and the only difference i see now is that in non-simplified version deeper threads open up inline instead of opening that status'es page. This also removes the need for any additions to the URLs.

Likewise, the >> and << Show full conversation links are duplicates of [clicking timestamp] and [clicking timestamp of the OP] respectively.

As for orphaned posts I think we should do it like this:

If first post is an OP, i.e. we can see the OP - add fake status "Unknown status" as its OP's child, and all orphaned posts are its children, with those children.
If first post is a reply, i.e. we can't see the OP either:
Always render thread in linear style, since we can't quite make a tree without its root.
Use same "Unknown status" placeholder as OP

Here's what I think: We should somewhat copy what misskey is doing, it seems to be very clear and intuitive. ![image](/attachments/186779fc-f8d8-40ae-a917-b14bb6b9ef22) When showing a post we render its direct parents chain above in linear way with faded style (how exactly is to be determined) and its children in tree style. If some parent has other replies that we hidden - we provide a link that opens up that status. Same if some branch goes too deep - status with hidden children gets a link that opens up that status. I guess it's pretty much the same as it is on kazv.moe now? The linear parents look weird with indentation. Nice job overall. Also I think there should be only one tree style, which is simplified one. There's no need for increased complexity, and the only difference i see now is that in non-simplified version deeper threads open up inline instead of opening that status'es page. This also removes the need for any additions to the URLs. Likewise, the `>>` and `<< Show full conversation` links are duplicates of [clicking timestamp] and [clicking timestamp of the OP] respectively. As for orphaned posts I think we should do it like this: * If first post is an OP, i.e. we can see the OP - add fake status "Unknown status" as its OP's child, and all orphaned posts are its children, with those children. * If first post is a reply, i.e. we can't see the OP either: * Always render thread in linear style, since we can't quite make a tree without its root. * Use same "Unknown status" placeholder as OP

image.png

79 KiB

hj commented

2021-08-17 13:24:43 +00:00

Owner

once #2659 merges we can discuss styles a little bit more. Most notably we should move the "See 1 other reply" link next to "Replies - #1 #2 #3" line which is below status now.

once #2659 merges we can discuss styles a little bit more. Most notably we should move the "See 1 other reply" link next to "`Replies - #1 #2 #3`" line which is below status now.

tusooa commented

2021-08-17 15:53:34 +00:00

Author

Owner

Parent indentation is for accessibility reasons. The "fade vs highlight" is only differences in colour, thus we need some other way to distinguish them. For me indenting the parents are pretty straightforward.

>> and << links are NOT the same as clicking the timestamps. When the thread is shown inside the timeline, the former ones always jump within the timeline page, and the latter always navigates to the individual conversation page.

For "fake status": I don't think it's a clear way, as it gives the impression that orphaned statuses are all directly replying to the same status, which is not the case.

Also, fully reverting to linear style if there is no single parent defeats the purpose of the tree view. Orphaned statuses can have valid direct replies, and showing that structure, I think, is necessary.

For me, treating the (visible) conversation structure as a forest is the most natural way--Although the full structure should be a tree, there might be a part of the structure not visible to us, but that's it: only that part is missing, and other parts of the structure are still complete, and they can still make up other trees on their own.

Parent indentation is for accessibility reasons. The "fade vs highlight" is only differences in colour, thus we need some other way to distinguish them. For me indenting the parents are pretty straightforward. \>> and << links are NOT the same as clicking the timestamps. When the thread is shown inside the timeline, the former ones always jump within the timeline page, and the latter always navigates to the individual conversation page. For "fake status": I don't think it's a clear way, as it gives the impression that orphaned statuses are all directly replying to the same status, which is not the case. Also, fully reverting to linear style if there is no single parent defeats the purpose of the tree view. Orphaned statuses can have valid direct replies, and showing that structure, I think, is necessary. For me, treating the (visible) conversation structure as a forest is the most natural way--Although the full structure should be a tree, there might be a part of the structure not visible to us, but that's it: only that part is missing, and other parts of the structure are still complete, and they can still make up other trees on their own.

tusooa commented

2021-08-17 15:53:34 +00:00

Author

Owner

That also defects my purpose to show the conversation as fully as possible (i.e. keeping the most important part of the linear view from my opinion). I made the link under the statuses because I intentionally want the side-replies to stand out, reminding users that "there are still other parts of the conversation remaining there." Same with the "show full conversation" thing. One thing that I think may need a big improvement is the wording for that. Ideally I would like to show "(X other top-level statuses)" besides "Show full conversation," just I guess I want some other wording than "top-level" or "orphaned."

hj commented

2021-08-17 16:16:44 +00:00

Owner

>> and << links are NOT the same as clicking the timestamps. When the thread is shown inside the timeline, the former ones always jump within the timeline page, and the latter always navigates to the individual conversation page.

I think it's unnecessary complication to allow doing this when thread is inside timeline. We don't allow highlighting other post like this, i see no need to allow thread manipulation either.

For "fake status": I don't think it's a clear way, as it gives the impression that orphaned statuses are all directly replying to the same status, which is not the case.

Well, not much that we can do with orphaned posts, the best we can do is show them in linear style, which is what will resulting "unknown status" tree will end up looking like. To clarify we could call it "Off-tree statuses" or something

Also, fully reverting to linear style if there is no single parent defeats the purpose of the tree view. Orphaned statuses can have valid direct replies, and showing that structure, I think, is necessary.

problem is we're missing a lot of data that we need to build a tree - misskey doesn't show them at all because of that. Best we can do is show them in linear way like we already do.

>`>>` and `<<` links are NOT the same as clicking the timestamps. When the thread is shown inside the timeline, the former ones always jump within the timeline page, and the latter always navigates to the individual conversation page. I think it's unnecessary complication to allow doing this when thread is inside timeline. We don't allow highlighting other post like this, i see no need to allow thread manipulation either. >For "fake status": I don't think it's a clear way, as it gives the impression that orphaned statuses are all directly replying to the same status, which is not the case. Well, not much that we can do with orphaned posts, the best we can do is show them in linear style, which is what will resulting "unknown status" tree will end up looking like. To clarify we could call it "Off-tree statuses" or something >Also, fully reverting to linear style if there is no single parent defeats the purpose of the tree view. Orphaned statuses can have valid direct replies, and showing that structure, I think, is necessary. problem is we're missing a lot of data that we **need** to build a tree - misskey doesn't show them at all because of that. Best we can do is show them in linear way like we already do.

hj commented

2021-08-17 16:18:27 +00:00

Owner

i just think it looks very off-place and breaks the visual flow.

tusooa commented

2021-08-17 16:51:32 +00:00

Author

Owner

>> and << links are NOT the same as clicking the timestamps. When the thread is shown inside the timeline, the former ones always jump within the timeline page, and the latter always navigates to the individual conversation page.

I think it's unnecessary complication to allow doing this when thread is inside timeline. We don't allow highlighting other post like this, i see no need to allow thread manipulation either.

It is not unnecessary. When on a mobile device I navigate to a different page and go back, either through "open link in current tab and then hit back" or through "open link in a new tab and go back to the original tab," I frequently experience page refreshes, maybe due to insufficient resources (RAM or something else), and I not only needed to wait for the refresh, but also lost the original position I was on the timeline. This is also true for Mastodon, and it makes me really frustrated. Pleroma is the only one where I can view the whole conversation inside the timeline without navigating to a new page, and I think it is important to keep this feature even we display conversation in timeline using a different style.

Best we can do is show them in linear way like we already do.

I do not agree with this. Take the following example:

A1
|--A2
   |--A3
|--B1
   |--C1
      |--A4
         |--D1
|--B2
   |--C2
      |--D2

Assume we can see everyone but B. Then our thread view as implemented on kazv.moe will be:

A1
|--A2
   |--A3
C1
|--A4
   |--D1
C2
|--D2

While you suggested

A1
|--A2
   |--A3
|--???
   |--C1
      |--A4
         |--D1
   |--C2
      |--D2

This is not a very big difference but if we further assume that A1 is replying to something else:

B0
|--A1
   |--A2
      |--A3
   |--B1
      |--C1
         |--A4
            |--D1
   |--B2
      |--C2
         |--D2

Under my current implementation it displays the same thing, but what you suggested is:

???
A1
A2
A3
C1
A4
D1
C2
D2

This defeats the purpose to show the conversation structure.

> > \>> and << links are NOT the same as clicking the timestamps. When the thread is shown inside the timeline, the former ones always jump within the timeline page, and the latter always navigates to the individual conversation page. > > I think it's unnecessary complication to allow doing this when thread is inside timeline. We don't allow highlighting other post like this, i see no need to allow thread manipulation either. It is not unnecessary. When on a mobile device I navigate to a different page and go back, either through "open link in current tab and then hit back" or through "open link in a new tab and go back to the original tab," I frequently experience page refreshes, maybe due to insufficient resources (RAM or something else), and I not only needed to wait for the refresh, but also lost the original position I was on the timeline. This is also true for Mastodon, and it makes me really frustrated. Pleroma is the only one where I can view the whole conversation inside the timeline without navigating to a new page, and I think it is important to keep this feature even we display conversation in timeline using a different style. > Best we can do is show them in linear way like we already do. I do not agree with this. Take the following example: ``` A1 |--A2 |--A3 |--B1 |--C1 |--A4 |--D1 |--B2 |--C2 |--D2 ``` Assume we can see everyone but B. Then our thread view as implemented on kazv.moe will be: ``` A1 |--A2 |--A3 C1 |--A4 |--D1 C2 |--D2 ``` While you suggested ``` A1 |--A2 |--A3 |--??? |--C1 |--A4 |--D1 |--C2 |--D2 ``` This is not a very big difference but if we further assume that A1 is replying to something else: ``` B0 |--A1 |--A2 |--A3 |--B1 |--C1 |--A4 |--D1 |--B2 |--C2 |--D2 ``` Under my current implementation it displays the same thing, but what you suggested is: ``` ??? A1 A2 A3 C1 A4 D1 C2 D2 ``` This defeats the purpose to show the conversation structure.

hj commented

2021-08-17 17:19:31 +00:00

Owner

Pleroma is the only one where I can view the whole conversation inside the timeline without navigating to a new page

ok, fair. i'll think about how to make it less confusing

Under my current implementation it displays the same thing, but what you suggested is:

how? can you give an actual example of it?

Under my current implementation it displays the same thing, but what you suggested is:

No, i'm suggesting ONLY orphaned nodes to be presented under "unknown status", posts that have parent are not orphanated:

>Pleroma is the only one where I can view the whole conversation inside the timeline without navigating to a new page ok, fair. i'll think about how to make it less confusing >Under my current implementation it displays the same thing, but what you suggested is: how? can you give an actual example of it? >Under my current implementation it displays the same thing, but what you suggested is: No, i'm suggesting ONLY orphaned nodes to be presented under "unknown status", posts that have parent are not orphanated: ![image](/attachments/7a592a13-7be3-4b47-831a-129aae0410c9)

image.png

324 KiB

tusooa commented

2021-09-05 14:58:55 +00:00

Author

Owner

// Case 0

If first post is an OP, i.e. we can see the OP - add fake status "Unknown status" as its OP's child, and all orphaned posts are its children, with those children.

// Case 1

If first post is a reply, i.e. we can't see the OP either:
Always render thread in linear style, since we can't quite make a tree without its root.
Use same "Unknown status" placeholder as OP

Ok so I looked into this, and turns out that we do not have a way to distinguish between Case 0 and Case 1.

If BE does not know about the existence of status 2 or 4 (e.g. no local user follows the account that created those followers-only statuses), its in_reply_to_id will be empty, which is the same as the "real root". As a result, we do not reliably know whether a status is replying to something else.

> // Case 0 > > If first post is an OP, i.e. we can see the OP - add fake status "Unknown status" as its OP's child, and all orphaned posts are its children, with those children. > > // Case 1 > > If first post is a reply, i.e. we can't see the OP either: > Always render thread in linear style, since we can't quite make a tree without its root. > Use same "Unknown status" placeholder as OP Ok so I looked into this, and turns out that we do not have a way to distinguish between Case 0 and Case 1. If BE *does not know* about the existence of status 2 or 4 (e.g. no local user follows the account that created those followers-only statuses), its `in_reply_to_id` will be empty, which is the same as the "real root". As a result, we do not reliably know whether a status is replying to something else.

tusooa commented

2021-09-05 20:01:10 +00:00

Author

Owner

Now the "show full conversation" button only shows up when there are other top-level statuses than the current root, and gives a count on it.

tusooa commented

2021-09-05 20:02:06 +00:00

Author

Owner

I guess I will make it a pref then.

tusooa commented

2021-09-05 20:39:32 +00:00

Author

Owner

Added a pref to customize whether to show "other replies" button below the status or inside it, replacing the original "Replies:" span.

shpuld commented

2021-09-07 15:07:47 +00:00

Owner

Overall I really like the idea of getting this option and thanks for the work on it so far.

I'll have to review it more closely later, there's some parts that seem slightly questionable on the first look, but stuff like debugs shouldn't be left in the code for sure

Overall I really like the idea of getting this option and thanks for the work on it so far. I'll have to review it more closely later, there's some parts that seem slightly questionable on the first look, but stuff like debugs shouldn't be left in the code for sure

tusooa commented

2021-09-10 19:25:27 +00:00

Author

Owner

Cleaned up.

tusooa commented

2021-09-15 14:02:54 +00:00

Author

Owner

It seems this makes Pleroma-FE slow as we are building the tree structure. Needs a lot of performance tweaks and benchmarking.

tusooa commented

2021-09-16 00:49:47 +00:00

Author

Owner

i see why it is so slow: it breaks virtual scrolling.

tusooa commented

2021-09-16 14:07:42 +00:00

Author

Owner

Fixed

hj commented

2022-01-19 13:48:33 +00:00

Owner

we do have a way to distinguish between case 0 and case 1.... sometimes. If post has "reply to" it's case 1, if it doesn't - it's 0.

I'm talking about case when reply to link is stricken through

Although it's quite rare and it seems that backend doesn't preserve reply-to right as refreshing the page causes reply-to link disappear entirely

(thanks gitlab for not pushing this through and instead adding it to review)

we do have a way to distinguish between case 0 and case 1.... sometimes. If post has "reply to" it's case 1, if it doesn't - it's 0. I'm talking about case when reply to link is stricken through ![image](/attachments/47752740-20a1-40f4-9dc2-351c5431a5a6) Although it's quite rare and it seems that backend doesn't preserve reply-to right as refreshing the page causes reply-to link disappear entirely (thanks gitlab for not pushing this through and instead adding it to review)

image.png

3.6 KiB

hj commented

2022-01-19 13:48:33 +00:00

Owner

seems to be fine although I'd default to linear style for now

hj commented

2022-02-28 16:40:02 +00:00

Owner

Got this bug when selecting "Show the "other replies" button" to "inside statuses"

Got this bug when selecting "Show the "other replies" button" to "inside statuses" ![image](/attachments/06da9bc6-7115-49f1-a662-01826a2f31b9)

image.png

32 KiB

hj commented

2022-02-28 16:40:36 +00:00

Owner

Also i think it should be an option to NOT to fade previous statuses

tusooa commented

2022-02-28 18:03:18 +00:00

Author

Owner

can't reproduce this...

hj commented

2022-02-28 18:07:25 +00:00

Owner

open this https://shigusegubu.club/notice/AGwMfladbORcTf7QG0 and set "show other replies button" to "inside statuses".

btw, chromium 98

open this https://shigusegubu.club/notice/AGwMfladbORcTf7QG0 and set "show other replies button" to "inside statuses". btw, chromium 98

tusooa commented

2022-02-28 18:11:42 +00:00

Author

Owner

i missed one commit when cherry-picking from my branch... should be fixed

tusooa commented

2022-03-06 17:55:15 +00:00

Author

Owner

from hj:

Fading ancestors to be made optional (default: don't fade)
Show full conversation should have left borders
conversation display style configuration:
- dropdown: linear (new default) / tree
- checkbox: allow more flexible navigation within tree
[for later] ad-hoc switch between linear and tree (per thread)

from hj: - [x] Fading ancestors to be made optional (default: don't fade) - [x] Show full conversation should have left borders - [x] conversation display style configuration: - dropdown: linear (new default) / tree - checkbox: allow more flexible navigation within tree - [for later] ad-hoc switch between linear and tree (per thread)

hj commented

2022-03-06 18:16:03 +00:00

Owner

adhoc switch could be implemented in separate MR

tusooa commented

2022-03-06 18:26:25 +00:00

Author

Owner

sure

tusooa commented

2022-03-06 19:19:55 +00:00

Author

Owner

done

hj commented

2022-03-07 18:01:50 +00:00

Owner

what's this?

hj commented

2022-03-07 18:01:50 +00:00

Owner

commented code?

hj commented

2022-03-07 18:01:50 +00:00

Owner

commented code?

hj commented

2022-03-07 18:01:50 +00:00

Owner

commented code

hj commented

2022-03-07 18:01:51 +00:00

Owner

might be an issue on my side but for me in the UI default is empty.

need to make a NumberSetting some day since there's two of them now

also, should be undefined, instance default

might be an issue on my side but for me in the UI default is empty. need to make a `NumberSetting` some day since there's two of them now --- also, should be undefined, instance default

hj commented

2022-03-07 18:01:51 +00:00

Owner

use css custom properties instead of of scss variables pls, you can keep it here but make it a fallback only.