[spip-dev] Différentes vues sur les médias attachés à un objet éditorial

Hop, je rebondis sur ce que je disais dans l'autre discussion sur Ordoc.

2) Autre demande qui arrive parfois c'est que dès lors qu'il y a plus de, disons, 10 documents sur un article, la liste assez très longue, et ce n'est pas toujours parfaitement pratique. Est-ce que d'avoir un JS (encore) qui ajouterait un changement de vue (une bascule vue dépliée (l'actuelle), vue courte (à définir), par exemple juste des vignettes), à droite des grands blocs (À droite du titre "Illustrations" par exemple), pourrait être utile ?

On vient d'en faire une implémentation dans un plugin nommé "Minidoc" actuellement, qui peut être testé en 3.1 (comme Ordoc d'ailleurs).

Je ne suis pas expert de CSS/JS, mais on a avec le plugin 3 vues :
- la première existe par défaut, la vue complète
- la seconde est une vue en cases / grille des icones
- la troisième est une vue en liste compacte

Un cookie sauve la vue choisie pour les 3 blocs (illustrations, portfolio, documents), de sorte que si la page est réaffichée ou si on va sur un autre article, le même affichage sera réutilisé.

Une petite vidéo présente rapidement ce que cela fait : http://medias.spip.net/medias/demonstrations/article/presentation-de-minidoc

Des avis ? Ça serait bien dans le plugin Médias de SPIP 3.2-dev non ?

MM.

On vient d'en faire une implémentation dans un plugin nommé "Minidoc"
actuellement, qui peut être testé en 3.1 (comme Ordoc d'ailleurs).

Une petite vidéo présente rapidement ce que cela fait :
http://medias.spip.net/medias/demonstrations/article/presentation-de-minidoc

Ça marche très très bien :slight_smile:

Des avis ? Ça serait bien dans le plugin Médias de SPIP 3.2-dev non ?

Ouiiii, 3 fois oui.

Ça a l'air très pratique.
Donc oui : oui oui oui !

JLuc

Où je raconte ma vie et partage aussi un peu de lumière.

Hello
comme vous peut être, j'ai regardé la démo du travail de marcimat
> http://medias.spip.net/medias/demonstrations/article/presentation-de-minidoc

Dans cette vidéo, j'intuitais que l'image exemple téléversée
irait rejoindre le groupe "Portfolio"
puisqu'elle n'est pas inclue en tant qu'illustration dans le texte
et qu'elle ne sera affichée, a priori, que via le "portfolio"
qui existe par exemple dans les squelettes-dist en dessous du texte.

Ça aurait été d'une certaine logique, non ?
Ben non, elle va dans les "Illustrations"
et elle n'est affichée nulle part dans la page publique.

J'imaginais alors plusieurs hypothèses et voulais les tester...

En essayant sur demo.spip.net,
toutes mes images ont été dans "Illustrations",
qu'elles soient téléversées via la page de visu (où on "Ajoute un document")
ou d'édit (où on "Ajoute une Image ou un document")
et qu'elles soient inclues ou non dans le corps du texte avec <img...>
(ça aurait pu être en rapport avec le champ "vu").

Finalement, je n'arrivais plus à imaginer ce que peut être ce "Portfolio",
et la doc sur spip.net ne m'a jamais éclairé à ce sujet.
C'est finalement le bouton "déposer dans le Portfolio" qui m'a fait comprendre :
effectivement, dans le privé il fait apparaître l'image dans la liste "Portfolio",
et dans le public l'image apparaît dans le diaporama en dessous de l'article.

Donc le portfolio, c'est un sous ensemble des documents associés à un objet éditorial,
défini par le choix de l'utilisateur au moyen des boutons "déposer dans le Portfolio",
et cette sélection permet dans spip-dist de faire un diaporama en dessous de l'article.

En fait, il y a plusieurs plugins dans SPIP pour faire des sélections éditoriales,
des grappes ou des listes.
Le portfolio est donc une manière standard dans SPIP de faire ça,
mais uniquement pour les documents.

Ayant compris cela je comprend mieux (l'intérêt) d'autres parties de la doc.
Par exemple la doc précise que l'interface d'insertion des documents
est différente pour les documents du portfolio :
« Lorsque vous éditez votre article, l’ensemble des médias est listé sur le côté.
Les icônes permettent de distinguer les médias :
icône type d’image code d’insertion proposé
Carte postale Illustration <img>
Pièce jointe Portfolio <doc>,<emb> »
Ah.
Cette seconde fonctionnalité me semble ne pas avoir de rapport avec la première a priori
et je me demande un peu pourquoi elles sont combinées.
Une justification fournie par la doc est que le porfolio contient des documents plus gros, qui nécessiteraient un diaporama.
Un peu comme une distinction entre image css de déco et image porteuse de sens ?
Sauf que « Gros » / « Pas gros », ça ne me parle pas vraiment vu que les squelettes réduisent automatiquement à la taille désirée, que ce soit dans un diaporama a part ou dans le corps du texte.
Et d’ailleurs, même si l’interface ne le propose pas,
tous les raccourcis fonctionnent toujours, même pour des documents qui ne sont pas dans le portfolio.
Comme si cette distinction était somme toute assez floue.

Par ailleurs, continuant à explorer j'ai découvert qu'un document présent dans le portfolio
n'apparaissait PAS dans le diaporama en bas de l'article s'il était inclu
dans le corps de l'article.
Ça se compliquait.
Mais en allant voire squelette-dist/inclure/documents.html
j'ai vu que l'affichage public dans le portfolio résultait de la combinaison
de 2 critères : {mode=document} et {vu=non}
J'en ai déduit que
- les documents du portfolio apparaissent grâce à {mode=document},
qu'ils soient insérés ou non dans le corps du texte
- on exclu ceux qui sont dans le texte avec {vu=non}
Ouf, c'est plus simple comme ça.

Puis j'ai cherché à savoir comment ça se passait lorsqu'un document
est associé à plusieurs articles
et j'ai trouvé que si un document est mis dans le portfolio pour un article,
il est dans le portfolio "partout".
Le portfolio n'est donc pas une sélection relative à un article,
car c'est un objet global à tout le site.
OK.

Alors peut être y aurait il moyen d'indiquer, dans ces bandeaux qu'on voit sur la vidéo,
ce que signifient "Illustration" et "Portfolio" par un title malin sur le titre
voire par un lien "i" vers une aide plus conséquente ?

Mais je me suis dit que la priorité était de partager mes trouvailles.
Voilà.
Et pour référence ultérieure je reporte sur
https://contrib.spip.net/Comprendre-le-portfolio-et-les-illustrations

Je crois aussi que la doc sur cette notion de "portfolio" est éclatée
entre doc sur l'interface privée et doc sur les boucles DOCUMENT
et que c'est cela, probablement, qui avait bloqué ma compréhension jusqu'à présent.
Si cette notion est vouée à perdurer (il y aurait une refonte en vue ?)
ce serait bien, à mon avis, de rassembler dans un même article sur ce thème
ou d'ajouter des liens des uns vers les autres.

SPIP c'est fouuuuu !
JL

JLuc a écrit le 10/01/2017 à 19:05 :

Mais je me suis dit que la priorité était de partager mes trouvailles.
Voilà.
Et pour référence ultérieure je reporte sur
Comprendre le portfolio et les illustrations (tentative)

De mon côté, voici le support de formation que j'ai écrit :

Cette documentation amorce une globalité de la description,
et précise bien et détaille certaines intuitions :
"porteuses de sens, il est impératif de leur donner un titre"...

Mais à cette doc comme à celle de spip.net,
il manque pour cerner le portfolio la description de l'autre interface du portfolio,
l'interface non avec le rédacteur mais avec le codeur,
c'est à dire le critère {mode} de la boucle DOCUMENTS.
Sans la doc de cette interface, les explications restent floues et vaguement magiques :
"Une image placée dans le Portfolio sera automatiquement utilisée pour faire une galerie en bas de l’article."
Ben non, si on fait son propre squelette, ça sera pas automatique : il faut une boucle,
et pour reproduire le fonctionnement de la dist il lui faut la combinaison de 2 critères
({mode} et {vu}).

JL

Au top ! Ça manquait ce genre de fonction :slight_smile:

Teenoo

Hop, je rebondis sur ce que je disais dans l'autre discussion sur Ordoc.

2) Autre demande qui arrive parfois c'est que dès lors qu'il y a plus de, disons, 10 documents sur un article, la liste assez très longue, et ce n'est pas toujours parfaitement pratique. Est-ce que d'avoir un JS (encore) qui ajouterait un changement de vue (une bascule vue dépliée (l'actuelle), vue courte (à définir), par exemple juste des vignettes), à droite des grands blocs (À droite du titre "Illustrations" par exemple), pourrait être utile ?

On vient d'en faire une implémentation dans un plugin nommé "Minidoc" actuellement, qui peut être testé en 3.1 (comme Ordoc d'ailleurs).

Je ne suis pas expert de CSS/JS, mais on a avec le plugin 3 vues :
- la première existe par défaut, la vue complète
- la seconde est une vue en cases / grille des icones
- la troisième est une vue en liste compacte

Un cookie sauve la vue choisie pour les 3 blocs (illustrations, portfolio, documents), de sorte que si la page est réaffichée ou si on va sur un autre article, le même affichage sera réutilisé.

Une petite vidéo présente rapidement ce que cela fait : http://medias.spip.net/medias/demonstrations/article/presentation-de-minidoc

Des avis ? Ça serait bien dans le plugin Médias de SPIP 3.2-dev non ?

MM.

Moi non plus, j'ai jamais compris cette histoire de portfolio… du coup je m'en sert pas, et j'utilise uniquement {vu}. Et je surcharge les modèles par défaut pour qu'il oublie cette histoire de mode document/images.

J'espérais que relater mon parcours de découverte aiderait aussi à comprendre.
As tu lu en détail ?

Avec le recul de la nuit je m'aperçois que l'analogie de "portfolio"
avec "selection éditoriale" ou "grape" est en fait inadéquat
car il n'y a qu'un seul et unique "portfolio" pour tout le site.
C'est plus comme une banale case à cocher sur les documents.

La notion de Portfolio, ça part d'une bonne intention (calquer l'UI sur une notion de la vie courante),
mais l'implémentation et la documentation sont trompeuses.
Pour mettre à plat le truc, voici des explications qui semblent complètes
et plus clairement structurées :

Pour complèter la discussion en essayant de pas la noyer :

- le portfolio a un défaut technique historique, il porte sur le document et pas sur le lien — c'est du à l'époque où on ne pouvait pas associer un même document à plusieurs articles.
Du coup si on passe un document en portfolio sur un article, il y est aussi pour tous les autres articles auxquels il est attaché. C'est un bug historique à corriger

- le "portfolio" n'est ambigu que pour les images : tous les documents non visuels sont de facto dans le portfolio. Ce sont les documents joints à l'article.

- le portfolio actuel du core, dans son usage tant que dans son esprit s'apparente à un album de documents du plugin albums

Pour le futur :

A ce titre je pense que ça devrait disparaitre du core et que cette fonctionnalité devrait être émulée/proposée par le plugin albums pour les afficionados de cette feature
"Déposer dans le portfolio" créerait automatiquement un album "Portfolio" associé à l'article
De même l'association d'un pdf a un article créerait automatiquement un album portfolio

- le champ 'mode' serait supprimé de la table des documents

- le compilateur introduirait une compilation dérogatoire pour traduire 'mode=document' en 'document qui est dans un album de type portfolio'
(ou alors on déplace le champ mode sur la table spip_documents_liens, et on laisse le plugin album gérer ce champ de façon à ce qu'on retrouve nos petits dans les boucles)

oui, oui, j'ai lu. Et bien compris, mais enfin c'est juste impossible à retenir comme logique :stuck_out_tongue:

Complètement d'accord.

Cédric, ce serait bien de poser ça dans un ticket pour garder une trace (et en discuter), et de l'attacher au méta ticket sur la gestion des documents :
https://core.spip.net/issues/3582

Et du coup, de proposer de fermer Evolution #2099: le mode des documents sur le liens et non sur le document - Medias - SPIP Core (Forge de développement) qui date de cinq ans ?

Pour l'intégration de Minidoc et Ordoc à Medias en 3.2, ce serait pas mal de faire un ticket évolution et de l'attacher au méta ticket roadmap sur la gestion des documents :
https://core.spip.net/issues/3582

- le "portfolio" n'est ambigu que pour les images :

> tous les documents non visuels sont de facto dans le portfolio.
> Ce sont les documents joints à l'article.

Qu'appelles tu, ici, "portfolio" ?
Je ne comprends pas car
- dans le privé, les documents (PDFs...) n'apparaissent ni dans "Portfolio"
ni dans "Illustrations" mais dans "Documents"
- dans le public avec squelettes-dist, ils n'apparaissent pas dans "Portfolio"
mais dans "Documents".
Cf http://demo.spip.net/Comment-ca-marche (valable ce jeudi seulement)

si on passe un document en portfolio sur un article,

> il y est aussi pour tous les autres articles auxquels il

est attaché. C'est un bug historique à corriger

Bug ou feature ? Un unique portfolio global a la vertu de la simplicité.

Actuellement l'usage dans le public embrouille le truc
à cause du mélange {vu=non} et {mode=document}
qui mêle le global au site et le local à l'article
et décorrèle le "portfolio" donné à voir dans le public
du "portfolio" créé dans le privé.

- le portfolio actuel du core, dans son usage tant que dans son esprit s'apparente

> à un album de documents du plugin albums

Super animations dans cette vidéo !
L'interface d'utilisation du plugin a l'air super sympa aussi.
Comme dans ce qu'a fait marcimat dans ordoc, il y a du glisser-déposer
et cette modernité est bien agréable.

Je m'inquiète de la nécessité de valider les déplacements après les avoir fait,
car le bouton de validation est tout en bas et il faut scroller pour le voir,
et ça me rappelle la nécessité de valider un changement de rubrique après l'avoir "fait",
(très souvent oublié par les rédacteurs, en spip 2.1 du moins)

Au niveau des squelettes le plugin est compatible avec tous objets éditoriaux :
« Les albums ont une jointure automatique pour tous les objets (cf. déclaration de la base).
[Dans une boucle] Dès qu’un qu’un id_xxx est présent dans l’environnement,
on peut donc sélectionner les albums liés à l’objet sans avoir à faire de jointure explicite
avec la table de liens »
MAIS les modèles <album> et <album_liste> ne gèrent encore QUE les articles :

Il faudra élargir.

Pour le futur :
A ce titre je pense que ça devrait disparaitre du core et que cette fonctionnalité devrait être émulée/proposée par le
plugin albums pour les afficionados de cette feature
"Déposer dans le portfolio" créerait automatiquement un album "Portfolio" associé à l'article
De même l'association d'un pdf a un article créerait automatiquement un album portfolio
- le champ 'mode' serait supprimé de la table des documents
- le compilateur introduirait une compilation dérogatoire pour traduire 'mode=document' en 'document qui est dans un
album de type portfolio'
(ou alors on déplace le champ mode sur la table spip_documents_liens, et on laisse le plugin album gérer ce champ de
façon à ce qu'on retrouve nos petits dans les boucles)

Mais quel serait alors le nouveau squelette de la dist,
c'est à dire comment sera remplacé cette boucle trompeuse avec {vu=non}{mode=document}
qui donne à voir un faux-frère du portfolio défini dans le privé ?

J'ai l'impression que la réponse devrait être différente
pour des upgrades sans douleurs où il faut conserver le rendu actuel
et pour des installation nouvelle avec conception non ambigüe du portfolio.

JL

Je pense que Cédric parlait du point de vue technique sous-jacent.
Le "portfolio" et les "documents" ont le même mode en base de données (mode=document). C'est l'extension des documents qui différencie les 2 (les images sont dans portfolio, le reste dans documents).

Les illustrations ont "mode=image".

Et il y a même un 3è mode "mode=vignette" lorsqu'on ajoute une vignette sur un document (dans ce cas là le document «parent» a le champ id_vignette renseigné).

MM.

2) Autre demande qui arrive parfois c'est que dès lors qu'il y a plus
de, disons, 10 documents sur un article, la liste assez très longue,
et ce n'est pas toujours parfaitement pratique. Est-ce que d'avoir un
JS (encore) qui ajouterait un changement de vue (une bascule vue
dépliée (l'actuelle), vue courte (à définir), par exemple juste des
vignettes), à droite des grands blocs (À droite du titre
"Illustrations" par exemple), pourrait être utile ?

On vient d'en faire une implémentation dans un plugin nommé "Minidoc"
actuellement, qui peut être testé en 3.1 (comme Ordoc d'ailleurs).

[...]

Des avis ? Ça serait bien dans le plugin Médias de SPIP 3.2-dev non ?

On vient d'intégrer le plugin "Minidoc" au plugin "Medias" dans SPIP 3.2-dev directement. Il restera plus qu'à l'améliorer si besoin.

MM.