S'identifier - S'inscrire - Ecrire un article - Contact

Standardisation des noms des blocs des modèles

Par Stephane • Echanges • Jeudi 04/10/2007 • 20 commentaires  • Lu 4267 fois • Version imprimable

Mots-clés : ,


Afin de permettre un passage plus aisé d'un modèle de mise en page à un autre, je vais standardiser le nom des différents blocs. Celà permettra de garder ses choix de blocs lorsqu'on change de modèle. Plus besoin de passer 10 minutes à re-remplir le formulaire de choix des blocs à chaque fois qu'on veut essayer un nouveau modèle.

Voici une proposition de noms de blocs, qui je pense convient bien à tous les modèles existants, et permettra de futures extensions :

  • sb.menu : bloc du menu
  • sb.col.left.1 : 1er bloc de la colonne la plus à gauche
  • sb.col.left.2 : 2ème bloc... (etc.)
  • sb.col.right.1 : 1er bloc de la colonne la plus à droite (etc.)
  • sb.main.top.1 : bloc central au dessus des articles (etc.)
  • sb.main.bottom.1 : bloc central en dessous des articles

Ceci sans limitation de nombre : chaque utilisateur pourra mettre autant de blocs au dessus ou en dessous des articles par exemple.

A noter que les noms correspondent plus à un "concept" qu'à une localisation géographique. Par exemple, les deux colonnes peuvent être à gauche des articles. Et elles pourraient même être au dessus et en dessous des articles, avec les blocs en ordre horizontal plutôt que vertical.

Une nouveauté que j'ai déjà mis en place : les macros sont maintenant executées en cascade. Ainsi, au début du bloc sb.col.left.1 par exemple, la macro sb.col.left.1_start va être appelée. Mais si elle n'existe pas, sb.col.left_start sera appelée, et ainsi de suite jusqu'à sb_start.

La chronologie que je pense suivre :

  1. définir une commande "pragma" spéciale dans les modèles qui indique que le modèle utilise les blocs standard
  2. adapter le menu choix des blocs pour qu'il soit possible de changer les blocs standards
  3. pré-peupler les blocs standards en utilisant le choix des blocs du modèle courant de chaque blog
  4. transformer les modèles publics pour qu'ils utilisent les blocs standards
  5. indiquer aux utilisateurs de modèles personnels comment adapter leur modèle pour qu'il utilise les blocs standards
  6. créer un nouveau menu choix des blocs "visuel" (et optionnel) pour les blocs standards

Je pense que je devrais pouvoir me débrouiller pour garder toute la compatibilité avec l'existant.

Questions, commentaires ou suggestions ?

D'autres articles sur des thèmes similaires :


Commentaires

Quelques remarques par labosonic le Jeudi 04/10/2007 à 07:49

A noter que les noms correspondent plus à un "concept" qu'à une localisation géographique.
Oui mais ça ne va pas forcément être aisé à comprendre et faire comprendre aux utilisateurs ...
Je vais prendre l'exemple d'un blog que j'aime bien : je ne suis pas sur que je puisse refaire un truc du même type avec ce système.
Il fonctionne en 4 bandeaux horizontaux :

  • Une image de titre et des onglets (sb_menu, je présume ?)
  • 6 blocs libres (sb_main_top 1 à 6 placés en horizontal)
  • 3 colonnes (sb_left, sb main, sb_right horizontaux)
  • un footer à base de sb_main_bottom
