Page MenuHomePhabricator

Get community feedback on Gadgets 2.0 before migrating
Open, MediumPublic

Description

Before we switch any wikis over to using Gadgets 2.0, we should have some community members test it out and give us feedback. Some specific questions to answer:

  • Is the new GadgetManager intuitive?
  • Are there any critical features that are missing?
  • Notice any bugs or inconsistencies?

Send an email to Wikitech-l mailing list as well.

Event Timeline

kaldari created this task.Feb 2 2016, 9:45 PM
kaldari raised the priority of this task from to Medium.
kaldari updated the task description. (Show Details)
kaldari added a project: Community-Tech.
kaldari added a subscriber: kaldari.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 2 2016, 9:45 PM
kaldari updated the task description. (Show Details)
kaldari set Security to None.
kaldari added a subscriber: Johan.
kaldari updated the task description. (Show Details)Feb 2 2016, 11:52 PM
TTO added a subscriber: TTO.Feb 3 2016, 12:08 AM
TTO added a comment.Feb 3 2016, 8:53 AM

I can tell you already that community members aren't going to be happy about the appearance of pages like http://commtech.wmflabs.org/wiki/Gadget_definition:AdminTool. At the very least, the gadget definition pages need to link to a page where this information is displayed in a more comprehensible format. Ideally, the prettified JSON wouldn't even be shown at all, and something nicer would appear in its place.

TTO added a comment.Feb 3 2016, 10:31 AM

True, but that's in a weird dark corner of Meta which only a few developers need to worry about. On the other hand, gadget definitions are user-facing (at least somehow more user-facing than event logging schemas, or whatever those things are), so they should be less cryptic.

TheDJ added a subscriber: TheDJ.Feb 3 2016, 10:37 AM

Can someone make my User:TheDJ account on that commtech server an admin ?

Can someone make my User:TheDJ account on that commtech server an admin ?

Done.

TheDJ added a comment.Feb 3 2016, 3:08 PM

Comments

  • Did we test the initial conversion step sufficiently ?
  • What is the 'rollback' strategy in case something goes wrong with en.wp deploy ?
  • I think it wouldn't be totally unreasonable to change the json extension to be able to include an extra page header or something that can be configured with a local MediaWiki message. That way we could explain to people what this pages are for (see concern of @TTO). Don't forget that these will be 'findable' with the search engine for instance, so users might encounter them.
  • Did we test what these new JSON pages do to bots and other recent changes checking tools ?
  • Gadgetmanager wise, I don't see many problems.
    • It's all jQuery UI, which we are trying to get rid off.. but it is fairly self contained, so I think that's ok for now, but is there a ticket for that ?
    • There is little documentation provided by the UI, there should probably be a follow up ticket for that as well.
    • There is no 'non JS' fallback for creating a new gadget. Not sure if that is even possible, or makes sense... but perhaps a no script informative message would be a good idea.

@TTO: Under Gadgets 2.0, the Gadget definition pages are not intended to be edited manually. That's what the GadgetManager is for. Have you tried out the GadgetManager interface? Perhaps we could add an edit notice to the gadget definition pages pointing people to the GadgetManager. Do you think that would help?

Did we test the initial conversion step sufficiently ?

Not yet. It has been tested some, but it does need more thorough testing. There is one currently known bug: T119008.

What is the 'rollback' strategy in case something goes wrong with en.wp deploy ?

The interface itself is switchable with a config variable, but the conversion script is only 1 way. Perhaps we should write a reverse conversion script as well.

I think it wouldn't be totally unreasonable to change the json extension to be able to include an extra page header or something that can be configured with a local MediaWiki message. That way we could explain to people what this pages are for (see concern of @TTO). Don't forget that these will be 'findable' with the search engine for instance, so users might encounter them.

Agreed. I had a similar thought above.

Did we test what these new JSON pages do to bots and other recent changes checking tools ?

No. If you can suggest any specific ones to check, that would be great.

It's all jQuery UI, which we are trying to get rid off.. but it is fairly self contained, so I think that's ok for now, but is there a ticket for that ?

No, but I'll make one.

There is little documentation provided by the UI, there should probably be a follow up ticket for that as well.

Good idea. Any specific suggestions would be appreciated.

There is no 'non JS' fallback for creating a new gadget. Not sure if that is even possible, or makes sense... but perhaps a no script informative message would be a good idea.

You can actually still create gadgets completely manually (without JS), it just isn't obvious how to do so. We could create a no-script message explaining it, but I'm wondering if that's really needed or not. Are there really people creating Gadgets (which are mostly JS) that don't use JavaScript themselves?

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptFeb 4 2016, 11:44 AM
TTO added a comment.Feb 5 2016, 1:21 AM

It needs more than an edit notice. It should have a notice on page view, I think. Don't forget that for many users, the edit tab will instead be a "View source" tab on these pages, and users will most likely not bother to click on it.

