Projet

Général

Profil

Evolution #4148

Augmenter la largeur de l'espace privé

Ajouté par tcharlss (*´_ゝ`) il y a 4 mois. Mis à jour il y a 3 mois.

Statut:
En cours
Priorité:
Normal
Assigné à:
-
Catégorie:
-
Version cible:
Début:
09/06/2018
Echéance:
% réalisé:

0%

Resolution:

Description

Il est temps d'augmenter la largeur de l'espace privé :)

En développant des plugins, je butte souvent face au manque de place et me retrouve à diminuer artificiellement des contenus pour essayer de tout faire rentrer : enlever ou fusionner des colonnes dans les tableaux, réduire des labels dans les colonnes, etc.
Mais ça ne règle pas tous les problèmes, et c'est vite frustrant de se contorsionner pour essayer de tout faire rentrer.

Pour ma part je serais d'avis de prendre simplement toute la largeur disponible, width: 100% quoi.
Les colonnes en pourcentage avec un min-width, le contenu central qui prend la place restante, et voilà.
Et surtout rien de configurable de ce côté là : pleine largeur, point barre.

Ça m'amène à la préférence utilisateur « petit écran » / « grand écran ».
Ces termes sont un peu trompeurs, car ils impactent avant tout le layout.
Le mode grand écran est certe un peu plus large, mais il ajoute une colonne à droite : au final les colonnes et le contenu central conservent exactement la même largeur que le petit écran, et on a toujours le même problème de place.
Donc l'idée serait d'avoir la pleine largeur quelque soit le mode, et de trouver des termes plus appropriés : « 2 / 3 colonnes» ou quelque chose du genre.

Mais à terme ces 2 options devraient disparaître à terme à mon avis, ça ne devrait pas être une préférence utilisateur.
Certaines pages ont besoin de 2 colonnes, d'autres de 3, mais c'est à décider page par page, pas de façon globale.
C'est d'ailleurs le cas actuellement sur certaines pages qui ont besoin d'une seule colonne avec la balise #LARGEUR_ECRAN{pleine_largeur}

Enfin, une précision, je laisse complètement de côté la question du responsive.
Pour l'instant le privé n'est pas responsive, donc il n'est pas question d'y toucher.
Là il s'agirait juste de modifier quelques règles CSS qui régissent la largeur générale, avec éventuellement quelques adaptations pour d'autres éléments.

J'essaierai de joindre un patch à l'occasion.

fluiiiiiide.png Voir (126 ko) b b, 09/06/2018 17:48

bug_css_fluiiiiide.png Voir - Bug plugin privé fluide dans certains cas (79,7 ko) tcharlss (*´_ゝ`), 13/06/2018 10:05

cms-drupal.png Voir - DrupSPIP (54,2 ko) tcharlss (*´_ゝ`), 13/06/2018 10:14

cms-grav.png Voir - GravSPIP (105 ko) tcharlss (*´_ゝ`), 13/06/2018 10:14

cms-joomla.png Voir - JoomSPIP (86,8 ko) tcharlss (*´_ゝ`), 13/06/2018 10:14

cms-prestashop.png Voir - PrestaSPIP (214 ko) tcharlss (*´_ゝ`), 13/06/2018 10:14

cms-wordpress.png Voir - WordSPIP (192 ko) tcharlss (*´_ゝ`), 13/06/2018 10:14

cms-thelia.png Voir - TheliSPIP (53,3 ko) tcharlss (*´_ゝ`), 13/06/2018 10:14

Capture du 2018-06-14 15-15-42.png Voir (436 ko) chan kalan, 14/06/2018 15:22

loooongues lignes.png Voir (100 ko) nico d_, 14/06/2018 16:33

textarea rikiki.png Voir (61,4 ko) nico d_, 14/06/2018 16:33

Capture du 2018-06-22 08-59-00.png Voir (104 ko) chan kalan, 22/06/2018 09:27

picture130-1.png Voir (2,38 ko) RealET 🔸, 23/06/2018 01:02

too_much.png Voir (35,5 ko) guytarr °, 23/06/2018 09:20

too_much_bis.png Voir (124 ko) guytarr °, 23/06/2018 09:21

