Framavox

Action 8 - Typologie des articles

Maïeul
Maïeul Public Seen by 30

En dehors de la question de la structure arborescente, il y a la question de la typologie des articles, notamment avec l'idée de séparer des doc de plugins, des éléments de conception, etc.

État au 27 avril :
- On utilisera un champ extra type_article
- Il y aura trois types d'articles : utilisation (défaut), conception, actualité
- Si jamais le champ type_article est vide, l'article est considéré comme une documentation d'utilisation

Maïeul

Maïeul April 18th, 2019 16:03

Proposition :
- Documentation utilisateur·ice
- Documentation intégrateur·ice
- Documentation programmeur·euse

A mon sens, les élèements de conception SONT de la documentation. Mais @rastapopoulos a je crois une autre vision

Lupinacci Eric

Lupinacci Eric April 18th, 2019 18:06

Je renouvèle mon alerte sur l'utilisation des mots clés qu'il faudra appliquer à des centaines d'articles. Forcément cela dérivera et les mécanismes basés dessus deviendront quelque peu caduques.
Je pense que le rubricage est bien plus efficace et pérenne pour identifier les différentes documentation de plugins, de carnet et de projets.
Le mot-clé doit être un plus qui apporte de l'information supplémentaire mais qui ne casse pas la logique si il n'est pas présent.

Maïeul

Maïeul April 18th, 2019 21:09

je suis d'accord avec toi pour les problèems de mot clé s'ils ont une fonction thématiques (ce dont parle tel ou tel article), pas s'ils ont une fonction de nature (le type d'article dont il s'agit)

Lupinacci Eric

Lupinacci Eric April 19th, 2019 07:44

J'ai l'impression que je dis exactement le contraire non (corrige moi si j'ai mal interprété) : thématique => mot-clé, type => pas de mot-clé.

Maïeul

Maïeul April 19th, 2019 07:51

ah donc on est pas d'accord. Je vois pas l'interet d'avoir des mot clé thématique si on une arborescence hiérarchique par catégorie

Lupinacci Eric

Lupinacci Eric April 19th, 2019 08:00

Parce que tu ne peux pas tout exprimer en une arborescence. Si tu lis le message que j'ai envoyé hier sur la méthode que j'ai adoptée pour revoir les catégories, j'ai pris le parti d'éviter de ranger les plugins dans une catégorie "outil" qui finalement est devenue un fourre-tout innommable. Donc, si je range les outils dans une catégorie qui exprime leur fonctionnalité, je peux avoir envie de savoir que c'est un outil et pas une fonctionnalité utilisateur. Et là un mot-clé fait l'affaire car si je l'oublie et bien c'est dommage, je perd de l'information, mais ça ne m’empêche pas d'avoir une arborescence correcte.

C'est un peu comme ça que je vois l'organisation finale, mais ce n'est que ma vision.

RastaPopoulos

RastaPopoulos April 19th, 2019 13:03

Là on ne parle absolument pas de rangement donc non aucun rapport avec l'arborescence, avec la hiérarchie des rubriques. Et d'ailleurs pour ça peut-être changer le titre de la discussion : je ne parlerais pas de catégories du coup (rangement) mais de typage/typologie des articles (à quoi ils servent et non pas de quoi ils parlent).

Là on parle de permettre (mot-clé ou autre peu importe) la distinction du type d'article, afin de pouvoir très concrètement changer l'ergonomie du site, et notamment l'ergonomie de deux endroits principaux :
1) la page d'accueil générale
2) l'accueil d'un projet précis (plugin ou pas)

L'idée étant dans ces deux endroits de distinguer très clairement, du premier coup d'œil, ce qui est de l'aide pour utiliser, ce qui est de la conception technique, ce qui est de l'actus pour informer d'une nouveauté. Et ça ça n'a aucun rapport avec le rangement : on parle bien de type d'articles dans un MEME plugin, un même projet (donc dans la même rubrique).

