Problem/Motivation

There have been several requests so far to provide customizable settings to adjust the admin interface to several desires/needs.

Proposed resolution

Provide a form with several settings to customize the UI. For example:

  • Font Size - WON'T FIX, see comment #13
  • Table cell padding or general spacing
  • Palette
  • Accent Color
  • Dark mode
  • Accessibility settings
    • Reduce motion
    • Highcontrast mode
    • etc.

So from this options proposed we should decide where they need to be defined and who should be able to change them:

  • Settings defined across the site (per theme / per site)
  • Settings defined per user (like dark mode / accessibility wise)
  • Settings defined per component (like decreasing table padding or thumbnail size on Media library)

Remaining tasks

Decide per setting the following:

  • In which form should it live?
  • Who should be able to change it (editor/content author vs site-builder)
  • Which settings/values
CommentFileSizeAuthor
#5 Screenshot 2019-07-11 at 19.45.11.png49.59 KBrembrandx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ckrina created an issue. See original summary.

ckrina’s picture

Issue summary: View changes
lauriii’s picture

Title: Provice form for customizable settings » Provide form for customizable settings
ckrina’s picture

There could be 3 levels of configuration:
- Building the site (per theme / per site)
- Per user (like font size / accessibility wise)
- Per component (like decreasing table padding or thumbnail size on Media library)

rembrandx’s picture

For the customization of font-size, I made a proof of concept in another issue

The result looks like this:

size switch

Clicking the links saves your preset in localStorage and retrieves it when refreshing the page. The little tabs are a nav-tag with a list and links.
Classes are set on the HTML-tag in order to resize font-size on that tag using percentages.

saschaeggi’s picture

Issue summary: View changes
huzooka’s picture

Project: Claro » Drupal core
Version: 8.x-1.x-dev » 8.9.x-dev
Component: Code » Claro theme
martijn.cuppens’s picture

How will this be implemented exactly? Regenerate a CSS file by doing a find and replace in the CSS files or what's the plan?

AaronMcHale’s picture

How will this be implemented exactly? Regenerate a CSS file by doing a find and replace in the CSS files or what's the plan?

I suppose looking at the core color module as a starting point/precedent, since we already do theme manipulation with that module. Maybe color could become a more generic theme customisation module.

ckrina’s picture

Exactly @AaronMcHale, thanks! The discussion about the color/palette changes is happening here: https://www.drupal.org/project/ideas/issues/3090894.

