Talk:Requests for comment/Redesign user preferences

Sections
We can come up with sections than figure out what to put in them but I would recommend that we do the opposite, use a card sorting method to have user organize the settings that we want to keep into groupings then name those groupings in logical ways. With a search mechanism that filters across all sections this become further irrelevant but still makes for a good entry point for preference browsing. I speak from experience of reorganizing the 100's of preferences that existed in AutoCAD due to 25 years of legacy buildup. One tool to use is Optimal Sort if someone can fine a free tool it would be ideal but if not we can pay for this one or something similar. Jaredzimmerman (WMF) (talk) 20:28, 7 April 2014 (UTC)
 * Search mechanism? Interesting idea... :) I would guess that's more of a long-term enhancement, rather than something we could achieve before Northern Autumn, though?
 * Re: Card sorting - This one is currently free http://conceptcodify.com/ - I've looked at the examples for OptimalSort and ConceptCodify, and they're certainly intriguing. Would you suggest that this method is more helpful if we were to drastically change the section-names (versus retaining most of them as-is, and simply merging some tabs into other tabs)? I'm definitely interested as to what "outside the box" orderings we could come up with; but I'm also keeping in mind that the less we change, the less problems we'll have with longterm editors getting lost and documentation to update. There would have to be an overwhelming benefit, to commit to a complete overhaul.
 * For reference: Enwiki has 12 tabs, split into ~30 subsections, each with 1-15 elements. I've listed the standard (En/MW) subsections in in this diff as a raw list, and also in this public trello board (sadly not a great card-sorting tool). If anyone plays around with the data in those or other tools, let us know! –Quiddity (talk) 04:01, 8 April 2014 (UTC)
 * Quiddity, by search i really just mean simple on-page filtering, similar to what you see in chrome browser at chrome://settings/ https://www.dropbox.com/s/pckp67nvkteyka4/Screenshot%202014-04-14%2016.27.05.png


 * as far as should we completely redefine how things are organize vs an iterative step? lets rip the bandaid off, and organize things how they should be organized, if we have basic filtering and well written alt text on things, findability won't be a problem, and new users, and infrequent preference users will be helped by items being in logical places. Jaredzimmerman (WMF) (talk) 23:29, 14 April 2014 (UTC)
 * Re: Search, yes, that's what I guessed you meant (but that's a great example, thanks :). Also, see en:SMOP! ;) (Though possibly that is indeed "simple" to code? idk.)
 * Re: reorganizing entirely: My main hesitation is that I can't think of a vastly different ontology that makes any sense! I grok that this is why Card Sorting requires numerous participants, but still... How much divergence from the current state and proposals can you envisage for the standard MediaWiki & Wikimedia preferences? (ie. I need a strong motivator, in order to spend hours of time setting up a card-sorting process. If you or someone else comes up with some outside-the-box ideas, then fine and good! but otherwise we're probably going to just fix and iterate upon the existing logical organization.). –Quiddity (talk) 00:26, 15 April 2014 (UTC)

Collapsing
"will be collapsed using JavaScript". No. --Nemo 20:45, 14 April 2014 (UTC)
 * Nemo, We don't design FOR no JS as a default user experience, but we should make sure that things degrade gracefully in no JS situations. I think that User:MZMcBride is correct in suggesting that more advanced features be hidden by default. Jaredzimmerman (WMF) (talk) 21:04, 14 April 2014 (UTC)
 * Collapsing only means hiding the dust under the carpet. It's never a solution to clutter and we clearly have a problem with clutter. --Nemo 21:19, 14 April 2014 (UTC)
 * Nemo I respectfully disagree, I think we should do both, we should take a hard look at what should be cut, and then of what should remain, we'll take the data being looked at by the analytics team about preference usage, and use that to inform what is "above and below the fold" for users, based on thresholds of frequency of use by user, and some cohort analysis by users types. Jaredzimmerman (WMF) (talk) 23:25, 14 April 2014 (UTC)
 * and Nemo: To begin: I'm generally opposed/reluctant/cautious about hiding content (in articles). It massively reduces the likelihood that the content will ever be seen, either by readers, or by editors (meaning mistakes and vandalism can go un-noticed). However, this interface has some different permutations.
 * Re: this thread: I think you're both discussing different things. Nemo is referring to MZ's Mockup section, which is about the overall visual design (and the way the Mockup is shown, would have all-but-one section "collapsed". Very similar to the Mobile interface for articles.).   Whereas Jared is referring (in his 2nd comment at least) to the idea that certain advanced options might be "hidden" somehow, either via a "show advanced options" button, or via re-organizing the options within each section (eg. above/below the fold).
 * I think there are other solutions though, such as simply Highlighting the basic options and Muting the advanced-options, or having 2 columns (basic on left, advanced on right), or other?
 * I'm generally a fan of options, particularly advanced-options for advanced-users. Firefox does this Right™ with their "about:config" page. Ubuntu and Windows angered a LOT of their powerusers, in recent years, by trying to remove the "underutilized" advanced-options. Hiding them (whether by moving them to subpages, or CSS/JS visibility-toggling), or Rearranging/Restyling them (to be less overwhelming for newcomers), is vastly preferable to Removing them. –Quiddity (talk) 00:04, 15 April 2014 (UTC)

"Redesign"?
I don't see anything about redesigning here, just cosmetic changes (which are important but not a redesign). Apart from the removal of useless preferences, the actual redesign is IMHO where to present preferences and switches. See 31882. --Nemo 20:48, 14 April 2014 (UTC)
 * It's kind of encompassing all aspects of "update the damn preferences!"
 * 1) Triage the bugs and wikis and memories for: Preferences-to-add and Preferences-to-remove. (to define/understand the scope, and allow for growth)
 * 2) Research how to organize the hundreds of preferences into a few sections. (either keep-but-update the current, or brainstorm an overhaul)
 * 3) Redesign the interface, to show those hundreds of preferences in the most efficient and usable way possible.
 * 4) Profit!
 * :) –Quiddity (talk) 00:10, 15 April 2014 (UTC)