The design here should be the same as T274832, but with a few tweaks:

1. Copy tweaks

a) Heading
The conversation starts here
A great discussion starts with you.

b) Paragraph
Talk pages are where people discuss how to make content on Wikipedia the best that it can be. Start by adding a new discussion topic to connect and collaborate with a community of Wikipedians.
When you create this page, Wikipedia contributors will be able to publicly connect with you via a discussion board to work with you to make content on Wikipedia the best that it can be. Start by creating the page and when other contributors connect with you, you will receive a notification.

2. User flow tweaks

The button on the main page should just create a new page (not a new discussion).
I've identified an area where we can put an input or button or some kind of call to action in the future that would help to make this page appear more intuitive but I believe that will be part of the Talk Page legibility work in the future.

Would love a copy and logic review from @ppelberg @Whatamidoing-WMF

@Whatamidoing-WMF provided some good feedback via T274831

Re:

I recall seeing someone who started conversations with others on this user’s own user talk page by pinging them. Pretty weird, but not without an example. Also, not being able to create one’s own talk page [using DiscussionTools] while all other talk pages on the wiki can be created is probably much more confusing.

@ppelberg @Whatamidoing-WMF Is there a reason why don't automatically create this page for users when they create an account?
If we did then we could design your user page more intentionally.

@ppelberg and I sketched out this experience FOR YOUR USER PAGE which builds off the design of T274832 but removes the action button.
The page would remain a red link until someone commented on your page , however I would like to revisit that in the future.

This would mean that if you are coming to this page as a different contributor, you would need a different call to action and button. So this makes me wonder:

Is it technically feasible for someone who is logged in as Snoopy457 to see a version of the not-yet-created User talk: Snoopy457 that is different from the version someone who is NOT logged in as Snoopy457 will see ? (Peter put this in the task description). cc @DLynch

I believe that's feasible, yes. (You can sort of see precedent in how we display some pages a little differently based on user permissions.)

In T277329#7191753, @iamjessklein wrote:

@ppelberg @Whatamidoing-WMF Is there a reason why don't automatically create this page for users when they create an account?

A red talk page link can be a sign that a junior contributor has never been contacted by anyone, so if they e.g. vandalize pages, it can be because they don’t know how to contribute.

On the technical side, which user would be the creator of the talk page? What content would it have? Whatever you would put there as default content, you can just display it if the page doesn’t exist. (Furthermore, if you create the page with some content, that will definitely be the same for the owner and for non-owners; wikitext content cannot differentiate between viewing users.)

Thanks @Tacsipacsi

Re:

so if they e.g. vandalize pages, it can be because they don’t know how to contribute.

Is the assumption here that because they have been contacted by someone who in turn created their talk page and wrote them a message, that they will understand how to contribute?

Re:

On the technical side, which user would be the creator of the talk page?

The page could exist automatically on sign up (so really, you are the creator) and then when another contributor adds a new topic it will appear beneath that "header" content. However, if wikitext can't differentiate between users, does this mean that if that was implemented there would potentially be different views of content in visual and source modes?

In T277329#7191753, @iamjessklein wrote:

@ppelberg @Whatamidoing-WMF Is there a reason why don't automatically create this page for users when they create an account?

What would be the point of creating a blank discussion page?

About the wording "This page is public and anyone on Wikipedia has access to it."

There's a missing comma in the middle of that sentence, and "anyone on Wikipedia" might sound like "anyone who has registered and logged into an account", when the reality is more like "anyone with an internet connection". Consider re-phrasing it to something like "This page is public, and anyone can read anything posted here."

Re:

What would be the point of creating a blank discussion page?

For one thing, they wouldn't have a red link, and conceptually you are shifting from making the page and then adding the topic to a one button click for more experienced contributors to add that topic.

Thanks for the thoughts on phrasing @Whatamidoing-WMF, if we keep this design, I'll rework that copy.

For one thing, they wouldn't have a red link, and conceptually you are shifting from making the page and then adding the topic to a one button click for more experienced contributors to add that topic.

A red link is a useful signal, though. Removing it just to add boilerplate seems like it's throwing away information for no purpose.

