ArborescenceDeSpipContrib

Arborescence ??

L’idée est de proposer une nouvelle arborescence pour spip-contrib .

Le but de spip-contrib est de prolonger le site officiel de SPIP, par la présence de squelettes en .php, de nouveaux filtres ou fonctions, de trucs et astuces, de nouvelles fonctionnalités (comme spikini, le forum, la restriction d’accés, ...), mais aussi de proposer des évolutions potentielles de SPIP (des fonctions ou des filtres qui seraient incluses dans les versions futures de SPIP), ou des Squelettes.

Il peut aussi servir, via le wiki, à préparer les futures docs sur certaines fonctionnalités, comme le mulitlinguisme.

Les contribs sont classées en fonction en différents mots-clés : compatibilités, licence (qu’on va laisser de côté), public.

cent20 : Arborescence v2 :

Idées simples :

-   Pas arborescence profonde (trois niveaux uniquement). Les deux premiers structurent, le troisième est composé de « bidouilles », « non validé par les administrateurs », « archives » etc … Comme ça on ne refuse pas de contenu, et au terme du processus de validation, si l’auteur n’a pas tenu compte de nos remarques, on publie dans « non validé » et voilà.
-   Pas de segmentation / sans php / avec php / plugin / spip ++ /, car on risque de ce retrouve avec les mêmes sous arborescences dans chacun des dossiers.
-   Autonomie des squelettes suivis, dans un dossier avec des droits admin pour le créateur
-   Bouclothèque, une collection de boucle extrêmement simple, en complément de la doc officielle, pour les grands débutants.

  • 01. Fonctionnement et actualité de SPIP-CONTRIB
  • 05. Tutoriels
    • 30. Bouclothèques
      • Boucles ARTICLES
      • Boucles RUBRIQUES
      • Boucles BREVES
      • Boucles AUTEURS
      • Boucles FORUMS
      • Boucles MOTS
      • Boucles DOCUMENTS
      • Boucles SITES
      • Boucles SYNDIC_ARTICLES
      • Boucles SIGNATURES
      • Boucles HIERARCHIE
      • BOUCLES imbriquées
      • Boucles sur d’autres tables de la base de donnée.
  • 10. Jeux de squelettes
    • 1re publication (contient les premières publications d’un squelette, si le créateur veut le faire évoluer, alors on lui créé une rubrique sur laquelle il est admin)
    • Une rubrique par squelette qui est maintenue par son créateur, le créateur étant admin sur sa rubrique. On responsabilise le créateur du squelette, il assure la doc, le suivi, les évolutions et n’est pas dépendant des admins.
    •  
  • 20. Outils webmestre
    • Inclassable
    • Audio ( à chaque fois, on aurait trois sous rubriques)
      • Non validés par les admins
      • Archives
      • Bidouilles
    • Authentification
    • Calendriers
    • Dates
    • Email
    • Formulaires
    • Images
    • Liens
    • Galeries
    • Migration
    • Navigation
    • Mise en page
    • Pagination
    • Réécriture d’urls
    • Statistiques
    • syndications
    • typographie
    • Un forum avec SPIP
    • Un wiki avec SPIP
    • Un agrégateur RSS avec SPIP

Multilingue ?

De plus, l’état actuel du multilinguisme devrait éventuellement permettre de s’affranchir des secteurs par langue (via l’utilisation des champs <multi>).

La question du multilinguisme a été soulevé pendant la contrib-night : Comment présenter les articles sans les séparer dans des secteurs par langue ? Le problème étant que toutes les contribs ne sont pas traduites. Si l’on sépare par secteur, alors un espagnol verra très peu de chose (le site aura l’air assez mort) et un français passera aisément devant une contrib intéressante dans une langue qu’il connaît à peut prêt.

La suggestion est de garder 1 seule arborescence (plus simple à gérer en plus) et de s’adapter à la langue de l’utilisateur. Plusieurs vues s’opposent :
-  mélanger les langues : on affiche le plus possible dans la langue de l’utilisateur, mais si les articles ne sont pas traduit, on les affiches dans une langue par défaut (voir un exemple et la contrib),
-  ne pas mélanger les langues directement, voir ici l’exemple :
Remarques de JMB : Je suis pour le mélange des langues... mais en ne déroutant pas le visiteur qui doit voir d’abord les articles dans la langue qu’il a choisie et, ensuite, avoir une vision de ce que d’autres langues peuvent proposer. Mais le site RAforum ne contient pas d’article traduit (sur les 1200 articles présents) : donc, sur un thème donné, on gagne à lire plusieurs langues ;-)))
J’ai décrit cela ici.

on vote ?