prive_plus_edit.png Voir (530 ko) nico d_, 24/06/2018 00:01

prive_plus_preview.png Voir (658 ko) nico d_, 24/06/2018 00:01

prive_plus_edit_small.png Voir (469 ko) nico d_, 24/06/2018 00:02

539fc0f1-d25c-4802-b0da-4c6828550364.png Voir (157 ko) chan kalan, 25/06/2018 10:04

Historique

#1 Mis à jour par b b il y a 4 mois

Version cible à 3.4 car pas certains qu'on ait le temps de voir ça en 3.3, à discuter.

À propos de la pleine largeur, j'ai dernièrement au accès à un site qui utilise le plugin "Espace privé fluide - remix" pour faire ça et je ne trouve pas le résultat très satisfaisant dans la manière dont c'est appliqué, exemple en capture ci jointe.

Même s'il est vrai que certaines pages méritent plus de largeur, amha, il faudrait cibler plus finement les blocs des différentes pages qu'on souhaite avoir en pleine largeur et affiner tout ça, sans quoi, on se retrouve avec des "aberrations" comme dans la capture : menu haut plein de vide et items alignés à droite, zone d'édition du contenu d'un objet bien trop large.

#2 Mis à jour par nico d_ il y a 4 mois

  • Version cible 3.4 supprimé

Tout a fait d'accord, sauf sur la largeur à 100% :)

Sur un écran un peu grand, c'est beaucoup trop large.

Pour ça, j'utilise ta css du plugin prive_fluide (elle est vraiment super bien pensée !), que j'ai très légèrement adaptée pour la caler sur un max-width de 1200px.

#3 Mis à jour par b b il y a 4 mois

@nicod "Version cible 3.4 supprimé" ????

#4 Mis à jour par nico d_ il y a 4 mois

Voilà, la capture écran montrée par b_b illustre exactement ça : c'est le plugin prive_fluide_remix, fork dans mon coin de prive_fluide :D

#5 Mis à jour par nico d_ il y a 4 mois

Flute, nos réponses se sont croisées et j'ai du cocher la mauvaise case sur les changements...

Mais bon, pourquoi 3.4 ? La css de tcharlss est toute prête, y'a juste à l'intégrer.

Je l'utilise en prod sur plusieurs sites (modulo la largeur à 100%, qui pourrait être en config).

#6 Mis à jour par b b il y a 4 mois

Mais bon, pourquoi 3.4 ? La css de tcharlss est toute prête, y'a juste à l'intégrer.

Parce que je ne suis pas certain que la modif en question sera pleinement prête avant qu'on release la 3.3, mais on ne sait jamais :p

#7 Mis à jour par nico d_ il y a 4 mois

Tiens je pourrais même réintégrer mon fork dans le plugin prive_fluide sur la zone et ajouter une config (j'ai juste pas pris le temps jusque là).

On pourrait même forker les radios "Petit écran / Grand écran" en changeant les libellés :)

#8 Mis à jour par nico d_ il y a 4 mois

On parie ? ça peut être prêt demain soir.
Allez, le WE prochain au max :)

#9 Mis à jour par b b il y a 4 mois

Allez, le WE prochain au max :)

Même en prenant en compte mes remarques listées plus haut ? :)

#10 Mis à jour par RastaPopoulos ♥ il y a 4 mois

b_b tes remarques je suis d'accord, il y a une ambivalence : ça ajoute des choses bien et ça peut ajouter quelques problèmes MAIS justement, quand on fait la balance, la quantité de choses que ça améliore est à mon avis nettement supérieure aux quelques soucis que ça causeraient.

Le menu ne me parait pas bizarre (et des plugins pourraient rajouter des entrées principales, c'est le cas pour Développement, mais il pourrait y avoir Commerce ou autre), et pour l'édition : c'est toujours mieux qu'une colonne ridicule de quelques pixels de large. À la limite, au file du temps on peut même imaginer agrandir la taille de police enfin, maintenant qu'on sait qu'on aura de la place.

#11 Mis à jour par nico d_ il y a 4 mois

Sur la largeur de la zone d'édition je suis d'accord, d'ailleurs le plugin n'est pas up sur ce site :)
J'ai réduit à environ 80 caractères la zone d'édition.

