Last modified: 2014-08-23 12:27:36 UTC
Gadgets being turned on for all site users (including readers) can cause a confusing users experience, especially when there is some disagreement and defaults change without notice (readers are rarely if ever part of these discussions) Move to model where gadgets are per user rather than part of a default experience for users
Community consensus for this is where?
Sorry, your request doesn't make any sense technically. Even without the gadgets extension, sysops would be able to edit MediaWiki:Common.js and the like (which don't even allow opt-out). If you want to request those to be disabled too, please open a new report with clearer scope.
Please make improvements to this bug rather than closing it and requesting a new one, thanks! The scope of this would be need to be larger please update as needed based on your technical knowledge of the matter.
Back to UNCONFIRMED and community-consensus-needed, even though I think that trying to extending the scope of this bug (how? by not allowing people to add gadgets to MediaWiki:Common.js?) is, well, senseless.
Gadgets are generally turned on by default for new users precisely BECAUSE of community consensus to do so. These tools are created as gadgets so that users can turn them off if needed, and turned on by default because it is agreed that most folks will indeed have a use for them - something about discoverability. Removing the ability to turn them on by default would either hide useful and often relevant tools from a majority of their intended audience, or instead force the functionality on everyone including those who are not part of said audience, because the alternative is to put the tool directly in the site css/js. And please do not suggest removing the site css/js unless you want a revolt. Now revolts can be fun, but...
(In reply to comment #3) > Please make improvements to this bug rather than closing it and requesting a > new one, thanks! If only I knew what you mean here... Sorry, I'm out. This bug is totally useless, you've been warned.
This feature was actually added because communities wanted it AFAIK. Have you considered these crazy ideas anywhere other than the design teams? perhaps a few mailing list posts are in order before you submit any more.
with all due respect, I completely agree with Isarra, Nemo and Tomasz on this one. Gadgets are enabled by default via community consensus and usually tend to improve the experience. If there are any particular problems with specific gadgets, then i suggest they be considered on case-by-case basis on how to improve / fix those gadgets. (not disable those)
An example of gadget enabled by default for every logged-in user on Wikimedia Commons is a script to offer a move feature. Commons don't allow any user to rename a picture, this is restricted to sysops and user with image move rights. Furthermore, there are precise criteria. Renames outside these criteria are denied. A gadget exists, which offer a popup allowing an user to request a move, and select the relevant criteria (and learn them): https://commons.wikimedia.org/wiki/File:RenameRequest,_Gadget-RenameLink_-_2012-03-13,_en.png * * * Another example of gadget enabled by default for every user, including anonymous is the credit capabilities: https://guillaumepaumier.com/2010/10/04/reuse-buttons-wikimedia-commons/ https://commons.wikimedia.org/wiki/Help:Gadget-Stockphoto * * * These gadgets have been developed to improve the user experience, not to confuse users. Furthermore, the changes deployed in a disagreement context and defaults change without notice are generally related to non-gadgets deployments, for example we have been listened to issues and opposition to the Autonym font deployment or the Visual Editor. The non aggressive and consensual new features deployment seems to me something different than restrict gadgets deployment. * * * To the bug requester, could you make a clear case of: (1) how do you offer to handle the deployment of consensual and useful gadgets like the Wikimedia Commons UI improvements and similar stuff on other projects? (2) what elements prove, not on a theory basis, but in a practical way, your proposal is useful to achieve your better usability goal?
You have chosen a solution and designated it as the problem to be fixed. That is always a bad bug report. Your free hints for today: Consistency: Global gadgets with options to configure them for groups of sites (all *.wikipedia.org) Readers/Editors: Separate configuration into those two user groups.
Gadgets appear because people want them. Gadgets become default because people REALLY want them. I would be the first to admit that gadgets, as well as common.css and common.js, make centralized development and deployment hard, because they make every project a little different. But then, you know, centralization is exactly the thing that made Nupedia so successful. Not. Seriously, gadgets are the prime example of community innovation. They show what the community actually needs and what the community can do. Rather than shut down community innovation, designers and developers must look at the default gadgets - in English and in other languages! - as The Number One Best source of ideas for features to productize.* -- * This last word is WMF jargon. I don't like the word, but I really like the concept.
I'm reminded of bug 34522 ("User notification when new gadgets are enabled on an opt-out basis"). (In reply to comment #0) > Gadgets being turned on for all site users (including readers) can cause a > confusing users experience, especially when there is some disagreement and > defaults change without notice (readers are rarely if ever part of these > discussions) A feature can be added in many ways: by modifying MediaWiki core, by adding a MediaWiki extension, by adding a JavaScript gadget, etc. Why are you focused on default-on (or opt-out) JavaScript gadgets specifically? (In reply to comment #8) > with all due respect, I completely agree with Isarra, Nemo and Tomasz on this > one. Gadgets are enabled by default via community consensus and usually tend > to improve the experience. This. (In reply to comment #10) > You have chosen a solution and designated it as the problem to be fixed. That > is always a bad bug report. And this. (In reply to comment #11) > Seriously, gadgets are the prime example of community innovation. They show > what the community actually needs and what the community can do. > > Rather than shut down community innovation, designers and developers must > look at the default gadgets - in English and in other languages! - as The > Number One Best source of ideas for features to productize.* > > -- > * This last word is WMF jargon. I don't like the word, but I really like the > concept. And, emphatically, this. Tentatively recommend resolved/wontfix here, though perhaps with refinement this bug is salvageable. At the moment, I see no path forward.
Great feedback, Let me see if I can summarize some of it: Gadgets are seen as a way for community members to propose changes to the site at a different time scale than the roadmap process or even agile feature development works. Separating default gadgets or the ability to turn on gadgets for readers vs editors would be something to research further. Decentralizing development efforts is something that has worked well and should be maintained. A better process for creating, installing, and integrating (making default, turing into an extension, or making ON by default) gadgets would be welcome. *one point of clarification, I was not implying gadgets are turned on in order to confuse people, simply that an inconsistent or constantly changing (without proper messaging) interface is confusing to people.
I'm being bold over here, and making this WONTFIX. This isn't something we could realistically do right now: People will then copy gadgets into Common.js which is even worse. If you'd also disable this, the communities will go crazy (seriously, a lot of things depend on these default scripting things). If you want to reopen this, please take the problem as serious as it is (Gadgets are a problem... there's hardly anyone knowing that better than me), but killing them isn't realistic unless we at least have a facility for global gadgets. By the time that's the case I'll really hope we can kill the local code mess fast (and I'll help with that). By the way: The security problems which gadgets often open up are much worse than any of the interface problems brought up here and this is known for years, but still nobody seriously considered doing this.
(In reply to comment #14) > If you want to reopen this, please take the problem as serious as it is > (Gadgets are a problem... there's hardly anyone knowing that better than me), > but killing them isn't realistic unless we at least have a facility for > global gadgets. By the time that's the case I'll really hope we can kill the > local code mess fast (and I'll help with that). The relevant bug for global gadgets is bug 20153.
(In reply to comment #10) > You have chosen a solution and designated it as the problem to be fixed. That > is always a bad bug report. > > Your free hints for today: > > Consistency: Global gadgets with options to configure them for groups of > sites > (all *.wikipedia.org) > > Readers/Editors: Separate configuration into those two user groups. Aka Salvatore's work on Gadgets extension: https://www.mediawiki.org/wiki/Roadmap/2012/April#MediaWiki_infrastructure https://www.mediawiki.org/wiki/User:Salvatore_Ingala/Notes (In reply to comment #13) > Separating default gadgets or the ability to turn on gadgets for readers vs > editors would be something to research further. See bug 29301 (or more generally, bug 20151) and its workaround at https://en.wiktionary.org/wiki/Wiktionary:Per-browser_preferences (In reply to comment #14) > but killing them isn't realistic unless we at least have a facility for > global > gadgets. By the time that's the case I'll really hope we can kill the local > code mess fast (and I'll help with that). +1 and [[mw:Gadgets 2.0]] is really taking too long to be implemented.
(In reply to comment #14) > I'm being bold over here, and making this WONTFIX. > > This isn't something we could realistically do right now: People will then > copy > gadgets into Common.js which is even worse. If you'd also disable this, the > communities will go crazy (seriously, a lot of things depend on these default > scripting things). > > If you want to reopen this, please take the problem as serious as it is > (Gadgets are a problem... there's hardly anyone knowing that better than me), > but killing them isn't realistic unless we at least have a facility for > global > gadgets. By the time that's the case I'll really hope we can kill the local > code mess fast (and I'll help with that). > > By the way: The security problems which gadgets often open up are much worse > than any of the interface problems brought up here and this is known for > years, > but still nobody seriously considered doing this. Well done Hoo. This discussion should never have started on bugzilla, that is completely the wrong place for a policy debate. @Jared. Bugzilla should be considered a technical place. Communities are expected to reach a community consensus (onwiki) before lodging a bugzilla, and WMF staff *should* be doing the same. Bringing it here basically hides it for the community members who would consider this a social discussion, not a technical issue. Many communities do have these discussions about turning on gadgets as default. So the standard should be set that it is the expectation that gadgets are discussed by the communities, and that a consensus is reached prior to implementation. Communities can manage that.
