A Content-First Alternative to Wireframes · An A List Apart Article

#web_design

C’est intéressant même si je ne suis pas d’accord avec le démarrage de sa réflexion sur le faire qu’un wireframe c’est forcément un dessin statique (et donc dans son argumentation pas responsive etc).

Du coup c’est déjà un peu ce qu’on fait, puisqu’on commence par mettre des blocs de contenu (faux ou plus précis suivant ce qu’on connait comme détails à ce moment) dans du HTML. Puis on style ce HTML en bloc que l’on place petit à petit. On pourrait aller plus loin et vraiment commencer par TOUT mettre en détail et faire valider cette liste de choses à placer dans un ordre de priorité, puis le styler une fois que c’est validé seulement.

Mais du coup ses documents de priorités il continue de les faire en pixels, alors qu’on peut parfaitement les faire en HTML directement (et donc au départ c’est mobile first tant qu’on n’a rien stylé oui mais on PEUT les styler ensuite, ce qui n’est pas possible avec un truc statique).

Bref, ça va dans le bon sens, mais je pense qu’il faut continuer à améliorer dans la voix de partir directement sur le HTML, jamais depuis un outil statique : aussi puissant qu’ils peuvent être (sketch etc), je trouve que c’est obsolète, des outils du passé, pour la majorité des cas.

#conception #web #prototype #design #maquette #méthodologie #bonnes_pratiques

Alors je suis tout à fait d’accord, je viens encore d’en faire les frais ^^ Les outils comme sketch ou autre enferme dans une reflexion « pixel perfect » qui effectivement viens du print ou tout du moins tendrait a y ressembler.

Le problème c’est aussi les gens qui utilisent le logiciel. Je retrouve les mêmes erreurs de conception de document, identiques a quand je faisais de la production et que j’executais les doc des directeurs artistique (ex 30 couleurs aucune dans le même format).

On récolte donc des protos, conçues par des gens qui n’on jamais intégré ou conscience du markup, ni des implications de leurs choix graphiques.

En exemple le plus courrant, des titres qui change de place suivant le mode mobile, mais change de bloc container : on se retrouve a dupliquer le code, a masquer en aria-hidden pour pas que les lecteurs vocaux double… bref moi j’aime pas et généralement on peut faire sans …

Ce sont des méthodes ou type de réflexion, qui vont a l’encontre du progressive enhancement, et du mobile first.

La en tout cas ce concept est intéressant car on pense la page en fonction du contenu réel : ce qui est totalement l’inverse des méthodes les plus couramment employées, encore largement tirés du print, sauf que l’ont à enlevé des étapes comme le calibrage ^^, et que maintenant on nous envoie le contenu quand le travail est fini, on marche à l’envers.

Il y’a quelques années, j’avais été intéressé, par un projet Project Hub lancé par Brad Frost (Atomic Design methodology) : ▻https://github.com/bradfrost/project-hub. En fait l’idée est de constatent garder le fil avec le client en le poussant a participer (genre Agile) . Je pense que l’implication, le suivi, le déroulement devrait faire partie d’un seul outil ou chaque intervenant à accès aux infos, a la timeline, des notifications rappels, guideline, …

Dans un outil qui gérerait l’ensemble de la progression, l’exemple cité dans l’article peut effectivement permettre au SEO, marketeux de faire leur sauce en parallèle de l’intégrateur, sans interférer avec la partie purement dev.
Je pense que réfléchir parallèlement ainsi pourrait éviter pas mal de problème pour ceux qui sont en fin de chaine, et surtout amener à se poser les bonnes questions sans penser QUE cosmétique mais contenu. Certainement un gain de temps aussi quand on travaille a plusieurs intervenants, …