Sur le menu principal, le "plein de vide" ne me choque pas :)

Et comme dit Rasta, en l'état c'est déjà plus agréable à utiliser, même si perfectible mais assez facilement.
Ce serait surtout de l'ajustement de largeurs, la base de tcharlss est très bien, avec du bon flex dedans, miam :)

#12 Mis à jour par nico d_ il y a 4 mois

Voilà, calé sur 1000px max en largeur totale, avec à peu près 80 caractères dans la zone d'édition comme à l'affichage
https://screenshotscdn.firefoxusercontent.com/images/c91c1813-3fdd-4ae3-9ea5-10e14bc95364.png
https://screenshotscdn.firefoxusercontent.com/images/836405b3-3220-494a-9ec8-9f1ddefaa50f.png

Et c'est up sur https://spip.lerebooteux.fr/ dans le privé :)

#13 Mis à jour par nico d_ il y a 4 mois

Pour la taille de la police, ce serait bien aussi.
Voilà ce que ça donne sur la même page, avec un simple body{font-size: 0.9em;} (qui surcharge donc le 0.8125em de base) et une largeur qui passe à 1100px :
https://screenshotscdn.firefoxusercontent.com/images/70256997-b870-489e-be77-c0eb267ca962.png

Bon, après pour affiner y'a des font-size qui se balladent de partout, et les deux font-stacks (Cambria et Lucida) n'ont pas le même rendu de taille, et ça doit varier en fonction des OS.
Une refonte complète serait sûrement un peu plus de boulot.

#14 Mis à jour par b b il y a 4 mois

@nicod oui ça me semble mieux maintenant :)

Pas trop d'avis concernant la taille de typo, cela devrait peut-être discuté dans un ticket spécifique sans quoi celui-ci va devenir un chantier refonte du privé sans fin :p

#15 Mis à jour par nico d_ il y a 4 mois

+1 pour le ticket séparé :)

#16 Mis à jour par b b il y a 4 mois

  • Version cible mis à 3.3

#17 Mis à jour par b b il y a 4 mois

  • Statut changé de Nouveau à En cours

#18 Mis à jour par tcharlss (*´_ゝ`) il y a 4 mois

Super nicod_, merci pour les remarques et le boulot :)

Alors concernant la largeur, 1200px ce serait déjà beaucoup mieux.
Mais pour ma part je pense que du 100% serait toujours la meilleur option. Au début ça fait un peu bizarre je le concède, mais on s'y fait vite et c'est dur de revenir sur une largeur fixe après. Pour les tableaux / listes d'objets par exemple ça devient vite indispensable. Le menu ne me pose pas de problème non plus : on comprend que les items sont alignés à gauche.

Il y a bien certains contenus qui doivent être limité en largeur pour avoir 80 caractères par ligne c'est vrai, mais il s'agit de quelques blocs à identifier, et ça reste valable quelque soit la largeur globale de l'interface.
Pour l'instant je ne vois que 2 blocs concernés : le #wysiwyg et les formulaires d'édition.
Donc mon constat c'est : à partir du moment où on limite la largeur de certains blocs qui contiennent du texte afin que ça reste lisible, pourquoi limiter arbitrairement la largeur globale de l'interface ?
Dans le plugin privé fluide, seul le #wysiwyg est ciblé pour l'instant. Attention il reste aussi des petits problèmes à régler dans certains cas, cf. capture d'écran.

Pour comparaison, avec RastaPopoulos on avait installé une floppée de CMS pour étudier leurs interfaces au moment où on s'intéressait au sujet, et ils ont tous une largeur 100%.
Je ne dis pas qu'il faut suivre bêtement ce que font les autres, mais ça donne des exemples concrets de choix de layouts qui fonctionnent.

Sur la question de rendre cette largeur configurable, je ne suis pas très chaud. C'est exactement pour ça que j'avais fait le plugin privé fluide dans mon coin alors qu'il existe déjà le plugin d'Ybbet : je pense que l'interface doit être d'office adaptée à tous les écrans, sans rien à configurer. Aucune envie d'avoir à configurer ça sur chaque nouvelle instance de SPIP qu'on déploie :p

