Expérimentation charte graphique pour lisibilité des contenus

Bonjour,

Je suis en train d’expérimenter une modification de la charte graphique Aurora (sous le nom officieux “Aurora Focus”), pour améliorer la lisibilité des contenus pédagogiques mis en ligne.

Aurora est déjà une charte graphique qui permet de créer des contenus respectant les normes d’accessibilité, ce projet est plus axé sur les pratiques de webdesign, et certains contextes spécifiques d’accessibilité.

Exemple de document publié avec cette charte / Publication aurora par défaut pour comparer

Téléchargement : AuroraFocus1-1_1.skinpack (496,3 Ko) ; compatible avec Opale 3.7.001

Code source pour SCENARIstyler : https://framagit.org/stephanep/aurora-focus

Principaux changements :

  • allégement : moins de bordures, moins d’encadrés, plus d’interlignes, de marge entre les paragraphes, plus de blanc
  • largeur de ligne maximum (85em), sans débordement lorsque la fenêtre descend sous cette taille
  • suppression de scrollbar interne au contenu et du mécanisme de scroll par boutons pour le menu de navigation
  • autres micro-ajustements (meilleur support d’un h1 sur 2 lignes, test d’autres polices)
  • le reste a pour conséquence des modifs dans la manière dont le responsive design est codé (a retester, je ne suis pas sûr de bien avoir repris toutes les fonctionnalités d’aurora…)

Le projet étant une expérimentation, il n’y a pas de garantie de maintenance, soyez prêt à retourner vers la charte graphique Aurora d’origine (ou une autre) si Aurora Focus n’était plus mis à jour, ou à reprendre vous même le projet (ce n’est pas monstrueux, aujourd’hui seulement 500 lignes de CSS).

Testé avec Firefox (desktop + android) et Chrome.

Idées pour l’avenir (mais probablement pas le temps de le faire dans le cadre de ce projet) :

3 J'aimes

Salut,

Il y a quelques semaines j’avais proposé l’intégration de less4j dans SC.Builder au niveau des générateurs mais personne a réagi et le monologue c’est pas mon fort. J’en ai conclu que personne souhaitait aller vers la variabilisation des CSS dans Scenari…donc je paie pour voir la suite (+1 :heart:) vu que je n’utilise pas cette méthode basée sur JS je suis curieux de voir ce que ça va donner :wink:

A+

Xa

1 J'aime

Expérimentation intéressante +++.
Bravo et merci pour cette initiative.
c’est effectivement bcp plus lisible, surtout sur tablette.
Sur smartphone, on a toujours les limites du menu qui prend bcp de place…
CdT. JPC

PS : Un “bug” repéré en testant : les Questions de catégorisation fonctionne en version poste de travail, mais pas sur mobile ou sur tablette. (iPhone sur SAFARI) (alors qu’avec la charte AURORA “de base” ça marche)

1 J'aime

Excellente expérimentation !

Du côté “officiel”, on attend simplement que les variables css “natives” soient généralisées dans les navigateurs, ce qui est imminent (ie la mort de IE11, https://caniuse.com/#search=CSS%20Variables), pour les exploiter dans les skins des générateurs : les approches exigeant une transpilation de type less ou sass n’ont alors plus d’intérêt.

Dans 15 jours, vous pourrez découvrir la nouvelle interface web de Scenari 5… Limité aux navigateurs modernes (Chromium pour le moment), les variables CSS sont naturellement de la partie pour le theming…

1 J'aime

oui, c’est pour ça que j’encourage @stephanep à poursuivre l’expérimentation. Pour l’instant les préprocesseurs sont plutôt efficaces à faire ce pour quoi ils sont faits et c’est pour ça que j’avais introduit l’usage dans OptimCV et mes autres productions :wink:

j’essaierai de venir au moins au début de la semaine…

A+
Xa

Pour les Variables CSS : si je poursuivais, ce serait avec un fallback sur des couleurs neutres afin qu’un visiteur obsolète puisse quand même voir le contenu. Même si, sur des sites gouvernementaux dont l’objet est l’expression démocratique, IE est déjà considéré comme mort (exemple grand bandeau sur https://www.referendum.interieur.gouv.fr/ ) donc effectivement c’est une position qui devient défendable.

Je ne suis pas sûr que les custom properties rendent obsolète le concept de pre-processing CSS, je ne voit pas trop en quoi l’un remplace l’autre. Le pre-processing apporte d’autres avantages, https://sass-lang.com/guide et minify par exemple. Si je faisais du CSS tous les jours je pense que je m’y plongerais plus sérieusement. Les problèmes que l’on avait au tout début de l’usage de ces technologies sont mieux gérés aujourd’hui (CSS source map pour debuguer dans les outils des navigateurs par exemple). D’un autre coté, pour Scenari, garder le workflow le plus simple possible pour produire des CSS n’est pas forcément une mauvaise idée si on veut que plus de personnes puissent changer les thèmes. (il y a plus de personnes qui maîtrisent CSS que LESS ou SASS).

@JPC-PARIS : merci pour le signalement de bug. Je n’arrive pas à le reproduire sous android (navigateur chrome ou firefox). Est-ce que tu le rencontres sur cette page : https://ics.utc.fr/aurora-focus/the/co/_Eval.html (exercice 7/8). Je peux imaginer par contre que si l’exercice est long, il est difficile de déposer des éléments dans les boites du bas vu qu’il n’y a pas de scroll possible au moment du drag, est ce que c’est ça le pb ? ou est-ce qu’il ne marche pas du tout ?

Ben, le bug ne bogue plus…
Décidément, les 0 et les 1…
Merci pour tes tests.
Bonne journée.

@stephanep : les autres “avantages” sont très vite une catastrophe en terme d’écroulement des perfs de rendu des pages (c’est du vécu). Quand à la minification, oui, bien sûr, mais c’est une autre couche logique, qu’il n’est pas forcément opportun de mélanger.