tosca a écrit:

Un point de détail qui attire mon attention : je vois que l'on parle de "groupe", alors que le terme est déjà utilisé par ailleurs pour les groupes ... d'utilisateurs.
Je crains qu'à terme, et plus ou moins hors contexte, ça ne puisse entraîner des confusions pour les utilisateurs.
Peut-on qualifier (groupe de ...) ou trouver un autre terme ?

Regroupement ?
:)

Mais çà fait moche "Ajouter un regroupement" :-(


A noter que le terme "groupe" n'est utilisé qu'une fois dans l'interface.

plg a écrit:

Bon, mon test s'arrête bien vite. Je suppose que tu ne prends en compte que les photos dans les catégories physiques :-/ Je n'en ai aucune (sinon, j'en ai 5000 des photos sur ma galerie de dev)

bon j'ai trouvé le problème (+ d'autres), je teste la correction et je fais une mise à jour dans la foulée.
j'ai fait l'erreur de ne pas désinstaller / réinstaller le plugin, et j'ai bossé sur une version des tables alimentées par une première version du plugin.... ^^;

Gotcha a écrit:

Si j'ai bien compris Grum, ton plugin sera capable de débusquer les information dans les champs XML, EXIF, IPTC d'une photo ? De sorte de multiplier les chances de remplir les champs méta-datas pour Piwigo ?

pas tout à fait.
le plugin est complètement autonome et s'il est installé, il supplante la gestion des métadonnées de Piwigo.
Après oui, le plugin est capable de récupérer les diverses métadonnées d'une photos, et à terme (la version en cours de dev ne le permet pas encore) le plugin permettra de sélectionner la métadonnée X à afficher si la métadonnée Y n'est pas présente (parce que la même information peut être stockée dans plusieurs métadonnées différentes)

pour Piwigo 2.1, je ne sais pas s'il sera fourni sous forme de plugin mis à disposition par défaut ou s'il sera intégré dans Piwigo.
Pierrick, quelle est ton idée quand tu dis que se sera livré avec Piwigo 2.1 ?

grum a écrit:

tosca a écrit:

Un point de détail qui attire mon attention : je vois que l'on parle de "groupe", alors que le terme est déjà utilisé par ailleurs pour les groupes ... d'utilisateurs.
Je crains qu'à terme, et plus ou moins hors contexte, ça ne puisse entraîner des confusions pour les utilisateurs.
Peut-on qualifier (groupe de ...) ou trouver un autre terme ?

Regroupement ?

Je peux chercher si je comprends un peu mieux de quoi il s'agit ...
De quoi sont constitués ces groupes ? A quoi servent-ils ? Sur quels critères sont effectués les regroupements ?

grum a écrit:

A noter que le terme "groupe" n'est utilisé qu'une fois dans l'interface.

Peu importe le nombre d'apparitions ... à partir du moment où une même appelation recouvre 2 réalités différentes, ça n'est pas clair

grum a écrit:

On regroupe tout simplement les métadonnnées selon ses besoins :
* Machin fera les groupes de données : "Xmp", "IPTC", "Exif"
* Truc fera les groupes de données : "Conditions de prises de vue", "Géolocalisation", "Appareil", "Photographe"
* Bidule fera un groupes de données : "Métadonnées"

;-)
Tu as trouvé toi-même ...

grum a écrit:

Il me semble difficile de pouvoir confondre avec les groupes d'utlisateurs le contexte étant complètement différent, mais bon. Je n'ai pas forcément une vision 'utilisateur'

Sur un écran donné de l'admin, il n'y a priori pas de confusion possible.
Mais à chaque fois que le sujet sera évoqué sur le forum, dans le wiki, etc. ça risque d'engendrer des confusions. Si on prend l'habitude de parler tout de suite de "groupe de données" (ou groupe de métadonnées, mais c'est un peu plus long), les choses devraient être plus claires dès le départ.

grum a écrit:

Va pour "groupe de métadonnées" alors
Même si c'est un peu long que "groupe de données", il s'agit bien ici de métadonnées.

+1
C'est celui que je préférais (sans ambiguïté).

plg a écrit:

J'ai testé "assez intensément" le plugin et je dois dire que j'ai un double sentiment : 1) ouch quelle puissance ! 2) ouch quelle complexité ! Maintenant, je vais détailler.