Du coup on écrivant tout ça, je verrais finalement la chose comme ça :
  • Largeur globale 100%
  • Supprimer carrément la préférence utilisateur « taille de l'écran »
  • Jusqu'à ~1200px : 2 colonnes (#navigation + #extra | #contenu)
  • Au-delà : 3 colonnes (#navigation | #contenu | #extra)

Du coup en écran large on aurait toujours 3 colonnes et ça équilibre un peu plus.
Et plutôt que du flex, je pense qu'on pourrait partir directement sur du css grid, avec un bête fallback en float pour les vieux navigateurs.
Parceque du coup je ne vois pas comment mettre la colonne #extra soit en dessous de #navigation, soit à droite de #contenu juste avec du flex.

#19 Mis à jour par tcharlss (*´_ゝ`) il y a 4 mois

Bon allez, quelques captures d'écran des voisins pour comparer :)

#20 Mis à jour par tcharlss (*´_ゝ`) il y a 3 mois

J'ai commencé à implémenter ma dernière proposition dans le plugin prive_fluide.

Il reste des détails à peaufiner, mais en général ça fonctionne comme prévu : le colonnage est dépendant de la largeur de l'écran, de 1 colonne sur mobile à 3 sur écran large (>1200px). Donc finalement il y a un peu de responsive, mais ça ne mange pas de pain.
Du coup la préférence utilisateur sur la taille de l'écran est complètement ignorée, et body.html est surchargé pour mettre les blocs principaux dans l'ordre logique : d'abord #conteu, puis #navigation et #extra.

Concernant les blocs à limiter en largeur pour avoir ~80 caractères par ligne, j'ai ciblé #wysiwyg et les textareas des formulaires.
Je pensais d'abord cibler les formulaires entiers, mais finalement je me suis dit qu'il y a des saisies qui peuvent bénéficier de la largeur entière, comme les sélecteurs de rubriques/articles par ex. À voir.

#21 Mis à jour par chan kalan il y a 3 mois

Comme ça on voit bien, merci tcharlss.
Autant j'aime bien la fluidité, et là ça fonctionne très bien à la réduction, autant j'en ai pas besoin au-delà de 1000px, ou si le max est à 1200px de large ça suffirait tout à fait et largement. Au-delà, donc, je trouve que ça gêne plus qu'autre chose.
En fait à 1200px avec les trois colonnes c'est parfait, inutile d'aller plus large.

#22 Mis à jour par RastaPopoulos ♥ il y a 3 mois

Je ne suis pas très d'accord avec ce constat. Pour moi c'est comme quand dans les années 90 on faisait du "optimisé pour 1024px" de large, sauf que là ce serait 1200 max.

Ce qu'il faut,comme l'a dit Charles, c'est identifier les quelques éléments précis qui sont des textes à optimiser en lisibilité, et dans ce cas, on sait qu'en ergonomie on préconise entre 45 et 75 caractères de longueur de ligne (aucun rapport avec une taille en pixels, à bas les pixels). Mais pour le reste, ya pas à bloquer spécialement, toutes les listes d'objets en tableau, les galeries de doc, etc, peuvent bénéficier de ne pas avoir de limite spéciale en largeur.

#23 Mis à jour par tcharlss (*´_ゝ`) il y a 3 mois

J'ai activé le plugin sur un site de test pour se faire une idée du résultat : http://bravecassine.com/dev/spip-interface/ecrire/

  • login : spip
  • mot de passe : spipspip

La colonne #extra est visible sur la page d'un article : http://bravecassine.com/dev/spip-interface/ecrire/?exec=article&id_article=1

#24 Mis à jour par chan kalan il y a 3 mois

Si ce n'est pas la nécessité du contenu qui élargi l'emplacement, je ne vois pas de gain, qu'une dispersion. L'espace qu'on avait à l'extérieur, on le retrouve de chaque côté du texte, et donc on a écarté les éléments qui nous intéressent, c'est tout ce qu'on a fait.

#25 Mis à jour par b b il y a 3 mois

Même avis que chankalan, perso ce genre de layout m'imposerait de réduire la taille de la fenêtre de mon navigateur sur les site SPIP pour ne pas "subir la dispersion". Ce n'est que mon avis, mais je pense que ça mérite réflexion.

#26 Mis à jour par nico d_ il y a 3 mois

J'avais donné mon avis initialement :)

En largeur à 100%, sur un 24" en 1920x1200 ça fait aussi des lignes trèèès longues, par exemple sur une liste d'objets, l'intitulé est tout à gauche et les infos sont loin, tout à droite.
Ça demande un effort aux yeux (si si).

Et on se retrouve avec des textareas tout rkiki de 580px de large au milieu d'inputs de 1360px, par exemple sur l'édition d'un auteur.

#27 Mis à jour par nico d_ il y a 3 mois

Bon, j'ai posé mon remix :)

https://zone.spip.org/trac/spip-zone/changeset/110763/spip-zone

Ça inclut aussi un travail de lisibilité : corps de texte à 1em (16px), utilisation de la police Lato (haters gonna hate), suppression de plein d'icones (lourdingues) et quelques ajustements sur les formulaires

Je vous laisse essayer.

#28 Mis à jour par Peet du il y a 3 mois

Je passe tous mes sites en mode plein écran (et je force ça pour tous les autres utilisateurs).
Je suis donc fan de cette initiative.

L'idée d'un 100% ne me branche pas du tout (vu les tests + les copies d'écrans de l'ensemble des autres CMS) L'effet dispersion !
Et comme disait Coluche :

C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!

Le travail sur la typo est immédiatement addictif :) Bravo !
Par contre, la disparition de la 3e colonne…bof. Par exemple, je trouve très bien d'avoir le bloc "Dans la même rubrique" à droite. C'est un raccourci vers les autres articles de la rubrique très pratique. Là il faut scroller pour le retrouver :(
Y'a moyen de garder cette 3e colonne ?

#29 Mis à jour par b b il y a 3 mois

Merci nicod, c'est vraiment pas mal du tout :)

Quelques remarques rapides à propos de certaines modifications qui s'écartent du sujet initial, la largeur de l'espace privé :

- le passage des legend en gras dans les formulaire les passe bien trop en avant ;
- à l'inverse, le retrait du gras sur les items de premier niveau du bandeau (sous les pictos) fait un peu pattes de mouche et participe à l'impression de vide de la zone haute.

++

#30 Mis à jour par chan kalan il y a 3 mois

Je suis assez d'accord avec b_b sur le remix de nicod, l'ensemble est vraiment chouette, je vois juste un petit ascenseur horizontal qui disparaît avec
#bando_haut #bando_liens_rapides { width:auto; }
Mais comme Peetdu j'aime bien la troisième colonne, ça remonte un contenu important et souvent utilisé...

#31 Mis à jour par nico d_ il y a 3 mois

J'ai déplacé dans une branche de prive_fluide plutôt que d'en faire un plugin à part :
https://zone.spip.org/trac/spip-zone/changeset/110769/spip-zone

Le code est donc là maintenant :
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/prive_fluide/branches/remix

Merci pour vos retours, ça me parait bien vu.
Je m'occupe de modifier ça.

- le passage des legend en gras dans les formulaire les passe bien trop en avant ;

C'est pour les styler comme des h3.legend, pour bien marquer les groupes de champs, à voir.

#32 Mis à jour par nico d_ il y a 3 mois

Suite aux retours :
- les legend, h3.legend un peu plus discrets (b_b)
- le menu principal en bold (b_b)
- le scroll horizontal qui apparaissait (chankalan)
et un peu plus d'emphase sur les titres de liste d'objets et de formulaires, vu qu'il n'y a plus d’icônes.

Details: https://zone.spip.org/trac/spip-zone/changeset/110784

Pour la 3e colonne à droite, je comprends bien, mais ce qui me chagrine personnellement c'est qu'en fait elle est vraiment très peu utilisée, ça bloquerait un gros espace à droite souvent vide en fait.
A discuter...

#33 Mis à jour par b b il y a 3 mois

Super, merci pour les modifs :)

