Produits Entr'ouvert » Publik

https://perso.entrouvert.org/~fred/tmp/27471-theming.webm

https://perso.entrouvert.org/~fred/tmp/27471-theming-2.webm

• Logo (repris dans les mails)
• Couleur de base (reprise dans les mails)
• Couleur du texte
• Police de base
• Taille de police de base
• Couleurs des liens

En pratique côté paramètres j'avais plutôt comme perspective d'être exhaustif et que tout ce qui se trouve possible et documenté https://doc-publik.entrouvert.com/dev/integration-graphique/infrastructure-scss/ puisse être exploité.

Mais cette liste reflète le déséquilibre qu'il peut y avoir entre différentes zones, beaucoup d'options pour le style des champs et presque rien pour l'entête de page, ça serait à corriger petit à petit en augmentant ces options.

Ça n'empêche pas de noter les options essentielles qu'il ne faudrait pas rater.

Oh ben évidemment c'est beaucoup mieux.

Il manque quand même le logo (indispensable pour permettre de décliner facilement une intégration graphique utilisée pour plusieurs communes).

Le logo et les autres éléments graphiques on les a déjà/parfois via les ressources dans combo mais c'est néanmoins une préoccupation à avoir parce que pour certaines intégrations on voudra prendre en compte ses dimensions pour placer d'autres éléments (typiquement éviter qu'un titre ou une navigation posée à côté ne se superpose).

J'ajoute mes interogations partagées pas mail :

Je (re)partage mon point de vue.
C'est amha pas possible et même une bêtise. (Pas de proposer une interface qui propose quelques options safe, mais de vouloir rendre paramétrable toute l'infra scss ou faire croire que c'est possible).
Quand on crée un thème, on le paramètre et le test juste sur certaines options, celles définies par la maquette et les choix faits au niveau de l'intégration si natif. Tous les cas de figures possibles > ne sont pas intégrés et testés. Et modifier 1 paramètre demande souvent des adaptations CSS ou la modification d'autres paramètres.
Et il y a des choses qui ne doivent pas être modifiables à la volée via une IU.
(Mais j'ai p-e raté un document ou un échange de mail à ce sujet).

À cela j'ajoute :

Pratique :
Pour faire de la maintenance sur les thèmes ou encore proposer des améliorations dans le core, il est important de pouvoir parser les CSS des thèmes et tester les thèmes en local.
Ça me semble important que les paramètres effectués via l'UI se retrouve dans le dépot GIT de publik-base-theme et ne pas devoir faire des export/import manuellement.

Design graphique :
Pour les couleurs, les tailles de font et le choix des polices par exemple, il ne faudra pas permettre de saisir librement une valeur. Ok ça ouvre une grande souplesse et laisse le choix total à l'administrateur de l'interface, mais par expérience, il est préférable de définir un nuancier de couleur, une liste de caractères (comme dans une charte graphique) et de ne pouvoir choisir dans les éléments graphiques définis.

Technique :
Je trouve dommage de demander au serveur de compiler les CSS à chaque changement d'une variable SCSS pour seulement ensuite pouvoir visualiser le résultat via l'IU, Sachant que via une UI un admin va faire 50 essais avant de valider son choix. Il faudra donc compiler une CSS de test avant d'écraser la CSS du portail, pour éviter que ses essais soient visibles en prod.
Alors qu'avec les variables CSS on pourrait proposer une interface avec un feedback rapide (meilleure UX), compiler via le terminal du client, avec une seule écriture sur le serveur une fois lors de la sauvegarde et la validation des choix suite aux essais.

Thomas Jund a écrit :

Design graphique :
par expérience, il est préférable de définir un nuancier de couleur

à coup sûr, le client ne trouvera pas la couleur de sa charte graphique, il faudrait permettre a minima la saisie d'un code hexadécimal

Proposition au club : https://publik.tracim.fr/ui/workspaces/1/contents/html-document/1977?folder_open=1