Topic on Talk:Beta Features/Archive 2

Recently @Nemo bis has indirectly asked why I insist on the feedback page for each Beta Feature being a Flow page, rather than the legacy talk page system that they prefer.

Briefly, the reasons are:

• Convenience for users, especially those having to respond;
• Scalability for lots of parallel discussions;
• Software-compatible way to mark threads as resolved (and un-mark when needed);
• Ability for individuals to subscribe to one thread; and
• Mobile compatibility.

I'm willing to discuss this further, especially with those who have new data to bring.

Says who?

I do. It's me to whom you're replying. Sorry that that wasn't clear.

Hi, perhaps I should also clarify myself. Mentioning users in Flow isn't very convenient as we have to use a wholly different template. Also, we can't add images, which can be a problem for jokers like @EEng and @Levivich who like to use imagery when conversing with other editors. We also can't hat discussions as offtopic, NOTFORUM, and "not a place to air grievances." FlowMention and Preview are also awfully slow.

Well, images aren't just for joking. As we well know, multimedia is often a more effective way to communicate than is text alone. (Just getting this ping three years later, so you see how effective the whole system is.) ~~~~

Each of your points sounds like a reason to keep using Structured Discussions. Abuse of discussion pages results in people being blocked here, not adding random archaïc wikitext to make them feel bad.

And if you really think you can convince me that pressing @ is not "very convenient" as a way to mention people, I shudder to think what is.

Test: @Jdforrester

Doesn't work

Flow has been removed from the English Wikipedia and now Meta-Wiki. It doesn't seem to be very popular. How many wikis are using Flow? I'm struggling to believe that <https://noc.wikimedia.org/conf/highlight.php?file=flow.dblist> is accurate.

My most recent gripe with Flow is that I've found the indentation/threading behavior aggravating and unintuitive.

I believe Nemo_bis refuses to use Flow at all, so he won't be able to engage or discuss here.

From my perspective if beta features were discussed on conventional talk pages, I'd be concerned about several things:

1) non-editors joining the conversation - wikitext does put off some users hence why we are building VisualEditor. Barrier for entry should be even lower here.

2) my team's ability to keep on top of all discussions. The archiving functionality is a life saver. it ensures nothing gets missed unintentionally; things get fixed; conversations happen in a single place rather than multiple places; things get tracked on Phabricator where necessary. Doing all this with a talk page is clunky and time consuming if you're not an advanced editor.

3) Mobile (editing talk pages is near impossible on mobile)

What exactly is seen as the problem with using Flow - what problems will the legacy talk page system solve that Flow doesn't?

The issue is more systematic than just beta features, so while my comments may be completely ignored because I'm an anonymous user and most beta features don't really work for "us" aside from the a/b tests, these comments might still offer a less biased perspective.

Some issues:

• Search - First architecturally speaking, a severe flow flaw is the fact that it isn't indexed in site search. This should really have been part of the MVP even if it required some hacks. For beta features it is important for people not to repeat the same feedback, and read related comments before submitting theirs. Funny that wikimedia itself has a similar feature request for phabricator developers (T883), highlighting its importance.
• Violates basic principles of usability design (https://www.nngroup.com/articles/ten-usability-heuristics/)
  • Recognition rather than recall - the interface shouldn't ask for things it can get automatically. When someone reports an issue, the browser has access to the wiki, mediawiki version, the user agent, the user scripts installed, default gadgets, and more. Yet none of this is automatically added in structured fields.
  • Error prevention - prevents errors by not requiring users to submit information that the wiki / browser already knows about
• Grouping - Lacks ways to manually group similar or near identical discussions, without leaving the interface (e.g category) .
• Ability to filter resolved discussions (with wikitext these can easily be collapsed).

Wikitext talk pages have even more severe flaws, yet their flexibility means that one can easily make use of headers to discuss similar topics, merge them, or even split them and move them elsewhere. It is very useful when discussing a problem to see different perspectives. Aside from user agent and ip, many user scripts aren't even private due to being added to common.js rather than being gadgets.

Finally, compare this to Wikia, who for example, is very consistent (community managers religiously ask people to submit bug reports to special:contact), and as an anonymous user I can submit feedback about any feature to them by using Special:Contact after testing the beta features activated in their testwiki. This is sent along with the browser and other info (added by a issue specific user-filled form) to wikia staff, who may eventually reply. According to them, registered users can even see progress of their report in a private issue tracker.

Wikimedia is very inconsistent about how it handles feedback, the contact interface in english wikipedia is different from ptwiki and probably many others. One way to improve this may be to improve the feedback interface, deploy the Extension:Contact and Extension:EnhanceContactForm to all wikis, and add a checkbox to submit potentially private information to either phabricator (for bugs) or flow (for other random feedback).

That being said, flow is by far more user friendly to newbies than wikitext-based talk pages (aside from the crippling lack of search functionality) that use even more arbitrary rules for indenting and posting.