#34 Mis à jour par Peet du il y a 3 mois

ouais...c'est vraiment bien !

deux remarques :
1- page /?exec=admin_plugin : avec l'option "Ecran large" activée, la colonne extra se glisse entre la colonne "Navigation" et "Contenu" créant une gouttière très large.
2- concernant la 3e colonne : ne pas la garder revient à supprimer (le principal intérêt ?) de l’option « petit écran / grand écran ». Ce serait donc une évolution qui devrait faire l’objet d’un nouveau ticket et/ou d'un autre plugin me semble t-il.

#35 Mis à jour par chan kalan il y a 3 mois

je reviens sur la troisième colonne avec une petite image, en mettant 50% sur le contenu et 23% pour chaque colonne, ça me paraît pas trop étroit... seulement pour 1200px et + ?

#36 Mis à jour par nico d_ il y a 3 mois

Oui, j'essaie de faire quelque chose comme ça, pour que la colonne #extra soit sous la #navigation en dessous d'une certaine largeur, et qu'elle passe à droite au delà.

Mais avec le markup c'est pas évident, que ce soit avec le body dist (qui fait un div séparé pour la colonne extra en écran large) ou le body du plugin qui le surcharge (qui supprime ce div).
Il va falloir jongler un peu (ou y coller un petit coup de js, pourquoi pas, c'est probablement le plus simple).

Mais si elle passe à droite au delà de 1200 et qu'on réduit le #contenu à 50%, comme sur ta capture, du coup il redevient beaucoup plus étroit :-/
Il faudrait calculer la largeur à partir de laquelle faire ce breakpoint :
#navigation 300px, #contenu 750px + 30px de marge gauche, #extra 300px + 30px de marge gauche -> breakpoint à 1410px environ ?
Ce serait donc plutôt pour des grands écrans (et là aussi, pour tout le monde sans tenir compte des préfs).

Qu'en pensez vous ?

#37 Mis à jour par RealET 🔸 il y a 3 mois

Bonjour,

Une remarque sur l'ajout des mots clefs : le label est trop court (nom des groupes) et pour des noms de groupes long, ça permet pas de les lire

#38 Mis à jour par tcharlss (*´_ゝ`) il y a 3 mois

Hop, j'ai pu tester un peu le remix (j'en ai profité pour piquer quelques trucs au passage ^^).

