Accueil

 
Le choix de SPIP, caractéristiques et contraintes



 

Les contraintes à respecter

De nombreux impératifs sont imposés à SPIP. L’ergonomie, ici, est liée à des aspects très restrictifs du format utilisé, des compétences des utilisateurs, etc.

Impératifs liés au « niveau » des utilisateurs

Contrairement à la majorité des logiciels libres, SPIP est directement utilisé par le grand public, qui est confronté à son interface « en direct » (à l’inverse, par exemple, du système d’exploitation des serveurs, Apache, logiciel quasiment omniprésent derrière les sites Web consultés et créés par les utilisateurs, mais dont le grand public n’a pas besoin de connaître précisément le fonctionnement et/ou les méthodes de configuration).

Une caractéristique de cet outil, constatée dès les origines de SPIP, est d’être exploité par des utilisateurs aux niveaux extrêmement hétérogènes : niveau informatique général, et compétence spécifique dans l’utilisation de SPIP.

- Échelle informatique

Les usagers de SPIP peuvent tout aussi bien avoir un excellent niveau général en technique informatique (expérience de nombreux outils, facilité à découvrir de nouveaux logiciels sans avoir besoin de stages de formation, confiance lors de la découverte d’une nouvelle interface, compréhension rapide d’une logique informatique...), qu’être des débutants (difficulté à aborder les concepts logiciels et/ou d’ergonomie informatique, appréhension face à un nouvel outil...).

Le débutant a besoin de simplicité et de tâches uniques.

L’utilisateur expérimenté veut sentir qu’il peut tirer profit de son expérience informatique, que ses habitudes sont valorisées (il veut sentir qu’il travaille plus vite qu’un débutant, son investissement personnel depuis des années doit être un élément visiblement utile - un outil qui lui imposerait d’en passer systématiquement par les « lourdeurs » d’une interface simpliste adaptée aux débutants le rebuterait). De plus, la rapidité est une priorité pour ce type d’utilisateur.

- Échelle SPIP

Le débutant a besoin de :
— percevoir immédiatement la limpidité de la structure logique du site,
— comprendre et retrouver immédiatement les fonctionnalités au travers de l’évidence de l’interface et des boutons.

À aucun moment un utilisateur ne doit se demander « comment » réaliser une tâche simple, ni ne doit s’interroger sur la structure logique du site.

L’utilisateur confirmé a besoin de :
— pouvoir travailler plus rapidement,
— pouvoir progresser dans son usage de SPIP.

Une notion est au centre de la philosophie de SPIP : la courbe d’apprentissage. Celle-ci représente l’effort à fournir pour atteindre un certain niveau de compétence. L’outil est conçu pour offrir une courbe d’apprentissage très progressive au début (installer SPIP et commencer à réaliser un site se fait presque immédiatement, sans avoir à lire de grosse documentation, ou à apprendre beaucoup de choses) ; à l’autre « extrémité » de la courbe d’apprentissage, le système est conçu pour permettre aux utilisateurs expérimentés de continuer à progresser. Ainsi, même les concepteurs, qui ont pourtant imaginé et programmé le logiciel, continuent eux-mêmes à découvrir des méthodes de travail avec SPIP.

Ces deux échelles de compétence se croisent en pratique : on constate effectivement l’existence de quatre grandes catégories d’utilisateurs :
— les utilisateurs qui débutent avec SPIP et qui ont un faible niveau de compétence informatique,
— les utilisateurs qui débutent avec SPIP mais qui ont de bonnes compétences informatiques,
— les utilisateurs qui maîtrisent bien SPIP et ont de bonnes compétences informatiques,
— paradoxalement, on trouve aussi d’excellents utilisateurs de SPIP (ils savent configurer et gérer parfaitement le travail éditorial avec SPIP), mais un niveau de compétence informatique très faible.

De plus, ces quatre catégories d’utilisateurs sont, dans la pratique, aussi bien de simples rédacteurs (ils participent à un site pour proposer du contenu) que des administrateurs (ils gèrent le travail éditorial du site).

N.B. Comme je l’ai indiqué précédemment, cette difficulté est gérée, dans SPIP, non seulement par le travail sur l’ergonomie de l’espace privé, mais par la présence des fonctions collaboratives elles-mêmes ; ces fonctions permettent en effet l’entraide entre les utilisateurs directement dans l’espace privé (un débutant peut ainsi demander de l’aide aux autres participants au travers des forums privés pour se faire expliquer l’utilisation de telle ou telle fonctionnalité).

Impératifs liés à l’organisation humaine du site

L’interface de gestion de SPIP doit pouvoir gérer des sites ayant des organisations humaines très différentes :
— site personnel, géré et alimenté par une seule personne,
— site collaboratif, auquel participent plusieurs rédacteurs :

  1. avec peu d’administrateurs,
  2. avec de nombreux administrateurs.

Dans le cas d’un site personnel, les fonctions de travail collectif sur un même article et de négociation de la ligne éditoriale deviennent totalement superflus (si elles sont trop présentes dans l’interface, elles deviennent alors gênantes).

Dans un site sur lequel collaborent plusieurs rédacteurs, les fonctions de travail collectif sur les articles sont nécessaires. S’il y a peu d’administrateurs (décision éditoriales très centralisée), les outils de négociation de la ligne éditoriale sont peu utiles. S’il y a plusieurs administrateurs, il faut intégrer les outils de négociation de manière omniprésente dans l’interface privée.

Là encore, on a pour impératif de réaliser une interface qui soit équilibrée, et qui n’impose pas à certains types d’usages une interface qui ne répond correctement qu’à un certain usage. Par exemple, il ne faut pas imposer massivement la présence dans l’interface des outils de négociation éditoriale et de travail collaboratif à un webmestre qui travaille totalement seul sur son site.