pour ma part (goetsu) je ne suis pas d’avis de mélanger les langues pour aller vers la simplicité. Si à l’heure actuelle il est vrai qu’ il n’y a pas trop de contrib en langue étrangère, elle sont amenées à se développer et cela fera trop de contenu à afficher quand ce sera le cas.
Donc dans un premier temps je renverrais par defaut sur la page française sur laquelle il y a un sélecteur de langue. Si la personne change on pose un cookie. Lorsqu’il y aura sufisament de contrib en langue étrangère on fait comme sur spip.net un écran de sélection au départ avec pose du cookie.
De plus puisque l’on a une seul arbo rien n’empeche de faire des liens directe du genre voir cette rubrique en anglais ou consultez les articles en anglais de cette rubrique, bref des liens sans repasser par la page d’accueil

(Mortimer) ben si tu regardes la proposition 1 pour les langues mélangées, il n’y a pas plus d’information à l’ecran. Si l’utilisateur est anglais il voit :
-  Comment passer son site en utf-8
-  Du joli code dans les articles
-  A form to write to the author. An anti-spam solution.
-  afficher une liste d’articles adaptée à la langue de l’utilisateur
-  Une arborescence dynamique et contextuelle (le retour)

alors qu’un français verra :
-  Comment passer son site en utf-8
-  Du joli code dans les articles
-  Formulaire d’écriture à l’auteur. Une solution anti-spam
-  afficher une liste d’articles adaptée à la langue de l’utilisateur
-  Une arborescence dynamique et contextuelle (le retour)

Seul, l’article traduit (le 3e) est affiché en anglais et le reste est dans la langue par défaut du site (on suppose que les gens qui viennent sur le site, ne sont pas outré de voir une liste d’articles en français).
voir cette contribution.

(goetsu) oui ok mais si on ne gère que des traductions, mais pour la création le problème reste le même et multiplie le contenu présent sur la page ex : si j’ai 2 articles écrit uniquement en anglais
-  Comment passer son site en utf-8
-  Du joli code dans les articles
-  A form to write to the author. An anti-spam solution.
-  afficher une liste d’articles adaptée à la langue de l’utilisateur
-  Une arborescence dynamique et contextuelle (le retour)
-  the show must go on 1
-  the show must go on 2

alors qu’un français verra :
-  Comment passer son site en utf-8
-  Du joli code dans les articles
-  Formulaire d’écriture à l’auteur. Une solution anti-spam
-  afficher une liste d’articles adaptée à la langue de l’utilisateur
-  Une arborescence dynamique et contextuelle (le retour)
-  the show must go on 1
-  the show must go on 2

donc on a bien plus de contenu affiché maintenant si on ne fait que gérer des traductions : ok. Même si pour moi le pauvre utilisateur anglais qui se retrouve avec 1 article en anglais parmis 10 en français il doit etre un peu paumé.

(Mortimer) Bon évidemment, on ajoute du contenu, mais c’est peu être le but : pouvoir découvrir des contribs dans une langue que l’on comprend, mais pour laquelle on n’aura peut être pas le reflex de changer la langue du site (et de se perdre dans un site totalement dans une autre langue).

Evidemment, si on met une langue exotique (que peut de gens lise autour du monde) comme langue par défaut, ça intéressera personne. Si par contre, on fait l’hypothèse que les lecteurs de la page lisent l’anglais (par exemple) en majorité, en plus de leur langue (pour spip-contrib, ça pourrait être le français vue que la majorité des articles sont dans cette langue).

J’imagine qu’en fin de compte, il faudrait fournir plus de choix au lecteur : donner une liste de langue qu’il voudrait/peut lire. ça serait vachement compliqué (pour l’utilisateur, qui veut aller directement à l’information => il faut lui imposer quelque chose à un moment, c’est le choix éditorial) et pas facile à implémenter avec le spip actuel.

On pourrait ainsi afficher la liste d’article dans sa langue maternelle, avec sur le côté une liste d’article dans les autres langues liés au contexte actuel : un peu comme le propose JMB. Mais bon, le problème est vraiment de limiter la quantité d’information affichée.

En résumé, je pense qu’il ne faut pas cloisonner les gens dans leur langue, parce qu’ils pourraient passer à côté de contribs qui les intéressent et qu’ils sont capable de lire (sur internet, les barrières linguistiques sont vraiment plus fines).


Idées

-  Bonne idee de vincent

  • concours de squelette , cela permet de ne pas avoir a trancher si c’est personnel ou professionel ;-) Tiens on en profite pour tester les sondages de Nicolas et l’integrer dans la distrib officielle ( Fil ? ;-) )
  • (goetsu) euh c’est pas moi qui m’occupe des squelettes ?

-  idee de Nicolas

  • envoyer les annonces sur spip-dev.

Proposition No 3, Karim

Grandes zones racine. EN GROS

1) - MES_FONCTIONS 2) - SQUELETTES 3) - ANNEXES 4) - DOCUMENTATIONS 5) - FORUM 6) - TEMOIGNAGES

Zones racines EN DÉTAILS

