Harmoniser le nombre de colonnes pour la Layout

[AnthonyBrunelli]

Vu avec @lucaa : il n'y a pas d'harmonisation de la mise en page par rapport au nombre de colonnes occupées : 12/12, 10/12, 8/12. Il faut une règle...

[AnthonyBrunelli]

@lucaa je te laisse compléter. @ugodtn @kamalcon

[lucaa]

Aujourd'hui, sur les maquettes de figma de https://www.figma.com/file/kG2znZqEzySDPUxiWbrEme/JDMA?node-id=90%3A24913 , si on considère que l'entête à toujours 12 colonnes de largeur, nous avons plusieurs tailles du contenu, ainsi:

• 12 / 12 : page d'accueil uniquement
• 10 / 12
  • page de présentation du produit JDMA
  • page de la démarche une fois ajoutée - informations sur la démarche, code pour récupérer le bouton, onglets avec les avis et la synthèse des avis
• 8 / 12
  • pages d'inscription et connexion
  • formulaire d'ajout de nouvelle démarche

En plus de la maquette figma, il y a d'autres pages de la plateforme:

• la page de l'observatoire - aujourd'hui sa taille est hybride, plus large que l'entête, pour accueillir le tableau
• toutes les pages de textes - CGU, Accessibilité, page expliquant les critères d'évaluation, autres pages d'explications et aides
• page de résultats de recherche
• à quelques exceptions, toutes les pages pour l'administration des données.

Aujourd'hui la base de la plateforme est d'afficher tout en 12/12, si on veut d'autres comportements, il faut les implémenter un par un sur les pages concernées.

On a réduit la taille des pages d'inscription et de connexion pour #1056 et celle de la page de présentation du produit JDMA pour #1048, mais on n'a pas prévu d'autre travail de cette taille, qui sera donc à 12/12 sur tous les autres écrans, dessinés dans figma ou pas.

Cette tâche est pour:

• décider quelle devrait être la taille "par défaut" - aujourd'hui 12/12
• potentiellement re-voir les maquettes pour avoir plus d'écrans qui utilisent cette taille par défaut plutôt que la variabilité couramment prévue. Notamment, si possible, pour les écrans de formulaire d'ajout de nouvelle démarche et l'écran de la démarche.
  • comme techniquement la logique de l'implémentation de la plateforme est à base de "conteneurs" stylées de manière universelle dans lesquels les contenus sont ajoutés soit sans style spécifique soit avec un style qui ne touche pas au conteneur mais uniquement au contenu en question, le choix d'une seule taille limiterait la complexité et serait préférable du point de vue purement technique.

[AnthonyBrunelli]

Vu ce jour avec Anca & Ugo :

• @lucaa doit ouvrir un ticket sur le fait que la maquette JDMA n'est pas respectée.
• Pour le reste, à voir en 4.11 car ça ne change rien par rapport à aujourd'hui.
• @ugodtn & @kamalcon confirmer que le changement de nombre de colonne d'une page à l'autre est important. "Harmoniser le truc" dit Anca.
• Décision: par défaut, c'est 10 colonnes sur 12.

[ugodtn]

C'est important, la question c'est plutôt : confirmer ce que l'on veut exactement pour chaque page. ToDo, donc.

[lucaa]

Notes de la discussion autour des contraintes des tailles et possibilités:

[ugodtn]

Bonjour @lucaa , on a fait le point avec @kamalcon et voici ce qu'on a décidé :

• Largeur large : 12 colonnes
• Largeur medium : 10 colonnes
• Largeur small : 8 colonnes
• Largeur extra large : 14 colonnes ? (on parle ici seulement du cas du tableau Top250)

La largeur par défaut serait la large, donc 12 colonnes.

