Page MenuHomePhabricator

Add support for preloaded text
Open, Needs TriagePublic

Description

This task is about adding support for preloaded text to the New Discussion Tool.

Behavior

  1. On wikis where the New Discussion Tool is available and on pages where the New Discussion Tool has been enabled for preloads (see: T270797), visit a discussion page that contains a custom new section call to action that, when clicked, loads the new section from from a URL that contains &preload=.[i][ii]
  2. Click the "custom new section call to action" mentioned in "Step 1."
  3. Observe the New Discussion Tool opens in source mode [iii], populated with the preloaded content that is being called from the page &title= portion of the URL mentioned in "Step 1."

Open questions

  • What makes it challenging to show people preloaded content in the tool's visual mode? My instinct: this constraint stems from the tool's [current] inability to offer reliable support for templates, as we talked about in T241388#5830983.
    • "...main problem would be support for templates, and even worse, substituted templates..." More details in T269310#6697490.

Done

  • All "Open questions" are answered
  • "Behavior" is implemented

i. en.wiki's WP: Teahouse is an example of page that contains said "custom" new section call to action
ii. More examples of pages that contain "custom new section calls to action" can be found in T250768
iii. See: T250768#6441372

Related Objects

Event Timeline

ppelberg created this task.Dec 3 2020, 12:01 AM
Restricted Application removed a project: Patch-For-Review. · View Herald TranscriptDec 3 2020, 12:01 AM
ppelberg moved this task from Backlog to Triaged on the DiscussionTools board.Dec 12 2020, 3:34 AM

Change 645211 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ArticleTargetLoader: Allow customizing 'editintro' parameter

https://gerrit.wikimedia.org/r/645211

Change 650006 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ApiVisualEditor: Support 'preload' etc. for new sections in visual mode

https://gerrit.wikimedia.org/r/650006

Change 650007 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] [WIP] Support launching new discussion tool from custom links, with 'preload' etc.

https://gerrit.wikimedia.org/r/650007

matmarex added a comment.EditedDec 17 2020, 1:21 AM

Prototype demo (v2):

(Note that things are slower on the demo wikis than they will on Wikimedia wikis.)