1) - MES_FONCTIONS
— 1.a) - Mes_fonctions c’est quoi ? Explications sur mes_fonctions, son rôle et ses usages Petit cour rapide pour créer soit même ses fonctions
— 1.b) - Mes_fonctions contributions Scripts mes_fonctions prêt à l’emploi

2) - SQUELETTES
— 2.a) HTML standard Aide à la conception de son site avec des balises HTML
— 2.b) CSS standard Aide à la conception de son site avec des feuilles de style CSS
— 2.c) La caverne aux boucles
— 2.d) - Les squelettes contributions Squelette prêt à l’emploi

3) - ANNEXES
— 3.a) A tester
— 3.b) SPIP spécifiques
— 3.c) Divers (ou Inclassables)
— 3.d) Outils rédacteurs
— 3.e) Outils webmasters

4) - DOCUMENTATIONS
— 4.a) idem celle qui existe actuellement +

5) - FORUM
— 5.a) mes_fonctions
— 5.b) squelette
— 5.c) annexe

6) - TEMOIGNAGES
— 6.a) utilisateur site perso
— 6.b) utilisateur site professionnelle
— 6.c) interview

Des remarques de filifab

1) - MES_FONCTIONS - 1.a) - Mes_fonctions c’est quoi ? Explications sur mes_fonctions, son rôle et ses usages Petit cour rapide pour créer soit même ses fonctions

Bonne idée mais je me demande si ce petit cours n’aurait pas plus sa place dans la doc sur spip.org

2) - SQUELETTES - 2.a) HTML standard Aide à la conception de son site avec des balises HTML - 2.b) CSS standard Aide à la conception de son site avec des feuilles de style CSS

Je suis pas sûr que l’on pourra arriver à les classer strictement.

-2.c) La caverne aux boucles

Très bonne idée de les mettre dans cette rubrique.

remarques de Ben

2.d) - Les squelettes contributions Squelette prêt à l’emploi

euh ?

3) - ANNEXES

Un peu trop générique comme nom et cela fait un peu fourre-tout.

5) - FORUM - 5.a) mes_fonctions - 5.b) squelette - 5.c) annexe

6) - TEMOIGNAGES - 6.a) utilisateur site perso - 6.b) utilisateur site professionnelle - 6.c) interviews

Je suis pas sûr de bien saisir ce que tu veux mettre précisement pour certaines des sous-rubriques dans ces deux rubriques.

remarques de Mortimer

certaines rubriques ont plutôt l’air d’article. e.g : « Mes_fonctions c’est quoi ? Explications sur mes_fonctions, son rôle et ses usages Petit cour rapide pour créer soit même ses fonctions »


Proposition No 2 (mortimer)

Il faut vraiment que l’on puisse naviguer en fonctions du public (filtrer en fonction du mot clef par exemple), pour que ce soit plus utilisable par tous : maintenant, l’expert se trouve perdu dans les divers menus déroulant et joujou graphique, alors que l’utilisateur lambda se sentira un peu agressé par du code php alors qu’il cherche une simple boucle.

L’idée principale de cette arbo est de diviser chacun des secteurs (FAQ, Boucles, etc...) en rubrique correspondant au niveau de complexité de la contrib. (je sais, c’est redondant avec les mots clefs. Je pense que c’est nécessaire pour accéder vite tans qu’il y a pas une meilleure interface transversale)

JMB pointe vers l’interface transversale de raforum.

Par exemple : une boucle, à la base, c’est pour afficher une liste d’article, de rubrique, etc...
-  Alors apres les contribs, ça peut être du code javascript, du css => juste de la mise en page pour faire divers sorte de menu, onglet etc...
-  mais il y a des gens qui veulent utiliser les forums comme chat room (article sans texte), les articles comme galeries photos, etc...
c’est des boucles bien plus complexes qui « détournent » le but principal de la boucle.
-  ensuite il y a les boucles « dopées » au php. Toutes les boucles vraiment complexes qui font des choses plutôt exotique que l’on ne peut pas faire sans passer par le php (pas du tout prévues dans les features spip). Par exemple : mélanger les articles de toutes les langues.

Un exemple plus simple à comprendre : La FAQ qui est basée sur les NG. Il y en a une basée sur le NG de dev et une sur celui user.