The page could exist automatically on sign up (so really, you are the creator) and then when another contributor adds a new topic it will appear beneath that "header" content. However, if wikitext can't differentiate between users, does this mean that if that was implemented there would potentially be different views of content in visual and source modes?

• Boring technical objection: it'd involve adding a bunch of database rows and revisions for no useful data.
• It'd be more complicated to have some special "hi this is your page!" view for the "empty" state if the page isn't technically empty.
• Any future changes to this header copy wouldn't be automatically applied to earlier talk pages. (Unless it's implemented as a template, and that just seems more confusing for a newbie.
• As you say, if we're customizing the "empty" page to be different for the owner anyway, if they edit it the wikitext won't be what it looks like it should be.

conceptually you are shifting from making the page and then adding the topic to a one button click for more experienced contributors to add that topic.

Either way it's the same flow, I think? Follow the link, click a button that gets you to a form where you can create the topic. There shouldn't need to be a separate "create the page" step for the tool.

In T277329#7206677, @iamjessklein wrote:

Re:

so if they e.g. vandalize pages, it can be because they don’t know how to contribute.

Is the assumption here that because they have been contacted by someone who in turn created their talk page and wrote them a message, that they will understand how to contribute?

“The assumption […] that they will understand how to contribute” is a bit strong, but yeah, if they have been contacted by someone, the hope is that they will understand better how to contribute.

Okay, so here's where I'm at. I have three possible proposals for this space:

A. Different Experience for User and Contributor - button creates a new talk page. Both the user and contributor have unique copy tailored to their situation.
Pro:

• advanced personalisation

• instructs contributors with approachable copy

• maintains the paradigm of red links which is familiar to sr. contributors

Con:

• maintains the paradigm of red links which is confusing for jr. contributors

B. Same Experience for User and Contributor - button creates a new talk page.

Pro:

• maintains the paradigm of red links which is familiar to sr. contributors

• instructs contributors with approachable copy

Con:

• maintains the paradigm of red links which is confusing for jr. contributors

C. No empty state
Pro:

• breaks the paradigm of red links which is confusing for jr. contributors

• Feels the most similar to current experience

• One less step for everyone

Con:

• potentially controversial with sr. contributors

• Some contributors use red links on user talk pages to help them to scan contributor skill level

• Creates this page for IP pages (This might be more of a note than a con)

I feel pulled towards version C because it's a better experience for junior contributors, however I understand there's a risk (primarily from the feedback that @Whatamidoing-WMF and @Tacsipacsi have provided). If we were to go down this route further in this direction I would argue that we could address the requirement of Senior contributors needing to understand a contributor's experience level on quick view concurrently.

This work could be completely decoupled from the User Page proper but if it's not and the user page and user talk page were created concurrently and upon account creation, then there are some potential opportunities for overlap with the work that the Growth Team has been doing on user dashboards.

Some links worth reviewing:

• Link Color on Wikipedia
• Red Links in User/Tool Menu T282254

Full designs are in the figma file.

I've thought of another reason to oppose actually creating a revision every time an account is created: it's going to make Special:RecentChanges notably less usable.

Also, I think that "we've decided that redlinks won't be a thing any more" is the kind of controversy-provoking decision that'll make deploying the extension trickier...

For what it's worth, Flow uses something similar to approach C, except for the red link treatment. When a new user account is created, their user talk page initially doesn't exist and appears as a red link when referenced somewhere else. But when you visit it, it behaves as if it does exist but is empty. There's no guidance or explanation of what a user talk page is, but there is a UI to add a new topic, just as there would be if the page was empty. If you then add a topic, the page is created behind the scenes before the topic is added.

Example screenshots from https://www.mediawiki.org/wiki/User_talk:Catrope-testaccount:

If you choose approach C, I would recommend not actually creating empty pages (e.g. on account creation). Instead, as this example from Flow shows, there's precedent for having pages that don't exist and appear as red links, but that pretend to exist when you visit them.