Pour commencer, merci de ton retour ! :-)
Ma vision d'utilisateur est un peu particulière, car j'ai la triple casquette photographe/programmeur/utilisateur qui fait :
- en tant que photographe, j'ai des besoins particuliers
- en tant que développeur, j'ai une connaissance (maintenant très poussée) du type de métadonnées disponibles dans une photo et de leur structure
- en tant qu'utilisateur, j'ai forcément ma vision à moi sur la façon d'associer ce qui est disponible avec mes besoins

J'ai conscience que le plugin est plein de lacunes, je n'attendais qu'un retour de quelqu'un pour déterminer ce qui n'allait pas.
Je vais donc essayer de défendre point par point l'existant (ce qui ne signifie pas que je ne vais pas tenir compte des remarques qui me sont faites, loin de là)

plg a écrit:

1) je pense qu'il y a un soucis de CSS, parce que j'ai des écarts assez importants entre ta capture d'écran et ce que je vois sur le mien d'écran (voir mes captures attachées). J'ai regardé dans mon fichier d'erreur log Apache, et je ne vois rien du type "j'essaie de charger un CSS mais je n'ai pas le droit". Ce simple problème de CSS me cause les soucis suivants : tout est centré, c'est moche; l'opacité des pseudo-popup n'est pas bon, ça rend le tout complètement illisible.

A propos des feuilles de style, vu les captures d'écran que tu nous -//:---\spam, soit :
- ton navigateur est obsolète (IE 3.0 ? ;-))
- le fichier css n'est pas présent ; à ce propos, peux-tu vérifier [Forum, post 133803 by grum in topic 16835] Pré-requis pour gestion des tags XMP & Co. ?

plg a écrit:

2) personnellement, je ne vois pas l'intérêt des groupes : ça complexifie l'interface pour un intérêt qui ne me semble vraiment pas évident pour le moment.

Oui et non.
J'ai pour ma part un besoin particulier.

J'envisage d'avoir sur ma page picture :
- un onglet "Prise de vue"
- un onglet "Géolocalisation"
- un onglet "Matériel"
- un onglet "Informations diverses"
Je parle bien d'onglet, car le template que j'utilise affiche les métadonnées sous forme d'onglet

Si on se limite au template Yoga, effectivement la gestion des groupes n'a que peu d'importances.

Par rapport à cette gestion de groupes, certains pourraient souhaiter gérer l'affichage différent :
- tout ranger dans un groupe "Métadonnées"
- gérer les métadonnées IPTC (pour tout ce qui va être contact par exemple) dans un groupe bien spécifique

Sur ce point, je suis certain que la gestion des groupes sera un atout pour la suite.

Au besoin, on peut créer un groupe par défaut "Prise de vue" afin que l'utilisateur néophyte ait déjà quelque chose qui soit déjà en place lors de la première utilisation du plugin et ne retrouve pas face à une page vide comme c'est le cas aujourd'hui.



A noter : la gestion des groupes souffre d'un bug (que je croyais avoir corrigé mais qui est revenu) : normalement au sein d'un groupe on peut gérer l'ordre dans lequel les métadonnées sont affichées. Actuellement, c'est kPut... ^_^;

plg a écrit:

3) on voit beaucoup beaucoup beaucoup trop de métadonnées dès le début, ce qui rend l'utilisateur mal à l'aise devant le déluge d'information :-/ La case "Exclure les métadonnées non utilisées" devrait être cochée dès le départ et même... avec mes photos, il me reste des centaines de metadata affichées.

La classe sait interpréter environ 540 métadonnées différentes sur les 840 qui sont reconnues (et je n'ai pas fini de tout implémenter !)

j'avais le choix :
- restreindre la liste, au risque de voir les utilisateurs demander "pourquoi celle-ci n'y est pas"
- afficher la liste complète des données pouvant être interprétée

Devant la masse d'information, l'interface permet de filtrer le contenu afin d'affiner les recherches.

Ce que je peux faire, c'est qu'à la première utilisation soient préselectionnés :
- le filtre sur la valeur "Magic"
- l'exlusion des métadonnées inutilisées

plg a écrit:

4) le principe de restitution est génial. Pour ceux qui n'ont pas testé, ça veut dire que quand je clique sur une métadonnées, ça rafraîchit le tableau en bas de page avec le nombre d'occurence de chaque valeur possible. D'un coup d'oeil, j'ai vu que j'avais 2561 photos faites avec mon Canon G6 et 81 avec mon Canon 40D (c'est ma galerie de dev, ce n'est pas représentatif de la réalité).

