Page MenuHomePhabricator

Implement new design for preferences submenus
Closed, ResolvedPublic

Description

In addition to updating the design of the main menu selector of Preferences we also want to update the submenus.

User Story

As a mobile-first Wikimedia contributor, I want to change my account preferences from my mobile device, so that I can customise my editing experience.

Design specs

Full image (PDF) detailing changes and specifications https://commons.wikimedia.org/wiki/File:Desing-specs-mobile-web-preferences.pdf. Note that some changes in this document are beyond the scope of this task, particularly specific-setting modals and the on/off toggle.

Section titles get a border bottom for stronger separation

In order to enable editors to easily scan the content of a page a solid black border will signify the beginning of each settings section.

Screen Shot 2022-06-24 at 11.31.19.png (214×1 px, 37 KB)

Tech Note

  • Ideally, we want to use CSS/JS to target the sections needing a border bottom etc. We should be careful to use selectors that are limited in scope to the mobile experience (mobile.js) and (resources/src/mediawiki.special.preferences.styles.ooui.less).
  • Since the actual factory used to create the default layout lives deep in core and is used by desktop, we want as much as possible to limit our change to CSS/JS.
Labels loose the colon “:” at the end

The colon is needed as a separator when the content is displayed on the same line. In this instance, we're going to rely on the line break to create a clear distinction between the label and the call to action (or text) below.

Screen Shot 2022-06-24 at 11.32.50.png (132×1 px, 24 KB)

Tech Note

  • The colon (:) lives in the translation files so this seems more of a content change (translation) rather than a programatic one.
  • We also need to identify if there are any guidelines surrounding the use of the colon ( : ) as a need rather than a want.
  • We could programmatically remove the colon ( : ) using a regular expression replace on all labels.
Buttons become links: T324586
Links stay as links

As above.

Screen Shot 2022-06-24 at 11.36.56.png (216×1 px, 31 KB)

Tech Note

  • Logic used to change buttons to links should not impact already existing links. They should stay the same, which is essentially a NOOP in this case.
Information (non-interactive) texts are set to grey

For content and is non-interactive, and only informational, we can de-prioritize it by setting the text color to grey.

Screen Shot 2022-06-24 at 11.33.28.png (150×1 px, 29 KB)

This should be done for the following information:

  • Username
  • Registration time
  • Email confirmation (when confirmed)

Tech Note

  • At first glance this looks like a change that can be applied and limited in CSS scope to the labels mentioned above. Ideally we would add some logic to our mobile.js file where all the other mobile magic is happening.
Options are separated by a grey line

To emphasize the distinction between an option and another we will add a grey separator line. These separators, together with the section separators, will give a stronger structure to the content of the page, hence improving the scan-ability of the content.

Screen Shot 2022-06-24 at 11.42.03.png (360×1 px, 76 KB)

Sections are more distant from each other

To improve the scan-ability, and to enable editors to quickly scroll the page, and find the section that they need, we will increase the space between each main section.

Screen Shot 2022-06-24 at 11.42.50.png (272×1 px, 56 KB)

Tech Note

  • At first glance this looks like a change that can be applied and limited in CSS/JS scope to the sections mentioned above. Ideally we would add some logic to our mobile.js file and corresponding CSS file.
  • We can add padding and a border-bottom of 1px to the appropriate section using CSS/JS.

Technical information

TBD

Testing and QA steps

  • Log in to a Wikipedia account
  • Navigate to the sidebar and select Settings
  • Turn on Advanced mode
  • Click 'Open preferences' in Settings
  • Select each menu item and check that the designs above have been met for each
  • Please also verify that the desktop (non-mobile) experience remains unchanged.

Acceptance Criteria

  • All design elements above have been met in every preferences section used in production MediaWiki
  • The functionality of Preferences on mobile and desktop have not changed

Event Timeline

Samwalton9-WMF set the point value for this task to 3.
Samwalton9-WMF removed a project: Epic.

Note that the colons on the input labels are translated text, so the messages will need to be updated to make that change. Translations will then need to be updated for the colons to disappear across locales. This change would impact desktop and mobile, so that should be considered.

