SPIP Blog

Du logiciel libre et de la tendresse

Accueil > Développement > Design > Typologie des utilisateurs (pour reconquête intergalactique)

Typologie des utilisateurs (pour reconquête intergalactique)

lundi 5 décembre 2011, par tetue

JPEG - 171 ko

C’est au hasard des rencontres que se décident les choses de SPIP, en crayonnant sur la nappe en papier d’un restau, pour illustrer les idées d’une discussion animée, sur la documentation de SPIP, sa galaxie, sa boussole. Notre reflexion poursuivait l’échange initié en ligne par _Eric_ : Une proposition de plus pour la doc... et ce gribouilli a aussitôt été tweetpické par @GusLeLapin, comme « plan de la (re)conquete du monde » rien que ça ! « galactique », a surenchéri @vlentz !

C’est toujours plus clair en reprenant au début...

Depuis l’origine SPIP permet aux rédacteurs de « publier sur le Web, sans connaître le HTML » et aux webmestres de faire un site dynamique, sans avoir besoin de maîtriser un langage de programmation, comme monsieur Jourdain faisait de la prose sans le savoir. Si l’on s’en tient à cette approche fondamentale — importante pour SPIP, qui se présente en page d’accueil du site officiel, comme « particulièrement attaché à la facilité d’emploi » — on dégage aisément trois profils :

  1. l’auteur, qui peut publier sur le Web, sans connaître le HTML,
  2. le webmestre, qui peut fabriquer un site, sans connaître le PHP,
  3. et le développeur, dont je ne parle volontairement pas [3].

Ces trois profils — ou trois étapes d’apprentissage — sont faciles à distinguer par les langages maîtrisés, qui tracent une frontière claire entre chacun, ce qui permet de cibler plus facilement lorsqu’on rédige et organise la documentation :

  • dès qu’il y a du HTML, ça ne s’adresse plus au rédacteur, mais au webmestre,
  • dès qu’il y a du PHP, ça ne s’adresse plus au webmestre, mais au développeur.

Ça mériterait même des sites différents. C’est ce qu’illustre ce schéma sur la nappe, entre deux verres de Bergerac. En le complétant, on dresse le tableau suivant :

ProfilNiveau prérequisApport de SPIPRessources actuellesAide à apporter
utilisateur [1] il rédige des textes dans sa langue et les met en forme et en hypertexte avec les raccourcis SPIP aide en ligne vieillissante de l’espace privé Site d’aide dédié, public et à jour : aide.spip.net (cf. 2253)
webmestre [2] il intègre des gabarits en HTML et CSS et les dynamise à l’aide des boucles et balises SPIP spip.net vieillissant et le grand fouilli de SPIP-Contrib  glossaire, bouclothèque, tutos... dans un site dédié : boucles.spip.net ? complété par le nouveau plugins.spip.net et le futur themes.spip.net.
développeur il programme en PHP et fabrique des plugins idem plus les sites dédiés doc.spip.org et programmer etc. [3]

Où il apparaît assez simplement que la meilleure façon d’aider les utilisateurs [1] est d’améliorer la saisie (raccourcis SPIP, barre typo) et de mettre l’aide à jour. Mais la priorité est plutôt le webmestre débutant, celui qui ne connaît pas SPIP, parce qu’on ne s’adresse plus à lui depuis longtemps — le tuto « Mon premier squelette », avec ses résidus de php3, est trop piégeux. Ne peut-on pas faire table rase ?

Refondre les dinosaures omnipotents (spip.net et Contrib) est une entreprise trop lourde, qui décourage avant même de commencer. Mieux vaut les dépecer en plusieurs sites dédiés — éventuellement liés par une barre de nav unifiée —, moins ambitieux, plus petits et mieux ciblés, qui font une chose et la font bien. Ils sauront d’autant plus facilement fédérer les bonnes volontés qui les maintiendront, car celles-ci existent.


