[SPIP Zone] gestion documents (Mediathèque)

[Paolo]

Bonjour,

Nous utilisons SPIP 2.0 (stable) SVN en production avec gestion_documents

Deux retours d'expérience :

1) Je traduirais le plugin gestion_documents très volontiers. Y a-t-il un projet de l'intégrer dans le système de traduction SPIP (ce qui facilite beaucoup la maintenance des traductions) ?

2) Nos rédacteurs se plaignent que les images dans les portfolios sont trop petites pour même identifier ce qui est sur l'image.
Pour l'instant chez nous j'ai palié à ceci en changeant ligne 17 du fichier
/gestion_documents/modeles/document_desc.html à :
    [(#LOGO_DOCUMENT{80,80}|#URL_DOCUMENT)]
(au lieu de {40,40}).
Si cela est nécessaire de garder le 40,40, est-ce que des paramètres comme celui-ci pourrait être placer dans un endroit modifiable par l'utilisateur (Avec cfg ??)

Paolo

[cerdic]

Le 14 juil. 09 à 10:57, Paolo a écrit :

Bonjour,

Nous utilisons SPIP 2.0 (stable) SVN en production avec gestion_documents

Deux retours d'expérience :

1) Je traduirais le plugin gestion_documents très volontiers. Y a-t-il un projet de l'intégrer dans le système de traduction SPIP (ce qui facilite beaucoup la maintenance des traductions) ?

Super !
J'essaye de finaliser l'interface avant de le mettre dans le système de traduction.
Je veux revoir le fonctionnement du portfolio et de l'interface de selection des documents qui vont dedans, car cela reste confus et peu compréhensible pour ceux qui n'ont pas un master de gestion documents dans SPIP

Après en avoir discuté dans le train vers Avignon avec Yannick et Romy, la piste qui se dégage est, sur la page articles_edit, une zone 'Portfolio' en bas de l'édition, dans laquelle on fait glisser les documents qu'on veut mettre dedans.

Reste la question du classement des documents. La solution du num titre etant pour le moins inconfortable, il me semble indispensable de pouvoir les ordonner simplement par glisse-depose.
Il me semble que le tri ne doit pas se limiter au portfolio, mais a l'ensemble des documents liés à l'article (ne serait-ce que parce que nombre de squelettes ne gèrent pas le mode=document des images pour afficher le porftolio public faute d'arriver à le faire comprendre aux utilisateurs ...)

Dans la page d'edition article, toujours, cela semble assez simple en activant le tri sur la colonne de gauche qui reprend tous les documents. Mais cela suppose de synchroniser l'affichage du portfolio à chaque modif de tri.

Dans la page de visualisation article, cela suppose par contre de ne pas garder les regroupements par illustration/portfolio/documents qui empechent l'ordonnement global.
J'hésite entre une seule liste ordonnée de tous les documents (avec un picto pour distinguer les illustrations, portfolio, document), et n'afficher que le portfolio seul, avec un lien pour voir tous les documents et acceder au tri et au téléchargement ...

Donc tout cela mûrit tranquillement, et je suis preneur de ton avis aussi.
Je rappelle que dans mon esprit, ce plugin préfigure la gestion documents refondue de la 2.1, et sortie en plugin (mais il faudra que l'on valide que tous les choix faits sont ok).

2) Nos rédacteurs se plaignent que les images dans les portfolios sont trop petites pour même identifier ce qui est sur l'image.
Pour l'instant chez nous j'ai palié à ceci en changeant ligne 17 du fichier
/gestion_documents/modeles/document_desc.html à :
    [(#LOGO_DOCUMENT{80,80}|#URL_DOCUMENT)]
(au lieu de {40,40}).

mmm. On va voir, c'est un compromis lisibilité/encombrement. Comme cette partie doit etre revue, j'en profiterai pour essayer.

Si cela est nécessaire de garder le 40,40, est-ce que des paramètres comme celui-ci pourrait être placer dans un endroit modifiable par l'utilisateur (Avec cfg ??)

Peut etre enrichir les configrations existantes. On peut deja configurer la taille des vignettes de previsu, donc pourquoi pas celle des vignettes des listes, oui

Cédric

[RealET]

* cedric.morin@yterium.com tapuscrivait, le 14/07/2009 11:30:

Donc tout cela mûrit tranquillement, et je suis preneur de ton avis aussi.
Je rappelle que dans mon esprit, ce plugin préfigure la gestion documents refondue de la 2.1, et sortie en plugin (mais il faudra que l'on valide que tous les choix faits sont ok).

Pour l'avoir testé (en formation) durant 2 jours, j'aurais 2 retours :
- sur un écran 1024×768 avec quelques barres d'outils, on ne voit plus le bouton de fermeture en haut à droite de la page de modification d'un document
- C'est fastidieux de devoir modifier un document juste après l'avoir inséré pour lui mettre son titre (et pourtant, en terme d'accessibilité, c'est quasiment impératif de le renseigner).

--
RealET

[cerdic]

Le 14 juil. 09 à 14:04, RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 14/07/2009 11:30:

Donc tout cela mûrit tranquillement, et je suis preneur de ton avis aussi.
Je rappelle que dans mon esprit, ce plugin préfigure la gestion documents refondue de la 2.1, et sortie en plugin (mais il faudra que l'on valide que tous les choix faits sont ok).

Pour l'avoir testé (en formation) durant 2 jours, j'aurais 2 retours :
- sur un écran 1024×768 avec quelques barres d'outils, on ne voit plus le bouton de fermeture en haut à droite de la page de modification d'un document

ah oui. Faut peut etre un bout de js pour adapter la taille de la popin a la taille de l'écran.
Mais la touche Esc marche aussi.

- C'est fastidieux de devoir modifier un document juste après l'avoir inséré pour lui mettre son titre (et pourtant, en terme d'accessibilité, c'est quasiment impératif de le renseigner).

heu plus qu'avant ? Parce que de ce point de vue le seul changement est d'avoir remplacé le cadre depliable par une pop in.
Cédric

[RealET]

* cedric.morin@yterium.com tapuscrivait, le 14/07/2009 15:07:

Le 14 juil. 09 à 14:04, RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 14/07/2009 11:30:

Donc tout cela mûrit tranquillement, et je suis preneur de ton avis aussi.
Je rappelle que dans mon esprit, ce plugin préfigure la gestion documents refondue de la 2.1, et sortie en plugin (mais il faudra que l'on valide que tous les choix faits sont ok).

Pour l'avoir testé (en formation) durant 2 jours, j'aurais 2 retours :
- sur un écran 1024×768 avec quelques barres d'outils, on ne voit plus le bouton de fermeture en haut à droite de la page de modification d'un document

ah oui. Faut peut etre un bout de js pour adapter la taille de la popin a la taille de l'écran.
Mais la touche Esc marche aussi.

Merci pour le raccourcis clavier.

- C'est fastidieux de devoir modifier un document juste après l'avoir inséré pour lui mettre son titre (et pourtant, en terme d'accessibilité, c'est quasiment impératif de le renseigner).

heu plus qu'avant ? Parce que de ce point de vue le seul changement est d'avoir remplacé le cadre depliable par une pop in.

Un peu plus qu'avant : le cadre était déplié par défaut juste après le dépôt du fichier.
Mais AMHA, il faudrait pouvoir forcer la saisie du titre.

--
RealET

[romy (romy@rezo.net)]

Le 14 juil. 2009 à 18:25, RealET a écrit :

Mais AMHA, il faudrait pouvoir forcer la saisie du titre.

Non.

Dans les modèles par défaut de SPIP, les titres servent à renseigner l'attribut alt, mais c'est un pis-aller ou une lubie, selon le point de vue. Le champ titre est avant tout un titre, une légende, qui n'est pas nécessairement ce qu'on attendrait dans un attribut alt.
Pour remplir ce alt, il faudrait idéalement un champ dédié.

De plus, d'un point de vue accessibilité, l'attribut alt n'est pas obligatoire de façon systématique, mais seulement quand l'image apporte une information

--
Romy

[RealET]

* romy@rezo.net tapuscrivait, le 14/07/2009 19:26:

Le 14 juil. 2009 à 18:25, RealET a écrit :

Mais AMHA, il faudrait pouvoir forcer la saisie du titre.

Non.

Dans les modèles par défaut de SPIP, les titres servent à renseigner l'attribut alt, mais c'est un pis-aller ou une lubie, selon le point de vue. Le champ titre est avant tout un titre, une légende, qui n'est pas nécessairement ce qu'on attendrait dans un attribut alt.
Pour remplir ce alt, il faudrait idéalement un champ dédié.

De plus, d'un point de vue accessibilité, l'attribut alt n'est pas obligatoire de façon systématique, mais seulement quand l'image apporte une information

Tout à fait.
Mais, je ne connais pas de cas où j'ai eu à utiliser une image insérée dans un article et que cette image ne porte pas d'information.
Toi oui ?

(pour ce qui est des images placées dans un squelette pour l'habillage, là, je conçoit l'image avec alt="").

--
RealET

[romy (romy@rezo.net)]

Le 14 juil. 2009 à 20:16, RealET a écrit :

* romy@rezo.net tapuscrivait, le 14/07/2009 19:26:

Le 14 juil. 2009 à 18:25, RealET a écrit :

Mais AMHA, il faudrait pouvoir forcer la saisie du titre.

Non.
Dans les modèles par défaut de SPIP, les titres servent à renseigner l'attribut alt, mais c'est un pis-aller ou une lubie, selon le point de vue. Le champ titre est avant tout un titre, une légende, qui n'est pas nécessairement ce qu'on attendrait dans un attribut alt.
Pour remplir ce alt, il faudrait idéalement un champ dédié.
De plus, d'un point de vue accessibilité, l'attribut alt n'est pas obligatoire de façon systématique, mais seulement quand l'image apporte une information

Tout à fait.
Mais, je ne connais pas de cas où j'ai eu à utiliser une image insérée dans un article et que cette image ne porte pas d'information.
Toi oui ?

Oui, c'est même majoritairement le cas : les images, telles que nous les employons la plupart du temps, ne sont que des illustrations, parfois redondantes, quand elles ne sont pas carrément que décoratives. Elles ne véhiculent pas l'information : si on les retire, on accède quand même à l'information.
C'est dans les cas, minoritaires, où, en l'absence d'image, on ne comprend plus, que le alt est nécessaire.

Mais qu'importe, ça ne justifie pas qu'il faille forcer la saisie d'un titre.
De mon point de vue, titre et descriptifs devraient même être des champs optionnels désactivables, tant qu'on n'en maîtrise pas l'affichage côté public depuis l'espace privé (par des modèles paramétrables ou sélectionnables).

--
Romy

[fil]

Mais qu'importe, ça ne justifie pas qu'il faille forcer la saisie d'un titre.

Pourquoi Real3t voudrait-il m'obliger à saisir un titre à chacune de
mes photos de fleurs, alors que je veux juste les partager avec mes
amis -- lesquels sauront peut-être, *eux*, de quelles fleurs il s'agit
!?

-- Fil

[RealET]

* Fil tapuscrivait, le 19/07/2009 22:44:

Mais qu'importe, ça ne justifie pas qu'il faille forcer la saisie d'un titre.

Pourquoi Real3t voudrait-il m'obliger à saisir un titre à chacune de
mes photos de fleurs, alors que je veux juste les partager avec mes
amis -- lesquels sauront peut-être, *eux*, de quelles fleurs il s'agit
!?

Je ne veux forcer personne en général.
Je voudrais avoir un réglage pour le forcer sur certains site.
Ce n'est pas la même chose.
Juste une option pour ne plus rendre optionnel le titre

--
RealET

[romy (romy@rezo.net)]

Le 19 juil. 2009 à 22:53, RealET a écrit :

* Fil tapuscrivait, le 19/07/2009 22:44:

Mais qu'importe, ça ne justifie pas qu'il faille forcer la saisie d'un titre.

Pourquoi Real3t voudrait-il m'obliger à saisir un titre à chacune de
mes photos de fleurs, alors que je veux juste les partager avec mes
amis -- lesquels sauront peut-être, *eux*, de quelles fleurs il s'agit
!?

Je ne veux forcer personne en général.
Je voudrais avoir un réglage pour le forcer sur certains site.
Ce n'est pas la même chose.
Juste une option pour ne plus rendre optionnel le titre

La bonne idée serait plutôt de développer un plugin « Accessibilité », qui ajouterait des champs alt et title partout où c'est nécessaire, avec de zoulies balises #ALT et #TITLE à utiliser dans les attributs homonymes
J'ignore si un tel projet est déjà en route.

--
Romy

[romy (romy@rezo.net)]

Le 14 juil. 2009 à 15:07, cedric.morin@yterium.com a écrit :

Le 14 juil. 09 à 14:04, RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 14/07/2009 11:30:

Donc tout cela mûrit tranquillement, et je suis preneur de ton avis aussi.
Je rappelle que dans mon esprit, ce plugin préfigure la gestion documents refondue de la 2.1, et sortie en plugin (mais il faudra que l'on valide que tous les choix faits sont ok).

Pour l'avoir testé (en formation) durant 2 jours, j'aurais 2 retours :
- sur un écran 1024×768 avec quelques barres d'outils, on ne voit plus le bouton de fermeture en haut à droite de la page de modification d'un document

ah oui. Faut peut etre un bout de js pour adapter la taille de la popin a la taille de l'écran.
Mais la touche Esc marche aussi.

- C'est fastidieux de devoir modifier un document juste après l'avoir inséré pour lui mettre son titre (et pourtant, en terme d'accessibilité, c'est quasiment impératif de le renseigner).

heu plus qu'avant ? Parce que de ce point de vue le seul changement est d'avoir remplacé le cadre depliable par une pop in.
Cédric

Oui, à l'usage, je confirme quelques trucs améliorables :
- la taille des vignettes du nouveau "portfolio" est un peu trop petite et frustrance, et effectivement, les manipulations sont moins aisées qu'avant (alors que la même chose en colonne gauche, lorsqu'on est en édition, fonctionne plutôt bien)
- trop grande proximité du lien « tout enlever » et « modifier » qui rend mes dérapages de souris périlleux
- très perturbant que la popin ne se referme par après validation en cliquant sur le bouton « enregistrer »
- je ne suis pas convaincue par la popin... il la faudrait partout (y compris dans la médiathèque) ou nulle part, pour éviter d'avoir des process différents selon l'endroit d'où l'on demande la modification

Ceci dit, à part le virer purement et simplement, j'ai pas d'idée d'amélioration, la notion de « portfolio » dans SPIP m'ayant toujours échappée.

--
Romy

[5375b1b830a01f1b6a89]

C'est déjà faisable avec le plugin extra2 non ?

Aurélien

La bonne idée serait plutôt de développer un plugin « Accessibilité », qui ajouterait des champs alt et title partout où c'est nécessaire, avec de zoulies balises #ALT et #TITLE à utiliser dans les attributs homonymes
J'ignore si un tel projet est déjà en route.

--
Romy

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

[BoOz]

Il s'agit d'une expression employée dans les arts (photographie), et plus récemment dans le graphisme sur Internet :

Définition dans le domaine de l'art :

"Dossier, en partie photographique ou illustré, constitué par un professionnel des arts ou de la mode en vue de présenter ses travaux ou de promouvoir ses activités.
Note : Il est déconseillé d'employer le terme book.

Équivalent étranger : portfolio. "

Terminologie officielle. Commission générale de terminologie et de néologie (France)
J.O n° 14 du 18 janvier 2005, p. 845
www.legifrance.gouv.fr/affichTexte.do

romy@rezo.net wrote:

la notion de « portfolio » dans SPIP m'ayant toujours échappée.

--
Romy

[romy (romy@rezo.net)]

Le 22 juil. 2009 à 14:27, BoOz a écrit :

Il s'agit d'une expression employée dans les arts (photographie), et plus récemment dans le graphisme sur Internet :

Définition dans le domaine de l'art :

"Dossier, en partie photographique ou illustré, constitué par un professionnel des arts ou de la mode en vue de présenter ses travaux ou de promouvoir ses activités.
Note : Il est déconseillé d'employer le terme book.

Équivalent étranger : portfolio. "

Terminologie officielle. Commission générale de terminologie et de néologie (France)
J.O n° 14 du 18 janvier 2005, p. 845
www.legifrance.gouv.fr/affichTexte.do

romy@rezo.net wrote:

la notion de « portfolio » dans SPIP m'ayant toujours échappée.

Je connais bien le milieu artistique et son vocabulaire, mais cela ne m'aide pas à comprendre le concept de « portfolio » dans SPIP... en trollant, je demanderai bêtement : ainsi les rédacteurs sont tous des artistes qui ont besoin de montrer leurs œuvres ??

Ce que je ne comprends pas, c'est son fonctionnement :
- il n'accepte que des documents visuels, ce qui ne permet pas à un musicien de faire le sien, de portfolio (ou si, côté public, bien sûr, mais à ce moment-là, le portfolio de l'espace privé ne correspond pas et perd son sens)...
- ce n'est pas un objet réel, mais une simple fantaisie d'affichage dans l'espace privé, une boucle arbitraire, que le webmestre reproduit, ou pas, ou bien souvent pas à l'identique, sur le site public, ce qui crée beaucoup de confusion et de perplexité chez nos chers rédacteurs...
- on ne peut en créer qu'un par article et on ne peut pas en mettre plusieurs dans une rubrique sans devoir préalablement créé un « article » pour chaque (va expliquer ça à un photographe qui plus est artiste !)

--
Romy

[BoOz]

romy@rezo.net wrote:

Le 22 juil. 2009 à 14:27, BoOz a écrit :

Il s'agit d'une expression employée dans les arts (photographie), et plus récemment dans le graphisme sur Internet :

romy@rezo.net wrote:

la notion de « portfolio » dans SPIP m'ayant toujours échappée.

Ce que je ne comprends pas, c'est son fonctionnement :
- il n'accepte que des documents visuels, ce qui ne permet pas à un musicien de faire le sien, de portfolio

Bah c juste le nom d'une boucle dans la dist, qui affiche les images, comme un "book" si tu préfères.

Le musicien il a pas de portfolio je dirais, à la limite il a une playliste avec des sons.

J'ai justement fait ca hier dans le nouveau plugin Lecteur multimédia 2 c'est marrant que tu en parles :

http://www.patagium.net/spip.php?article1

  (ou si, côté public, bien sûr,

mais à ce moment-là, le portfolio de l'espace privé ne correspond pas et perd son sens)...

Oui justement je ne crois pas qu'il y ai de portefolio dans l'espace privé de spip, ou alors c une feature Bonux ou que sais-je non officielle.

Tu as une image ? je ne vois pas trop de quoi tu parles en fait je crois.

BoOz

[BoOz]

BoOz wrote:

romy@rezo.net wrote:

Le 22 juil. 2009 à 14:27, BoOz a écrit :

Il s'agit d'une expression employée dans les arts (photographie), et plus récemment dans le graphisme sur Internet :

c juste le nom d'une boucle qui affiche les images, comme un "book" si tu préfères.

Ah oui ben si, en fait il y en a un aussi dans l'espace privé, merci Cerdic qui me l'a fait remarquer. Ben en gros ca affiche les images ensembles, d'ou le nom portefolio.

BoOz

[cerdic]

Le 22 juil. 09 à 16:33, BoOz a écrit :

romy@rezo.net wrote:

Le 22 juil. 2009 à 14:27, BoOz a écrit :

Il s'agit d'une expression employée dans les arts (photographie), et plus récemment dans le graphisme sur Internet :

romy@rezo.net wrote:

la notion de « portfolio » dans SPIP m'ayant toujours échappée.

Ce que je ne comprends pas, c'est son fonctionnement :
- il n'accepte que des documents visuels, ce qui ne permet pas à un musicien de faire le sien, de portfolio

Bah c juste le nom d'une boucle dans la dist, qui affiche les images, comme un "book" si tu préfères.

Non, c'est officiellement présenté PORTFOLIO dans l'espace privé, sur la base d'un critère arbitraire.
Mais c'est mal foutu au possible :
- un seul et unique portfolio par article
- que des documents visuels
- ce n'est pas un objet editorial, mais juste un critère, qui est, comme le dit tetue, appliqué ou non dans l'espace public, avec une belle cacophonie à la clé
- une interface de selection des documents dans le portfolio pas très intuitive (c'est le moins qu'on puisse dire ...)

Le musicien il a pas de portfolio je dirais, à la limite il a une playliste avec des sons.

Oui, donc il peut pas "selectionner ses sons, partitions .." pour les mettre dans le "portfolio".
Donc il peut pas faire quoi que ce soit.
Donc on refait un porftolio dans le squelette public géré sur la base d'autres critères.
Donc l'espace privé est complètement faux.

Bref, je suis assez sidéré que tu découvre seulement cette fonctionnalité, et ses défauts. C'est un incontournable dès que t'essaie d'expliquer à un débutant comment gérer ses images (comprendre, il s'y vautre à chaque fois ...), pire encore lorsque ça n'en sont pas (des images)

Cédric

[BoOz]

cedric.morin@yterium.com wrote:

Oui, donc il peut pas "selectionner ses sons, partitions .." pour les mettre dans le "portfolio".

En fait tu te réfères à une définition large du portefolio, qui est un ensemble cohérent de documents. Une liste de documents quoi.

C'est vrai que le terme portefolio dans spip est aujourd'hui abusif dans le sens ou il est généré à l'arrache en fonction du type de fichiers, et non pas en tant qu'objet autonome, je crois que je commence à comprendre ton argumentation (en faisant fi des imprécations et autres anathèmes on y arrive ^^).

Bref, je suis assez sidéré que tu découvre seulement cette fonctionnalité, et ses défauts. C'est un incontournable dès que t'essaie d'expliquer à un débutant comment gérer ses images (comprendre, il s'y vautre à chaque fois ...), pire encore lorsque ça n'en sont pas (des images)

Bah en fait ce n'est pas si génant à l'usage, en fait du temps ou je m'occupais du plugin thickbox, j'étais même satisfait de ce fonctionnement.

En pratique, c important aussi la pratique, tu balances tes images sur un article, de là, la boucle portfolio de la dist te groupe les images, et thickbox démarre tout de suite.

Donc assez intuitivement tu as avec spip un comportement, peut etre bancal selon une logique de typologie avancée, mais pratique.

Si tu veux faire un e-portefolio avec un zip,un pdf,et une image de ton projet de campagne de pub, c'est vrai que spip te force à utiliser un nouvel article.

De même si tu veux présenter deux listes de lectures d'un artiste, et bien il faut faire deux articles ou bien ruser autrement (mots clés ou que sais-je).

Peut etre qu'un meilleur système de liste de documents est envisageable en effet.

BoOz