Talk:Beta Features

Previous discussion was archived at Talk:Beta Features/Archive on 2015-11-04.

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.

I'm not able to deactivate any beta feature if "Automatically enable all new beta features" is activated.

If I try to deactivate a feature, that setting is not saved.

Correct. Disable it, if you don't want to have (almost) all beta features enabled for you.

Hello, I think that here should be listed Reply tool. It is available at almost Wikipedias (example). Also New discussion tool will be soon available at few Wikipedias (phab). Thanks.

Tracked in Phabricator
Task T165162

New wikitext editor lacks visual edition of redirects.

Can you clarify? Do you mean that the "Options → Page settings" dialog is unavailable? This is reported as T165162.

(Jeśli wolisz, możemy rozmawiać po polsku – czy chodzi Ci o to, że dialog „Opcje → Ustawienia strony” jest niedostępny? Ten problem mamy zgłoszony jako T165162.)

Will look into this and create a task on Phab if applicable. Anyways thanks for the help.

Since the Beta Features extensions also registers features from extensions that are not installed for that wiki it will be good to list also the respective feature strings here, e.g. tmh-videojs for the new video player to be used with the $wgBetaFeaturesWhitelist. This would allow to easily identify and exclude these unavailable features.

I don't think that's a good idea. The list lives in config as wgBetaFeaturesWhitelist and no-one will ever remember to update an orphaned list documenting things here when there's no process reason to do that.

Fair enough though will be more difficult to find these flags.

(Also, what you wrote is wrong; the Beta Feature extension doesn't know anything about an individual features, it's those extensions which are installed on the wiki which register themselves as Beta Features.)

A wiki I control offers Popups, HoverCards or what it is called in the preferences. Trust me that neither the extensions TextExtracts, PageImages or Popups are installed or invoked for the this particular wiki. So I wonder where this comes from. Must be a bug from core in this case.

Ah, ok. I got confused. Sorry. It is shown in the "Appearance" tab and not in the "Beta Features" tab. So this is a MediaWiki core issue offering features that are not installed.

Known-to-code-search beta feature registrations: https://codesearch.wmflabs.org/search/?q=GetBetaFeaturePreferences&i=nope&files=extension%5C.json&repos=. As you can see, MW itself doesn't register against the hook (and any attempt to do so would be reverted, as it mixes concerns the wrong way around).

Do you mean "Reference Previews"? That's provided by the Popups extension, yes, and if you can tell me the bug I'll be glad to fix it. :-)

As noted in the post you reply to this is no longer about Beta Features. Sorry for the noise.

The preference section allows users to select: Reading preferences - Page previews (get quick previews of a topic while reading a page). No idea what this could be. / Just checked for the system message keys which start with "popups-prefs-..." which I assume refers to functionality provided by the Popups extension. This one is however neither invoked nor installed. It is a core bug in this case. I will create a task for it on phabricator.

Is it possible to add an undo feature in Minerva skin? An editor created this meta:User:FR30799386/undo.js script which adds an undo button while previewing a diff on mobile. I've asked on Village Pump (technical) in English Wikipedia to make it a gadget. Is it possible to make it a part of Mediawiki since the Minerva skin lacks an undo feature?

Note that gadgets aren't loaded on mobile, so you're right, you'd need to do it as a feature. Beta Features is desktop-only, however.

Well StructuredDiscussion is a beta feature but it works on Minerva skin. Also how to add this script to Mediawiki to make it work globally? It is compatible with any wiki which can run using Minerva skin.

No, StructuredDiscussions is a regular feature; opting into it for your talk page is a Beta Feature, mostly for ease of user interface.

If you want to add a new feature to Minerva, you should post a Phabricator task suggesting it and explaining why users will get value from it.

I see. Thanks. I will wait until it becomes a gadget on en-wiki.