Last modified: 2014-02-12 23:35:54 UTC
Arbitrary userjs- preferences (as implemented per bug 40124) should be shown in the GUI, with the possibility of clearing them one-by-one. (They are currently only deleted when doing a full reset of preferences.) Sister bug of bug 43959, which is the same, but for the API itself.
If a user script wants to provide a preferences UI, it should provide its own UI instead of just dumping a bunch of raw text fields on the preferences screen. Unfortunately there is no way to sanely allow a user script to provide a sane preferences display on Special:Preferences, but that's a limitation that will have to be lived with. Or is the point of this to just list the keys, to allow a user to "clean up" their userjs preferences? But how will a user know if "userjs-foo-baz" is safe to delete? Either way, that sounds like something most users won't understand, much less be able to make effective use of. The users who might have use of such a thing can use a user script that does it via the API. I suggest we mark this as WONTFIX.
(In reply to comment #1) > Or is the point of this to just list the keys, to allow a user to "clean up" > their userjs preferences? But how will a user know if "userjs-foo-baz" is > safe > to delete? That's what I was thinking of. Even the ability to clean all "additional" preferences from GUI (while keeping regular ones intact) would be useful – for example for solving issues with those scripts if people manage to somehow corrupt their prefs and the script can't recover. Maybe even as an option on the "Reset preferences" screen? (Slightly off-topic below:) (In reply to comment #1) > If a user script wants to provide a preferences UI, it should provide its own > UI instead of just dumping a bunch of raw text fields on the preferences > screen. Unfortunately there is no way to sanely allow a user script to > provide > a sane preferences display on Special:Preferences, but that's a limitation > that > will have to be lived with. Yes, of course. I was working on a config manager for userscripts/gadgets on pl.wikipedia, that would provide the UI and easier access for reading&writing settings (prior to the security fix that disabled this option). It has to be adjusted to the new API rules slightly, and I've not polished it properly yet, but it still works, and it's translateable, so it could be a good option for other wikis as well. [https://pl.wikipedia.org/wiki/MediaWiki:Gadget-gConfig.js]
I would support the addition of maybe a "Reset All" and "Reset JS Options" button to the preferences form, but listing the individual userjs- option keys is a little too much.
Just to be sure, does the MW API is only usable through JavaScript? If not, maybe the "js" in "userjs" is not very appropriate...
https://gerrit.wikimedia.org/r/48576
We know that our preferences can be very confusing. Adding two more buttons to "do stuff to it" could potentially increase user confusion. I have added Brandon, Munaf and Pau to CC for this issue and as reviewers for the patch set. I will also send a mail to design-l about this issue/patch set with a request for input.
Yeah, I think the userjs is a little oddly named. More to the point, I agree with the concern about not wanting to clutter the preference interface. Since preference panes are linkable (e.g. https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets ) what about having an unlisted pane just for userjs? It would not show up as a tab, so as not to the add further to the vast preferences interface. However, if a user ran into problems (and asked on a help desk), or an engineer was testing, they could visit the pane directly. This pane could have just the "Reset/restore all userjs settings" button, but more likely it would also at least allow deleting userjs prefs one by one.
(In reply to comment #7) > Yeah, I think the userjs is a little oddly named. If you have better ideas, I think this could still be changed with reasonably little fallout. /offtopic
Can we see a screenshot of the proposal?
No, as it's not implemented. Tyler's changeset simply adds two more buttons labeled 'Restore site settings only' and 'Restore custom script settings only' next to the already existing one 'Restore all default settings', and enhances the summary displayed above the buttons. I suppose you can imagine that easily.
+1 to Munaf's request. At this moment, it sounds like this is going to be confusing as hell to users who aren't technical enough to deal with userjs prefs, which is most of MediaWiki's user base. But it's hard to tell without actually seeing a mockup or it live on a Labs instance.
In any case, I agree with Steven and think this is more of a developer-centric feature and thus represents a minority of our user base. If there is a very simple way to separate "super advanced" preferences out from the rest, I'm open to it (wireframes welcome). But I think this will mostly add clutter. I'd agree with Brad about marking this as WONTFIX pending a good design proposal. Perhaps we can just create a bug to redesign preferences altogether, while including this in a cohesive way? I have no problem with exposing developer-friendly features in general, but I think they should be separated.
> (In reply to comment #7) > > Yeah, I think the userjs is a little oddly named. > > If you have better ideas, I think this could still be changed with reasonably > little fallout. Agreed it's offtopic, but unlisted, or unlistedjs, would have been better. The proposed feature is not entirely developer-centric, though it definitely benefits developers. There is a real concern that these userjs preferences will get borked, and users won't have any way to fix things.
They are still cleared by a full reset, but even for a user who's made just a few customizations (signature, watchlist, a couple gadgets) that's pretty unappealing.
(In reply to comment #6) > We know that our preferences can be very confusing. Adding two more buttons > to > "do stuff to it" could potentially increase user confusion. I have added > Brandon, Munaf and Pau to CC for this issue and as reviewers for the patch > set. > I will also send a mail to design-l about this issue/patch set with a request > for input. No rationale provided and no design input received in a month -> closing. Can be reopened when both are provided; patch was already -2'ed.
(In reply to comment #15) > (In reply to comment #6) > > We know that our preferences can be very confusing. Adding two more buttons > > to > > "do stuff to it" could potentially increase user confusion. I have added > > Brandon, Munaf and Pau to CC for this issue and as reviewers for the patch > > set. > > I will also send a mail to design-l about this issue/patch set with a request > > for input. > > No rationale provided and no design input received in a month -> closing. > Can be reopened when both are provided; patch was already -2'ed. Bugs should not be closed as WONTFIX just because they need design input. There may be some issues with the current ideas on how to fix the issue. But that does not preclude a better idea from being proposed to fix the bug.
(In reply to comment #16) > Bugs should not be closed as WONTFIX just because they need design input. That's not the point, the point is that there's no rationale for adding clutter to the UI. > There > may be some issues with the current ideas on how to fix the issue. But that > does not preclude a better idea from being proposed to fix the bug. Not as long as "shown in the GUI" is among the requirements.
Nemo, I provided two rationales immediately above your comment closing the bug. 1. "There is a real concern that these userjs preferences will get borked, and users won't have any way to fix things." ... "They are still cleared by a full reset, but even for a user who's made just a few customizations (signature, watchlist, a couple gadgets) that's pretty unappealing." 2. "it definitely benefits developers." I realize the main focus needs to be users, but this is a feature that could aid developers working on userjs preferences too. I agree we should not clutter the interface, but as I said there are ways around that. Just to restart the conversation: a. A URL going to an advanced screen that is not linked b. A subtle link or button (wrench?) to that advanced screen c. Same as a or b, but going directly to the userjs list. There are other approaches we can take beyond just Yet Another Tab. So this is not ready for implementation, but WONTFIX is not appropriate either.
Taking myself off assignment until there's a better consensus on how to fix this.