1ère impression très sympa avec la largeur augmentée, la police plus grande, et les autres détails.
Je ne vais commenter que ces 2 premiers points et le layout (ces 3 points étant liés), pour ne pas qu'on sorte du sujet du ticket.

(...) pour que la colonne #extra soit sous la #navigation en dessous d'une certaine largeur, et qu'elle passe à droite au delà

3 fois oui, comme ça le layout s'adapte à la largeur de l'écran. La colonne de droite peut avoir son utilité, c'est très bien qu'elle soit affichée quand il y a la place.
Dans le trunk c'est sur ça que je suis parti.

Toujours sur le layout, il y a un point qui me semble important, c'est qu'en absence de contenu dans une colonne, les autres doivent remplir l'espace libéré.
Par exemple sur la page des articles, où on a une grande marge vide à gauche actuellement.
Ça c'était la 2ème raison principale du plugin, et on a perdu ça dans le remix apparemment.
La difficulté, c'est qu'on ne peut pas poser de taille directement sur une colonne #navigation ou #extra, car elles sont toujours présentes même si elles sont vides. Et même à coup de flex-shrink puissance 10, c'est très compliqué d'avoir la main sur leur taille du coup.
J'ai contourné le problème en posant la largeur sur le contenu direct de ces colonnes , jusqu'à présent je n'ai pas constaté de dommage collatéral :

#navigation > .ajaxbloc > *,
#navigation > :not(.ajaxbloc),
#extra > .ajaxbloc > *,
#extra > :not(.ajaxbloc) {
      width: calc(8em + 12vw);
}