5) le principe de restitution est très mal mis en avant (et c'est d'autant plus dommage que la fonctionnalité est géniale). J'explique : j'ai 100 métadonnées différentes, qui s'affichent donc sur 100 lignes, sur au moins 2 hauteurs d'écran. Je clique sur magic.Camera.Model. Le tableau tout en bas de page est rafraichit (en Ajax et tout et tout la super classe) mais je n'ai pas codé ce plugin, donc il m'est rigoureusement impossible de savoir qu'il y a un tableau 2 hauteurs d'écran plus bas qui s'est rafraichit. C'est peut-être un problème de fichier CSS oublié également.

Cf. mes captures d'écran à moi, le problème provient probablement du fichier css chez toi (normallement on voit très bien le rafraichissement du deuxième tableau)

plg a écrit:

6) Au début, j'ai noté sur mon cahier "quand je clique sur magic.Camera.Model, il devrait me cocher la checkbox quand même, c'est basique, ça m'étonne de grum" et ensuite... j'ai compris le principe du rafraichissement du tableau "de restitution" et donc ça explique pourquoi le clic sur le nom de la métadonnées ne la coche pas. Mais pour 95.6% des utilisateurs, ça ressemble à un bug :-/ (alors que je suis persuadé que c'est parfaitement voulu)

Au début, quand on cliquais sur "quand je clique sur magic.Camera.Model" la checkbox était effectivement cochée. Sauf que, si effectivement on veut visualiser la pertinence de la métadonnée avant de la sélectionner, il ne faut pas qu'un clic sur la ligne provoque le changement d'état de la checkbox.

Ce que je peux faire pour améliorer le système dans son ensemble :
1/ ne mettre qu'une seule liste
2/ sur chaque ligne, mettre une petite loupe
3/ clic sur la loupe = ouverture d'une popup pour afficher le domaine de valeur de la métadonnée
4/ clic sur la ligne ailleurs que sur la loupe = sélection/désélection de la checkbox

A noter que le système actuel permet d'éviter de cliquer 36000 fois (qui dit popup dit re-cliquer pour la fermer)

avis ?

plg a écrit:

7) j'adore le principe de restitution parce que ça -//:---\spam des infos que l'utilisateur comprends : "Canon 40D", "f/1.4" ou encore "1/200s". Seulement voilà, bien que la constitution du référentiel soit optionnelle, moi j'affirme haut et fort que l'on ne peut pas configurer AMetadata sans avoir remplit son référentiel :-D. Ne manipuler que les codes des métadonnées, c'est capilotracté. Or, l'analyse du référentiel, c'est un peu flippant quand même :-) (avec le gros warning, "attention, si votre hébergeur vous voit, il va vous engueuler"). Tout ça pour suggérer d'envisager une approche plus unitaire et basée sur le contenu et pas sur le contenant.

L'analyse du référentiel n'empêche pas d'utiliser le plugin, mais il est vrai que cette analyse, c'est un peu comme -//:---\spam une pleine nuit de tempête sans phares...
Néanmoins, lancer l'analyse sur une galerie complète sollicite rudement le serveur.

Pour exemple ma galerie de test fait environ 5800 photos :
- le traitement dure environ 7 minutes
- par défaut, chaque transaction traite 25 photos, dans ces conditions le client effectue 232 requêtes au serveur en 7minutes
- le traitement effectue en moyenne 1200 insertions par secondes dans la table
- la table principale se remplit de 500000 enregistrements (environ 13Mo)

Ce n'est certainement pas un traitement considéré comme normal par les hébergeur qui verront vite qu'il y a un problème sur le site...

Le message me parait donc nécessaire.

plg a écrit:

Plus unitaire : au lieu d'afficher des statistiques sur mes 5000 photos, pourquoi ne pas prendre les photos actuellement dans le caddie ? J'arrive sur la page de configuration des métadonnées, il me dit qu'il faut au moins 1 photo dans le caddie, je vais mettre une photo dans le caddie, je reviens sur la page et il analyse les photos du caddie (ou juste la première), en affichant la miniature de la photo en question. L'utilisateur rattache sa configuration à quelque chose de concret.