Some thoughts: (and an answer to your question, at the end)

  • I think we should only enable this on pages that "opt-in" somehow, at least at the beginning.

    There are many workflows using section=new links with custom preload/editintro text that will break assumptions of the new discussion tool (e.g. https://en.wikipedia.org/wiki/Wikipedia:Files_for_discussion#Listing_a_file where if you follow the instructions, you end up in a section=new form where you're supposed to leave the title blank; someone also listed a few other examples just minutes ago at https://www.mediawiki.org/wiki/Topic:Vzqm8mdsh79sy3r7).

    For the prototype, I implemented this by only launching the new tool on links wrapped in <div class="newtopiclinks">…</div> in the page wikitext (there's probably a nicer way, this was just the simplest idea). Other links just open the normal editor as before.
  • Given the above, I think we should support the visual mode as well. Somebody has to explicitly enable the new tool, so they can probably also take care to make the preloaded text work well in the visual mode. You're right that the main problem would be support for templates, and even worse, substituted templates (like in the "Wikipedia:Files for discussion" example I linked).

    (I didn't actually tweak the preload text for visual mode in the Teahouse demo, so you'll actually see there how it fails.)
matmarex updated the task description. (Show Details)Dec 17 2020, 1:27 AM

This is looking great, @matmarex; the tool seems to adapt as expected when the parameters are changed (e.g. Talk:New_section&direction=next&oldid=254) and when some are removed (e.g. Talk:New_section&oldid=257).

Some thoughts: (and an answer to your question, at the end)

  • @matmarex Can you say more here? In suggesting we make the new discussion tool opt-in on pages using preloads to start, what scenario(s) are you wanting us to avoid?

    ...the examples you shared above don't immediately strike me as concerning considering the tool seems to have no issue with publishing a topic without the Topic field containing any content.

    Asked another way: is there something about how the New Discussion Tool currently behaves that you think is more likely to cause disruption and/or confusion than the existing workflow on pages like wp:Files for discussion where the posting instructions ask people NOT to fill content in the Subject field?
  • Given the above, I think we should support the visual mode as well. Somebody has to explicitly enable the new tool, so they can probably also take care to make the preloaded text work well in the visual mode.
  • @matmarex: what would it look like for someone to adapt the preloaded content work well in the tool's visual mode? And what would "working well" look like/mean for the person using it?

You're right that the main problem would be support for templates, and even worse, substituted templates (like in the "Wikipedia:Files for discussion" example I linked).

Roger that, okay.

I'm glad you posted this; I hadn't seen this page before.

  • @matmarex: are there paramters within the Edit and submit section the New Discussion Tool will not be able to support? I ask this in anticipation for editors wondering what – if anything – constrains their ability to potentially customize the way the New Discussion Tool handles preloads.

@matmarex We need a way to suppress the anon edit notice as we already have one built in to the widget.

  • I think we should only enable this on pages that "opt-in" somehow, at least at the beginning. (…)
  • @matmarex Can you say more here? In suggesting we make the new discussion tool opt-in on pages using preloads to start, what scenario(s) are you wanting us to avoid?

    ...the examples you shared above don't immediately strike me as concerning considering the tool seems to have no issue with publishing a topic without the Topic field containing any content.

    Asked another way: is there something about how the New Discussion Tool currently behaves that you think is more likely to cause disruption and/or confusion than the existing workflow on pages like wp:Files for discussion where the posting instructions ask people NOT to fill content in the Subject field?

In this particular scenario, you'd get an annoying warning about the topic field being empty (and if you fill in the field, then you might annoy other editors when they see a heading in the wrong place).

There are also workflows where you're not supposed to add a signature, or where the signature is included somewhere in the preloaded text, and our tool would always insert (another) one. (Example: undeletion requests at pt.wp: https://pt.wikipedia.org/wiki/Wikipédia:Pedidos/Restauro click "Inserir um novo pedido")

It doesn't completely "break", but I think it would be a negative experience, both for the user of the tool, and for others who might need to fix the page to follow the existing conventions.

  • Given the above, I think we should support the visual mode as well. Somebody has to explicitly enable the new tool, so they can probably also take care to make the preloaded text work well in the visual mode.
  • @matmarex: what would it look like for someone to adapt the preloaded content work well in the tool's visual mode? And what would "working well" look like/mean for the person using it?
  • [before you start: Verify that this is a discussion workflow (that is, you want users to provide a topic title, and to sign their comment at the end), rather than something different (e.g. a form for adding yourself to the list of members of a wikiproject). Otherwise, you probably don't want to use the new tool.]
  • Avoid {{subst:…}} syntax
  • Put instructions into the editintro, instead of wikitext comments (<!-- … -->)
  • If you have a signature in the preloaded text, ensure it's at the end so that the tool doesn't insert another one
  • @matmarex: are there paramters within the Edit and submit section the New Discussion Tool will not be able to support? I ask this in anticipation for editors wondering what – if anything – constrains their ability to potentially customize the way the New Discussion Tool handles preloads.

We probably don't want to support the 'preview' parameter, since we have an "always-on" live preview in wikitext mode, and don't want to have a preview in visual mode.

I've mentioned the 'nosummary' parameter earlier, and we could support it, but on second though, I don't think we want to. I'd expect it to be used for mostly non-discussion workflows (also… I've never seen it used in practice).

As mentioned, we can support 'summary'. All other parameters remaining don't apply to the new section mode.

I've mentioned the 'nosummary' parameter earlier, and we could support it, but on second though, I don't think we want to. I'd expect it to be used for mostly non-discussion workflows (also… I've never seen it used in practice).

It’s used e.g. at hu:Wikipédia:Bürokraták üzenőfala/Átnevezés (local request page for renaming users; legacy from the pre-SUL times when local bureaucrats handled rename requests but still handled by Hungarian-speaking global renamers). This page is not a 100% discussion page, but it still has a title (created by the subst’d template to make sure that section titles are uniform and the user doesn’t need to type more than strictly required), and a new section still initiates a discussion (at least one reply from the bureaucrat indicating that the request has been fulfilled/cannot be fulfilled). Currently the reply tool doesn’t work there, but we could add a hidden user name link in the last line to make it work. However, avoiding subst is not really an option there (this is not an instruction, but a real template that also makes use of {{subst:REVISIONUSER}}, where subst is essential).

@matmarex We need a way to suppress the anon edit notice as we already have one built in to the widget.

@Esanders: good spot. I've been thinking this work will happen in T270454. Please comment there whether you think adjustments need to be made to the task description.

  • I think we should only enable this on pages that "opt-in" somehow, at least at the beginning. (…)
  • @matmarex Can you say more here? In suggesting we make the new discussion tool opt-in on pages using preloads to start, what scenario(s) are you wanting us to avoid?

    ...the examples you shared above don't immediately strike me as concerning considering the tool seems to have no issue with publishing a topic without the Topic field containing any content.

    Asked another way: is there something about how the New Discussion Tool currently behaves that you think is more likely to cause disruption and/or confusion than the existing workflow on pages like wp:Files for discussion where the posting instructions ask people NOT to fill content in the Subject field?

In this particular scenario, you'd get an annoying warning about the topic field being empty (and if you fill in the field, then you might annoy other editors when they see a heading in the wrong place).

There are also workflows where you're not supposed to add a signature, or where the signature is included somewhere in the preloaded text, and our tool would always insert (another) one. (Example: undeletion requests at pt.wp: https://pt.wikipedia.org/wiki/Wikipédia:Pedidos/Restauro click "Inserir um novo pedido")

It doesn't completely "break", but I think it would be a negative experience, both for the user of the tool, and for others who might need to fix the page to follow the existing conventions.

The kinds of issues you had in mind are now clear to me; thank you for explaining this.

In light of the above, I too agree pages that use preloads in their section=new form should have to opt-in to using the New Discussion Tool to start.

@Esanders had some ideas for how this could be implemented. I've documented this work and the ideas Ed shared in T270797.

I've also updated this task's description to reflect the above. See the revised "Step 1." within the ===Behavior section.

  • Given the above, I think we should support the visual mode as well. Somebody has to explicitly enable the new tool, so they can probably also take care to make the preloaded text work well in the visual mode.
  • @matmarex: what would it look like for someone to adapt the preloaded content work well in the tool's visual mode? And what would "working well" look like/mean for the person using it?
  • [before you start: Verify that this is a discussion workflow (that is, you want users to provide a topic title, and to sign their comment at the end), rather than something different (e.g. a form for adding yourself to the list of members of a wikiproject). Otherwise, you probably don't want to use the new tool.]
  • Avoid {{subst:…}} syntax
  • Put instructions into the editintro, instead of wikitext comments (<!-- … -->)
  • If you have a signature in the preloaded text, ensure it's at the end so that the tool doesn't insert another one

I see. I've added this point as a question in T270797 as it's not yet clear to me what might be a good way to make page "maintainers" aware of why and how they can enable the New Discussion Tool for preloads and how to adapt said preloads so they "cooperate" with the New Discussion Tool's visual mode.

  • @matmarex: are there paramters within the Edit and submit section the New Discussion Tool will not be able to support? I ask this in anticipation for editors wondering what – if anything – constrains their ability to potentially customize the way the New Discussion Tool handles preloads.

We probably don't want to support the 'preview' parameter, since we have an "always-on" live preview in wikitext mode, and don't want to have a preview in visual mode.

I've mentioned the 'nosummary' parameter earlier, and we could support it, but on second though, I don't think we want to. I'd expect it to be used for mostly non-discussion workflows (also… I've never seen it used in practice).

As mentioned, we can support 'summary'. All other parameters remaining don't apply to the new section mode.

Understood. A resulting question...

  • @matmarex, in T269310#6699739 you alluded to pages [i] where it would be unexpected/undesirable for people using the section=new workflow to populate the form's Subject/headline field. This leads me to wonder: Why did you suggest that we not support the nosummary parameter [ii] considering it seems, as @Tacsipacsi shows in T269310#6703855, there are cases where disabling that field by way of the nosummary parameter seems like it would be useful?

i. https://en.wikipedia.org/wiki/Wikipedia:Files_for_discussion
ii. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Edit_and_submit
iii. https://w.wiki/rrB

ppelberg updated the task description. (Show Details)Dec 24 2020, 12:13 AM
ppelberg updated the task description. (Show Details)Dec 24 2020, 12:16 AM

Change 650006 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ApiVisualEditor: Support 'preload' etc. for new sections in visual mode

https://gerrit.wikimedia.org/r/650006

Change 645211 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ArticleTargetLoader: Allow customizing 'editintro' parameter

https://gerrit.wikimedia.org/r/645211

  • @matmarex, in T269310#6699739 you alluded to pages [i] where it would be unexpected/undesirable for people using the section=new workflow to populate the form's Subject/headline field. This leads me to wonder: Why did you suggest that we not support the nosummary parameter [ii] considering it seems, as @Tacsipacsi shows in T269310#6703855, there are cases where disabling that field by way of the nosummary parameter seems like it would be useful?

I think these pages probably have somewhat complicated workflows with templates and stuff, and it would probably be more practical to just keep using the old interface for them rather than try to adapt our new interface.

Also, adding the ability to hide that field would make validation (T269285) more difficult to implement.

i. https://en.wikipedia.org/wiki/Wikipedia:Files_for_discussion
ii. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Edit_and_submit
iii. https://w.wiki/rrB

I think these pages probably have somewhat complicated workflows with templates and stuff, and it would probably be more practical to just keep using the old interface for them rather than try to adapt our new interface.

Understood.

Also, adding the ability to hide that field would make validation (T269285) more difficult to implement.

Noted.

This will require T269033 first, as custom preloaded text often comes with a custom edit notice containing instructions.

For example:

Below are notes from today's team conversation about this task's dependence on T269033 per T269310#6749816...

Next steps

  • We are going to pause work on support for prelaods and edit notices until after the New Dicussion Tool is available as a Beta Feature (T269471) and before we consider offering it as an opt-out preference (T271964).

Agreements

  • We came to agree that it would be risky to incorporate the contents of the edit notice component into the New Discussion Tool's Description field, even temporarily.
    • Reason: we assume, in most cases, "page maintainers" populate edit notices with content that is notably different from the content they populate the new section form's Description / Body field with. As such, we think people would be confused were they to open the New Discussion Tool and see the Description field filled with two kinds of guidelines: 1) guidelines for how and what to talk about on a given talk page and 2) guidelines for how a new topic's description ought to be formatted.

Considerations

  • Related to the "Agreement" above, we thought we could save "page maintainers" effort by offering support for preloads and edit notices within the New Discussion Tool at the same time.
    • Thinking: if preloads and edit notices are introduced at the same time, we can save "page maintainers" the effort of having to reconstruct the page's existing preloads in ways that will work with the New Discussion Tool's source and visual modes (T270797), having some time pass and then having to come back and do something similar for the to-be-designed edit notice component (T269033).

We should also consider buttons generated by the <inputbox> extension, as mentioned here: https://www.mediawiki.org/wiki/Topic:W0n4nevz8ty8it1r