Introduction

Le but de ce projet est de fournir un espace web, à la fois collaboratif pour que les membres puissent avoir une plateforme référentielle de développement, et à la fois public, pour afficher la vitrine du projet: [http://nasgaia.org].

Ce document n’est qu’une appréciation de ce qui est nécessaire, selon mon point de vue (riri) d’abord, puis de manière plus étendue au fur et à mesure des complètements par les différents membres intéressés par ce projet.

Note: pour une meilleure clarté, veuillez préfixer vos idées/annotations/commentaires par votre nom/pseudo, ce qui permettra des discussions plus rapides entre les intervenants.

NWP étant un seul et unique projet, le résultat sera quand même double:

  • un espace de développement réservé aux membres du projet, où ils pourront effectuer toutes les tâches relatives à leur participation. Nous appelerons désormais cet espace le panel ;
  • un site web dynamique s’appuyant sur le contenu généré par les membres, depuis l’espace collaboratif. Nous appelerons désormais cette partie le site.

Les grandes lignes

Le panel

Gestion des utilisateurs

La première chose à régler est la gestion des utilisateurs, et à forciori celle des membres du projet. Je dis utilisateurs, car avec déjà quelques idées sur les concepts du site, je pense que les simples visiteurs pourraient avoir besoin de s’enregistrer dans la base utilisateurs (pour les forums par exemple, mais on peut envisager d’autres raisons).

Les premiers concepts à établir sont les actions de base (dans le désordre) :

  • création par un administrateur ;
  • enregistrement depuis le site ;
  • visualisation du profil d’un utilisateur quelconque ;
  • modification de son propre profil ;
  • modification du profil d’un utilisateur par un administrateur ;
  • suppression d’un utilisateur par un administrateur ;
  • requête par l’utilisateur à un administrateur (pour changer d’état, ou pour être supprimé par exemple) ;
Note : Les confirmations à des requêtes (comme l’enregistrement ou le changement d’état) peuvent être implémentées par la page de modification de l’utilisateur par un administrateur. En effet, un utilisateur peut très bien avoir un état indiquant par exemple qu’il n’est pas encore validé.
Note: Une bonne gestion des sessions doit également être mise en place pour que tout le panel puisse fonctionner correctement.

Ce qui est le plus important ensuite, est une bonne gestion des droits. Une possibilité utilisée par coWiki est de réutiliser les principes des systèmes de fichiers Unix ; bien que l’idée est très bonne, je considère qu’un espace web a des besoins différents d’un système de fichiers, et l’idée ne peut être complètement transposée. Par exemple, un utilisateur pourrait avoir le droit de créer de nouveaux documents (fichiers) mais pas de nouvelle rubrique/section (répertoire). L’utilisation des permissions Unix est donc pour moi trop limitée.

Pour cette raison, je pense qu’une bonne gestion des droits ne peut être envisageable que par un système de rôle. On définit des rôles qui permettent des actions, et on associe les utilisateurs à tel(s) ou tel(s) rôle(s) pour lui donner les droits. On peut également étendre le principe en définissant des groupes, et assigner les rôles aux groupes plutôt qu’aux utilisateurs.

Note : Le fait de pouvoir associer un seul ou plusieurs rôles à un sujet (utilisateur ou groupe) est une décision d’implémentation, suivant lequel est le plus pratique (d’où les ‘s’ entre parenthèses ci-dessus).

Gestion des équipes/projets

L’un des autres grands intérêts du panel à côté des utilisateurs est la gestion des équipes de travail (selon la Charte de Nasgaïa) ou projet (selon une définition plus large). Il faut pouvoir définir :

  • l’appartenance d’un utilisateur à un projet ;
  • le rôle de chacun des utilisateurs membres d’un projet (responsable, etc..) ;
  • assigner une ou des fonctions/tâches à un membre du projet (le fait que cette tâche lui soit dédiée n’implique pas qu’il ait une quelconque obligation de résultat, seulement qu’il est l’interlocateur privilégié pour cela) ;
  • les propriétés du projet pour son(ses) responsable(s) et un administrateur.

Gestion des documents

L’intérêt de ce panel est non seulement de pouvoir gérer la communauté, mais également le contenu du site public. Une gestion des documents (articles, howto, pages ‘statiques’, news, etc..) est donc nécessaire.

Bien que Nasgaïa soit à premier abord un projet francophone, il me semble essentiel que le site et tout ce qui l’entoure soit multilingue. Cela a des répercutions sur la structure des données bien-sûr, mais également sur le fonctionnement du panel. En effet, à partir d’un document, il pouvoir définir des traductions, ou inversement, lorsqu’on crée un document, pouvoir indiquer qu’il s’agit de la traduction d’un autre document.

Par ailleurs, tout élément à base linguiste doit être traductible. Cela comprend:

  • le titre et la description d’un projet ;
  • les informations suplémentaires d’un utilisateur (bio, centres d’intérêt, etc..) ;
  • les catégories (sections) faisant la structure des documents.

Afin de faciliter la rédaction, un langage de marquage (markup language) devra être utilisé. On peut utiliser des langages existants et qui ont faits leurs preuves (textitle, wiki, etc..). Le moteur du site se chargera de traduire ce contenu en XHTML (voir la section De belles pages), et cela pourra même être mis en cache pour améliorer les performances (mais c’est une autre histoire).

Note: je ne parle même pas de la traduction des éléments inamovibles comme les menus, la langue du panel, etc.., cette partie va de soit pour moi (vraiment je ne peux pas imaginer un système de gestion de contenu ne gérant pas ça).

Gestion du site/panel

Bien-sûr, tout l’outillage doit être aministrable, et de préférence à plusieurs niveaux. En effet, la première chose à laquelle on pense lorsqu’on parle d’administration, est celle du site :

  • les utilisateurs ;
  • le site ;
  • les projets ;
  • les documents et leurs sections ;
  • les autres outils mis à disposition sur le site (forums, votes, etc..).

Il faut également penser au fait que certains membres ont des droits supplémentaires sur une partie du site/panel: les responsables de projet (d’équipe). Il leur faut de quoi administrer leur partie :

  • propriétés du projet (description, état d’avancement, etc..) ;
  • membres faisant partie du projet ;
  • documents liés à ce projet.

Le site

De belles pages

La règle d’or lorsqu’on participe à un projet comme le notre, est le respect de certains concepts, tels que les standards et l’accessibilité. Le contenu du site et sa facilité d’accès doivent toujours primer sur des fonctionnalités qui pourraient ne pas être disponibles à tous. Cela n’empêche pas d’ajouter des fonctionnalités facilitant le travail ou la lecture à certains utilisateurs pouvant jouir de ces ajouts, tant que c’est débrayable.

Les standards sont bien-sûr ceux du W3C. Utiliser donc au maximum du XHTML 1.0 (transitional, car le strict n’est pas bien compris par tous les navigateurs), du CSS 2 (avec un minimum de structuration du document en fonction de l’affichage - penser aux navigateurs texte), du Javascript (ECMAScript) pour les navigateurs qui le supportent (mais à chaque fois avoir une alternative via la balise <noscript>).

Une des formes d’accessiblité est l’accès aux pages par URI reconnaissable, ou en d’autres mots, autre chose qu’une Query String ou des identifiants. Cela pourra être fait via des règle d’URL rewriting d’Apache ou directement dans le code PHP de visualisation de la page (recherche d’un identifiant par son titre).

L’autre forme d’accessibilité porte sur le contenu lui-même. Comme dit plus haut, toute fonctionnalité (comme du javascript pour diverses raisons comme le concept AJAX) doit être débrayable, et fournir un équivalent si nécessaire (si le traitement ne peut faire sans un certaines forme d’interraction). Bien souvent, du traitement peut être fait côté serveur (dans le PHP), comme les validations de formulaire par exemple ; une validation côté client par javascript classique ou utilisant le concept AJAX ne doit être qu’un confort pour ceux en bénéficiant.

On évitera de la même manière les clics multiples pour accéder à une page. Proposer un maximum de liens sans surcharger l’interface, et ce sur tout le site (par exemple, éviter les menus disponibles uniquement dans une zone du site, sauf si le contraire surchargerai la page ou si ce menu n’est applicable qu’à cette page/zone).

Contenu global

Un site web portail contient de nombreux types de contenus. Parmi eux, on trouvera:

  • les pages statiques, à savoir celles qui ne sont pas saisies par les utilisateurs - ce qui ne veut pas forcément dire qu’elles sont codées en dur, elles peuvent faire partie de documents typés comme statiques pour les différencier des autres ;
  • les documents, articles, tutoriels, etc.. saisis par les utilisateurs du panel ;
  • les brèves, ou nouvelles (communément appellées news), saisies la plupart du temps par les administrateurs du site, ou les responsables de projets (on peut prévoir soit une archive de brèves unique, soit une archive par domaine (le site en général, plus une par projet) ;
  • les forums, indispensable pour la communication avec les (futurs) utilisateurs de Nasgaïa ;
  • les liens vers d’autres sites.

L'outillage

Le minimum

Etant donné l’outillage à disposition chez notre hébergeur (TuxFamily), il sera nécessaire d’utiliser le langage PHP (4 ou 5, les deux étant disponibles), et si besoin MySQL comme base de données (je n’ai plus la version en tête, mais je crois que c’est du 4.x), ou bien PostgreSQL (on peut même avoir les deux).

Allons-nous ou non utiliser CodeIgniter ? Utiliser CodeIgniter implique une POO pauvre (pas d’exceptions, encapsulation inéxistante..) et donc des fonctionalités communes à PHP4 et PHP5. Si au contraire nous sommes joueurs, on peut se lancer dans un développement from scratch et bénéficier du sucre de PHP5. Notez bien que je n’ai rien contre CodeIgniter et qu’à mon avis, le pari est moins risqué avec CodeIgniter. — Benoit Myard 11/07/2006 01:11
Disons que parmi les framworks permettant une structure propre (MVC), CodeIgniter me semble le mieux. C’est vrai, il garde la compatibilité PHP4 ; à la rigueur on pourrait s’inspirer du code (il y a vraiment de bonnes idées à prendre, d’autres à améliorer, d’autres à éviter) et partir de zéro comme tu le dis, mais c’est un gros boulot (car il faut refaire toute l’abstraction sous-jacente). — riri 11/07/2006 21:01
Quoi qu’il en soit, on peut utiliser CodeIgniter pour un prototypage rapide et aviser ensuite en fonction de la qualité réelle du framework, de ses performances et de son efficacité. — Benoit Myard 18/07/2006 20:00

Les systèmes existants

Aucun système d’existant ne convient pour répondre à tous les besoins exprimés ci-dessus. Nous avons donc les possibilités suivantes :

  • fabriquer notre propre système, qui conviendra parfaitement, dans la mesure où il y a au moins une personne capable et ayant le temps de le faire ;
  • utiliser un système existant et se passer de certaines fonctionnalités ;
  • utiliser plusieurs systèmes existants conjointement en prenant en compte le fait que les gérer ensemble ne sera pas une mince affaire (base utilisateurs par exemple).
Je penche évidemment pour la première solution. — Benoit Myard 11/07/2006 00:47
 
les_idees_de_conception.txt · Dernière modification: 15/02/2007 22:13 par riri
 
Recent changes RSS feed Creative Commons License Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki