Topic on Talk:Talk pages project/New topic/Flow

At phab:T247485#6086554, @Iamjessklein commented

One additional thing that felt off was what happens when a user doesn't add a title to their discussion but posts it. If a user doesn't provide a subject on their new topic post, the post goes under the previous topic. I find that to be unexpected and something that we should not reproduce when we do our iteration.

And at phab:T247485#6067031

Many participants only left a topic and were not directed how to write the initial comment.

I'm not sure if that means they filled in the “Subject/headline” box but added no text in the main editor box?

---

Try doing the same thing on Mobile web: the Publish button is disbled if either box is blank. (Fields are labelled "Subject" and "What is on your mind?" in mobile.) Fix: apply the same logic to Desktop web.

@Pelagic the first workflow for desktop is:

- tap add topic button

- write a message (but no subject)

- publish changes

- find your post by going to the last discussion on the page and it's written on a new line (not indented or anything) below the last message on that thread.

In the second example, yes, several test participants were confused by having to follow conventions that I guess are more similar to email than comments.

@JKlein (WMF) Your phrase “conventions … more similar to email than comments” reminds me that there's a spread in the use of topic headings:

• email, mailing lists – web forums – wikis – news sites, blogs, YouTube – workplace collaboration tools, MS Teams, Slack, Trello – Facebook, Twitter

To what extent has your team compared different discussion environments? What kind of conventions do you think the participants were used to?

[Side notes:– (a) Not all of the platform types use discussions / comments to collaborate or build content. Other purposes include: fomenting conflict "driving engagement", user profiling / advertising intelligence, one-sided feedback gathering, fooling people to feel involved even though they don't matter. Keeping discussions organised and on-track (which may involve using headings, etc. in various ways) is more important to some purposes than others. (b) In addition to headings, it's useful to compare other ways the types of venue differ in their treatment of: top post versus follow-up posts, content versus comment, authors versus rabble.]

Alternately you could pre-populate the fields so that if somebody hits Publish without typing anything, they produce

== New topic ==
What's on your mind?

But I foresee endless arguments about what that text should be.

Agreed.

I think that another option is to have an error message appear or make it impossible for someone to post without filling in these required fields.

Error messages feel unfriendly, but “disable the button to make it impossible” is the approach taken on mobile web.

Is giving people a button they can't use more unfriendly than allowing them to post clueless default text? I'm not sure, but either will be a better experience than allowing them to smoosh their "new discussion" into the previous one.

(Personally I prefer the disable button approach, but some people still mightn't get it. Maybe that's something WMF could A/B test? Acknowledging that time and budget for user testing is probably limited, I guess.)

We often get feedback that contains no (non-automatic) "body", just a title.

On that Structured Discussion board, @Whatamidoing (WMF)? For me, the Add topic button stays disabled until I put something into both title and body.

A single space works, but if they are doing that then is it with intent rather than by accident?

(At work we have a helpdesk ticketing system where I sometimes enter a single '.' into a mandatory field because I really have nothing to add over and above what I've entered into the other fields. On the other hand, it's not uncommon that I'll move a long subject (mine or someone else's) into the body and replace it with a shorter summary heading. I'm the type who re-phrases email subject lines when replying, so I'm a bit special. Maybe more like the Wikipedia population and less like the general population. Now I'm mentally picturing a new banner "Wiki ❤️ Gnomes"!)

No, this feedback comes through a form that's inside VisualEditor. Open a page in the visual editor or 2017WTE, and look in the "(?)" help menu for a software-feedback form. Every wiki except enwiki can have their feedback delivered directly to the team at the main feedback page here.

Aah, I see. Sorry I didn't realise; thanks for explaining, @Whatamidoing (WMF). That's a case where pre-populating the box with an automatic body makes sense.

Side question: does anybody still monitor en:wp:VisualEditor/Feedback ? Oh, I just saw the highlighted text at the top of the page. But people using the VE UI won't.

And can you see the link to en:wp:VisualEditor/Feedback in the previous paragraph?

You had accidentally made an interlanguage link there. I fixed it for you. (Remember this, because some day, someone will tell you that you can't fix other people's links in Flow, and you'll be able to set them straight.)

I'd like to have enwiki's feedback posted here. See phab:T224851 if you want to know why it's not happening.

Thanks, User:Whatamidoing (WMF). I totally forgot about old-style inter-language links and the leading colon. Redrose pointed me to a discussion where they mention that Talk namespaces behave differently, which might be how I formed the wrong expectation.

Oh, I assumed the separate treatment of en-wp was social/organisational rather than technical. (You could say it is, but indirectly).

I fixed it for you. (Remember this ... Understood. Can one also refactor and move posts to different topics? I haven’t seen a way to do that in SD.

Another off-topic observation that I may have already mentioned elsewhere: I’m writing this on the mobile web interface and Structured Discussions editor doesn’t have a toolbar, so pinging you just got harder. Also there’s no preview (hope I got the templates right). I really want Discussion Tools to be available on mobile, and to have feature parity with desktop. 🙁

[Edit: nup, I left an underscore in the username. Guess the ping is broken.] Pelagic (talk) 19:29, 2 June 2020 (UTC)

It looks like that link is to "User:User:" underneath the label. That's probably the visual mode tripping you up; you can use the pencil icon by the blue button to switch to wikitext if you want (on desktop, anyway).

Flow autosubscribes you to a thread that you've commented in, so pings are not necessary. (Flow also unsubscribes you to threads that you *don't* reply in or actively subscribe to, on pages that are on your watchlist.) If they had finished building Flow, it would be possible to refactor posts (might be limited in some ways, but merge/split was definitely planned), move threads to different pages, and have the same thread appear simultaneously on multiple pages (and originally, on separate wikis: Imagine a deletion discussion for a Commons file that was visible on the Talk: page of any article that used that image). None of that has been built.

Back when the visual editor was new, we had local noticeboards at dozens of Wikipedias. Over time, all of them have either been redirected to the central page on MediaWiki.org or turned over to local volunteers. I followed the English Wikipedias longer than any other, but eventually I decided to have it merged. In between now and then, they put in a "special" configuration for enwiki, and anything using MediaWiki core's built-in feedback tool is broken. (At the moment, VisualEditor is the most significant user, by a substantial margin, but it is not the only thing that is broken.)

User:User: – tehehe, I have no idea how I managed to do that!

Pings not necessary – thanks, I’ve been wondering about the etiquette here of pinging to generate an Alert versus just replying to generate a Notification. I’ll hold off pinging people already in the thread.

also unsubscribes you – didn’t know that, thx

If they had finished building Flow – yes fair point

MediaWiki core's built-in feedback tool – if core has a dependency on an extension that’s not even recommended for third party MediaWiki installs, that would be ... not great? But thanks for the clarification. No I was wrong there. Feedback can post to normal wiki pages, so its support for SD is a capability not a dependency. The breakage is more a case of trying to integrate between wikis that have different extensions required/available.

Yes, the problem is when you send content to a page that the sending-user's wiki doesn't grok. Or, to put it more generally, we should just let the Ops folks decide how to configure the wikis.

> I really want Discussion Tools to be available on mobile, and to have feature parity with desktop. 🙁

@PPelberg (WMF), do we have a plan for getting the Reply tool onto the mobile site? You and I haven't talked about it for months, but I don't know if the team is talking about it.

Disallowing empty input for the New Section workflow could be beneficial in general, not just for Talk.