Ton idée de limiter l'analyse au contenu du panier est excellente, je vais rajouter l'option (tout en conservant les deux déjà en place).
Au niveau du message d'avertissement, il me semble nécessaire de le conserver. Je suis ouvert à toute proposition de texte moins alarmante ^^;

plg a écrit:

Basée sur le contenu et pas sur le contenant : au lieu d'afficher les noms abscons des métadonnées, n'afficher que les valeurs (et en tooltips ou quelque chose dans ce genre, le nom de la métadonnée correspondante).

Afficher les deux me semble intéressant :
- celui qui ne connait rien se limitera au libellé de la métadonnée
- celui qui s'y connait sera intéressé de connaitre de quelle métadonnée il s'agit ('FNumber' et 'ApertureValue' ne sont pas identiques, loin de là)

Note qu'actuellement le libellé des métadonnée n'est pas traduit.
Enfin si, c'est juste que la traduction est foireuse : j'ai 540 métadonnées à traduire, pour l'instant j'ai eu la flemme.
Actuellement le libellé de exif.exif.FNumber dans le fichier .po/.mo c'est ****FNumber
C'est fait exprès, çà me permet de vérifier que la traduction fonctionne bien.
Si libellé = nom de la métadonnée, c'est que le fichier .po/.mo n'est pas à jour....

plg a écrit:

8) le 2eme niveau d'onglet, on dirait un bug. C'est graphiquement un onglet, mais placé ainsi ça n'en est plus un. Je pense qu'il vaudrait mieux rester sur un seul niveau d'onglets.

Un seul niveau d'onglet ne me convient pas.
Le deuxième niveau d'onglet c'est parce que les fonctionnalités "Sélection" et "Affichage" vont de pair.

Ce qui est pose problème pour moi, c'est le choix graphique des onglets dans Piwigo.
Et c'est vrai que çà fait moche.

plg a écrit:

9) ça manque de préconfiguration. Dans 83.4% des cas, l'utilisateur va vouloir afficher "Canon EOS 40D, Canon EF 50mm f/1.4 USM, 2009-12-27 13:21:58, f/3.2, 1/250s, 640 iso, 50.0 mm" (enfin, ces infos là, pas forcément de cette façon là) Pour obtenir ça, l'utilisateur a un bout de chemin à parcourir et ce bout de chemin est un peu long :-/ La puissance de la classe JpegMetaData permet maintenant d'afficher ces informations proprement, le moteur est manifestement puissant.

Tout à fait d'accord.

En préconfiguration :
- analyse du référentiel préselectionné sur "analyse du panier"
- préselection des métadonnées "Magic"
- un groupe par défaut déjà créé "Prise de vue" avec toutes les métadonnées "Magic" affectée à ce groupe

Avis ?

plg a écrit:

10) le plugin AMetadata traite la fonctionnalité "affichage des métadonnées". Est-ce prévu, de traiter également la fonctionnalité "utilisation des métadonnées" ? Si c'est généralement pensé pour remplir la colonne images.name avec le champ IPTC 2#085, on peut aussi bien faire des trucs géniaux (en terme de navigation après) comme "créer un tag avec la valeur de magic.Aperture". J'ai fait ça pour Juza, et j'ai adoré naviguer de cette façon [Forum, post 124971 by plg in topic 16528] quand un photographe voyage a Madagascar mais bon, je m'écarte un peu du sujet.

Oui c'est prévu, mais pas forcément sous forme de tags.

Je pensais mettre en place une interface permettant d'effectuer des recherches sur un panel de métadonnées.
Rien n'empêche de faire les deux.

Mais ce n'est pas dit que cette fonctionnalité soit présente lorsque le plugin sortira (ou alors il faudra peut-être patient pour disposer d'une première version dans PEM)

plg a écrit:

Voilà voilà, je critique pas mal, parce que je pense qu'il y a un super potentiel derrière ce plugin mais qu'il me semble inutilisable tel quel :-/ grum, n'hésites pas à me demander de participer plus activement si ça permet d'avancer.

Je vais déjà prendre en compte ces remarques, je ferais signe quand le plugin sera prêt pour une seconde phase de tests.