» Case Study : Our #SVG Icon Process Cloud Four Blog
▻http://blog.cloudfour.com/our-svg-icon-process
SVG’s versatility empowers us to craft the most appropriate solution for our audience and use-case. So as much as I’d like to, I can’t say exactly how you should implement SVG icons in your next project. There’s no substitution for research and tryi… Tags: #processus #picto #grunt #gulp SVG #clevermarks
En lien avec, puisque ce sont les mêmes :
►http://seenthis.net/messages/433569
Mais je persiste : je ne trouve pas ça bien d’avoir à insérer des images (SVG ou pas peu importe) de décoration, dans le HTML. Pour moi c’est typiquement un truc uniquement propre au thème graphique du moment, et qui doit pouvoir être changé juste en changeant les choix graphiques, sans toucher aux templates.
@rastapopoulos si tu les gères à l’extérieur et que c’est juste ton processus de packaging/déploiement qui les met dans le HTML, ça ne te suffit pas ? ;-)
oui ça c’est encore autre chose… avec un post-processeur ?
Du coup qu’appelles-tu les gérer à l’extérieur ? Dans ton HTML tu as par exemple des classes CSS classiques, par exemple class="bouton precedent", et ensuite comme tu dis que sur cet élément tu veux le décorer avec un pictogramme SVG ?
Oui, par exemple, et du coup une tâche (npm, Grunt, Gulp, whatever) prend le HTML, injecte le sprite SVG au début, puis des <use> aux bons endroits.
Oui, je comprends bien le principe du post-processing, ya pas de problèmes… mais ma question c’était plus, comme tu gères concrètement le fait de dire que tu veux tel pictogramme de décoration devant le texte de tel bouton ayant telle classe ? Où et comment tu décris ça ? C’est un peu une réinvention du CSS quoi ?… :D
Ah mais on ne s’est pas compris, comme eux je dis que "because our icons represent or reinforce content, they should exist in markup", donc ce n’est pas (complètement) de la décoration, donc pas du ressort de CSS.
Si tu regardes le source de ►http://play.esviji.com tu verras au tout début du <body> un sprite SVG qui contient des boutons que j’utilise après dans l’interface. Pour l’instant le sprite est en dur dans le HTML initial, mais j’ai prévu de l’externaliser dans les sources, pour qu’il ne soit inclus qu’à la « compilation ».
Ah oui mais moi je dis clairement l’inverse, que « une flèche vers la gauche », c’est une décoration pour un bouton « précédent ».
Une loupe c’est une décoration pour un bouton « rechercher ».
Etc etc. Donc ce n’est pas du tout du contenu (pour moi).
(Et une icône toute seule sans aucun label, c’est quasiment à coup sûr très mal.)
Après si le post-proc sert « juste » à dire qu’on transforme le span class « icone loupe » en lui assignant un SVG de loupe, évidemment là le truc est déjà dans les balises. Bon au moins ça permet de changer l’icône si le thème graphique change, sans toucher aux balises.
Mais pour moi c’est le fait même de dire d’aller chercher une icône de « flèche vers la droite » qui ne fait pas partie du contenu (et qui peut très bien changer).
Je comprends ta réticence de puriste, on pourrait continuer sans fin… ;-)
Une icône toute seule sans aucun label, c’est parfois nécessaire, et avec le SVG inline, ça peut être complètement accessible.
Hihi oui je sais. :D
Pour l’accessibilité, oui et non : pour moi l’accessibilité ce n’est pas QUE une histoire de lecteur d’écran (et là oui on peut lui faire lire un label, etc). Même si t’as des yeux, une icône toute seule, il y a un grand nombre de cas où le sens n’est potentiellement pas immédiat à beaucoup trop de monde, car il n’y a pas de standard. Ça fait trop d’apprentissage, trop lent, et donc ce n’est bon ni pour les gens qui ont un handicap de compréhension (il y a des handicaps cognitifs), ni pour l’optimisation des « conversions » dans un contexte marketing.
Les tests A/B sur hamburger seul VS mot « menu » le montrent assez bien. Et « Try Icon Labels instead of opening for interpretation. »
▻http://goodui.org/index.html#47
Je connais bien le problème du hamburger comme seule représentation du menu, effectivement. Nous sommes d’accord que c’est de l’accessibilité au sens cognitif, mais donc plus largement de l’UX pour tout le monde.
Mais imagine mettre des labels sur tous les boutons d’un WYSIWYG par exemple… :-p
GoodUI - A Good User #interface
▻http://goodui.org/index_b.html
“A Good User Interface has high conversion rates and is easy to use. In other words, it’s nice to both the business side as well as the people using it. Here is a running idea list, which we try on projects.” Tags: #UI #UX interface #bonnes_pratiques
GoodUI
▻http://goodui.org
▻http://seenthis.net/messages/153865
@seenthis Seenthis ne le reconnaît pas à cause du www. Seenthis_todo ?