Concernant les pages où il faut appliquer une largeur spécifique, elles sont à jour dans la maquette, et voici le détail (si je n'oublie rien) :

• Page d'accueil du site (connecté ou non) : medium
• Page Outil JDMA : medium
• Page d'une démarche : medium
• Page de connexion : small
• Page d'inscription : small
• Page de création / édition d'une démarche : small
• Tableau Top250 : extra large

Par ailleurs, on souhaiterait que sur l'ensemble des pages (ou a minima celles spécifiques), le comportement responsive change pour celui-ci : n'avoir qu'un seul point de rupture mobile (768px), et avoir un comportement fluide le reste du temps. Par fluide, on entend : si la largueur de la page est plus large que le nombre de colonne, le contenu garde la même largeur, si la largeur de la page est plus faible, le contenu s'adapte en largeur de manière à être toujours au bord de l'écran.

Enfin, cela va nous mener à modifier le comportement spécifique de deux éléments sur le site :

• La présentation des 8 critères sur la page d'accueil non connecté
• Les 4 étapes sur la page Outil JDMA

Ce deux éléments doivent avoir le comportement suivant : au-dessus du point de rupture 992px : affichage de 4 éléments par ligne. Au-dessus du point de rupture mobile de 768px : affichage de 2 éléments par ligne. En dessous du point de rupture mobile de 768px : affichage d'un seul élément par ligne.

La maquette est à jour. On reste à disposition si besoin. @kamalcon est-ce que tu peux relire et valider juste en dessous que ça correspond bien à ce que l'on s'est dit ? Merci !

[kamalcon]

Je valide !

[lucaa]

Bonjour @lucaa , on a fait le point avec @kamalcon et voici ce qu'on a décidé :

• Largeur large : 12 colonnes
• Largeur medium : 10 colonnes
• Largeur small : 8 colonnes
• Largeur extra large : 14 colonnes ? (on parle ici seulement du cas du tableau Top250)

La largeur par défaut serait la large, donc 12 colonnes.

Pour clarifier: 12 colonnes est le 100% de la taille du conteneur fixe pour la taille d'écran sur laquelle l'observatoire est affiché, correct? Plus précisément:

• pour écrans > 1200 px, conteneur fixe à 1170px
• pour écrans entre 992 et 1200px, conteneur fixe à 970px
• pour écrans entre 768 et 992px, conteneur fixe à 750px
• pour écrans en dessous de 768px, le conteneur n'est pas fixe mais a une taille variable, la taille actuelle de l'écran - 100% de la largeur de l'écran.

Ceci sont les tailles courants et les points de rupture courants (bootstrap), on peut les changer à la marge si elles ne conviennent pas, cela n'impacte pas les règles de proportions.

Ensuite, la largeur large sera égale à ce conteneur fixe (avec les tailles ci-dessus) et les autres largeurs seront proportionelles:

• medium 10/12 * taille du conteneur
• small 8/12 * taille du conteneur
• extra large: max 14/12 * taille du conteneur, min 100% de la largeur de l'écran .

Par ailleurs, on souhaiterait que sur l'ensemble des pages (ou a minima celles spécifiques), le comportement responsive change pour celui-ci : n'avoir qu'un seul point de rupture mobile (768px), et avoir un comportement fluide le reste du temps. Par fluide, on entend : si la largueur de la page est plus large que le nombre de colonne, le contenu garde la même largeur, si la largeur de la page est plus faible, le contenu s'adapte en largeur de manière à être toujours au bord de l'écran.

Je ne comprends pas vraiment cette description du comportement... c'est uniquement pour les pages de largeur non-large? "si la largueur de la page est plus large que le nombre de colonnes" -> sachant que les colonnes sont une division de la largeur de la page elle-même, je ne comprends pas vraiment ce que ça veut dire...

Essayons de décrire le comportement attendu par rapport aux tailles d'écrans (ci-dessus) et par rapport aux 4 largeurs de pages definies, voici ce que je comprends:

largeur de page/taille de l'écran	écran < 768px	768px < écran < 992px	992px < écran < 1200px	1200px < écran
large	100% écran, variable	fixe à 750px (taille du conteneur fixe)	fixe à 970px (taille du conteneur fixe)	1170px (taille du conteneur fixe)
medium	100% écran, variable	fixe à 10/12 * 750px	fixe à 10/12 * 970px	fixe à 10/12 * 1170px
small	100% écran, variable	fixe à 8/12 * 750px	fixe à 8/12 * 970px	fixe à 8/12 * 1170px
extra large	100% écran, variable	hybride à 100% écran pour tous les écrans < 875px, 875px au dessus; 875 = 14/12 * 750	hybride à 100% écran pour tous les écrans < 1131px, 1131px au dessus; 1131 = 14/12 * 970	hybride à 100% écran pour tous les écrans < 1365px, 1365px au dessus; 1365 = 14/12 * 1170

[lucaa]

spécification à écrire par @lucaa suite aux discussions en call.

[lucaa]

Suite aux discussions, le besoin est un peu différent du commentaire ci-dessus, ainsi:

• une page est vue comme composée de 2 (3) blocks: le header (et le footer) et le contenu;
• ces blocks peuvent avoir des tailles différentes les uns des autres;
• le header et le footer auront toujours la même taille, une taille de 12 colonnes (voir ci-dessous l'explication pour les colonnes);
• le contenu pourra avoir 4 tailles, en fonction de l'écran de l'application: large (12 colonnes), medium (10 colonnes), small (8 colonnes), extra large (14 colonnes).

Les tailles de block se comportent différemment par rapport à aujourd'hui, dans le sens ou il y a uniquement 2 cas, pour chaque tel block:

• taille fixe - pour toutes les largeurs d'écran au dessus d'un seuil établi pour chaque taille de block;
• taille variable - 100% de l'écran, pour toutes les largeurs d'écran en dessous de ce seuil.

Les blocks de la page étant dimensionnés indépendamment, il est possible d'avoir, pour une taillé d'écran donnée, un des blocks qui sont de taille fixe (par exemple un contenu small) et les autres qui sont à 100% de l'écran (header et footer qui sont toujours de taille large).

Le nombre de 'colonnes' de chaque taille est, ainsi, une manière d'exprimer des tailles en pixels, car, en réalité, les proportions entre les différentes tailles de block seront préservées uniquement pour les écrans pour lesquels tous les blocks sont de taille fixe. La correspondance est à faire à base de l'écran de 1200px d'aujourd'hui, donc pour un conteneur de 1170px. On obtient ainsi:

• 1 colonne = 100px avec gouttières (de 15px de chaque côté)
• taille large: 1170px (=12x100px - 2x15px)
• taille medium: 970px ( = 10x100px - 2x15px)
• taille small = 770px ( = 8x100px - 2x15px)
• taille extra large = 1370px (14x100px - 2x15px).

Ces tailles sont à compter du début du contenu à gauche jusqu'à la fin du contenu à droite, sans marges droite et gauche. Ainsi, quand on va parler de tailles d'écran on va devoir ajouter à ces tailles de la place pour les marges droites et gauche, pour que le texte ne colle pas à l’extrémité de l'écran, à droite comme à gauche.

Ainsi nous avons le comportement suivant pour les différentes tailles d'écran:

largeur de block/taille de l'écran	écran < 800px	800px < écran < 1000px	1000px < écran < 1200px	1200px < écran < 1400px	1400px < écran
large	100% écran, variable	100% écran, variable	100% écran, variable	fixe à 1170px	fixe à 1170px
medium	100% écran, variable	100% écran, variable	fixe à 970px	fixe à 970px	fixe à 970px
small	100% écran, variable	fixe à 770px	fixe à 770px	fixe à 770px	fixe à 770px
extra large	100% écran, variable	100% écran, variable	100% écran, variable	100% écran, variable	fixe à 1370px

Les points de rupture Bootstrap pour les dispositifs mobiles sont à garder tels quels car le contenu des différents blocks sera sensible aux points de rupture standard (xs, sm, md, lg).

@ugodtn peux-tu confirmer le tableau ci-dessous au niveau du principe? (il y a peut-être des ajustements de ±30px à faire en fonction de comment on décide de compter les gouttières droite-gauche).

[lucaa]

vu avec @ugodtn en call: les comportements décrits ci-dessus sont correct.

[clemdee]

• Les différentes tailles de layout ont été implémentée. (implémentation du SSX Demarches.Code.setLayoutContainerSizeSSX permettant de définir la largeur du layout de la page en la lui passant comme paramètre)
• Les pages indiquées (page d'accueil, page d'une démarche, login, ...) ont été modifiées afin de respecter la taille du layout qui leur était spécifiée.

[lucaa]

@ClemDee header et footer doivent aussi avoir la taille .container-fluid-lg et le comportement associé . De ce que je vois aujourd'hui sur le serveur de dev, ils ont toujours le comportement du conteneur fixe bootstrap.

[clemdee]

• le fichier setLayoutContainerWidth a été renommé
• la taille / comportement .container-fluid-lg a été implémenté pour le header et le footer.

[clemdee]

Le footer a été refactoré de manière à respecter boostrap

[AnthonyBrunelli]

@ugodtn c'est pour oit! Testable en staging

[ugodtn]

C'est bon pour moi !