Impératifs liés au support Web

Toute l’interface de gestion (privée) de SPIP est réalisée, à l’instar de l’intégralité du site, pour être consultée par le Web.

— Il faut prendre en compte la lenteur, dans l’absolu, du Web. Même avec une connexion à haut débit, l’interface d’un logiciel sur le Web est infiniment plus lente qu’un programme natif. La réactivité est incomparablement plus lente.

— Les possibilités de synchronisation en temps réel sont quasiment inexistantes. Là où un logiciel installé sur un ordinateur peut s’autoriser des vérifications en tâche de fond, des mises à jour immédiates entre différents éléments..., une interface sur le Web reste du « client-serveur » : l’information ne peut être modifiée, mise à jour, synchronisée, qu’à partir du moment où un formulaire est envoyé vers le serveur ou qu’un lien hypertexte (ou un bouton) est cliqué. Cela implique d’énormes lourdeurs en terme d’interface.

— Un tel logiciel, fonctionnant sur un serveur Web, utilise les ressources (temps machine, puissance processeurs, etc.) du serveur, et non de l’ordinateur de chaque utilisateur. Chaque « calcul » (et SPIP réalise de très nombreux calculs) est réalisé sur le serveur qui héberge le site. Il faut considérer que SPIP est utilisé :

  1. pour des gros sites (gros et nombreux calculs), et pour de petits sites (petits et peu nombreux calculs),
  2. sur des serveurs n’hébergeant qu’un seul site (généralement pour les « gros » sites des entreprises), et sur des serveurs « mutualisés » (hébergeant de nombreux sites).

Ainsi, dans certains cas, le système SPIP sera quasiment seul à tourner sur une machine, ce qui dans l’absolu l’autoriserait à réaliser de nombreux calculs ; dans d’autres cas (la plupart), de nombreux sites utilisant SPIP fonctionnent en même temps sur une même machine, ce qui impose de limiter ses calculs (et donc sa richesse fonctionnelle).

Impératifs liés au développement

Les développeurs ont besoin que l’interface graphique retenue fonctionne selon des méthodes (et des automatismes) qui n’entravent pas leur travail de développement (puisque SPIP n’est pas un produit figé : il évolue en permanence depuis des années) :
— facilité de modification du logiciel,
— méthodes systématiques d’interface et d’ergonomie qui permettent à des développeurs non graphistes de facilement développer l’outil (et ajouter de nouvelles fonctionnalités) tout en respectant la cohérence graphique,
— « robustesse » du graphisme : celui-ci doit être suffisamment cohérent et « souple » pour pouvoir répondre à des besoins imprévus sans nouvelle intervention lourde du graphiste ou de l’ergonome.

Impératifs de production graphique

Le logiciel étant utilisé au travers d’une interface Web (donc via un logiciel client tel que Microsoft Internet Explorer, Mozilla, Opera...), des impératifs techniques de compatibilité limitent énormément les possibilités.

Par exemple, les pictogrammes doivent être à un format compatible avec tous les logiciels. En particulier, l’excellent format PING 24 bits (PNG-24), qui gère une transparence fine et élégante (couche alpha) est exclu (Microsoft Explorer ne le gérant pas correctement). On est limité, pour la transparence, au Gif (transparence « tout ou rien »).

Faibles possibilités d’animation graphique

Liée à l’impératif précédent (compatibilité avec une multitude de clients Web), une autre limite réside dans les faibles possibilités d’animation en HTML (DHTML, XHTML), qui reposent sur un langage Javascript encore mal normalisé. Les animations doivent donc être limitées, sauf à devoir développer des codes Javascript extrêmement complexes (donc incompatibles avec l’impératif de simplicité des développements futurs).

Interdiction d’imposer des formats « propriétaires »

SPIP est un logiciel libre (free software, tel que défini par la licence GPL). L’outil est donc fortement lié aux idées philosophies du mouvement du logiciel libre. Philippe Rivière, l’un des développeurs de SPIP, rappelle ce point essentiel dans un article du Monde diplomatique :

« [SPIP] a, surtout, la particularité d’être né d’un projet plus politique que technique, et reste imprégné des valeurs que ses concepteurs entendent défendre. »

SPIP étant lui-même un logiciel libre, les formats retenus pour l’affichage de l’interface doivent eux-mêmes correspondre à cette philosophie :

— les langages utilisés doivent être des standards ouverts (HTML, XHTML...), et ne pas imposer l’utilisation par le client de logiciels propriétaires ; ainsi, il est rigoureusement exclu d’utiliser des balises HTML qui n’existent que sous Microsoft Explorer, ce qui pousserait les utilisateurs à préférer ce logiciel propriétaire à, par exemple, Mozilla (logiciel open-source) ;

— les développeurs ne doivent pas se voire imposer l’utilisation d’outils de développement eux-mêmes propriétaires.

Ainsi l’usage de Flash (Macromedia) est-il exclu pour ces deux raisons : les usagers seraient obligés d’installer l’extension Flash (certes gratuite, mais qui n’est pas un logiciel libre), et les développeurs devraient utiliser le logiciel de création Flash (logiciel qui n’est ni open source, ni gratuit) pour poursuivre le développement de SPIP.

N.B. Nous utilisons ici des animations en Flash pour exposer les propositions d’interface graphique et d’ergonomie. Évidemment, si ces idées étaient retenues pour SPIP, tout serait converti au format GIF et reprogrammé en HTML (tâche technique qui ne peut être réalisée que par les développeurs eux-mêmes, et qui implique non seulement la maîtrise du HTML, mais aussi du PHP utilisé dans la programmation de SPIP).