On n'est absolument pas d'accord pour le moment avec @maieul sur ce typage. :)

Comme dit ailleurs, je pense qu'il en faut 5 grands maximums, et j'en vois seulement 3 pour l'instant. À mon sens il ne faut surtout pas détailler, mais bien faire quelques grands types quand le sens n'est pas du tout le même.

Par exemple, la doc d'utilisation d'un plugin, et un tutoriel pas-à-pas ou un screencast, ce n'est pas la même manière de rédiger, mais ça sert à la même chose et c'est destiné à peu près à la même personne : expliquer comment utiliser. Donc ça DOIT être dans le même type, et il ne faut pas détailler.

C'est pour cela que moi je voyais seulement :
- conception
- documentation
- actualité

Le mot "documentation" si tu vas par là @maieul ça peut être n'importe quoi en fait, car "documenter" c'est tout, dès qu'on écrit on documente, qu'on parle à l'utilisateur ou qu'on explique la conception technique à des devs. Je ne suis pas contre reformuler, mais mon découpage serait le même. Par exemple :
- conception
- aide
- actualité

Un article de conception peut être écrit avant même qu'il y ait le moindre code, mais pourtant le projet existe, que ce soit la création d'un plugin ou la refonte ergo d'un site de la galaxie. Mais ça peut aussi être après dans un projet déjà existe, pour la refonte d'un plugin par exemple, ça reste de la conception aussi.

La documentation (ou l'aide), c'est pour expliquer comment l'utiliser, que ce soit dans l'interface, dans des boucles, ou même pour une API en PHP pour des dévs.

L'actualité c'est des tous petits articles, pour dire qu'on a ajouté une fonctionnalité à un plugin existant par exemple. Ça nous déculpabiliserait et on fera plus d'annonces de ce genre, alors qu'on ne le fait à peu près jamais actualitement. Mais on le fera enfin souvent si ces articles n'étaient pas du tout mélangé au reste, et présentés dans une liste à part.

Donc voilà, moi je ne vois vraiment que ces trois là, sans détailler plus.

Maïeul

Maïeul April 19th, 2019 13:22

ok, je vois plus clair. Pour répondre rapidement.
- catégorisation ou typage, peut me chaud le terme, du moment qu'on est d'accord que ce n'est précisement pas une arborescence
- effectivement, documentation pourrait s'entendre au sens très large. Cela étant, après refelxion, je pense que "documentation" est mieux "qu'aide" car les gens l'entendent spontanéemnt au sens restreint
- ok pour pour ta tripartition.

Lupinacci Eric

Lupinacci Eric April 19th, 2019 16:08

Oui je plussoie.

Je propose comme Rasta qu'on parle de catégorisation pour les plugins au sens de l'organisation des rubriques. Pour les articles le terme typologie me parait très bien adapté.
D'accord aussi pour les 3 types, je pense qu'on pourrait remplacer aide par utilisation qui je trouve fait mieux le pendant à conception.

Je pense qu'on commence à s'approcher d'une vision d'ensemble de l'organisation des rubriques et des articles.

Maïeul

Maïeul April 19th, 2019 16:47

la typologie devrait être obligatoire : groupe de mot clé "impératif" + plugin "mot obligaoire" non?

Lupinacci Eric

Lupinacci Eric April 19th, 2019 16:59

Oui c'est aussi une possibilité.

RastaPopoulos

RastaPopoulos April 19th, 2019 17:15

@maieul ça pourrait oui. Ça dépend de ce qu'on dit dans l'autre fil : à la suite de la remarque d'Éric, je me dis qu'on pourrait dire que par défaut tout ce qui n'a pas de typage est une documentation. Ce qui évite de devoir typer de nooooombreuses choses. Et comme ça on devrait que faire le boulot de typer les conceptions et annonces/actus (pour les anciens là dans le rangement, et à vérifier rapidement pour les nouveaux).

cy_altern

cy_altern April 20th, 2019 15:09

OK aussi pour la tri-partition de @rastapopoulos (et amha "documentation" mieux que "aide")

C

chankalan April 24th, 2019 07:04

OK aussi, ça paraît très bien.

Lupinacci Eric

Lupinacci Eric April 24th, 2019 11:53

Je crois qu'on est d'accord sur la typologie à 3 valeurs. Le seul truc qui me gêne c'est le terme "documentation" par opposition à "conception". Tout est documentation.
Les alternatives que je vois, en considérant que "conception" et "actualité" conviennent à toute le monde, sont:
- utilisation ou utilisateur (au sens de manuel utilisateur)
- aide (proposition de Rasta)
- exploitation (au sens de doc d'exploitation)
- guide (peut-être trop restrictif)
- mode d'emploi
- tutoriel
- prise en main
- référence

Maïeul

Maïeul April 25th, 2019 12:02

perso "utilisation" me paraît bien :). Tuto/prise en main sont trop spécifiques. De même que référence (ou alors on distingue tuto vs référence). mode d'emploi ca fait IKEA. Aide je trouve ca va pas, parce que tout peu aider. Donc "Utilisation" (plutot qu'utilisateur, qui en plus serait pas épicène) me semble le mieux. Autre solution : "manuel" ?

