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)
 * Quiddity, its easy, we don't need to think of a better way, "we are not our users" (I know you are an active editor and user of the software, but i think this still holds true) I can come up with a grouping, and I'm sure it will be fine, so can you. But only with the aggregate views of many many users do i think that we will get an organization that resonates with the largest number of users. Obviously we have to make tradeoffs, when to we trust our intuition, when do we use data. In this case lets do both, let's get the info from Analytics to show what properties users use, and then with that in mind make an initial cut of things that should be removed, and things that should be prioritized and then balance that will how users, both familiar with the current system and those who are not to organize their ideal.


 * Concept Codify looks interesting, once we have usage numbers from Analytics lets work together to run some test with it, could be a useful datapoint. Jaredzimmerman (WMF) (talk) 01:43, 15 April 2014 (UTC)


 * JZ: I tried to get the Wikimedia Foundation design team involved in redesigning Special:Preferences, but nobody seemed interested. :-)
 * I've proposed a series of simple steps to iteratively and incrementally improve the user preferences interface. If the design team would like to work on the layout specifically (63583), that would be wonderful. If the design team would like to make concrete proposals for moving preferences to different sections or if the design team would like to make concrete proposals for adding, removing, or renaming preferences sections, that would also be wonderful.
 * As it is, I understand your philosophy (or process) for re-sorting user preferences and I'm not sure I disagree with the approach you're proposing here, it simply isn't the approach I've decided to take. --MZMcBride (talk) 03:01, 15 April 2014 (UTC)
 * MZMcBride, and thats fine, I just ask that you take the work from the analytics team into account when its available about usage data for individual preferences to inform, the order, and basic/advanced groupings.


 * when I look at your mockups, a few things come to mind, such as are all these items really necessary? should they have the same visual weight? how can they be further organized within their groupings. How can we provide access to help and actions from some of the non-actionable items. e.g. for Username, should we provide access to the help page on how to change your username? why write the account creation data that way, rather than a more readable, and widely accepted format? Should user ID have the same level of visibility and information hierarchy as user name (probably not…)? Should username and password be more closely associated and connected apps be sub-sectioned off a bit. This is the kind of thinking that I'm asking for. We're both on the same page about goals I think, so I'm not particularly worried about the end result, and I'm happy your working on this. Jaredzimmerman (WMF) (talk) 00:18, 16 April 2014 (UTC)


 * JZ: Yeah, I think we're pretty much agreed. We should let any reasonable analytics inform our decisions, sure.
 * Currently in this RFC, most of the content remains unchanged. This RFC is about laying a framework for how changes should be implemented: using focused discussion about concrete proposals, which can individually be killed or accepted.
 * I think the entire user profile section should be redone or possibly moved to a separate place altogether (a preferences page is an odd place for a user dashboard). I've filed 63987 and 63988 with concrete-ish ideas. :-) --MZMcBride (talk) 03:44, 16 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)
 * Quiddity, thank you for translating, yes, thats exactly what I'm referring to, if you look at Chrome's preferences it shows a very similar pattern to what I'm referring to as one…possible…option.


 * What do you mean by "No."? Let's be clear here: the longstanding currently in-use Special:Preferences interface uses JavaScript to collapse every section into tabs. Again, the current user interface of Special:Preferences uses JavaScript to collapse the sections.
 * At stake in 63583 (changing the layout of Special:Preferences) is whether we take the currently horizontal tabs:
 * [User profile] [Editing] [Search]
 * and instead turn them vertical (and possibly add icons):
 * [User profile]
 * [Editing]
 * [Search]
 * In the current layout or in the new layout, we're still collapsing all sections except the initial tab (User profile).
 * I don't understand what you mean by "No." What do you think about the current implementation of Special:Preferences? What do you propose as a layout for Special:Preferences? --MZMcBride (talk) 02:51, 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)


 * This section is about the current title of the RFC ("Redesign user preferences")? If so, please suggest a better title or be bold and move the page. I think "redesign" is fine because we're dealing with the design of "Special:Preferences" both aesthetic and non-aesthetic, but the page title of this design document is pretty trivial. --MZMcBride (talk) 02:43, 15 April 2014 (UTC)

Miscellaneous cheerleading
It's really, really heartening to see long-neglected parts of the core application getting this kind of attention. Thank you. —  Scott  •  talk  21:17, 8 June 2014 (UTC)