@TTO: If they don't have permission to edit in the Gadget or Gadget Definition namespaces, they also won't have permission to use the editing interface in the Gadget Manager (the Modify and Create links won't be shown), so directing them to the Gadget Manager won't actually be helpful in that case.

@TTO: I made you an admin at http://commtech.wmflabs.org so you can test further.

TTO added a comment.Feb 9 2016, 1:18 AM

What's the point of the gadget title? It doesn't seem to be used anywhere in the interface. I was expecting it to automatically show up in Preferences, like

  • Title: Description

instead of just

  • Description

It's also not possible to reorder entries in the "Scripts" list in the gadget editor dialog. This is important for Twinkle (which I set up on the test wiki), because Morebits.js and Twinkle.js need to be run before the other modules, but if you get the order wrong when setting it up (as I did), you can only reorder them by manually edit the gadget description JSON.

But yay! Twinkle works.

He7d3r added a subscriber: He7d3r.Feb 10 2016, 12:12 PM

@TTO: Under Gadgets 2.0, the Gadget definition pages are not intended to be edited manually. That's what the GadgetManager is for. Have you tried out the GadgetManager interface? Perhaps we could add an edit notice to the gadget definition pages pointing people to the GadgetManager. Do you think that would help?

Maybe the "edit" or "View source" link of "Gadget definition:Foo" should open Special:GadgetManager in Modify mode, instead of opening
http://commtech.wmflabs.org/w/index.php?title=Gadget_definition:Foo&action=edit

! In T125582#1995519, @kaldari wrote:
No, but I'll make one.

Done: T126446: Migrate GadgetManager from jQuery UI

What's the point of the gadget title? It doesn't seem to be used anywhere in the interface.

It is used at Special:GadgetManager. See:
http://commtech.wmflabs.org/wiki/Special:GadgetManager?uselang=qqx

I was expecting it to automatically show up in Preferences, like

  • Title: Description

instead of just

  • Description

+1 for that. Currently
http://commtech.wmflabs.org/wiki/Special:Preferences?uselang=qqx#mw-prefsection-gadgets
only uses gadget-Foo-desc.

It's also not possible to reorder entries in the "Scripts" list in the gadget editor dialog. This is important for Twinkle (which I set up on the test wiki), because Morebits.js and Twinkle.js need to be run before the other modules, but if you get the order wrong when setting it up (as I did), you can only reorder them by manually edit the gadget description JSON.

Aren't gadget editors supposed to enforce the correct loading order of their scripts by creating separate modules, and using ResourceLoader dependencies or mw.loader.using? See e.g. the "hidden" gadget modules on Commons for example:
https://commons.wikimedia.org/wiki/MediaWiki:Gadgets-definition#modules

@Legoktm: Do you think it would be worth writing a reverse migration script (for moving Gadget files back to MediaWiki namespace) in case something goes wrong with a deployment?

What's the point of the gadget title? It doesn't seem to be used anywhere in the interface. I was expecting it to automatically show up in Preferences, like...

I'm inclined to agree with you about using "Title: Description" instead of "Description" in the preferences interface, however, many gadget descriptions already start with the title, so this would be awkward in practice. Maybe we should just get rid of the Titles and use the Gadget IDs in the Gadget Manager.

It's also not possible to reorder entries in the "Scripts" list in the gadget editor dialog.

This should be enforced using module dependencies, not script order.

He7d3r added a comment.EditedFeb 11 2016, 5:21 PM

Maybe we should just get rid of the Titles and use the Gadget IDs in the Gadget Manager.

@kaldari: Aren't they very limited with regard to which characters are accepted?
(In case it is: Isn't that bad for i18n purposes? It is common to have the gadget names translated from English to the local languages when people create forks)

DannyH added a subscriber: DannyH.Feb 11 2016, 10:15 PM
kaldari updated the task description. (Show Details)Mar 15 2016, 5:33 PM
TTO added a comment.May 26 2016, 9:56 AM

Has Community Tech stopped working on Gadgets 2.0? :( I hope I won't have to wait another five years for the next burst of activity...

@TTO: We're blocked on T132082 (and since Gadgets 2.0 wasn't in the Community Wishlist Survey, it's low priority for us).

It's not clear to me what feedback is still possible, wanted or useful. Is this task now invalid?

kaldari changed the task status from Open to Stalled.Mar 14 2017, 7:46 PM

No, just stalled.

Pppery updated the task description. (Show Details)Feb 3 2019, 4:59 AM
Xover added a subscriber: Xover.May 14 2019, 6:15 PM

No, just stalled.

Is it still stalled? I wonder when Gadgets 2.0 will be implemented.

Whenever anyone volunteers or has capacity to work on it...

@TTO: We're blocked on T132082 (and since Gadgets 2.0 wasn't in the Community Wishlist Survey, it's low priority for us).

That task has been closed as a duplicate of T108653: ResourceLoaderWikiModule should follow redirects for JavaScript/CSS content, which was resolved

DannyS712 changed the task status from Stalled to Open.Mar 1 2020, 7:02 AM
Masumrezarock100 added a comment.EditedMar 1 2020, 7:43 AM

Whenever anyone volunteers or has capacity to work on it...

Well, I see that almost all subtasks of T31272: Implement Gadgets 2.0 has been resolved. Only a few of them left. If this task is not blocked on anything else, then it should not be a problem to get community feedbacks on it. Deploying it on a test wiki and announcing on Tech-News would be the first steps to get community feedback, I suppose. I already see Gadgets namespace on production wikis. I think all it waits is getting feedbacks before fully enabling this new system on production wikis. I might be wrong though. @kaldari could you confirm if it's good to go?

Lens0021 added a subscriber: Lens0021.EditedMar 1 2020, 8:23 AM

Well, I see that almost all subtasks of T31272: Implement Gadgets 2.0 has been resolved.

I think T140323 should be resolved first. The fact $wgGadgetsRepoClass can be set by only one class either MediaWikiGadgetsDefinitionRepo or GadgetDefinitionNamespaceRepo is also problematic. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/389793 is for that, but not reviewed for 2 years.

The main issue at this point is just that no one is working on Gadgets 2.0 and it's not part of any team's goals at the moment. If anyone wanted to pick it up as a volunteer project, that would be welcome. A lot of the heavy lifting has already been done.