RastaPopoulos

RastaPopoulos April 27th, 2019 13:35

guide, mode d'emploi, tutoriel, ce sont des types de docs utilisateurs, suivant leur "format", une manière de rédiger (des sous-types quoi), donc trop précis.

Comme je l'ai déjà dit plus haut, oui si on veut "documentation", ça peut vouloir tout dire. Mais dans le langage courant, pour la majorité des utilisateurs, la doc c'est comment utiliser un truc (que ce soit une interface mais aussi une API PHP), c'est la réponse à la question "comment moi je peux l'utiliser". Alors que conception c'est la réponse à "comment c'est fabriqué, comment c'est architecturé". Voilà pourquoi le mot "documentation" continue de me paraitre clair quand même pour la majorité des gens, ya juste 2 ou 3 personnes qui se poseront la question maxi.

Si vraiment on ne l'utilise pas, alors ma préférence va pour "utilisation", car c'est bien ça qu'on veut regrouper dans ce type : la doc d'utilisation, comment utiliser ce projet.

Maïeul

Maïeul April 27th, 2019 13:42

Si conception c'est "comment c'est architecturé", je vois pas en quoi
cela n'aide pas à utiliser... c'est aussi un sous type de doc.

Quid de "manuel"?

Lupinacci Eric

Lupinacci Eric April 27th, 2019 13:58

Dans l'ingénierie on distingue les documents de conception, d'exécution (as built), de formation et d'exploitation (exploitation et maintenance). En général, on réserve le terme manuel à l'exploitation et la maintenance mais c'est pas une règle intangible.
Franchement au fil de nos échanges je trouve que le meilleur compromis est conception, utilisation et actualité.

Maïeul

Maïeul April 27th, 2019 14:00

Ce compromis me va

RastaPopoulos

RastaPopoulos April 27th, 2019 14:01

Moi ça me va.