Another such precedent is global user pages. @iamjessklein has never created a user page on the Dutch Wikipedia (nlwiki), yet if you go to https://nl.wikipedia.org/wiki/Gebruiker:JKlein_(WMF) you'll see something that looks a lot like a user page. But really it's the GlobalUserPage extension sort-of pretending that this page exists, by displaying the contents of https://meta.wikimedia.org/wiki/User:JKlein_(WMF) . What's more, links to this page are blue (e.g. here)! That's how good at is at pretending to exist. The only way you can tell that it doesn't "really" exist is by looking at the tabs in the top right next to the search bar, and noticing that there are no "edit" or "history" tabs, but instead there are "create" and "view on meta.wikimedia.org" tabs.

All that is to say:

• There is precedent for pages that don't really exist, but pretend to (and this is relatively easy to do)
• You can (and probably should) make a smooth transition from pretend existence to real existence
• There are some limits to this pretense: non-existent pages won't have a history and can't be deleted or renamed (unless you're prepared to layer on a lot more fakery, which I don't recommend)
• Despite that, making links that "should" be red be blue instead is easy, and there's precedent for that too

So those are things that you could consider using if you want to pursue approach C.

Despite that, making links that "should" be red be blue instead is easy, and there's precedent for that too

Interesting, I didn't realize that was so easy. Okay, my previous comments' objection on the basis of storage and garbage revisions are withdrawn.

I do think that a boilerplate user talk page that nobody has yet used becoming a blue link would be weird, though. The GlobalUserPage extension does, at least, present a page with content from somewhere, just eliding over the technical detail of whether it's in the current wiki's revision history.

In T277329#7218859, @DLynch wrote:

Despite that, making links that "should" be red be blue instead is easy, and there's precedent for that too

Interesting, I didn't realize that was so easy. Okay, my previous comments' objection on the basis of storage and garbage revisions are withdrawn.

