[EPIC] White brand docs

[virgile-dev]

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe.
As a reuser of Docs when I instanciate Docs many things are irrelevant to the context of my organization:

• The theme (css)
• The homepage
• The login button
• The legal pages
• The 404 page
• Select the languages you want to activate
• The waffle (redirecting to other la suite apps)
• The branding of the transactionnal emails
• The product name (ex : docs vs note) (and use strings that are agnostic to the product name "Virgile a partagé un document avec vous. Virgile a partagé une note avec vous")*
• font Roboto instead of Marianne
• Disable homepage and force login
• Do not show AI Action button if no env variables are found
• and more

Describe the solution you'd like
As reuser of Docs I want to be able to instanciate Docs and be able to personalize it to my own context.
I should be able to do it in a simple and maintainable way (meaning I shouldn't struggle with version upgrades)

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Discovery, Documentation, Adoption, Migration Strategy
If you can, explain how users will be able to use this and possibly write out a version the docs (if applicable).
Maybe a screenshot or design?

Do you want to work on it through a Pull Request?

[virgile-dev]

@AntoLC has been working on this POC : #665

[berrydenhartog]

1. I would like to remove the waffle and set an alternative redirect url that redirect to a portal with all tools we support in the suite
2. i would like to be able to skip the landing page and immediately redirect to SSO. (this would help reduce the theming load for us, not allot of things would need theming after this
3. I would like to be able to set the primary and secondary color schema (minimally)
4. theming overwrite options on css and html level would be nice to have (similair to jinja or apache freemarker)

[virgile-dev]

Thanks for your feedback @berrydenhartog we'll prioritize at least the 3 first ones.

[virgile-dev]

Rename this as an EPIC, it will be better to tackle these in several issues. Can you guys help by opening the most prioritized one ?

[rvveber]

@berrydenhartog
Let's start with the simplest example.
How are you expecting to configure primary and secondary color?

Currently it is not possible to change the frontend without changing the source and re-building the image.
The theme is selected via API call to the config-endpoint, but the theme has to exist in the pre-compiled frontend code to be selected.
The theme already has configuration options regarding the Waffle, just not enough.

Maybe we can discuss/find a better way to customize and add custom modules.

[berrydenhartog]

@rvveber i agree with you that it is indeed hard to dynamically set colors. I see a few solutions, all are not dynamicly loaded on runtime (except 4).

1. Add a CSS to public/css/ that we can change during kubernetes deployment. this CSS defines the :root
   :root { --colors-primary: #000000; --colors-secondary: #ffffff; .... }

2. Support SCSS/SASS and put it somewhere in the container so we can overwrite it with our own. Add a pre-compile step in the entrypoint script of the container.

3. Support design tokens, and put it somewhere in the container so we can overwrite it with our own, and add a pre-compile step in the entrypoint script of the container.

4. you could use dynamic colors where you load a json file from the server and use the values to set the colors in javascript
   document.documentElement.style.setProperty('--colors-primary', color);

[rl-83]

I propose this theme based on the official colors of Europe.

-> All correspondence here

[virgile-dev]

Hey @rl-83 I really liked the yellow shadow on the Docs Logo can we have it back ?

[bzg]

If I'm not mistaken, the proposed theme is still using Marianne as the font - @rl-83 do you confirm? if so, could we replace this with a font anyone can legally use?

[virgile-dev]

For the generic theme we are going for black and white instead (@rl-83 is working the color palette as we speak). It convey better the idea that docs is white brand and let's user focus on their content.

@rl-83 We'll have to redo the screenshot and the gif of the homepage

[virgile-dev]

Hey @AntoLC
Added these to the list of todos

• Disable homepage and force login
• Do not show AI Action button if no env variables are found

[rvveber]

@rvveber i agree with you that it is indeed hard to dynamically set colors. I see a few solutions, all are not dynamicly loaded on runtime (except 4).

1. Add a CSS to public/css/ that we can change during kubernetes deployment. this CSS defines the :root
   :root { --colors-primary: #000000; --colors-secondary: #ffffff; .... }
2. Support SCSS/SASS and put it somewhere in the container so we can overwrite it with our own. Add a pre-compile step in the entrypoint script of the container.
3. Support design tokens, and put it somewhere in the container so we can overwrite it with our own, and add a pre-compile step in the entrypoint script of the container.
4. you could use dynamic colors where you load a json file from the server and use the values to set the colors in javascript
   document.documentElement.style.setProperty('--colors-primary', color);

I do like the first option the most.
If everything was based on css variables, we could overwrite a lot by simply defining custom CSS.

We would not need to define a "Theme" via the Backend, because the css vars would already be Theme definition and could be overwritten at any point. @AntoLC
Technically logos/images etc. can also be a css-var.

And everything else could also be customized via FRONTEND_CUSTOMIZATIONS... (name tbd)
just like custom CSS could be customized with FRONTEND_CUSTOMIZATIONS_CSS_SRC
Passed from the backend on runtime, forcing us to sparingly and cleverly design customizations.

E.g. instead of defining a boolean in json theme to "activate LaGaufre" which requires it to be hardcoded into the app -
we would be forced to add a variable that is multi-purpose:
FRONTEND_CUSTOMIZATIONS_MODULE_HEADER_SRC
or even
FRONTEND_CUSTOMIZATIONS_MODULES_SRC
And pass the URL to e.g. a json that can be used to overwrite default configuration for modules.

It would force us to re-design components with general purpose and sensible pre-defined defaults.
It would give just the right amount of flexiblity to configure certain parts of the UI. And it would all be optional and partial.

I can't think of a better solution at the moment.
What do you think? @berrydenhartog @AntoLC @lunika

[berrydenhartog]

I am indeed in favor of option 1 or 3. But i leave it to the implementer to make choice since they can best estimate what the impact would be on the codebase. I did not do a deep dive into the source yet. If they prefer a theme, that would be fine for now. It would however limit flexibility for others hosting Docs.

I myself would go for option 1 because it gives allot of flexibility for everyone wanting to use Docs and does not require a compile step

[AntoLC]

Hi!
We just merged this PR #771, giving an easy runtime way to overwrite docs with css.
It is the first step of a series of way to override Docs (see #799).

[mclegrand]

The waffle (redirecting to other la suite apps)

I really like the concept, which I think is great, but the code seems to hardcode the dinum which in turn calls this fixed list

AFAICT "La Gaufre" would be easy to self-host if it's only a small piece of js and a static html list (would need some documentation though), or even could be optionally provided as a small pod of docs with an ingress to /gaufre and a configmap (or a volume)