(Et non "comment c'est architecturé" ça ne sert pas du tout à l'utiliser, tu n'as pas du tout besoin de savoir ça pour l'utiliser. Tu as besoin de le savoir si tu veux aider au dévelopepement du projet, mais pour l'utiliser tu dois juste savoir soit l'interface, soit les boucles/balises que ça fournit, soit l'API publique PHP que ça fournit, mais pas du tout comment c'est architecturé.)

Maïeul

Maïeul April 27th, 2019 14:06

bon, ben je crois qu'on arrive à un consensu :)
(je crois que le terme "architecturé" a induit de la mecomprhension chez moi)

Lupinacci Eric

Lupinacci Eric April 27th, 2019 14:07

Ok, je mets ça dans le texte d'accueil.
Je ferme le fil ?

Maïeul

Maïeul April 27th, 2019 14:09

j'ai deja modifié le texte d'accueil. Mais allonsy pour fermer le fil
(et modifier le texte d'accueuil pour dire décison finale)

Lupinacci Eric

Lupinacci Eric April 27th, 2019 14:11

J'ai modifié un peu le texte d'accueil. Si on ferme on ne va plus voir le fil dans la liste. Je propose que pour l'instant on indique dans le titre que la discussion est close.

Maïeul

Maïeul May 5th, 2019 21:26

je rebondi la dessus, et je reviens. A mon sens un type non defini c'est pas top. J'aurais pluitot tendance à dire : typo retroactivement en utilisation tous les articles, et proposons par défaut comme type d'article "utilisation". Plutot que de dire type vide = utilisation. Je trouve ca plus propre.

RastaPopoulos

RastaPopoulos May 5th, 2019 21:32

On peut typer au maximum. Mais les squelettes devront toujours être souples et savoir quoi faire lorsqu'un article n'a pas de type rempli (et donc le prendre comme étant de l'aide utilisateur), de toute façon.

Maïeul

Maïeul May 5th, 2019 21:37

alors ok dans ce sens. Encore qu'avec champ extra, on peut rendre
obligatoire le typage, donc a priori ces cas ne devraient pas se poser.

RastaPopoulos

RastaPopoulos May 5th, 2019 21:49

Il ne faut jamais dire ça. :p
C'est une bonne pratique de programmation de toujours être strict en sortie (s'assurer que ce qu'on produit est le mieux possible), mais souple en entrée (s'attendre à gérer des cas tordus). Je me rappelais d'un article de Bortzmeyer qui évoquait ça mais je le retrouve plus. :)

Maïeul

Maïeul May 5th, 2019 22:22

il y a du vrai dans ce que tu dit. cela étant ca couterait pas grand
chose de remplir quand même, même si oui souplesse en entrée.

Lupinacci Eric

Lupinacci Eric May 6th, 2019 07:35

En fait, je me suis reposé la question hier en écrivant le doc parce que je me suis demandé si le typage qu'on propose est bien à utiliser dans tous les secteurs et pas uniquement dans les secteurs-plugin ?

RastaPopoulos

RastaPopoulos May 6th, 2019 07:55

Moi je pense aussi que ce n'est pas partout et que donc dans l'admin on ne doit pas l'imposer. Par exemple je pense que ça n'a aucun sens dans le carnet, c'est un wiki, on peut même créer des pages depuis la partie publique, c'est totalement libre, le wiki n'a pas à être cloisonné comme la partie éditoriale.

Lupinacci Eric

Lupinacci Eric May 6th, 2019 08:12

C'est bien mon avis aussi. Mais dans ce cas le problématique de l'interprétation de la valeur vide diffère d'un secteur à l'autre non ?

RastaPopoulos

RastaPopoulos May 6th, 2019 08:15

Bah c'est à chaque partie de squelettes de l'interpréter suivant son contexte. Et c'est bien pour ça que là en "entrée" le codage doit être souple. Dans tous les cas dans les parties où ya pas besoin (par ex Carnet), bah c'est sans objet puisque justement on l'utiliserait pas dans cette partie, et dans la partie publique, les squelettes de Gribouille n'en tiennent pas compte du tout de toute façon.

Maïeul

Maïeul May 6th, 2019 08:23

effectivement j'avais oublié cette problématique de multi sectorialité....

Lupinacci Eric

Lupinacci Eric May 6th, 2019 08:23

Ok, ça doit le faire. On part comme ça.

Lupinacci Eric

Lupinacci Eric May 6th, 2019 08:52

Je recopie ici ce que j'ai écrit dans mon GDoc. Est-on d'accord sur cette interprétation ?

La typologie des articles est également mise en place au travers d’un champ additionnel à l’objet Article nommé “type_article” qui contiendra les valeurs suivantes:
- “conception”, pour un article-conception,
- “actualite”, pour un article-actualité,
- “”, pour les autres articles. C’est la valeur par défaut du champ.
Cette valeur est interprété différemment suivant le secteur. Pour un secteur-plugin, cette valeur sera interprétée comme un article-utilisation. Pour le Carnet Wiki ou le secteur “A propos de Contrib” c’est la seule valeur possible. Pour le secteur Galaxie l’interprétation est identique à celle des secteurs plugins.

Maïeul

Maïeul May 6th, 2019 08:55

OK pour moi

RastaPopoulos

RastaPopoulos May 6th, 2019 09:45

Perso je ne suis pas contre (et c'est peut-être mieux) qu'il y ait un vrai type explicite pour l'aide utilisateur. Comme je le disais strict dans ce qu'on produit, mais souple sur ce qu'on reçoit. Mais le type peut-être toujours être vide (et dans une bonne partie du site, le vide serait reconnu comme l'aide utilisateur aussi par défaut).

Lupinacci Eric

Lupinacci Eric May 6th, 2019 11:26

Si je résume autrement ma proposition c'est en fait le "vide" s'interprète suivant le secteur et on a deux cas particuliers qui sont actualité et conception qui eux ont toujours la même interprétation. Et c'est les squelettes qui gèrent ça (surement avec un filtre bien pensé).

Lupinacci Eric

Lupinacci Eric May 14th, 2019 07:20

J'ai mis en oeuvre la notion de type d'article et d'article principal. Le type d'article avec un champ extra et l'article principal avec le plugin article d'accueil.
J'ai deux questions :

Pour le type d'article, 3 choix sont possibles, utilisation, conception et actualité. Lors de l'édition d'un article on a toujours ce choix proposé. Ne faudrait-il pas exclure certains choix suivant le secteur ?

Le plugin article d'accueil propose d'emblée la liste des articles de la rubrique quelque soit leur type et leur statut. J'ai fait une modification hier sur le plugin afin que l'on puisse modifier la liste des statuts autorisés et éventuellement ajouter un filtre.
Aussi :
* ne faudrait-il pas réduire les statuts (mais ça voudrait dire qu'on ne pourrait pas choisir l'article au début) ?
* et surtout ne faudrait-il pas réduire la liste des articles à ceux du type "utilisation" uniquement ? On pourrait aussi choisir un article "conception" pour un projet uniquement.

A votre avis ?

JLuc

JLuc May 15th, 2019 11:54

Si jamais il est utile de restreindre, ça me semble pas important de le décider tout de suite.

Lupinacci Eric

Lupinacci Eric May 15th, 2019 12:02

En tout cas j'ai les outils pour le faire facilement par paramétrage avec les modifications que j'ai faites dans le plugin contrib et article_accueil.

RastaPopoulos

RastaPopoulos May 16th, 2019 13:07

Pour le type, je le disais je ne sais plus quand : ça peut être filtré suivant les compositions sûrement. Car les rubriques-catégories vont aussi avoir une composition dédiée sûrement (vu que possiblement présentation dédiée). Ce qui permettrait déjà de pas afficher les types dans le Carnet par exemple.

Pour l'article d'accueil, non, je ne vois pas pourquoi on limiterait quoi que ce soit. C'est de l'éditorial, ya rien à bloquer techniquement. Je peux préparer ma rubrique et déjà savoir lequel des articles sera le principal. Et je peux y mettre n'importe lequel des articles, c'est pas à toi de le dire. Après ya des admins qui relisent, donc suivant une charte éditoriale, mais pas technique bloquée.

Lupinacci Eric

Lupinacci Eric July 25th, 2019 08:00

Petit up en relation avec ceux des actions 3 et 2:
La typologie des articles est opérationnelle dans le plugin Contrib.
A voir dans le site de démo (cf. actions 2 et 3).