Having made that claim, I should probably back it up :) . The GlobalUserPage extension does this through the TitleIsAlwaysKnown hook, which allows you to inspect a Title object and decide whether links to that page should always be blue or always red regardless of whether it exists (in which case the existence check won't even be performed). The built-in logic in core also has special behavior for some kinds of pages, e.g. special pages (Special:Log is a blue link but Special:Fdfjsadkfdsllj is red, despite the fact that neither exists in the database) and files (which are blue if they exist on Commons).

I do think that a boilerplate user talk page that nobody has yet used becoming a blue link would be weird, though. The GlobalUserPage extension does, at least, present a page with content from somewhere, just eliding over the technical detail of whether it's in the current wiki's revision history.

I agree, I think it probably makes more sense to keep it as red in this case too.

Open Questions:

• Do we keep red links?
• Which mockup should we go with of the 3 indicated?
• Whichever mockup we select, should we change other designs for cohesion?

Next step: @ppelberg meet with Jess to discuss especially about which mockup

In T277329#7225075, @LZaman wrote:

Next step: @ppelberg meet with Jess to discuss especially about which mockup

Answers to the open questions are written below and within the task's description's newly-created ===Requirements section.

@DLynch, please comment if any of the answers below read as surprising, unclear, etc.

Next steps

• @iamjessklein: can you please add the mockups that are to be implemented to the task description's ===Mockups section?
• @iamjessklein: can you please share more details about the use case referenced below [i]?

Answers to open questions

• Do we keep red links?

Yes, in all cases (T274831, T277329, and T274832) talk pages that have not-yet-been-created should continue to appear as red in the same way(s) and places they currently do. [i]

• Which mockup should we go with of the 3 indicated?

We should move forward with the mockup that shows the person viewing their *own* user talk page an empty state that is different from the empty state other people will see (read: the version most similar to Approach A in T277329#7218284). [i]

• Whichever mockup we select, should we change other designs for cohesion?

As I currently understand things, moving forward with the mockup most similar to Approach A in T277329#7218284 will not "degrade" cohesion in any unexpected ways (e.g. we expect for people viewing their *own* user talk page to see an empty state that is different than another person viewing that user talk page).

@DLynch / @iamjessklein: if by moving forward with the mockup most similar to Approach A in T277329#7218284, you think we will introducing more inconsistency into the experiences between T274831, T277329, and T274832, please comment as much.

i. Note: Jess identified a potential scenario where people would need to create (read: start a conversation on) their own user talk page. She is going to provide more details about this scenario. Should this scenario prove to be more common than we currently understand it to be, we would need to consider revising the initial implementation described above.

a potential scenario where people would need to create (read: start a conversation on) their own user talk page.

We talked about it in the meeting today. To summarize the discussion:

• Generally, editing starting new topics on your own talk page is discouraged, because usually no one else is watching your talk page, and no one will see the messages.
• The only scenario where you need to do that is when you're blocked and requesting to be unblocked (because you're not able to edit any other page while blocked). Depending on the wiki, you might be supposed to use a template when doing this (e.g. https://en.wikipedia.org/wiki/Template:Unblock, it adds your talk page to a category that people watch and will see the edit), so it might be more awkward to do in our default visual mode.
• There are some workflows where you'd do that (in addition to the unblocking one, @Whatamidoing-WMF mentioned https://en.wikipedia.org/wiki/Template:Help_me), so it needs to be possible to do it, but there probably shouldn't be a call to action. It might be even okay to only have the old interface for doing this (the "Edit"/"Create" tab to open the wikitext editor).

In T277329#7228227, @matmarex wrote:

• Generally, editing your own talk page is discouraged

You mean starting new topics on your own talk page, don’t you? Other edits—including replying to talk page messages and cleaning up/archiving the page—are not discouraged or even encouraged.

Yes :)

In T277329#7228227, @matmarex wrote:

• The only scenario where you need to do that is when you're blocked and requesting to be unblocked (because you're not able to edit any other page while blocked). Depending on the wiki, you might be supposed to use a template when doing this (e.g. https://en.wikipedia.org/wiki/Template:Unblock, it adds your talk page to a category that people watch and will see the edit), so it might be more awkward to do in our default visual mode.

Usually, if you're requesting an unblock, your User_talk: page will already exist. However, that will not always be the case, especially if you've been caught by an IP range block. Consequently, there will need to be some way for editors to create their own User_talk: pages. (The [Edit] button at the top of the page is what they use now, and it would probably be just as adequate then, too.)

I've updated the ticket description with the final designs.

As @Whatamidoing-WMF described, we will rely on the Edit button at the top of the page for "your" user talk page.

In T277329#7232748, @iamjessklein wrote:

I've updated the ticket description with the final designs.

Thank you, Jess.

In T277329#7232622, @iamjessklein wrote:

What (user) sees:

The talk page’s owner should certainly not see “Creating User talk:Snoopy”, but rather “User talk:Snoopy”, since they don’t have the ability to create the page inline. Probably others shouldn’t see “Creating” either, to be consistent with how DiscussionTools works on existing pages (there’s no “Editing User talk:Snoopy”, just “User talk:Snoopy”).

The talk page’s owner should certainly not see “Creating User talk:Snoopy”, but rather “User talk:Snoopy”, since they don’t have the ability to create the page inline. Probably others shouldn’t see “Creating” either, to be consistent with how DiscussionTools works on existing pages (there’s no “Editing User talk:Snoopy”, just “User talk:Snoopy”).

@Tacsipacsi Thanks for bringing this up.

While, yes there is no obvious affordance for making the page, the page isn't technically created as there is still a red link. I say obvious because of course there are still the tabs at the top of the navigation that will allow you to perform this task.

However, @ppelberg and I discussed it and we are going to default to abstracting the complexity away and as you suggest, remove "Create," I will update the mockups in the description.

Change 708713 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Apply an empty-state to pages with the new topic tool enabled

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

@DLynch: are you able to adjust the implementation to include the copy I've posted to the task description?

@DLynch: are you able to adjust the implementation to include the copy I've posted to the task description?

We talked about this and came to decisions in T274831. We're going to make a -link message for the help page and let the projects adjust it if-needed.

Change 708713 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Apply an empty-state to pages with the new topic tool enabled

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

In addition to myself, I'd like @KieranMcCann to do a design review.

Change 711670 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Apply design tweaks to empty states

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

Change 711670 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Apply design tweaks to empty states

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