But to know what is going to be configurable in Claro's settings form each element's option and level of configuration needs to be defined before jumping into technical implementation. Feel free to suggest what you think is the best for each. My bet for the current ones listed in the issue summary would be:

  • Font Size: user (user preference, so user settings)
  • Table cell padding or general spacing: Site builder (general site, so Claro)
  • Palette: Site builder (general site, so Claro)
  • Accent Color: Site builder (general site, so Claro), I'd say it should be the same as Palette
  • Dark mode: not sure if general site (so Claro) or user's preference
  • Accessibility settings (I'd say user preference for all, so user settings)
saschaeggi’s picture

For me the following options should be user based:
* Dark mode
* Accessibility settings (e.g. High contrast mode)

But it would also make sense for better customisation options to provide some settings on both theme level and user level, e.g.:
* Accent Color

So you could set a default accent color for your project but the user would still be able to override it if he likes to.

Btw: As a proof of concept I've already integrated Accent Colors to Claro with this theme: https://www.drupal.org/project/gin

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

andrewmacpherson’s picture

Re: #5

Font-size user-preferences aren't Claro's job (or even Drupal's). Understanding WCAG SC 1.4.4 Resize Text is emphatic that text resizing is the responsibility of the user-agent, not the web-site. Rather, our responsibility is to ensure that Claro plays well with the user-agent's text sizing features. Claro is already doing very well in this regard - see #3087225: [META] Assess Claro's conformance with WCAG Text spacing, Text resize, and Reflow..

I've never seen custom text-resize controls which provided anywhere near the level of flexibility offered by the browser's own controls. Typically they offer a very opinionated and/or limited range of sizes, and often aren't very robust in situations where the user has already applied settings of their own. In the worst examples I've seen, they actually prevented the browser's text-resize controls from having any effect. I don't think it's worth the effort to develop (and maintain) them.

There are some circumstances where a web site may need to implement their own controls, but by and large these aren't relevant for Drupal's default admin theme:

  1. Supporting user-agents which don't provide adequate text-resizing controls. This became irrelevant years ago. All of the browsers supported by Drupal core provide excellent text resizing capabilities.
  2. Content using technologies like Flash, Silverlight, Java applets, or such. Not relevant for Drupal's admin UI.
  3. Scenarios where access to the browser UI and/or preferences has been restricted. This is commonly the case for public kiosks. Not relevant here, because Drupal's admin theme isn't likely to be used in scenarios like this.
  4. Supporting users who may not be aware of the browser's built-in text resizing capabilities. There's some merit to this one, but I don't think it's a major use case for Drupal's admin UI:
    • Users who need larger text will need it on all websites and native applications. If we assume (careful, now) that Drupal admin users already have some general computing experience, there's a likelihood they have already investigated the OS and/or browser text size preferences.
    • A scenario where we could expect some "admin" users without much computing knowledge would in distributions whose users have detailed profiles; such as learning management systems, community forums, or some e-commerce sites. For these, I suggest it's a question best left to Drupal distribution maintainers to address for their own use-cases. For one thing, they often use custom admin themes.

For web sites (or distributions) which warrant text resize controls, I think it's a job best left to contrib projects. A bunch of such modules already exist, covering several major Drupal core versions. These vary in their approach (and effectiveness), but most provide a block which can be placed anywhere, and try to be agnostic to themes.

@rembrandx - I appreciate that you've gone to the effort of building a proof-of-concept. I'll provide feedback on your implementation in that issue.

andrewmacpherson’s picture

Issue summary: View changes

Updating summary; won't-fix font size controls.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

benjifisher’s picture

Issue summary: View changes

We discussed this issue at #3186531: Drupal Usability Meeting 2020-12-11.

I am making a small update to the issue summary based on #13.

My personal opinion is that the three categories mentioned in the issue summary should be three separate issues:

  1. Settings defined across the site (per theme / per site)
  2. Settings defined per user (like dark mode / accessibility wise)
  3. Settings defined per component (like decreasing table padding or thumbnail size on Media library)

The simplest is (1). Decide what settings to provide, add them to the form at /admin/appearance/settings/claro, and figure out how to modify the theme based on the settings. Other than the decision of which settings to provide, this seems like an implementation issue, not a design issue.

(2) is more complicated. One question is how permanent the options will be. We could add a form to /user/%/edit and store the settings in the database. Or we could add a form in a block, position it wherever it is needed, and store the results in a cookie or the session. Probably the session. We could even do both: when a user logs in, copy settings from the database to the session.

Either way, we want to be careful when implementing the feature not to break caching. We do not want different markup depending on user preferences. For example, to allow dark mode, we might use JavaScript to add a CSS class to the <body> tag, and then modify all the CSS rules to respect that class.

On second thought, since Claro is an admin theme, maybe the pages are not cached anyway. Never mind?

As we discussed at the Usability meeting, (3) has to be made more specific. What do we mean by a component? However that is answered, I think we want some way for a component to declare its settings. Then the settings form in (1) has to collect those options and present them to the site administrator. Maybe this is not so hard to implement: Claro can define a configuration schema to be used by its components, and the settings form can collect all the config items. (Or is defining configuration schemata something that only modules can do?)

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

This is similar to https://www.drupal.org/project/fluidui

Exposing this information as a choice in the CMS would be interesting. However, you'd kinda want it to be something that anonymous users could take advantage of too.

Another plugin is https://github.com/skipto-landmarks-headings but you haven't mentioned anything like that. It could fit into this category of user choices.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ckrina’s picture