-  accueil

  • Comment fonctionne spip-contrib
  • écrire une contribution
  • FAQ (tirée des diverses ng)
    • user
    • dev
  • Boucles
    • mise en page (par exemple pagination, menu déroulant, etc...)
    • exotisme (utilisation détourné des mots clefs, article à durée limité, etc...)
    • dopage php (toutes les boucles « dopées » au php. Toutes les boucles un peu complexes qui font des choses vraiment exotique.
      que l’on ne peut pas faire sans passer par le php)
  • Fonctions
    • Filtres
    • mes_options.php3 (divers filtres typos ajoutés : latex, code beautifier, etc...)
  • Extention des fonctionnalités de SPIP
    • Documentation SPIP vs PHPBB
    • Documentation Spikini
  • Squelettes (ici ça serait cool un filtrage sur la version spip, le mutilinguisme, etc...)
  • Divers (j’avais oublié. ça me plaît pas trop dans le sens où si les rédacteurs sont pas bien disciplinés, tout va finir ici. Mais il y aura bien des contribs qui iront pas autre part.
  • Modifications du noyau
  • Fonctionnalités cherche dev. (pour les utilisateurs qui y connaissent rien et ne trouvent pas ce qu’ils veulent. Peut être ils trouveront un développer gentil.) (mais ça pourrait faire partie du wiki)

Je pense qu’il faut que ce soit vraiment très hiérarchisé avec des système de filtrage sur les mots clefs. Ce qui implique de trouvé des mots clefs spécifique pour chaque partie du site, en plus de la compatibilité et le public. exemple :

-  Boucles

  • article
  • forum
  • ...

-  squelette

  • multilingue
  • blog, editorial, etc...
  • clefs en main
  • compatible navigateurs exotiques

Et surtout que les descriptions des rubriques soient vraiment explicites sur ce que l’on doit et ne doit pas mettre dedans. Actuellement, à chaque contribution que je fais, je ne sais pas trop où la poser, si le redacteur est pas sûr, alors le lecteur ne peux être que perdu.
[Dadoo] Il faudrait plutôt prendre un max de place sur la home pour détailler les « rubriques » et ainsi expliciter comment chercher l’info.


Proposition N°1

Cette proposition ne concerne que la section français de spip-contrib, puisqu’on suppose que les autres langues auront la même organisation.

Les mots en gras sont des articles à écrire

accueil
Comment fonctionne spip-contrib
écrire une contribution
-  Fonctions
-  Filtres
-  Extention des fonctionnalités de SPIP
- Documentation SPIP vs PHPBB
- Documentation Spikini
-  Boucles avancées
-  Divers
-  Squelettes
-  Distributions spécifiques
-  Modifications du noyau (a vos risques et périls, ces modifications seront perdues lors des mises à jours de spip)
-  proposition de nouvelle rubrique : « Us et coutumes » (j’aime pas mon titre mais j’ai pas trouvé mieux) une rubrique contenant des contrendus de d’utilisation spécifique de contrib. Permet de faire le lien entre des choix d’organisation interne (des rubriques, et des mot-clef), de spip-contributions et de structure de site. Pour une orientation dans tout le choix de contribution tenant compte des usages (noe de naama).

La bouclothèque, la FAQ, certaines documentations (paramétrer mes_options, etc.) sont ramenées dans spip.net. La section chantier est ammenée dans Spikini.

Une navigation par mots-clés (compatibilités et public) est proposée.

Annexe 1 : L’arbo actuelle


-  Arabe

-  English

  • FAQ
  • Specific SPIP releases

-  Español

  • Esqueletos
  • Distribuciones específicas de SPIP
  • La caverna de los bucles

-  Français

  • A tester
  • Chantiers
    • Documentation Spip VS phpBB
  • Distributions SPIP spécifiques
  • Divers
  • Documentation
    • Supports à télécharger
  • FAQ - Les questions fréquentes
  • Filtres : mes_fonctions
  • La caverne aux boucles
    • Bouclothèque
  • Outils rédacteurs
  • Outils webmasters
  • Squelettes

-  Rubrique interne (articles publiés en interne)

Annexe 2 : discussion lors de la première spip-contrib Night, cela peut donner des idées

<fil-rezo-net> Je ne comprends pas l'histoire des validations internes, au fai
<fil-rezo-net> si c'est validé en interne, c'est invisible ?
<filifab> juste histoire de dire qu'on fout pas à la poubelle et que cela peut servir...
<fil-rezo-net> Ca me parait bancal, conceptuellement
<fil-rezo-net> On pourrait imaginer un secteur "périlleux", "à vos risques et périls"
<fil-rezo-net> avec des gros warning partout
<filifab> vi c'est le texte de la rubrique 
<fil-rezo-net> mais de là à ne pas les afficher, et à obliger les gens à venir dans l'espace privé (où il n'y a pasd de moteur de recherche...)
<fil-rezo-net> m'enfin...
<Ben_Spip> oui mais les mettre sur la partie publique cela officialise un peu non ? 
<Ben_Spip> un peu trop ...
<Ben_Spip> ou alors il faut vraiment mettre de gros GROS warning
<filifab> au début c"était pas l'esprit de cette rubrique, juste l'"idée de pas mettre à la poubelle, cela a pas mal dévié
<filifab> on est ouvert aux propostions
<Ben_Spip> allez un peu d'histoire : au début on refusais ... et puis un jour le "troll" (son nom m'echappe) de spipage avais mis son grain de sel et je m'étais dit : il a raison, c'est bete après tout si quelqu'un assume de patcher spip autant qu'il profite de cette contrib 
<Ben_Spip> Mais il ne fallait pas inciter les novices à utiliser de telles contribs ... donc on a créé une rubrique spéciale
<Ben_Spip> voilou
<filifab> ah vi le fameux troll, maintemant je me rappelle pourquoi j'ai mis un tel texte pour le descriptif de la rubrique
<fil-rezo-net> je pense que l'idée de ne pas publier de patches est bonne dans le principe ; mais en même temps les modifs du noyau permettent aux gens de se familiariser avec le code, donc éventuellement de proposer par la suite des modifs plus intéressantes pour le noyau -- donc...
<fil-rezo-net> c'est une question d'inviter les gens à entrer dans le code s'ils ont envie
<fil-rezo-net> mais d'éviter que ça devienne la manière standard de tordre spip à ses besoins alors qu'il existe très souvent des manières plus propres de faire
<fil-rezo-net> bref... encore une histoire de doc
<fil-rezo-net> et de support
<filifab> hum va se reposer le super débat : qu'est-ce que l'on publie en public ou pas
<filifab> ça va troller un max
<Ben_Spip> bin on publies presque tout dans ce cas là ... si cela à été testé avec succès . 
<fil-rezo-net> oui, par contre il faudrait remettre les mots-clés "cool" etc. "Vous aimez..." / "On aime..."
<fil-rezo-net> actuellement il n'y a plus que "Vous aimez"
<Ben_Spip> "On aime" je l'ai viré du squelette car il n'était pas utilisé ... facile à remettre
<filifab> moi j'ai jamais compris ce que se cache derrière "on aime" et compagnie
<goetsu> le probleme avec sa c'est qu'on a souvent des redondence en plus
<Ben_Spip> bah on aime : les admins (qui peuvent mettre le mot clé on aime ) aiment cette contrib
<goetsu> entre les vous aimez, on aime, le plus constulé etc
<fil-rezo-net> oui, mais par exemple il y a des contribs importantes mais qui n'apparaiisent plus à la une
<fil-rezo-net> là faut "aimer"
<fil-rezo-net> :)
<goetsu> mais moi je comprend pas parcque il y a pas que des contrib qui modifi le source de spip dans la rubrique interne
<goetsu> cf: la contrib passer spip en xhtml qui est juste un filtre
<filifab> Fil comme tu es lancé, tu vas nous faire une jolie étude sémantique sur "on aime"
<fil-rezo-net> un site d'astuces pas mal : http://www.macosxhints.com/
<fil-rezo-net> maintenant que spip-contrib est bien lancé, le problème ne se pose plus vraiment pareil qu'avant
<fil-rezo-net> on a besoin de deux choses juxtaposées : un flux très ouvert
<mortimerp9> Avis perso, j'ai un peu l'impression que toutes les contribs qui sortent dernièrements ne sont pas très innovante: menu, arborescence, etc... pourquoi ne pas privilégier des contribs qui exposent les nouvelles fonctionnalités de la 1.7?
<fil-rezo-net> et des commentaires / orientations pour les utilisateurs moins "pointus"
<fil-rezo-net> d'accord avec morti
<fil-rezo-net> quoique, "privilégier" n'est pas le mot
<fil-rezo-net> il faut les publier toutes, mais si des contribs se ressemblent faire des liens entre elles
<fil-rezo-net> soit en les installant dans une même sous-rubrique (si la navigation est prévue pour ça)
<fil-rezo-net> soit en ajoutant des liens à la main entre elles (?)
<mortimerp9> je voulais juste dire qu'il faut bien mettre une priorité peu être différente en fonction de l'apport en nouveautés des contribs.
<fil-rezo-net> oui, mais "nouveau" n'est pas toujours "bien"
<fil-rezo-net> si la contrib donne une mauvaise manière de faire les choses, bof
<fil-rezo-net> or souvent les trucs "nouveaux" sont difficiles à comprendre, et les premières contribs sont un peu à côté de ce qu'il faudrait faire
<fil-rezo-net> et là ça vaut le coup de discuter pas mal de temps en interne pour que les premiers utilisateurs, qui défrichent la fonctionnalité, démarrent dans la bonne direction, et imposent donc le bon mouvement initial
<fil-rezo-net> sinon ça part en c.
<fil-rezo-net> cf. "modification graphique des champs extras"