A priori (et à condition qu'on puisse placer le sb_menu où on le veuille), c'est possible à faire mais ça ne sera pas évident de saisir immédiatement que ça l'est.
De la même manière, j'aimerais que tu nous dise quel type de bloc irait où sur un modèle comme Pitr, où il y a des blocs qui sont sur ce qui est ensuite deux colonnes, est ce que cela empêche d'avoir des sb.bottom ou des sb.top ailleurs ?

3 colonnes uniquement, ça me paraît peu ...

Supposons que je souhaites mettre le bloc de navigation de lasso (celui sur fond rose en haut à droite) dans une colonne dédiée (de largeur minime <50 pixels et statique, qui ne défile pas avec l'ascenseur de ma page), typiquement pour faire un photo-blog qui se feuilleterait latéralement. Ca veut dire que je ne peux pas avoir  deux colonnes à droite de ma photo  ?

Les macros sont maintenant éxécutées en cascade.
Ce qui signifie si je ne trompe qu'on peut choisir ou non de mettre un titre à un bloc ? En laissant le sb_title global vierge et en déclarant des sb_title locaux, j'ai bon ?

Définir une commande "pragma" spéciale dans les modèles qui indique que le modèle utilise les blocs standard
Les blocs standards sont-ils uniquement ceux que tu as listé ? Si oui, aucun problème pour moi. Si, non, mouais, j'ai jamais été très convaincu par le bloc standardisé que tu as fait pour le menu admin (donc je m'en suis fait un dans lequel, j'ai mis des icônes et des liens en plus qui ne me servent rien qu'à moi ) et je ne serais pas particulièrement heureux de devoir le récupérer à cette occasion.

Je pense que je devrais pouvoir me débrouiller pour garder toute la compatibilité avec l'existant.
Euh, oui, c'est la moindre des choses, non ?


Re: Quelques remarques par Stephane le Jeudi 04/10/2007 à 10:15

Stephane  

A noter que les noms correspondent plus à un "concept" qu'à une localisation géographique.
Oui mais ça ne va pas forcément être aisé à comprendre et faire comprendre aux utilisateurs ...

Je pense qu'ils comprendront tout seul, visuellement, en voyant le résultat. On pourrait aussi mettre une ligne de commentaires dans le menu choix des blocs qui indique par exemple que sur ce modèle, les colonnes de blocs sont utilisées comme des lignes de blocs. Ou que le premier bloc de la colonne est positionné différement.

Pour Pitr, le plus simple est de mettre les blocs sb.main.top au dessus des deux colonnes au lieu d'au dessus des articles.

3 colonnes uniquement, ça me paraît peu ...
 
Une autre façon de voir les choses, c'est que tu as 2 colonnes de blocs (sb.col ) + 2 autres colonnes de blocs (sb.main) + 1 bloc de menu. Donc tu peux faire un blog avec 6 colonnes en comptant celle du contenu.

Je pense que ces 4 "listes de blocs" + 1 bloc sont suffisants pour la quasi-totalité des modèles. Si ce n'est pas suffisant, il y a toujours la possibilité de ne pas utiliser les blocs standards. Avantage : on peut faire n'importe quoi. Inconvénient : on ne profite pas des avantages des blocs standards comme le futur menu visuel de choix des blocs.

Les macros sont maintenant éxécutées en cascade.
Ce qui signifie si je ne trompe qu'on peut choisir ou non de mettre un titre à un bloc ? En laissant le sb_title global vierge et en déclarant des sb_title locaux, j'ai bon ?

Oui.


Définir une commande "pragma" spéciale dans les modèles qui indique que le modèle utilise les blocs standard
Les blocs standards sont-ils uniquement ceux que tu as listé ?

Oui. La liste de commandes "S'identifier, s'inscrire etc." n'est pas un bloc. A chaque modèle de voir si ça convient ou non.

 
Je pense que je devrais pouvoir me débrouiller pour garder toute la compatibilité avec l'existant.
Euh, oui, c'est la moindre des choses, non ?

Pas nécessairement. A chaque fois il faut regarder ce qu'on gagne, ce qu'on perd, et s'il y a moyen de ne rien perdre (ou presque) et tout gagner (ou presque). Il va sans dire que la compatiblité avec l'existant pèse beaucoup dans la balance. Un exemple c'est le nouvel éditeur visuel. On gagne beaucoup, mais on perd la compatibilité avec Safari.


Re: Quelques remarques par labosonic le Jeudi 04/10/2007 à 13:57

Sur le nombre de sb_main, sincèrement, je le trouve assez limité et un supplémentaire ne serait pas de trop.
Il me paraît assez évident qu'un des deux sb_main va plus presque systématiquement terminer en pied de page pour un footer de style 2.0 (avec d'autant plus de certitude que c'est une nouvelle fonctionnalité, qu'elle est à la mode et déjà présente sur de nombreux blogs) dès que ce sera possible.
Ca ne laisse plus qu'un autre sb_main et deux sb_col et c'est peut être un peu juste.

Typiquement, si je devais refaire le design de VdV avec une solution de ce type et un look proche de Pitr :
- Je mettrais les derniers commentaires et dernières discussion dans un gros footer en bas.
- un gros nuage de mot clé dans le sb_main au dessus des deux colonnes latérales.
- une colonne avec les derniers posts de chaque rubrique d'un coté.
- une colonne complète avec que des accès aux fonctions de recherche de l'autre (tables dynamiques et recherche "standard")
- un sb menu

Je conserverais le sb_main au dessus pour y laisser ce qu'il y a déjà (des descriptions bèves de chaque catégorie, éventuellement en le contextualisant plus selon la catégorie).

Et un sb_main, ne serait pas de trop ...

Ceci dit, je dis ça, je dis rien, j'aime pas les footers 2.0, moi, mais je pense que si c'est pas impossible mieux vaut directement implémenter un bloc de plus maintenant plutot que de devoir s'en occuper plus tard ...

Pas nécessairement. A chaque fois il faut regarder ce qu'on gagne, ce qu'on perd, et s'il y a moyen de ne rien perdre (ou presque) et tout gagner (ou presque). Il va sans dire que la compatiblité avec l'existant pèse beaucoup dans la balance. Un exemple c'est le nouvel éditeur visuel. On gagne beaucoup, mais on perd la compatibilité avec Safari.

