Le 30 juil. 09 à 13:36, Fil a écrit :
Préalable : il existe bien deux types d'images. Celles qui sont là à
titre d'illustration seulement, et celles qui sont de vrais documents.
+1
Mais, là où on a fait une erreur, c'est que ce n'est pas en termes de
*présentation* que ça se joue : la vraie question est de savoir quels
documents sont "diffusables" en tant que tels (par exemple en pièces
jointes via les RSS, ou dans une page "toutes nos photos").
C'est un point important effectivement.
Le problème du champ "mode", c'est qu'il confond deux notions : la
diffusabilité d'une part, et la présentation par défaut d'autre part ;
la "faute" de programmation est d'avoir mélangé ces deux notions *et*
de leur avoir donné le même raccourci d'affichage, pour faire des
choses qui au fond sont différentes.
L'interface de gestion est trop compliquée :
* soit l'interface est lourde, avec deux formulaires d'upload
(ancienne méthode) pas clairs (charger une image vs charger un
document)
Avec d'ailleurs quand même des utilisations identiques possibles, si je me souviens bien, ce qui ajoute à la complexité.
* soit la présentation d'un document est instable, puisque ce bouton
qui le fait changer de diffusabilité transforme son affichage
(nouvelle méthode)
Aaah, je viens de comprendre, tu parles du bouton « Déposer cette image dans le portfolio » / « Retirer cette image du portfolio » !
Je ne l'avais jamais vu, descendant rarement en dessous du bouton « Enregistrer » après avoir modifié le titre et descriptif de mes docs. C'est récent ?
* soit (dernière option, qui avait ma préférence), le tri se faisait
automatiquement à l'upload en fonction de la taille de l'image : une
petite passait en mode image, une grande en mode document. Et on
n'avait pas le choix de basculer d'un mode à l'autre.
Pas terrible. Cela induit un lien entre contenu et présentation qu'un CMS est censé minimiser. Si je décide aujourd'hui que mes images font 500 pixels de large max, une image de 520 pixels devient un document, et si demain je change mon design de site pour pouvoir afficher des images de 600 pixels de large, j'aurais des documents là où je penserais normal d'avoir des images.
On devrait à mon sens déplacer la génération automatique de vignettes du back office, vers le front office, justement.
Je mets mon image dans le back office, peut importe sa taille. J'ai un bouton qui me permet de générer une vignette éventuellement, et surtout la possibilité de mettre ma propre vignette.
Dans le front office, je n'ai pas que image_reduire(x, y), qui réduit l'image sans garder accès à la grande version, j'ai aussi vignette_auto(x, y), qui génère une vignette à la volée si l'image est trop grande, et lui met un lien vers l'original.
Mais en tout cas, ce n'est pas parce qu'une image est affichée en taille réduite, avec lien ou non vers l'original, que ça en fait plus un contenu avec sens qu'un contenu d'illustration.
Le sens doit être donné à l'ajout en back office, pas automatiquement en fonction de choix de présentation qui peuvent varier.
De plus, même si je ne sais plus si c'est encore d'actualité, ce n'est pas parce qu'une image
Tout cela n'est pas simple...
Dans les trois cas, les différences de traitement ne sont pas faciles
à comprendre.
Les images dont on parle peuvent être aux formats gif, jpg, png, mais
aussi swf ou autre.
Tout changement doit prendre en compte l'existant, avec des images
(illustrations ou diffusables) qui sont présentées via des raccourcis
img, doc ou emb, et disposant ou non de titre et/ou légende.
Pour les images SWF, c'est un peu plus simple : elles n'ont jamais été
uploadables autrement qu'en mode document.
Tous les documents ayant {mode=document} peuvent de plus avoir une
version réduite ("vignette") apposée à la main, ou calculée
automatiquement, ou un logo.
Une proposition nouvelle consiste à fournir un "modèle universel", que
Romy appelle <doc> (ce qui ajoute de la confusion mais a le mérite de
conserver une certaine compatibilité entre les sites). Ce modèle a des
options : <doc|vignette> affiche en petit, etc. Les modèles img et emb
restent pour compatibilité ascendante, mais ne sont plus proposés dans
la case de l'image.
Bénéfice de cette approche : c'est à l'insertion de l'image dans
l'article qu'on précise comment on l'insère, et non dans l'image
elle-même. Une même image peut être insérée de différentes manières
dans différents articles. Exemple : je fais un article qui indique
"toutes les pièces de la maison", en les insérant sous forme vignette
(sans lien). Un autre article va lui embedder spécifiquement la photo
de la cuisine, car il s'agit d'un article sur cette cuisine. L'image
est identique, mais son traitement est spécifique à chaque article.
Cela me semble très intéressant, mais toujours trop lié à l'usage en back office. Ajouter à cela ma proposition de traitement en front me semble nécessaire pour aller au bout du sujet (ou s'en approcher).
Il y a trois questions à traiter :
1) Quelle interface proposer, qui soit plus simple que l'existant
Dans la colonne de gauche (ou ailleurs si ça bouge, dans une médiathèque hors articles par exemple), upload simple, avec titre et descriptif, éventuellement date, et génération ou upload de vignette. Rien concernant la présentation à cet endroit.
Insertion des docs dans le contenu avec une syntaxe traditionnelle (on pourrait ajouter un <pj>, comme "pièce jointe", plus générique pour éviter la confusion avec <doc> qui donne un sens de "document" pas intuitif), avec le porte plume éventuellement (surtout si on sort tout ça dans une médiathèque), avec des paramètres de présentation optionnels de type alignement, taille, vignette ou pas, etc.
Possibilité de surcharger cette présentation dans les squelettes avec les filtres.
2) Comment conserver l'existant, et ne pas se retrouver à diffuser
d'anciennes vignettes d'illustration, ou à embedder des photos de
3000px de large
3) Comment gérer la "diffusabilité" d'une image
Le problème, au final, quand tu parles de "diffusabilité", c'est surtout de savoir quels pièces jointes on peut lister en plus de l'affichage du contenu. Cela peut être une case à cocher sur la pièce jointe, pour accepter ce listage. Sinon, si on sort les pièces jointes des articles, on gère un nouveau type d'association (déjà presque présent) entre contenu (article, rubrique et breve) et pièce jointe, en plus (c'est à dire complètement dissocié) de l'insertion directe dans le contenu.
Pour l'interface, la proposition de Romy est pas mal : on uploade des
images via un seul formulaire d'upload, et on les insère via un seul
raccourci <doc>.
J'ajoute :
=> On conserve le champ SQL spip_documents.mode pour que l'existant
continue à s'afficher comme avant.
=> L'embedding permet par défaut de retailler une image de façon à ne
jamais avoir d'image de 3000px de large.
=> on peut passer des variables supplémentaires au modèle
<doc1|titre=x|alt=y|description=z|largeur=l|hauteur=h>
Reste le problème de la diffusabilité des documents.
Je propose d'ajouter un "mode", équivalent à l'actuel mode=image, mais
n'affectant que la diffusabilité, et plus du tout l'apparence :
=> mode=image serait caduc, mais conservé pour raisons de compat ascendante
=> mode=vignette sert toujours à référencer les vignettes de doc
(perso je préférerais qu'on les gère comme les logos d'article, mais
c'est hors-sujet !)
=> mode=document est le mode standard, diffusable
=> AJOUT mode=XXXX (nom à trouver) fonctionne avec les mêmes
raccourcis que les mode=document, mais n'est pas diffusable.
Ainsi seuls les mode=document seraient diffusables, ce qui en fait un
critère simple à appliquer dans nos boucles standard et dans l'espace
privé.
Par défaut, au chargement d'une image, sa diffusabilité serait OK
(mode=document) si elle est grande, et NOK (mode=XXXX) si elle est
petite. L'interface permettant de changer ça (soit la taille limite,
soit un bouton de sélection diffusable/pas diffusable pourrait être
l'enjeu d'un plugin (ou d'un simple crayon posé qq part dans une liste
de documents).
Alternativement, on pourrait dire que le mode=image ne signale plus
QUE la non-diffusabilité, et n'affecte plus l'affichage. Dans ce cas
il faudrait upgrader la base des contenus pour transformer tous les
raccourcis <imgXX> et <docXX> des documents qui se trouvent en
mode=image. Avec de gros risques de foirades.
-- Fil
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
-Nicolas
--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/