La taille de police augmentée, très bien, c'est plus lisible et agréable.
Je pense qu'elle pourrait être un brin responsive, c'est à dire partir d'une base un peu moins grande et augmenter proportionnellement à la largeur de l'écran.
Dans le trunk je teste cette règle qui donne 14px à la base, et 15px en 1920px par ex. : font-size: calc(0.8em + 0.133vw);
Un dommage collatéral quand même : on perd un peu de la place libérée avec la nouvelle largeur, mais c'est un mal nécessaire.

Et donc j'en viens au truc principal : la largeur.
Bon, si on part sur du 1200px, ce sera déjà une bonne avancée, je ne vais pas me plaindre. Allez, tant qu'à faire on peut pousser vers ~1400px ?

Mais d'une façon générale, je reste persuadé qu'à terme, la pleine largeur est la meilleure option pour une interface (et là je peux reprendre la citation de Coluche à mon compte si j'ai bien compris ?).
C'est du coup un peu plus compliqué que de mettre un witdh: 100% au conteneur général d'un coup de baguette magique, en fait il y a finalement pas mal de choses concomitantes à régler (plus que ce que j'imaginais à la base).
Notamment la taille de la police, en augmentant comme dans le remix de nicod_, c'est déjà beaucoup plus équilibré.
Après d'une façon générale, il faut que cette largeur soit bien exploitée. Là on part d'une interface où les contenus ont été pensés pour rentrer dans du 780px de large, donc forcément au départ il y aurait des choses un peu bancales, quelques pages déséquilibrées. Mais dans l'ensemble je suis sûr qu'on y gagnerait à terme et ça poserait les bases pour la suite.

Enfin, il y a un point que je veux souligner, parceque je ne suis pas du tout d'accord avec certaines remarques : la proposition de pleine largeur n'est pas une préférence esthétique, c'est un besoin imposé par le contenu.
C'est ça la demande à la base pour ce ticket, le but est de parvenir à « faire rentrer » du contenu qu'il est difficile de placer actuellement.
Ne pas en avoir « l'utilité » personnellement certes, mais il y a tout un écosystème de plugins avec des besoins divers pour lesquels ça devient nécessaire.

#39 Mis à jour par RealET 🔸 il y a 3 mois

RealET ???? a écrit :

Bonjour,

Une remarque sur l'ajout des mots clefs : le label est trop court (nom des groupes) et pour des noms de groupes long, ça permet pas de les lire

Une tentative d'amélioration : https://zone.spip.org/trac/spip-zone/changeset/110815

#40 Mis à jour par RastaPopoulos ♥ il y a 3 mois

+1 donc, le but de la demande de départ, c'est vraiment d'avoir la place nécessaire à plein de choses dans la partie contenu. Pas d'augmenter la lisibilité, ce qui est très bien aussi hein et totalement nécessaire, mais ce n'est pas l'objet du ticket. Si on augmente seulement légèrement la largeur, et qu'on augmente la taille du texte (ce qui est bien encore une fois), au final en terme de proportions, on aura pas gagné énormément de place pour y loger des contenus plus larges[*]. Alors oui, il y a plus de choses à caler pour garder un texte lisible et des formulaires pas absurdement grands ou trop petits.

Le but est d'arriver
- à ce que le contenu de base d'un CMS soit bien proportionné (relecture de texte et édition de formulaires)
- tout en permettant sans bidouille d'avoir de l'espace quand on en a besoin. Et cela y compris pas sur ses propres pages qu'on controle à 100% mais quand on insère des blocs dans des pages existantes.

[*] Tableaux avec plus de colonnes, liste de vignettes avec plus que 3-4 par lignes, afficher des images plus grandes tout en ayant du texte à côté, avoir une colonne de facettes/filtrage tout en ayant encore beaucoup de largeur pour le contenu qui liste les résultats, etc… on peut en trouver un paquet des choses qui ont besoin de largeur [**]

[**] Cela dit, c'est "quand c'est possible", car dans tous les cas il faut aussi prévoir comment ces contenus vont s'afficher en petit écran. Par exemple si on a un tableau d'objet avec 10 colonnes, comment on affiche ça responsivement.

#41 Mis à jour par guytarr ° il y a 3 mois

nico d_ a écrit :

Flute, nos réponses se sont croisées et j'ai du cocher la mauvaise case sur les changements...

Mais bon, pourquoi 3.4 ? La css de tcharlss est toute prête, y'a juste à l'intégrer.

Je l'utilise en prod sur plusieurs sites (modulo la largeur à 100%, qui pourrait être en config).

Trop d'espaces inutilisés en full hd, j'imagine même pas sur un 4k :p

#42 Mis à jour par chan kalan il y a 3 mois

Jusque là on avait une option "grand écran" qui utilisait la colonne droite. C'est un comportement qu'on peut avoir sans option, juste si on a un écran assez large.
Et finalement on pourrait utiliser l'option pour présenter un affichage 100% lorsqu'on en a besoin... parce qu'il me semble pas que ce soit courant... ?

#43 Mis à jour par nico d_ il y a 3 mois

Je pense que l'idée de tcharlss à la base, de court-circuiter l'option petit/grand écran, est très bonne.
Ça date d'une époque ou certains écrans étaient encore rikiki, et où le responsive était une utopie.
Et ça permet de se concentrer sur un seul jeu de css, un seul layout.
Donc +1 pour garder ce principe.

L'affichage à 100%, ce serait sûrement l'idéal, pour les raisons évoquées, mais pour ça il y a pas mal de choses à revoir.
C'est pour ça que j'ai fait ce remix, qui est un premier compromis, et plus facile à gérer, forcément.
Mais ça m'intéresse de continuer à creuser, je vais peut être repartir de ta dernière version du trunk pour tester d'autres trucs sur une base 100%.

Ralala, si on faisait ça sur git, pouvoir faire des branches et merger des idées...

#44 Mis à jour par nico d_ il y a 3 mois

J'ai fait une simple surcharge css de la dernière version de l'Espace privé fluide dans une nouvelle branche.
Ce sera donc plus facile à intégrer au cas où les idées soient retenues.

Ça donne donc un nouveau plugin, Espace privé fluide ++ (mais où vais je chercher ces noms ?).
À activer, en plus de Espace privé fluide 0.1.10 (il le nécessite de toute façon).

C'est un travail sur les formulaires : tous les champs passent sur deux colonnes, label à gauche et champ à droite, y compris dans les champs de textes, .editer_parent, tout ça...
Ça donne plus de cohérence aux pages comme l'édition d'un article, qui ont des layouts farfelus.
Les champs de saisie ont aussi une longueur maxi, parce que 100% c'est vraiment trop.

En dessous de 980px, tous les champs repassent sur une seule colonne : label sur une ligne, champ en dessous.

Cf captures écran.

https://zone.spip.org/trac/spip-zone/changeset/110829/spip-zone

#45 Mis à jour par nico d_ il y a 3 mois

Et je dois dire, tcharlss, que ta gestion du layout est impeccable dans cette dernière version, avec la colonne de droite qui se positionne comme il faut.
On tient peut être quelque chose de bien là...

#46 Mis à jour par chan kalan il y a 3 mois

C'est déjà beaucoup mieux avec la troisième colonne, mais je reste pas trop emballé par toutes les page avec le contenu très large, comme avant... même si le fait de tout grossir et de répartir les vides, ça fait un peu moins dispersion...
En tout cas je trouve déjà mieux que l'espace fixe actuel.
Merci pour tous vos tests, tcharlss et nicod ((o: !

Juste un p'tit problème dans la config des urls, cf doc joint...

#47 Mis à jour par tcharlss (*´_ゝ`) il y a 3 mois

Bien vu pour les formulaires nicod_, ça fonctionne finalement beaucoup mieux comme ça avec les champs de même taille.
Les labels pourraient peut-être être légèrement aggrandis quand ils sont sur la même ligne que le champ ?

J'admets que certaines pages ne sont pas très heureuses en pleine largeur, là, tout de suite. Par exemple la page des articles qui ne contient qu'un tableau avec 4 colonnes... Mais c'est typiquement une page où il faudrait des facettes sur le côté (cf. plugin ajaxfiltres).

En tout cas, même si ce n'est pas une solution retenue, merci pour le temps pris pour explorer la piste :)

Formats disponibles : Atom PDF