I did a quick spot check of other forms on enwiki and found a seemingly arbitrary mix of colons and no colons:

forms with colons:

forms without colons:

Additionally, not all production preferences sections use colons, eg:

The use of colons seems like it should be a choice at the skin level. If you want to remove them only in Minerva, you could make use of https://gerrit.wikimedia.org/g/mediawiki/core/+/19a36b9ae2c931cead9a116dc398d49a08fb1a9f/resources/src/mediawiki.interface.helpers.styles.less (make the colons additions via pseudo CSS selectors)

The use of colons seems like it should be a choice at the skin level. If you want to remove them only in Minerva, you could make use of https://gerrit.wikimedia.org/g/mediawiki/core/+/19a36b9ae2c931cead9a116dc398d49a08fb1a9f/resources/src/mediawiki.interface.helpers.styles.less (make the colons additions via pseudo CSS selectors)

That seems reasonable. It really seems like they don't belong in translated labels since they act as a visual separator. We could strip them out of the messages and then add them back into vector via css psuedoselectors; although that would add colon separators to some labels that don't currently have them. We could just drop them and leave them out everywhere.

The inconsistency muddles things. I don't understand the logic behind their presence in some places but not others. @bmartinezcalvo: could you offer some design systems guidance on separators for form labels? I just plucked your handle off of the design systems page, so if you're not the right person to ask, could you point me in the right direction?

eigyan updated the task description. (Show Details)
eigyan added a subscriber: ERayfield.

@eigyan thanks for putting that update in the description; @Samwalton9 I have the same question about Buttons become links as Labels loose the colon “:” at the end: if the current state of the art is a problem, shouldn't we fix it across the board instead of hacking at it in minerva? The change would be cleaner and require less maintenance.

@eigyan thanks for putting that update in the description; @Samwalton9 I have the same question about Buttons become links as Labels loose the colon “:” at the end: if the current state of the art is a problem, shouldn't we fix it across the board instead of hacking at it in minerva? The change would be cleaner and require less maintenance.

I can see the argument for this for buttons - on desktop there seems to be no consistent reason for a link to be a button vs a link, so making them all links sounds fine. Colons, on the other hand, are primarily a new-mobile-design problem. I'm less sure that it would work on desktop, e.g. at small viewports:

Screenshot 2022-12-06 at 15.03.36.png (1×904 px, 204 KB)

In the new design we're separating header from information/links with a newline, which I think fills the function the colon currently serves in desktop.

Colons, on the other hand, are primarily a new-mobile-design problem. I'm less sure that it would work on desktop, e.g. at small viewports:

As @Jdlrobson mentioned, I think it would be useful to think of this as a skin-level thing instead of a mobile/desktop thing. I don't think visual separators should be in the translated messages. I think the right way to handle a change would be to remove them from the messages, and then add them back into the "desktop" skins via css.

Colons, on the other hand, are primarily a new-mobile-design problem. I'm less sure that it would work on desktop, e.g. at small viewports:

As @Jdlrobson mentioned, I think it would be useful to think of this as a skin-level thing instead of a mobile/desktop thing. I don't think visual separators should be in the translated messages. I think the right way to handle a change would be to remove them from the messages, and then add them back into the "desktop" skins via css.

That makes sense to me. It's also, honestly, one of the least impactful changes in this list, so I'm not losing sleep over whether we do it or not.

In RTL today we discussed how some of the changes listed here are improvements to Preferences on any device, so I'm going to split this out into some sub-tickets for those elements.

Moving this off the kanban for now to prioritise completion of the subtasks.

Although we've decided to deprioritise some of this work - we were able to get some major elements completed in T324227. In particular, "Section titles get a border bottom for stronger separation", "Information (non-interactive) texts are set to grey", "Options are separated by a grey line", and "Sections are more distant from each other".

patchdemo.wmflabs.org_wikis_8f0898c995_wiki_Special_Preferences(Samsung Galaxy S8+).png (2×1 px, 303 KB)

Samwalton9-WMF claimed this task.

We did everything we wanted to get done here.