Annexe 3 : réflexion de Cyril

... Ensuite on regarde le contenu : qu’est-ce qu’on veut dire, et à qui : là, C peut être important de reprendre tout (rapidement...) "à la base" : pourquoi Spip contrib ? Qui y vient ? Pour trouver quoi ? (quoi / pourquoi / pour qui / comment...) De là on regarde : est-ce qu’il faut toucher à la navigation, est-ce qu’on conserve les 3 colonnes ? ...

réflexion de Ben : la doc ? scission spip, spip-contrib

Pour ce qui est de la doc officielle et la doc contrib, je pense qu’il faut laisser les deux séparés (justement pour cet aspect officiel). Par contre on peux envisager des liens beaucoup plus fréquents vers la doc officielle, ou alors des mots-clés associés aux articles qui renvoient vers la doc officielle.

Pour les forums, je ne suis pas certain ... et puis il y a deja le forum general sur le site officiel

Pour la partie de nicolas :
La rédaction dans SPIP
L’administration fonctionnelle de SPIP
Développer des squelettes simples sans PHP
Développer des squelettes complexes avec PHP
Modifier le coeur de SPIP
Installer et administrer techniquement un site SPIP

J’aime l’idee mais comme noms de secteurs, c’est un peu long non ;-) ?

Vous en etez ou de travail sur l’arbo ? (goetsu)