[3Car les devs ont toujours su se débrouiller : ils ont déjà des sites dédiés, certes plus ou moins à jour (doc, programmer, contrib), mais surtout ils savent chercher, quitte à lire dans le code pour trouver, chose qu’on ne peut légitimement pas attendre des autres utilisateurs. Au pire ils s’en tirent en programmant directement en PHP. Bref, le besoin d’aide n’est pas bloquant en ce qui les concerne.

[1Auteur, utilisateur, rédacteur, administrateur, admin restreint, etc. bref, toutes celles et ceux qui utilisent l’interface de SPIP, sans toucher aux squelettes.

[2Webmestre, bidouilleur, spipmestre, intégrateur, dev front, webdesigner, graphiste, etc. bref, toutes celles et ceux qui manipulent les squelettes et autres fichiers servant à fabriquer le site.

Messages

  • Excellent article, et, tu le sais, je suis entièrement d’accord. :)

    Tout comme les barbus découpent le noyau de SPIP en moult modules faisant UNE chose, les concepteurs des sites de la galaxie (qui sont souvent les mêmes) doivent suivre le même chemin en définissant les limites de ce qu’on met dans chaque lieu. Le principe est valable presque partout : faire une chose et le faire bien.

    Je pense que le problème principal c’est que la plupart des gens participent au logiciel libre durant un projet qui les concerne (professionnel ou personnel, peu importe). Et du coup, ils font avancer le code de SPIP et des plugins, pendant leur projet. C’est clairement possible de coder du PHP et des squelettes et du HTML/CSS tout en travaillant.

    Tandis que la doc générale (pas celle de tel ou tel plugin), les sites de la galaxie, etc, c’est forcément en plus, à part, sur le temps libre. Et du temps libre, on est très peu à en avoir. Du coup ça n’avance pas, ou très lentement, comparativement au code.

  • (P.S. : pourquoi la note numéro 3 est avant la 1 et 2 ?)

  • J’adore spip, mais le principal reproche que l’on peu lui faire (comme à de nombreux autres) est sa lourdeur à avancer.
    on nous parle de la version 3 depuis déjà plus d’un an, et meme si elle est en beta, on en sais guerre plus sur son avancement (à par à la téléchargée et à la testée)
    aucune deadline n’est donnée, et ça, quand on a des projets en devenir ou en cours , et bien c’est rébarbatif, et bon gré, mal gré, on se tourne vers une autre solution (genre wordpress par exemple)...

  • De deadline, je pense qu’il n’y en aura jamais et c’est très bien comme ça : ça avance suivant les disponibilités des gens, pas suivant des impératifs professionnels et cadrés (Wordpress et Drupal sont chapeautés par des entreprises, autre logique, autre ambiance).

    En revanche, communiquer sur l’avancement des choses et leur documentation, ça oui. Et c’est en partie l’objet de cet article de tetue.

    Savoir « où ça en est » et avoir la doc pour l’utiliser, c’est quelque chose qui permet de prendre une décision quand on commence un projet, quelque soit la date finale de sortie.

  • Je suis d’accord avec toi tetue. Il y a urgence de replacer l’auteur en cœur du processus.
    Son « expérience utilisateur » n’a quasiment pas évolué depuis 10 ans. Cela nous aidera à rajeunir l’image de SPIP et montrer la puissance des derniers développements.

    Même si nombre de sites de la galaxie vieillissent, la renaissance de plugins.spip.net m’a redonné du baume au cœur en la vitalité de la communauté.

    Engageons ce nouveau chantier :)

    Eventuellement auto-finançons la doc pour aboutir plus rapidement.

    ps. pour le webmaster, je suis tombé par hasard sur ce site SPIP pour les nuls

  • @RastaPopoulos libre et entreprises ne font obligatoirement pas mauvais ménage ;)
    Drupal ez publish et wordpress en sont de bons exemples.

    mais on est d’accord sur l’essentiel !

    SPIP doit communiquer !

  • Juste un commentaire après coup sur la partie « devs » car j’ai été devancé par la publication...

    Quand on a sorti SPIP 2.0, l’annonce insistait sur l’aspect « framework » de SPIP. SPIP 3.0 va renforcer ce caractère même si des améliorations sont encore nécessaires. par contre, la documentation de « devs » elle ne suit pas cette logique.

    Il ne faut donc pas oublier cette documentation car elle doit être refaite à partir de l’existant en distinguant bien la partie API du framework et la partie mécanismes, c’est-à-dire les tutos (créer un plugin, un objet éditorial, développer une interface dans le privée, la charte du privé...)

  • Oui _Eric_, mais ce ne sont pas les devs [3] qui ont le plus besoin d’aide actuellement...

    SPIP 2 s’est défini comme « framework ». Mais il a aussi fait passer le message qu’il délaissait — temporairement avons-nous espéré alors — les utilisateurs [1], qui, comme le souligne plus haut erational, n’ont pas vu leur usage évoluer depuis un paquet de temps (pas vraiment d’évolution d’interface ni des aides à la saisie) et [2] (ni des docs et tutos dédiés, lesquels mentionnent toujours du php3, quand même ! alors que les squelettes ne cessent de se complexifier et ce sera encore pire avec Z).

    Il y a urgence à se recentrer sur l’auteur, sur la publication, sur la liberté d’expression. À repenser SPIP, ce programme [qui] n’est pas destiné aux informaticiens, mais à tous ceux qui souhaitent s’exprimer sur la Toile comme projet plus politique que technique (tel qu’il est présenté dans La toile de SPIP).

    Et oui Al_, ça passe par une meilleure communication.

    @Rasta : la réalisation d’un projet peut aussi être l’occasion, comme pour le code, de rédaction de documentation, par exemple pour former les utilisateurs. Mais où et comment reverser cela à la communauté ? Quel est notre mode de récolte de ce qui n’est pas code (mais doc, créa, etc.) ?

  • Il y a un quatrième profil : l’acheteur, celui qui va payer la solution ...

  • @erational : « pour le webmaster, je suis tombé par hasard sur ce site SPIP pour les nuls » est un bel exemple d’initiative personnelle, mais malheureusement isolée et probablement abandonnée : le site affiche une version pas à jour, et plus grave, un copyright qui laissent entendre que le contenu (que je ne juge pas sur le fond) est en droits réservés, donc pas réutilisable... dommage. Mais la piste est bonne.

    @Rasta : développer un projet ne devrait pas se résumer à la production de code. développer un projet, c’est élargir sa base d’usages, d’utilisateurs, c’est aussi, par exemple, assurer le support (et là, on pourrait croire qu’on est gâté avec SPIP : irc, forum web, listes, et je le dis plus optimistement, les apéros ...). Mettre à jour, ou organiser, la doc ne devrait pas être traité aussi négligemment et j’espère qu’il n’y a pas QUE des devs qui n’ont QUE le temps de coder. Je comprends bien qu’il y a derrière l’évocation du manque de temps des contraintes économiques. J’ai les mêmes. :-) Mais comme disait Toggg, on devrait commencer nos projets par la documentation. Ce que je traduirais bien par « on devrait prendre l’habitude de poser nos idées quelque part avant de les coder », quitte à ce que ce soit des brouillons qui seront repris par d’autres contributeurs, terme que je préfère à celui de codeur ou de développeur, au passage. Et de plus, si on n’a pas le temps de documenter, on peut tout de même réfléchir au meilleur moyen de se faire aider par l’ensemble de la communauté ...

    @tetue : au même titre que programmer.spip.org serait le site de référence des développeurs, on pourrait imaginer :

    • utiliser.spip.org pour le profil utilisateur
    • integrer.spip.org pour les webmestres
    • choisir.spip.org pour les décideurs ^^

    ces sites pourraient être des points d’entrée exploitant les ressources des sites plus technique contenant thèmes, boucles, plugins, doc, wiki , party etc.

    euh, c’est purement théorique ce que je dis là hein ... j’en suis à imaginer.spip.net :P

  • @James, tu n’as pas lu ma phrase entièrement, peut-être :

    Tandis que la doc générale (pas celle de tel ou tel plugin), les sites de la galaxie, etc, c’est forcément en plus, à part, sur le temps libre.

    Quand un développeur faisant partie de la communauté code un plugin, la grande majorité du temps on a sa doc ensuite sur Contrib. Qu’il commence par la doc ou qu’il la fasse ensuite, on finit par l’avoir.

    Je parlais bien de la documentation de SPIP lui-même, ainsi que du temps à passer sur les sites de la communauté : aucune de ses deux grandes tâches ne peut faire partie d’un projet payer par un client dans notre vie quotidienne (ou alors de manière hyper marginale, exceptionnelle). Donc forcément sur du temps libre que presque personne n’a.

    Hors c’est de ces points là dont parle l’article : la doc générale, et l’amélioration de la galaxie.

  • Faut pas pousser mémé non plus :p Je sais bien qu’il y a plein de choses améliorables, mais quand je lis :

    pas vraiment d’évolution d’interface ni des aides à la saisie

    Le porte plume, la médiathèque, le plugin menus, etc, ce ne sont pas des évolutions de l’interface de saisies ça ?

  • @Al_ : tu parles de roadmap en gros. Et tu cites wordpress.

    Quand je vais sur la feuille de route de worpress, je vois une planification très vague, mais très facile à trouver :

    • 3.3 Sometime in 2011
    • 3.4 2012

    C’est pas si précis que ça ...

    J’ai l’impression que ce n’est pas plus précis pour drupal, et qu’il y ait plus un engagement sur les fonctionnalités que sur des délais. J’avoue que je n’ai pas trouvé de date prévisionnelle, c’est un peu le bazar quand on cherche « drupal+roadmap » sur un moteur de recherche...

    Rasta a bien raison : autre logique, autre ambiance. On ne s’appuie pas sur des moyens garantis pour réaliser une version stable. C’est dépendant de la seule bonne volonté des contributeurs.

    Nous sommes apparemment incapables à ce jour de dire quand sort une version, ou ce que la prochaine contiendra précisément. Peut-être qu’il faudrait qu’on choisisse l’une ou l’autre de ces possibilité ? Que ce soit écrit quelque part et qu’on s’y tienne ? J’avoue que je ne sais pas ...

  • Hop,

    Nous sommes apparemment incapables à ce jour de dire quand sort une version, ou ce que la prochaine contiendra précisément.

    Si on utilise bien redmine, on peut avoir une rodmap du type « ce qu’il y aura dedans » avec cette page :

    http://core.spip.org/projects/spip/roadmap

    Comme le dit souvent Edgard : Paye ton ticket ! :)

    ++

  • Pour compléter le message précédent, on dispose aussi de l’info pour la date :

    http://core.spip.org/versions/show/9

    En retard de environ 2 mois (1/10/2011)

    On ne se moque pas ! C’est rien deux mois :p

  • Oui mais ca change quoi de savoir la date de sortie ? Je veux dire, pour les utilisateurs (sujet du billet) ?

  • si on refond http://spip.net en utilisant les sites de la galaxie, on pourrait avoir qqchose de bien sans forcement s’épuiser.

    j’aime bien comparer avec http://wordpress.org , on est assez proche

    faut il unifier ? pour la doc, faut il se financer pour dégager un rédacteur en chef ?
    si cela permet d’avancer sans trop troller ...

  • Pourquoi toujours parler pognon quand on parle de la doc de SPIP alors que ça n’est JAMAIS évoqué quand il s’agit de coder le noyau ????

  • Oui, erational, c’est cohérent et ce serait pas mal.

    Par contre, il ne faut plus faire de ces sites omnipotents, ventripotents... C’est trop compliqué à comprendre pour les nouveaux venus, à maintenir et ça décourage la contribution et les mises à jour, si bien que... N’y a-t-il juste personne qui puisse virer la gazette d’avril 2008 de cette page d’accueil ? Bin nan.

    Il ne faut pas tant refondre spip.net que le morceler en plusieurs sites simples, de façon à ce qu’il n’y reste que quelques pages d’accueil, de présentation. Bref, que spip.net soit juste le portail d’entrée de la galaxie — comme c’est joliment dit ! — ainsi que le suggère RastaPopoulos. Et on y collerait une barre de nav intergalactique, comme celle que tu décris. Je précise (en rappelant les types d’utilisateurs concernés) :

    • Accueil : qq captures + présentation
      et qq remontées d’actus, occasionnellement
      • Présentation [1] (showcase + about) : que l’on qualifie plus haut de « décideur » alors que ça aide juste les teubés comme moi à comprendre ce qu’il y a dans le biniou ; merci de ne pas nous oublier :P
      • Télécharger, comme actuellement. Ca pourrait aussi être un site dédié, avec toutes les archives.
      • Aide [1] : comme l’actuelle « aide en ligne », mais à jour, dans aide.spip.net. Contrairement à ce qui se dit, je ne sais pas qu’il faut un nouveau site (utiliser.spip.org ou publier.spip.net), du moins n’est-ce pas à SPIP de s’en soucier. L’aide répond déjà à cela, non ?
      • Contributions, à détailler comme suit :
        • Thèmes : dans themes.spip.net
        • Squelettes : idem
        • Plugins : dans plugins.spip.net
        • Extensions : idem
      • Documentation
        • Webmestres [2] : comment fabriquer ses squelettes ? avec glossaire, manuel de référence, tutos, bouclothèque... dans un seul webmestre.spip.org ? ou plusieurs glossaire.spip.org, manuel.spip.org, tutos.spip.org, etc. ?
        • Développeurs [3] : dans programmer.spip.org, doc.spip.org, etc.
      • Contribuer
        • Contrib : l’actuel spip-contrib.net, mais moins fourre-tout, expurgé pour être re-orienté contribution
        • Wiki : avec un wiki dédié (= l’actuel carnet de contrib, mais à part, pas diffusé ni référencé, pour réfléchir tranquillou) : wiki.spip.org
        • Trad : espace traducteurs, tradlang.spip.org
        • Zone : trac, redmine, etc. zone.spip.org et core.spip.org
        • Créa (NOUVEAU !) : avec espace de dépôt no code et liste dédiée. Si.
      • Blog : blog.spip.net pour les actus, annonces et billets doux :)
      • Forums : forum.spip.org sans oublier irc.spip.org

    Mais, je fantasme... La priorité n’est pas tant d’organiser et ranger tout ça, qui n’existe pas encore vraiment, ni d’en penser la navigation, que de rédiger et mettre à jour (les docs, l’aide, les tutos, etc.) et re-parler aux gens. D’où mon billet.

  • c’est la période des listes de noël,
    il faut lancer une campagne« offrons une doc à spip » ;)
    offrons une doc à spip

  • Je crois que c’est une bonne idée, erational :)
    Et même plus : lançons une campagne « Rendons SPIP à ses utilisateurs » ?

  • Et même plus : lançons une campagne « Rendons SPIP à ses utilisateurs » ?”

    Faut arrêter cette lubie Tetue... ce postulat est erroné dès la question. Il n’y a ni utilisateurs oubliés, ni utilisateurs kidnappés, ni utilisateurs qui ne peuvent accéder à SPIP. Il y a des utilisateurs et des utilisations multiples et variées. Il y a une offre de choses possibles supérieure à avant avec SPIP, et des demandes de choses possibles supérieures également. Évidemment si un outil permet plus de choses (parce que les utilisateurs demandent plus de choses, entre autre !), il est évident que l’outil peut paraître moins abordable. Ce n’est pas pour cela que c’est réellement le cas, et son utilisation est de plus en plus fluide, intuitive et logique même. Je suis fatigué de t’entendre raconter sans arrêt que rien n’est fait pour les utilisateurs ; à chaque fois, cela ne me donne qu’une envie, c’est d’arrêter de participer. On dirait que ce que l’on fait ne va jamais dans le bon sens à chaque fois qu’on te lit. Pourquoi participer et donner du temps dans ce cas ? Peut être parce que la plupart des autres retours sont positifs !! « Mes utilisateurs à moi » sont très satisfaits des améliorations, et s’ils rencontrent des difficultés, ils n’en font pas tout un fromage non plus, ils apprennent, en attendant que SPIP s’améliore encore plus. Mais chaque chose en son temps. Maugréer sur ce qui est fait ou sur ce qui existe parce que ce n’est pas parfait (selon ton point de vue en plus), c’est agaçant. Je ne dis pas que ce que fait SPIP est parfait, que ses raccourcis typo ou l’aide en ligne ou je ne sais quoi n’a pas à être améliorée... mais tout est ouvert, tout se fait lorsque le moment est le bon. Vous êtes vous mis d’accord sur les nouveaux raccourcis typo que vous aimeriez ? je n’ai rien vu de cela je crois encore...

    Par ailleurs, petit détail, je ne suis pas entièrement satisfait de la définition de « webmestre » lorsque tu dis que « dès qu’il y a du PHP, c’est un développeur ». Un webmestre qui inclut des JavaScript, langage plus difficile de compréhension que PHP, dans du HTML, devient-il un développeur également ? Si c’est le cas, nombre de webmestres sont développeurs ! Je dirai plutôt qu’un webmestre peut utiliser des API (il ne les crée pas), que ce soit en JavaScript ou en PHP. Encore que je ne vois aucune raison pour qu’on ne considère pas « webmestre » quelqu’un qui se crée son petit filtre de squelettes dans son squelettes/mes_fonctions.php ou ajoute quelques propriétés dans un config/mes_options.php ... Ça n’en fait pas forcément un développeur non plus :)

    MM.

  • @marcimat : je crois que tetue nous agace souvent parce qu’elle nous dérange dans notre confort de développeur.

    Cela dit je pense sincèrement qu’en ce qui concerne l’approche des utilisateurs elle est bien plus souvent dans le vrai que nous qui avons une vision déformée.

    Il me semble donc qu’on a plus à gagner à l’écouter qu’à l’envoyer promener, même si parfois on pourrait souhaiter que ses remarques soient formulées de façons plus positives...

  • Merci a Marcimat de rappeler, comme Romy (avec un entetement méritoire)
    l’importance des utilisateurs initiaux, c’est a dire ceux qui vont entamer SPIP !

    C’est une aventure qui m’est arrivé il y a peu (d’accompagenr un grand débutant en Web), et je peux vous confirmer que le découragement guette trop facilement le newbie-spip !
    Et meme pour un utilisateur habitué, il reste tres difficile de se tenir au courant, a moins d’etre en permanence sous IRC (ET, abonné aux listes !)

    Or, (excusez-moi de faire un peu de marketing) l’avenir de SPIP (comme pour tout produit), c’est de conquérir de nouveaux utilisateurs, donc, des webmestres !
    L’argument des développeurs (auquel je crois volontiers), c’est que SPIP permettra d’aller plus loin !
    Mais attention !! Voyez comme Drupal 8 se branche sur Symfony2 : il affiche clairement la possibilité prochaine d’etre aussi un framework !
    Voyez aussi la restriction croissante de SPIP qui se restreint en couverture de BdD :
    - Oracle n’a jamais pu etre fini (j’avoue n’avoir pas repris ESJ)
    - Postgres est déprécié (pourtant fondamental pour l’évolution PostGIS)
    - SQL Serveur n’en parlons pas, politique oblige
    (mais si vous pensez aux décideurs cf.ci-dessus, nous privons SPIP de tout un périmètre)
    - et d’ici que MySQL disparaisse pourSQLlite.... j’espere que non !!

    Alors, +1 pour participer a un site clairement orienté accueil du Webmestre débutant
    meme si http://spippourlesnuls.fr/ n’est pas tres avancé, paré à y participer !

    Plus généralement, une remarque globale sur les sites (et pas seulement ceux sous SPIP) :
    ils me semblent trop souvent conçus comme du « libre-service » et non comme un itinéraire guidé : et si les pages sont un peu longues à lire, la nécessité de remonter sur uen barre de menus pour repartir aux articles proches n’est pas tres ergonomique.
    Deux propositions pour l’améliorer :
    - pour les rédacteurs : ajouter régulièrement des liens dans le dernier paragraphe de l’article vers d’autres articles associés
    - pour le webmestre : insérer systématiquement la boucle du plugin Precedent/Suivant en bas de page article, qui garantit une lecture de parcours facile.... (en espérant que l’ordre des articles suivants sera logique : sinon, il faudrait mettre un critère de poids, ou numéroter les articles...)

    Car il me parait impératif de proposer un accompagnement à la prise en compte de l’initiation à SPIP, en prenant en compte deux formes d’accès :
    - la lecture suivie a l’écran (à l’exemple de tutoriels récents sur Symfony2)
    - la lecture (imprimée) d’un document (PDF) explicite, pour les débutants plus « expérimentés » (comprendre, ceux qui ne sont pas trop ’digital natives’... ;-).

    De meme, l’orientation parmi les plugins, thème sur lequel m’a « missionné » JLuc devra aussi se simplifier, dans un site d’orientation, complémentaire au site actuel centralisant la documentation directe, mais me parait moins critique....

    Un dernier souhait, car je n’oublie pas les dev, ou plutot ceux qui « pourraient » les rejoindre (enfin, souhaiter, essayer,..... et payer son ticket !).
    Comment suivre et mémoriser les éléments circulants en particulier sur IRC ?

    mes 2 wish
    YannX

  • Bonjour,

    Pour ma part je trouve aujourd’hui que spip.net, contrib, plugin, et programmer (doc.spip j’ai du mal à savoir comment et quoi y trouver) couvrent plutôt bien les problématiques des utilisateurs. Les admins actuels de ces sites et leurs contributeurs ont fait un très gros efforts de documentation. Perso, lorsque je dois replonger dans le webmastering d’un site spip, j’ai avec moi le manuel des boucles au format pdf que j’ai trouvé sur contrib, le site programmer en pdf et je fouine sur plugin et contrib pour trouver le plugin qui pourrait m’aider.

    Ceci pour dire que le souci de sans cesse remettre la doc en chantier n’a jamais quitté la communauté.

    Je suis aussi très admiratif de la manière dont les développeurs de SPIP ont su gérer le beurre, l’argent du beurre et la crémière, en haussant le niveau de l’outil vers le framework sans abandonner le côté « légos » des boucles. On peut toujours sans maîtriser la machinerie du web monter des sites personnalisés avec spip.

    La difficulté que j’avais ressenti et que je ressens toujours tiens à ce que :

    - tous les sites ne présentent pas leur contenu en fonction de la version de spip que j’utilise

    - tous les utilisateurs de spip ne peuvent pas épisodiquement apporter une pierre ou même un gravillon à l’édifice de la documentation

    J’aime bien programmer.spip.org parce qu’on parle de la dernière version de spip et seulement elle. C’est clair. Je sais ce que je lis et je n’ai pas les lourdeurs de spip.net qui m’explique encore comment fonctionner en php3...

    Pour demain, j’aimerai qu’il ne me parle que de SPIP3 mais qu’il garde à ma disposition en document pdf la version 2.1

    Entre temps, il y aura à écrire mais aussi à relire les articles en fonction de ce que la version 3 aura pu modifier. Y a t il une version wiki où l’on puisse venir aider sur la doc ?

    Mon rêve donc serait une conception des sites de la galaxie spip (en tout cas spip.net, contrib, programmer...) qui permette à chaque nouvelle version de SPIP, de remettre en chantier les articles du site et de laisser à disposition une archive au format pdf de la version précédente.

    La proposition de erational de lancer une campagne pour la documentation de SPIP prendrait tout son sens. Il deviendrait possible, par exemple, de proposer une liste des articles sur laquelle tout contributeur viendrait indiquer qu’il travaille sur tel ou tel article ce qui permettrait de ne pas doublonner les efforts et de visualiser la part d’articles encore à relire et modifier/valider pour la nouvelle version.

    Ce type de campagne serait en soi une communication sur le besoin d’une mobilisation collaborative des utilisateurs de SPIP. Si des parties de documentation devaient rester en attente d’être validées pour la nouvelle version de SPIP le procédé signalerait par lui même aux utilisateurs (nouveaux et anciens) que la communauté SPIP s’organise pour mettre à jour la doc mais qu’elle dépend clairement des bonnes volontés des membres de la dite communauté...

    Amicalement
    Stanislas

  • Et pourquoi pas faire un « Sprint Doc » ? comme chez Mozilla, qui organise un « Mercredi Doc » pour accueillir les nouveaux contributeurs en leur montrant comment c’est trop facile et pas spécialement consommateur de temps de participer à la doc parce que honnêtement, faire de la doc tout seul ce n’est pas ce qu’il y a de plus amusant, par contre, à plusieurs, c’est sympa :)

  • Pour en finir avec l’éparpillement et le chacun dans son coin, les sites fédérateurs doivent être clairs, attrayants et bien valoriser leur contenu !

    Quels sont les éléments qui rendent attrayant ?
    - le layout
    - la clarté de l’organisation
    - l’interaction avec l’internaute

    L’interaction avec l’internaute est d’ailleurs un de ces éléments d’intérêt qui manque sur spip.net : comme tout un chacun, le créateur de doc aime bien avoir des retours sur ses créations. Même s’il faut les canaliser, les commentaires doivent donc être ouverts.

  • Quel utilisateur n’aurait donc pas bénéficié des développements récents de SPIP ?

    C’est évident que pour les utilisateurs qualifiés de webmestres dans cette typologie, il y a plein de nouvelles fonctionnalités puissantes et faciles d’accés. Des choses qui n’auraient même pas été imaginables il y a 5 ans. SPIP à ce niveau a bien accompagné le développement du web.

    Il y a aussi de nouvelles fonctionnalités pour les rédacteurs, mais ceux ci ayant toujours eu moins de champ d’action, ont aussi moins bénéficié de ces nouveautés.

    Mais surtout, le rédacteur est confronté au quotidien à la non évolution de la partie privée dans son layout et surtout dans son fonctionnement, car la madame Michu de la rédaction a l’habitude de wysiwyg, de glisser déposer, d’ajax efficace. A force d’évoluer aussi peu à ce niveau, SPIP déçoit et devient pénible à utiliser, simplement parceque maintenant on a l’habitude de plein de facilités.

  • Bonjour à tous,

    Je reviens sur ce billet de Romy, qui a lancé la discusssion,
    pour remercier autant Bernard qui m’a permis de compléter
    déja grandement Spip pour debuter, alias SPN

    Bonne lecture,
    et merci de nous faire part des questions restantes,
    (ou de toute erreur encore presente)

    Cdlt

Un message, un commentaire ?

Qui êtes-vous ?
Se connecter
Votre message

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