| • MZMcBride | |
| Apr 5 2014, 7:39 PM |
| F34528763: image.png | |
| Jun 27 2021, 11:06 AM |
Rather than having tabs at mw:Special:Preferences, we should switch to collapsible, stacked sections. Each section will have an associated icon and the first section will be auto-expanded on page load.
Mockup:
URL: https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences#Mock
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T64559 Redesign Special:Preferences (tracking) | |||
| Declined | None | T65583 Change MediaWiki core user preferences layout |
[[mw:Requests for comment/Redesign user preferences#Mock]] will one day have a mock-up of what this should look like.
Expanding this bug report's bug summary a bit.
One option is switching from tabs to stacked collapsible sections, but there are other options, which may or may not include icons.
(In reply to MZMcBride from comment #0)
Rather than having tabs at [[mw:Special:Preferences]], we should switch to
collapsible, stacked sections. Each section will have an associated icon and
the first section will be auto-expanded on page load.
Why?
Collapsible stacked sections (accordion-style layout) only make sense for some skins, and just like a tabbed layout, an accordion-style layout has its advantages and disadvantages; I see no reasoning that this would be any better in general. If anything, which particular method is used should be determined by the skin, because that will be the determining factor as to what layout will be most appropriate.
Accordion-style, for instance, would make perfect sense for MobileFrontend and is indeed already widely used for pages in general; tabs make sense for skins like Wikia's which implement consistent vertical tabbed/list navigation, where the respective height on the page indicates the scope; and skins like MonoBook and Vector, which just have navigation all over the place, can't really do anything that will make sense because nothing makes sense already.
Yeah. I'm not sure if this is a good idea in general. The layout should be defined by the skin, and the default one (tabs) is least likely to clash with anything.
This bug used to be the one associated with the "Redesign user preferences" RFC. The scope has slightly changed since then. The task for the RFC is now T64559, of which the layout (this task) is a part.
The way Special:Preferences contents are currently constructed and how many preferences views (tabs) there are, this doesn't seem like an user-experience improvement. Not from providing overview even in a vertical collapsed state as mocked-up – enwiki for example features 10 different preference tabs right now – nor from a performance point of view.
In the meantime we've improved the structure and experience of Special:Preferences in T180538 and there are a number of other actionable improvement requests in T64599 and its subtasks instead.