:-S

J'ai un peu de mal avec ta comparaison et l'analogie avec l'éditeur visuel me paraît pas super bien adaptée. Le basculement d'éditeur visuel  permet effectivement un gain et une perte. Mais la perte est située au niveau des moyens (l'outil). L'utilisateur a la possibilité de s'activer en coulisses comme il peut sans que ça impacte son blog avant qu'il ne soit adapté à l'évolution.

L'équilibre de la balance pour ce problème est différent puisque la perte éventuelle est là liée au produit fini de l'utilisateur. La différence est quand même de taille.

Un blog où il est impossible de publier est un blog handicapant pour celui qui le tient et ceux qui y commentent. Un blog qui ne peut pas être lu, c'est autre chose, ça impacte beaucoup plus de monde (puisqu'il y a toujours plus de gens qui lisent un blog que de gens qui publient et commentent).

Ceci dit, c'est toi qui voit. Mais, en tant qu'utilisateur, tu utilises beaucoup de logiciels où, quand tu changes de version, tu ne peux pas réutiliser ce que tu as fait à la version n-1 ? Personnellement, je n'en utilise aucun (et j'ai même des produits Microsoft installés).


Re: Quelques remarques par Stephane le Jeudi 04/10/2007 à 14:11

Stephane Pour un troisième main, ça me dérange un peu, car je vois l'effet inverse : s'il y a un troisième main, celà peut inciter les auteurs des modèles à toujours afficher tous les blocs que peut choisir l'utilisateur. Et pareillement, les utilisateurs peuvent râler pour dire "j'ai choisi des blocs dans le troisieme main, ils ne s'affichent pas dans mon modèle machin, ils devraient s'afficher dans tous".
Un autre solution pour l'auteur des modèles pourrait etre d'afficher ce 3eme main comme un 2eme main. Mais bon...

> Ceci dit, c'est toi qui voit. Mais, en tant qu'utilisateur, tu utilises beaucoup de logiciels où, quand tu changes de version, tu ne peux pas réutiliser ce que tu as fait à la version n-1 ?

En fait ce n'est pas exactement ce que je voulais dire : il sera toujours possible de réutiliser la version n-1, mais il est possible que dans certains cas (qui ne sont jamais arrivés jusqu'à présent), cette réalisation nécessite une adaptation/conversion etc. Donc pour l'équilibre, il faut prendre en compte ce qu'on gagne, et aussi les éventuelles manipulations que certaines personnes utilisant certaines fonctions devraient faire avant de pouvoir faire cette réutilisation. Il va sans dire que je m'efforce toujours de minimiser les chances de telles situations. Mais si un jour une super avancée nécessite que tu ailles changer 2 lignes dans ton modèles personnel, ca vaut le coup de peser le pour et le contre (en sondant les utilisateurs par exemple).


Re: Quelques remarques par leblase le Jeudi 04/10/2007 à 16:21

leblase Labo,
je suis comme toi, je n'aime pas trop les footer (la vache, c'est la première fois que j'emploie le terme!) mais j'aime beaucoup que l'on voie l'apport des visiteurs.
Et donc

- Je mettrais les derniers commentaires et dernières discussion dans un gros footer en bas.
Je ne suis pas du tout d'accord avec çà: les commentaires devraient être mis en avant.
..."en tant qu'utilisateur, tu utilises beaucoup de logiciels où, quand tu changes de version, tu ne peux pas réutiliser ce que tu as fait à la version n-1 ? Personnellement, je n'en utilise aucun ...

Là, évidemment, je te suis!


Re: Quelques remarques par Jean-Luc le Jeudi 04/10/2007 à 17:22

Jean-Luc Je n'interviens pas parce que je ne comprends pas tout mais je suis solidaire avec ton point de vue, labo, et ce, sur toutes tes interventions concernant les modèles, qu'il s'agisse de l'amélioration de la css ou de la standardisation...


Re: Quelques remarques par Stephane le Jeudi 04/10/2007 à 17:42

Stephane Et si labo sautait à travers une fenêtre au dessus d'une cascade de styles, tu le suivrais ? ;)


Re: Quelques remarques par Jean-Luc le Jeudi 04/10/2007 à 19:01

Jean-Luc Non, mais je serais à ses côtés pour une impulsion conjuguée ou pour amortir sa réception...


par isabelle le Jeudi 04/10/2007 à 13:16

isabelle c'est un scoop, le bloc en dessous des articles ou j'ai loupé une marche ?


Re: par Stephane le Jeudi 04/10/2007 à 14:12