réflexions de cent20 (26/09/2006)

Adapter l’arborescence de SPIP contrib à l’usage des visiteurs ...

Le constat statistique :
La rubrique "Français" recueille 96% des visites
Dans la rubrique "Français", les sous rubriques "Squelettes", "Outils webmestres" et "Documentation" recueille respectivement 27%, 26%, et 13%.

’idée serait donc de réorganiser contrib en limitant l’arborescence profonde.

Chaque rubrique à la racine contiendrais uniquement les articles de généralités sur la rubrique, et des sous rubriques.

La rubrique 10 contiendrais les articles de présentation du fonctionnement de contrib (moins d’une dizaine), et les brèves sur la vie du site (date des validations, modifications du site, maj du site, nouveaux admin fraîchement nommés etc ...).

La rubrique 20, "Jeux de squelettes" contiendrait une sous rubrique par jeux complets de squelette, sur cette rubrique, l’auteur du squelette serait administrateur, et s’organiserait comme il le souhaite. (Il faudra faire une charte simple et compréhensible).

La rubrique 30 serait le nouveau point de stockage des squelettes non complets, des bouts de squelettes, à ne surtout pas confondre avec les boucles.

La rubrique 50, elle contiendrait un sous dossier par type de boucle, et l’idée serait non pas de proposer des articles complets, mais des boucles simples et compréhensibles, décortiquées et documentées. cad quelque chose de simple, didactique, qui complète la documentation SANS jamais copié, tout en explicitant et détaillant les boucles. Une librairie de boucle en somme, des articles très court, très simples, juste une boucle expliqué.

La documentation DEVRAIT être publié en totalité sur spip.net, pas sur contrib.

Chaque rubrique à la racine contiendrais toujours deux sous rubriques numérotés 98 et 99, l’une serait "bidouilles" et l’autre "archives". Ainsi, les vieux articles ne serait jamais supprimés mais archivés, et les bidouilles seraient intégrées dans chacune des rubriques, ou sorte de dossier sur lequel, dans lequel on publierait TOUT les articles dépassant un délais de carence à fixer (6 mois ?), ainsi on ne perd aucune contrib, on nettoie les contrib en attente, et on fixe les règles du jeux clairement.

hum bon je continu ma réflexion et je repasse bientôt par là ...


