Last modified: 2014-09-24 01:06:58 UTC
Rather than having to click save every time a preference is changed, it would be nice if changes would save automatically.
Does anybody know the estimate effort of this task? Would it be simple for a newcomer to dive into it? Is there anybody willing to mentor a potential junior taker? Is it something that a senior developer would fix in a couple of hours, aka a potential Google Code-in task or a "Bug of the week"?
(In reply to Dan Garry from comment #0) > Rather than having to click save every time a preference is changed, it > would be nice if changes would save automatically. I'm not sure the first part of your comment is accurate. When a user visits Special:Preferences and modifies his or her preferences in different tabs of the user interface, he or she only needs to press the save button once, as I understand it. If this is not the case currently, that sounds like a major user interface behavior regression that needs to be fixed. For this bug report, it sounds like you want per-input auto-save at Special:Preferences in MediaWiki core? What do you envision being the visual cue (if any) to users that their preferences have been auto-saved? And is there solid evidence that users expect this type of behavior and/or wouldn't be annoyed or startled by the introduction of it? (In reply to Quim Gil from comment #1) > Does anybody know the estimate effort of this task? Would it be simple for a > newcomer to dive into it? Is there anybody willing to mentor a potential > junior taker? At present, the requirements aren't clear enough. It's mostly about figuring out the right way to do this (i.e., without annoying or startling users). The actual technical piece, once we figure out what we want, shouldn't be too difficult. Probably borderline easy task.
The visual cue would be the toaster style notification mentioned in in https://bugzilla.wikimedia.org/show_bug.cgi?id=65984 they are small, non-obtrusive, and do not require the user to scroll up to the top of the page to confirm that changes have been saved. perhaps someone from the mobile team can chime in on this bug and the linked bug as the the correct name of the "toaster" message component.
(In reply to Quim Gil from comment #1) > Does anybody know the estimate effort of this task? Would it be simple for a > newcomer to dive into it? Is there anybody willing to mentor a potential > junior taker? There's a couple ways to do it. The API way is discussed below (saves items one at a time and uses the actual API without wasting bandwidth). It could also be done by posting the entire preferences form every time you change anything. This is kind of wrong in that it's a waste of bandwidth and doesn't use the API, but it would probably be faster to develop, since the server doesn't know the difference, and the form can be serialized with $.serialize. ---- There is an API for saving preferences already (https://www.mediawiki.org/wiki/API:Options). That means the main issues are: 1. Figuring out what changed. 2. Figuring out to map the form elements to the name and value. For text and regular select inputs this is trivial (drop the wp prefix from the name and call .val()). E.g.: editfont: $( '#mw-input-wpeditfont' ).val() Checkboxes and radio buttons are a little more complicated, but not unduly (checkboxes need to be saved even if unchecked, radio buttons have multiple elements with the same name, so straight ID check doesn't work). There are some edge cases that might be more complicated, like HTMLCheckMatrix. Everything is componentized (see includes/htmlform), and you can see on the client-side which component is being used from the class name (e.g. mw-htmlform-field-HTMLCheckMatrix). It's neither trivial nor impossibly complicated. Maybe 2-3 weeks for a quick newcomer with prompt code review; more if they're working on it less frequently.
(In reply to Matthew Flaschen from comment #4) > It could also be done by posting the entire preferences form every time you > change anything. Note, I mean posting with AJAX.
would submitting the whole form give us bad data in our preference logging schema? e.g. would we be submitting that a user had "changed" a value from 5 to 5 for things they hadn't actually changed? we plan on using the preferences logging data to make informed decision about how user are using pref and what is important to keep, deprecated, and highlight in prefs. I want to make sure this method won't impact that. Second, as we move toward service oriented architecture doing things "the right way" via the API would be a move towards that goal.
(In reply to Jared Zimmerman (WMF) from comment #6) > would submitting the whole form give us bad data in our preference logging > schema? e.g. would we be submitting that a user had "changed" a value from 5 > to 5 for things they hadn't actually changed? It shouldn't, since it explicitly checks that the value changed before logging it: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikimediaEvents.git/14b37f317101a4ffaeb2917963fe63cb549a2159/WikimediaEventsHooks.php#L144