Stephane C'est une nouveauté qui a été présentée à la dernière réunion ViaBloga, mais tout le monde n'était pas hyper attentif. ;-)


Histoire de dire que j'ai peut être compris l'article ;-) par mitra le Jeudi 04/10/2007 à 15:12

"Une nouveauté que j'ai déjà mis en place : les macros sont maintenant executées en cascade. Ainsi, au début du bloc sb.col.left.1 par exemple, la macro sb.col.left.1_start va être appelée. Mais si elle n'existe pas, sb.col.left.2_start sera appelée, et ainsi de suite jusqu'à sb_start."

On dirait qu'il manque un petit 2 dans cette phrase ... à moins que je me trompe !


Re: Histoire de dire que j'ai peut être compris l'article ;-) par Stephane le Jeudi 04/10/2007 à 15:46

Stephane Tu te trompes ;-)

Enonce plus clair : lorsqu'une macro doit être interprétée, c'est toujours la plus spécifique qui gagne :

sb.col.left.1_start
sb.col.left_start
sb.col_start
sb_start

L'intérêt c'est que tu peux définir un format de bloc par défaut, mais décider que les blocs dans la colonne de gauche seront un peu différents.



Je reviens sur le points qui me chagrinent par labosonic le Lundi 08/10/2007 à 15:45

Sur le premier qui concerne le nombre de mains/colonnes, j'ai bien compris l'enjeu (Est-ce que le nécessaire pour une minorité ne va pas pénaliser l'admin car utilisé à mauvais par une majorité ?) mais je pense quand même qu'on devrait se poser la question.
Sur un blog comme celui-ci, honnêtement, je ne vois pas de solution avec la configuration que tu envisages. C'est vraiment mineur (1 sur les 45 du billet que tu avais signalé), certes, mais bon ...

Il est possible que dans certains cas (qui ne sont jamais arrivés jusqu'à présent), cette réalisation nécessite une adaptation/conversion etc.

Dans ce cas précis, en général, l'éditeur du logiciel fournit une moulinette, non ?
L'idée du sondage des utilisateurs me paraît pas top, vu l'endogamie de VdV.


Re: Je reviens sur le points qui me chagrinent par Stephane le Lundi 08/10/2007 à 15:54

Stephane > Sur un blog comme celui-ci,

Ben là, ce n'est pas des colonnes en plus qui vont arranger les choses, ça serait plutôt un attribut pour choisir la taille du bloc (100% ou 50% de la colonne). Et là tu aurais ensuite besoin d'une seule colonne, avec tous les blocs en float.


Re: Je reviens sur le points qui me chagrinent par labosonic le Mercredi 10/10/2007 à 17:23

C'est prévu ce genre d'attribut ?


Re: Je reviens sur le points qui me chagrinent par Stephane le Mercredi 10/10/2007 à 18:18

Stephane

Pas dans l'immédiat. Par contre c'est envisageable. Je propose de lancer une première version, et ensuite de voir quelles sont toutes les améliorations que l'on pourrait mettre en oeuvre.


Où en est-on dans cette chronologie ? par Jean-Luc le Lundi 17/12/2007 à 23:12

Jean-Luc

Le nouveau menu blocs Code HTML (qui remplace le menu blocs libres) ne s'applique pas aux modèles personnalisés : doit-on patienter encore ou comment procéder ?

De tous les modèles publics que j'ai testés, je n'en ai trouvé aucun qui permette l'ajout d'un bloc Code HTML comme indiqué par ailleurs :

est-ce que quelque chose m'a (encore) échappé ?


Re: Où en est-on dans cette chronologie ? par Stephane le Lundi 17/12/2007 à 23:19

Stephane Je ne l'ai pas encore mis sur le serveur spécial qui héberge les influenceurs.


Re: Où en est-on dans cette chronologie ? par Jean-Luc le Lundi 17/12/2007 à 23:34

Jean-Luc Un serveur spécial ? Ouah, je suis impressionné !

Cela dit, les tests que j'évoque ont été effectués sur des sites tout a fait "anodins". Je viens même de vérifier sur un site juste créé il y a une semaine et là je n'ai pas de blocs du tout et aucun moyen (accessible par moi) d'en créer : comment je fais ?


Re: Où en est-on dans cette chronologie ? par Stephane le Mardi 18/12/2007 à 00:55

Stephane Ah, j'avais changé un truc, c'est corrigé.



Session

Pour participer plus facilement, ouvrez une session :

Identifiant de
mon blog
Nom d'utilisateur
Mot de passe

Si vous avez déjà un blog sur ViaBloga ou si vous avez ouvert un compte sur l'un d'entre eux, vous pouvez vous identifier avec votre nom d'utilisateur et mot de passe en précisant d'abord l'identifiant de votre blog.

S'inscrire

Discussions actives (+ commentaire)


Archives par mois