cent20 : Arborescence actuelle :

  • francais
    • Actualité
    • Squelettes
      • Diaporama
      • Blogs
    • FAQ - Les questions fréquentes
    • Documentation
      • Administrer son site SPIP
      • Coding Party 4 mars 2006
      • Découvrir SPIP
      • Documentation à télécharger
      • Le multilinguisme
      • SPIP 1.8
      • Tutoriaux techniques
      • Utiliser l’espace privé
    • La caverne au boucles
      • Bouclothèques
    • Filtres : mes fonctions
      • Dates
      • Images
      • Liens
      • Mise en page
      • Pagination
      • Plugins (obsolète)
      • Typographie
    • Outils webmestres
      • Audio
      • Authentification
      • Calendriers
      • Email
      • Espace privé
      • Formulaire / sondages / QCM
      • Galeries / images
      • Migration
      • Navigation
      • Plugins
      • Réécriture d’url
      • Statistiques
      • Syndication
      • Typographie
    • Outils rédacteurs
    • SPIP ++
      • De nouvelles [(#BALISES)] pour spip
      • Experimental
      • Spikini
      • Spip VS phpBB
      • SPIP-Mantis
      • SPIP-Wap
    • Distributions SPIP spécifiques
    • Divers
    • Distributions SPIP spécifiques
    • Bidouilles
      • Authentification (accès protégés)
      • Editeurs WYSIWYG
      • Les champs extra
      • Modifications de l’espace privé
      • Prototypes
      • Squelettes "bidouilles"
      • Versions « Modifiés » de Spip

cent20 : Arborescence v2 :

Idées simples :

-   Pas arborescence profonde (trois niveaux uniquement). Les deux premiers structurent, le troisième est composé de « bidouilles », « non validé par les administrateurs », « archives » etc … Comme ça on ne refuse pas de contenu, et au terme du processus de validation, si l’auteur n’a pas tenu compte de nos remarques, on publie dans « non validé » et voilà.
-   Pas de segmentation / sans php / avec php / plugin / spip ++ /, car on risque de ce retrouve avec les mêmes sous arborescences dans chacun des dossiers.
-   Autonomie des squelettes suivis, dans un dossier avec des droits admin pour le créateur
-   Bouclothèque, une collection de boucle extrêmement simple, en complément de la doc officielle, pour les grands débutants.

  • 01. Fonctionnement et actualité de SPIP-CONTRIB
  • 05. Documentations sur SPIP
  • 10. Jeux de squelettes
    • 1re publication (contient les premières publications d’un squelette, si le créateur veut le faire évoluer, alors on lui créé une rubrique sur laquelle il est admin)
    • Une rubrique par squelette qui est maintenue par son créateur, le créateur étant admin sur sa rubrique. On responsabilise le créateur du squelette, il assure la doc, le suivi, les évolutions et n’est pas dépendant des admins.
    •  
  • 20. Outils webmestre
    • Inclassable
    • Audio ( à chaque fois, on aurait trois sous rubriques)
      • Non validés par les admins
      • Archives
      • Bidouilles
    • Authentification
    • Calendriers
    • Dates
    • Email
    • Formulaires
    • Images
    • Liens
    • Galeries
    • Migration
    • Navigation
    • Mise en page
    • Pagination
    • Réécriture d’urls
    • Statistiques
    • syndications
    • typographie
    • Un forum avec SPIP
    • Un wiki avec SPIP
    • Un agrégateur RSS avec SPIP
  • 30. Bouclothèques
    • Boucles ARTICLES
    • Boucles RUBRIQUES
    • Boucles BREVES
    • Boucles AUTEURS
    • Boucles FORUMS
    • Boucles MOTS
    • Boucles DOCUMENTS
    • Boucles SITES
    • Boucles SYNDIC_ARTICLES
    • Boucles SIGNATURES
    • Boucles HIERARCHIE
    • BOUCLES imbriquées
    • Boucles sur d’autres tables de la base de donnée.

> Zzz. de passage à Cageart... // 31/01/2007

Bon, j’ai parcouru vite fait ce que vous aviez écrit mais il y en a une sacrée tartine quand même :P Je vais essayer de reprendre vite fait les quelques points qui ont été évoqués de manière récurentes et sur lesquels j’ai un avis. Pour le background, certains me connaissent depuis un petit moment pour avoir lu mes questions à la c*n et mes quelques troll sur la liste des utilisateurs. Du reste, je viens d’arriver en tant qu’admin sur contrib et là je suis en train de m’ateler à la refonte du secteur English. Je trolle donc moins sur spip/AT/rezo mais plus sur spip-en maintenant.

Globalement, je suis OK avec certaines choses qui se sont dites ici et là notamment sur la simplicité du rubriquage. J’aurais même tendance à être un peu radical et ne proposer qu’une arbo à 2 niveaux. 3, pour moi c’est déjà trop quand tu sais que pour être bien, un visiteur ne doit pas faire plus de 3 clics sur sa souris pour accéder à son info (du moins c’est un principe qu’on m’a enseigné et auquel j’essaie de me tenir. Le fait est en plus, que Spip-Contrib (SC pour les intimes et pour la suite de mon propos) commence à être plus que bien remplis (pour le dispatching du contenu, on verra plus tard) et que par conséquent les temps d’accès aux pages sont parfois assez lents. Tout le monde ne surfe pas (encore) en ADSL et même moi qui en bénéficie sur le réseaux de mon entreprise, ce n’est pas rare d’avoir des pages qui mettent plus de 40 secondes à se charger. Assez pénible en soit, quand tu dois effectuer des tâches d’admin en série)

Pour ce qui est du visiteur lambda qui arrive sur SC, que cherche t’il avant toute chose ? Il cherche une contrib qui va gérer TEL aspect de son site. Cet aspect là rentre dans une thématique générale (audio, traitement d’image, module additionnel (forum, guestbook, ...)) à qui il convient à mon sens de donner la primeur. Privilégier le fond avant la forme en quelque sorte. Puisque la forme (boucle, ou noisette, ou plugin, ou portion de code php, ...) peut au final, plutôt faire l’objet d’un bon mot-clé bien choisis, que d’une rubrique. Pourquoi ? Un, parce que chaque fond, peut prendre plusieurs des formes disponibles, et 2- Parce que je crois sincèrement que l’utilisateur se fout de connaitre la forme du moment qu’il accède à ses besoin sur le fond.

En plus concret, si je cherche une soluce antispam pour mon site, je me contrefout comme de ma première chaussette que ce soit une boucle, un script PHP, un plugin, une petite fleur des champs ou que sais-je encore... Tout ce que je veux c’est avoir un antispam qui MARCHE !
Après bien sûr, si je veux LE plugin antispam qui fait fureur dans le monde spipien, ben c’est pas dur, il y a un moteur de recherche pour ça. Ou mieux encore, ya un menu paralèlle en page d’accueil proposant une navigation claire par mots clés.

Au final, je pense que le rubriquage acteul de contrib est, dans les grandes lignes, déjà pas mal. Reste éventuellement à le fignoler au cas par cas. L’important pour moi, c’est vraiment de mettre l’accent sur les mots clés. En page d’accueil ils ne sont pas assez mis en valeur. Je les verrais bien au même niveau visuel que les rubriques avec éventuellement un menu déroulant sous chaque nom de groupes de mots. Genre :

  • profils
    • tout public
    • debutant
    • confirme
    • extr3m c0d3urzzz
    • etc...
  • type
    • plugin
    • boucle
    • scripts
    • filtres
    • etc...

Le truc, c’est qu’il nous faudrait, nous admin, être super vigilents sur l’utilisation faite des mots-clés (genre pour être sûr faudrait qu’on tague nous même, ou alors qu’on laisse l’utilisateur le faire mais qu’on ne valide rien tant qu’au moins 2 ou 3 mots clés parmis les groupes les plus stratégiques navigationellement parlant (version spip, type contrib, par exemple...) n’ont pas été sélectionné (ça peut eput être même se faire techniquement ça non ? genre tu soumet ton article et le site te renvoit un "vous devez sélectionner un mot clé en rouge avant de valider votre article" ?)

Dans la pratique finale, le visiteur cherchant un truc pour gérer un aspect particulier s’orientera donc plutôt vers le rubriquage par thème (IDEM pour un débutant à qui Boucle, plugin ou filtre ne dira pas grand chose alors que "soluce d’administration" ou "traitement d’image" sera peut être déjà plus significatif à ses yeux), là où un utilisateur peut être un peu plus au courant, cherchant LE plugin machin, ou LA boucle truc utilisant lui, ce menu de mots clés.

Le problème de langue maintenant. Ben soyons clair, pour moi sur contrib ça n’en est pas un tel qu’il est géré à l’heure actuelle. Sur un site communautaire, on ne peux pas prétendre à mon sens s’affranchir de la structure telle qu’elle existe. Vu le nombre de cntributeur et vue qu’on ne cause pas tous les mêmes étrangers, si on ne structure pas un peu ça va devenir le bordel ! Tu mélanges le Français et l’Anglais quand tu as une vingtaine d’articles publiés, ok ! Pas quand tu en as près de 900 !

Cependant, je pense que ce n’est pas parce que l’interface de Spip est traduite en watt-mille langues, qu’il faut que SC en fasse autant. Parce que je met au défi chacun d’entre vous, sauf cas extrême de parler plus de deux, voire 3 langues suffisement bien pour prétendre contribuer avec. Peut être une sélection est-elle à faire en fonction : 1- des stats de visites de SC réparties par langues, 2- de l’activité des différentes listes d’utilisateurs étrangers, 3- de la langue dont la traduction officielle de la doc est la plus avancée. Je pense sincèrement qu’au final on pourrait ne garder que 2 ou 3 langues et ce serait déjà énorme pour un tel projet. Et sans forcément vouloir prêcher pour ma paroisse, tout étranger qu’on soit, on a tous au moins l’Anglais en commun ou presque. Derrière, c’est l’espagnol. (perso moi je parle allemand mais pas assez pour traduire quoi que ce soit et je doute de l’intérêt réel de la chose selon ce que je viens de vous exposer).

Ensuite, il y a ce système de rubriques-dossiers où il est question de créer une rubrique par contrib. Perso je ne suis pas trop pour. Ya t’il vraiment beaucoup de contribs qui sont suivies dans le temps ? Oui... bon... d’accord... Y en a t’il suffisement pour que ça justifie un dossier systématiquement ? Là par contre je ne pense pas. Au lieu d’une rubrique, je pense qu’un groupe de mots clé ’contributions phares’ contenant un mot clé/nom de la contrib, serait amplement efficace. Et quite à donner des droits d’admins à des gens, autant les donner sur une thématique que sur une contrib-dossier. ça permet aux auteurs de différentes contribs inscrites au sein d’une même thématique de se mêler plus facilement et éventuelement d’envisager plus fréquemment des développements communs du fait qu’au final ils managent la même rubrique dans un même soucis d’efficacité et d’accès à l’information. Si ça peut éviter le développement anarchique de 150 000 contribs qui au final font très exactement la même chose, c’est plutôt tout bon, non ?

That was my 2 cents. Désolé si je ne suis pas clair sur tous mes propos, mais il est quand même vachement tard tôt !

> FIN / Zzz. de passage à Cageart... // 31/01/2007

Discussion

Aucune discussion

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom