Page MenuHomePhabricator

Deprecate {{outdent}} in favor of per-script pure visual behavior
Open, Needs TriagePublicFeature

Assigned To
None
Authored By
Wellverywell
Tue, Oct 22, 2:10 PM
Referenced Files
F57633797: image.png
Tue, Oct 22, 3:29 PM
F57633778: image.png
Tue, Oct 22, 3:29 PM
F57633755: image.png
Tue, Oct 22, 3:29 PM
F57633751: image.png
Tue, Oct 22, 3:29 PM
Tokens
"Love" token, awarded by Jack_who_built_the_house."Like" token, awarded by MBH.

Description

Problem

Currently, to structure large discussions with large "depth" of comments templates like {{outdent}} (82 interwikis) are used. First of all, this template is not semantic -- what it does is not related to the discussions where it is used or their structure, what it does is only related to their visual display on HTML pages.

Wikimarkup of discussions is significantly more complicated and harder to understand when the template is used -- because now, to understand on which depth a comment is it is not sufficient to look on the number of colons/asterisks to the left of it -- there is always a possibility there could be an outdent above, and, worse, it could be arbitrary number of comments/lines above. This absolutely destroys the very simple (and working when not using {{outdent}}!) abstraction of a discussion as a tree of comments (with depth of any comment = number of indentation symbols) for both users and tools.

There is another problem -- its ambiguity. Consider the following example:

:
::
:::
::::
  ___|
  |
:

Where should one place a reply to the second comment? If they try to do that in a simple tree-abstraction way that users and tools are used to, they'd get:

:
::
:::
::::
  ___|
  |
::: reply
:

...which now will be understood as a reply in the outdented branch. For these reason, tools (at least Convenient-Discussions, DiscussionTools AFAIK produces such incorrect behavior) in such situations place the reply directly above the branch with outdents -- which breaks the chronological (and logical) order and is quite an ugly hack by itself, but the lesser evil here.

As a display feature it also lacks a very important aspect -- configurability. For example, see T265750 for a request to make DiscussionTools be able to configure outdents behavior (though why not then could it control all their behavior by itself?).

Proposal

Just stop using {{outdent}}. I propose that outdents visual behavior would be implemented in major tools (like DiscussionTools and Convenient-Discussions, the maintainer of the second already give his agreement in the case this proposal would be supported) -- they are free to make the behavior 100% the same as is currently in {{outdent}}, to make it configurable, or anything, that's completely up to them (and probably the discussion in this task). In my opinion starting with the existing {{outdent}} behavior would be fine. Something like this was actually proposed in T93238 for StructuredDiscussions, but was never implemented and the tool was deprecated.

As for the template itself, I think this is a less important issue, but the ideal solution in my opinion would be to try to do a bot run autodeoutdentifying (i.e. removing {{outdent}} templates and changing comments' indentation to their logical not visual one in the cases where it's possible) at least on large wikis, with possibly some manual cleanup after. After that the template could be deleted.

Probably, if there would not be much activity on this task for some reasonable amount of time I will start such a discussion on these large wikis.

Benefits and Drawbacks

First benefits are obvious. Now, the discussion structure will be again semantic, again easily abstractable on each comment level, the replies will be no longer ambiguous, the markup will be significantly less complicated and more understandable for users and tools, and users/tools will be able to control and configure outdent visual behavior much more.

As for the drawbacks, well, the only one is that users in some cases may see comments without outdentation -- which results, in worst case, in one word-per-line behavior (on small screens). But what exact uses will be affected?

  • Reading comments through wikimarkup -- nope, only made easier because of simplifying structure,
  • Writing comments through wikimarkup -- nope, only made easier because of ambiguity removal,
  • Reading comments through HTML without using major discussion tools -- could be affected, but the only problem is listed above and the number of such users is probably not very large (logged-out users that read comments + logged-in users without DT or CD enabled). Probably a script could be implemented that does fallback visual outdentation in the case CD or DT aren't enabled (and such a script would be enabled by default even for logged-out users),
  • Reading comments using a major discussion tool -- nope, only made better because outdentation behavior now could be configured in tool,
  • Writing comments using a major discussion tool -- nope, only made better because now chronological order will be conserved and will not be broken in situations with {{outdent}} template.

Analyzing this, it seems for me that the number of benefits quite significantly outweighs the number of drawbacks.

Event Timeline

I've researched different ways of handling long threads for Convenient Discussions. The strategy Convenient Discussions currently implements is quite intricate and a result of many trade-offs. CD has long supported handling existing outdent templates (and is even able to identify the target comment of an outdented reply after some comments were added between the outdented reply and its target, i.e. the thread was broken). At some point, I also decided to support placing outdents (for several reasons – first, CD is heavily used in Russian Wikipedia where long threads are a commonplace; second, Vector 2022 makes the content block narrower than old Vector).

Strategy that CD uses

  • Place the outdent template when the discussion is deeper than 15 levels by default.
  • Don't place the outdented reply on the 0th (no indentation) or even 1st level (:). Instead, place it so that there is no ambiguity as to which comment the comment under it replies to. For example, if we place the reply like this:
    image.png (368×559 px, 33 KB)
    what does the Reply 6 reply to: the outdented reply or the opening comment of the topic? But if we place the reply like this:
    image.png (360×558 px, 33 KB)
    there is no ambiguity.
  • But issues start to erupt as soon as we have a really populated discussion with many threads and subthreads and so on.
    • First, while trying to disambiguate as I laid out, you sometimes encounter a situation where you can't put the outdented reply on a high level in the visual hierarchy (e.g. 2, ::). Instead, you put it on a low level which partly defeats the point of outdenting. Heated debates in Russian Wikipedia sometimes look like this:
      image.png (1×1 px, 110 KB)
    • Second, there is the problem that @Wellverywell described in the task (see "Consider the following example"): where should the tool put the reply if there is an outdent between its natural place and the target comment? CD, in that case, either puts the reply directly below the target comment (violating the chronological order) or (when replying directly to a comment that is followed by an outdent) replies to the section instead while quoting the target comment; it looks like this:
      image.png (695×1 px, 47 KB)

DT, as I can see, implements a different strategy. It doesn't place its own outdents, and as for the outdents interfering in replying, it just places the reply above the comment with the outdent, confusing the latter's target. I tried to show the difference between CD and DT on this test page.


The above strategy is the best I could come up with existing limitations and being a maintainer of a tool used by a portion of users. I believe it does a relatively good job, but as you can see, it is very limiting. When users post both with DT and CD on one page, the resulting look is often confusing.

An alternative where the source code would contain the logical structure of the discussion (i.e. model) while the web page would shape the visual structure of the discussion (i.e. presentation) in a way appropriate for the given format (I only saw a discussion and some mockups for mobile in T116686) is definitely preferred and is in line with the principle of separation of concerns.

So I would definitely support the intention of this topic and the deprecation of outdent templates in favor of fiddling with the visual output using tools. As for the implementation part, it's mostly up to Discussion Tools developers at this point. It could be a part of a visual revamp outlined in T282269. If this is implemented in some form, I'll try to catch up in CD. A bot run would be non-trivial, and maybe existing usages should be left as they are.