Salut tout le monde,

Voici quelques idées que j'ai notées pour relancer SPIP.

ORGANISATION DU BOULOT
------------------------

La façon de bosser jusqu'ici (chacun son propre code pour son propre site)
a permis d'avancer sur notre maîtrise technique, mais on aboutit à une
impasse, car on n'arrive pas ensuite à fusionner les travaux. Il faut qu'on
trouve une autre méthode à partir de maintenant.

Techniquement, on a chacun fait des trucs complémentaires:
- Laz a fait une interface de mise en ligne, et un système de gestion des
autorisations;
- Erwan a monté l'interfaçage avec mySQL;
- Fil et moi avons trouvé une méthode pour gérer un site à structure complexe.

Je propose donc qu'avant de commencer la moindre ligne de code, on
définisse "sur le papier" très précisemment ce vers quoi on veut aller,
définir très précidemment le produit. Ensuite une réunion tous ensemble
pour valider les choix. Ensuite seulement on pourra attaquer le code.

CARACTERISTIQUES DE SPIP
-------------------------

- Système de création et de gestion de sites Web
- Interface entièrement en ligne (WEB)
- Travail collaboratif
- Sites à structure complexe (ex: l'Ornitho a une structure très complexe,
à la fois chronologique (par numéros) et thématique (type d'articles), plus
me semble-t-il les sujets "par auteur"; c'est le type même de structure
ingérable à la main que SPIP doit permettre facilement)

Le système doit être très simple à installer et à utiliser. Grosso modo, un
dossier à installer sur son site, et on peut directement commencer à
travailler sans presque lire la documentation. Il faut que n'importe qui,
sans la moindre connaissance technique (sauf: installer un dossier par
ftp...) puisse commencer à créer un site, sans installer de packages,
recompiler quoi que ce soit, etc.

Le site doit pouvoir être très adaptable à n'importe quelle situation. Bien
sûr, pour personnaliser le site, la docu sera indispensable.

Le système doit être "dans un dossier", facilement intégrable à un site
déjà existant.

Tout cela doit (bien sûr) être en GPL.

CHOIX TECHNIQUES
-----------------

Ca, on doit se mettre d'accord absolument avant de commencer... C'est la
base même.

- Interface PHP3;
- documents gérés par mySQL (ça m'a l'air d'être plus pratique, souple et
puissant que de simuler une base de donnée en mode texte comme on le fait,
Laz et moi); [problème: mySQL n'est pas encore très répandu chez les
hébergeurs gratuits - faudra peut-être lancer des "négotiations" avec eux,
par ailleurs]
- pages dynamiques ou pré-générées? Là j'ai pas d'opinion tranchée. Où
alors on peut faire un mélange des deux, c'est sans doute avec ça qu'on
aura les résultats les plus puissants.

Important: architecture modulaire.
Chaque fonction de SPIP doit être sur un page PHP3 séparée, et clairement
définie. A mon avis, y'a que comme ça qu'on pourra désormais collaborer:
quand chacun a le temps, il annonce qu'il se charge de tel module, et peut
le faire évoluer. Cela permettra également au produit d'évoluer par la
suite. Si c'est bien foutu, on devrait réussir même à ajouter des modules
par la suite (genre: export PDF, cahier mensuel, envoit par mailing-list,
etc.) sans perturber les autres modules.

La version de base serait livrée avec 2 bases de données pré-installées:
une base des articles et une base des auteurs. Ainsi le site serait près à
fonctionner dès le chargement du dossier.

LES MODULES
==========
Par module, j'entends deux choses:
- chaque fonction du site est clairement identifiée;
- chaque module est sur une page PHP3 indépendante (pour faciliter
l'organisation du travail).

GESTION DES AUTORISATIONS
---------------------------
3 niveaux d'autorisation:

- Administrateur
Le seul à pouvoir tout faire. Notamment modifier la structure de la base de
donnée, l'interface graphique, etc.

- Membre
Articles acceptés "à priori".
Peut ajouter des rubriques au site et gérer la structure du site.
Participe aux votes de validation des articles soumis par les "invités"
Reçoit les courriers de la liste de discussion interne du site
Peut modifier les anciens articles directement.

- Auteur invité
Peut proposer des articles (qui devront être validés par les membres)

Je propose que les auteurs invités aient leurs propres code d'accès:
lorsqu'ils veulent proposer leur premier article, ils doivent remplir une
fiche d'identité contenant notamment leur adresse email. Alors ils
recoivent par mail un code d'accès personnalisé. De cette façon l'auteur
est au moins identifié par une adresse mail valide. Dans la base
"articles", chaque article contiendrait un champ de validation (genre:
"pour:2;contre:3" ou "veto" ou "valide"); les règles de validation
(majorité, unanimité, un seul vote d'acceptation, etc.) seraient libres,
définissables par interface graphique.

Faut-il prévoir un statut spécial pour des "Contributions libres", sans
aucun enregistrement?

CREATION DES ARTICLES
----------------------
L'interface Web de Laz.

Avec "raccourcis SPIP" (note de base de page, intertitres, etc.).

Première correction typographique. Une solution que j'utilise sous TeX: la
version stockée est "simplifiée", c'est-à-dire que tous les "blancs" sont
supprimés (supprime les blancs doubles, supprime même les blancs avant les
deux points, etc.) ce qui permet d'éviter les conflits dans les corrections
de typographique (ajouter des blancs insécables alors qu'ils y sont déjà,
etc.). La version stockée est donc, dans l'absolu, incorrecte
typographiquement, mais beaucoup plus facilement éditable. Ensuite, lors de
la génération du site, les quelques blancs nécessaires sont ajoutés.

Y'a-t-il possibilité de correction orthographique automatisée?

L'auteur choisit lui-même la(les) rubrique(s) où installer l'article. En
réalité, il doit remplir tous les champs liés à l'article, ce qui permet
ensuite de gérer n'importe quelle organisation du site (par auteur, par
date, par sujet traité, etc.).

GESTION DES CHAMPS DES BASES DE DONNEES
---------------------------------
Le site serait structuré autour de plusieurs bases de données. Par défaut:
articles & auteurs. On peut imaginer des bases supplémentaires pour
n'importe quel usage: par exemple des listes thématiques de liens Web, des
cartographies, des listes de dates, etc. Je ne connais pas bien mySQL, mais
je suppose que l'utilisation de différentes bases de données permet
d'enrichir des croisements d'info.

L'admin doit donc pouvoir personnaliser ou créer des bases. Par exemple:
ajouter dans "articles" un "sur-titre", un champ "sujet traité". Dans
"auteurs" il peut ajouter "photo de l'auteur", "date de naissance", etc.
N'importe quoi, donc. Cette interface graphique de base de donnée pourrait
ressembler à l'UngiTrombi de Gilles Maire.

Si on fait ça bien, le site peut être de n'importe quelle nature, avec le
même moteur. Par exemple, j'utiliserais SPIP pour créer une base de donnée
cinéma sans problème (on aurait donc des liens dans tous les sens, plus une
hiérarchie thématique). Les problèmes que soulève Fil pourraient être
résolus uniquement en utilisant de manière personnalisée la structure de la
BdD (par exemple, ajouter dans la base "articles" un champ "Cahier", et
ainsi on pourrait ajouter à la structure hiérarchique une structure en
cahiers).

GESTION DE LA STRUCTURE DU SITE
--------------------------------

Là, c'est très différent du module précédent (gestion des champs des BdD),
il s'agit simplement d'organiser la structure du site (déplacer un article,
créer une nouvelle rubrique, etc).

Notez bien: ça me semble très ardu de réussir là une interface graphique
pour gérer "simplement" quelque chose d'aussi complexe. Car l'interface
doit pouvoir s'adapter à n'importe quelle structure du site, selon des
champs et des base de données qu'on n'aurait pas prévu à l'origine.

Le tout avec une interface graphique Web. Hum... Java et glisser-déposer?

GESTION DE L'INTERFACE GRAPHIQUE
---------------------------------
Au départ, c'est tout simplement un choix entre plusieurs "thèmes" (skins)
préinstallés, histoire de pouvoir commencer rapidement le site.

Ensuite, c'est plus complexe, il faut pouvoir paramétrer facilement sa
propre interface, avec ses propres "champs" (sachant qu'on peut en créer
directement dans la base de donnée). Là encore, c'est un point délicat.

Ca peut être un double système:
- le graphiste fabrique les pages en HTML, avec quelques champs de pseudo-HTML;
- une fois sur le Web, ces champs "pseudo-HTML" peuvent être personnalisés
(présentation des différents "champs" des bases de données.

Il faut pouvoir gérer deux types d'appels:
- les appels simples (afficher le titre de l'article, le nom de l'auteur)
- les appels récursifs (la liste des articles traitant du même thème...).

Prévoir peut-être des ordres conditionnels: afficher uniquement si une info
existe, sinon autre chose. Etc.

GENERATION DU SITE
-------------------

Facile: c'est la page où on appuie sur un bouton, et le site est créé. 

Doit gérer:
- la seconde correction typographique (remettre les blancs insécables);
- les listes de type "quoi de neuf", classement thématique, etc.

MODULE DE COMMUNICATION
--------------------------
Module(s) permettant les échanges entre les membres.

Principalement: gestion des votes de validation pour les articles proposés
par des invités. Interface mail-Web. -> MODULE DE VALIDATION
On peut imaginer: chaque fois qu'un "invité" poste un article, chaque
membre reçoit un mail avec un adresse Web à visiter. Là il peut lire
l'article, qui est suivit de: bouton "pour", bouton "contre", champ de
texte "commentaire".

OPTIONS A PREVOIR
-----------------
Là, je sais pas: est-ce qu'il faut les prévoir dès le début? Ou bien est-ce
qu'on peut imaginer une programmation du "noyau" principal suffisamment
souple pour que l'ajout de nouvelles fonctions soit facile (genre
"plug-in")?

- Versions HTML imprimables (genre Menteur/Scarabée) pour chaque article;
- Versions multilingues;
- Cahiers PDF;
- Création d'images typographiques (titres, intertitres avec des "belles"
polices - transformer une base genre "H1" en GIF avec une police choisie et
quelques effets);
- Gestion d'interfaces un poil chiadées: menus déroulants, image-map (le
tout en server-site, bien entendu).
- Interface pour listes de diffusion, forums, moteur de recherche, etc.
- Interface vers Eternam (quand ça existera...).

Voilà pour le moment, c'est tout ce que je vois... Ce ne sont que des
propositions, hein. 

Amicalement,
ARNO*

Le Scarabée: http://www.scarabee.com