Archives pour la catégorie Réflexions

J’écris moins ici, mais plus ailleurs

J’ai du mal à tenir mon blog avec une écriture constante de billets qui valent d’être lus. Mais ce n’est pas de ma faute ! C’est les jours qui sont trop courts … Pourtant j’aurais de quoi dire. Pour votre information j’ai 42 articles de publiés  mais j’ai aussi 30 articles en brouillons … rhâaa ! Le temps me manque pour finir à chaque fois (bon d’accord, j’ai sans doute un problème de procrastination).

En réalité, c’est parce que j’écris ailleurs aussi ! Avec mes collègues de La simple agence, on édite le site 3minutes30.com. J’ai pris un petit rôle de rédacteur pour enrichir le site de mes petits billets qui ne traitent pas forcement de technique (par comme ici). C’est intéressant, ça me force aussi à écrire et au final, c’est plutôt une bonne chose !

Donc pour faire un petit récapitulatif, ici, sur mon blog perso à mon nom, c’est essentiellement de la technique web dont je parle. Sur 3minutes30, c’est assez varié. Voici quelques expemples :

3minutes30 est un site léger pour y lire de courts billets et prendre un bol de frais à n’importe heure de la journée. C’est l’objectif du site. Cependant, il y a des articles de fonds aussi, notamment dans la rubrique signes et symboles, tenu par Jean-Jacques Urvoy.

Quand un sujet me tient à coeur, comme le dossier sur la création d’un site d’école, le billet est plus long et plus complet, mais on reste sur des articles succincts et directs.

Donc voilà au moins une excuse correcte pour mon manque de publication ici même ! Mais parmis les 30 brouillons qui traînent, j’ai de beaux sujets de publication à venir :)

Expert, comme à la télé

La baseline de mon blog me présente comme « Expert web front-end ». Vous seriez de passage sur ce blog par mégarde ou vous ne seriez pas forcement au fait des éléments techniques qui composent l’essentiel des billets, vous pourriez me croire sur parole.
Par contre, il est fort possible que vous pourriez douter de mes compétences à la lecture des commentaires sur mon dernier billet « L’accessibilité ? Mais lol quoi !« .

Les commentaires, décrédibilisant mon article, ne me posent aucun problème. Je trouve même cela très sain : la critique provoque le besoin de s’interroger, de se remettre en question et donc d’évoluer. J’ai d’ailleurs beaucoup aimé lire le retour d’expérience sur le sujet d’Amaury Bouchard qui illustre bien le genre de dérive que l’on peut subir à la suite d’une publication sur Internet.

Une question sous-jacente que l’on peut se poser est : qu’est-ce qu’un expert ? Le problème de l’expertise est qu’il faut bien souvent maitriser un grand nombre de métier connexe. Dans les métiers du web par exemple, l’expert SEO (référencement pour les moteurs de recherche) doit forcément avoir un niveau d’expertise certain dans les domaines suivants : Html, JavaScript, configuration serveur, performance… et la question sous-jacente de la question sous-jacente est : si cet expert est compétent dans tous ces domaines, il est donc généraliste … est-ce vraiment un expert ? Faites l’analogie avec les médecins et vous obtiendrez les mêmes réflexions.

Pour résoudre l’équation, il faut donc deux sortes d’expert

  1. L’expert de pointe, qui ne connait que son domaine de prédilection et qui a besoin d’avoir d’autres experts à ses côté
  2. L’expert généraliste, celui qui maîtrise l’ensemble des sujets et qui a besoin d’experts de pointe à ses côté

C’est deux « types » d’expert publiant sous leur propre nom à travers leur site/blog perso, engendrent ainsi notre lot quotidien de commentaire utiles et intéressants mais aussi de trolls en tout genre sur les différents lieux d’échanges, forum, twitter, commentaire…

Non seulement l’expert publie seul et l’expertise est donc critiquable mais en plus il entre de facto dans la fameuse « bataille d’experts ».

Je vous l’avais dis, c’est aussi chaud qu’à la télé.

Accessibilité ? Mais lol quoi !

La question est de moi, la réponse est de … je crois qu’il vaut mieux taire son nom ! La question était sincère et la réponse tout autant. En général quand on me demande mon avis sur un nouveau projet web top moumouth qui vient de sortir, ah ! c’est plus fort que moi il faut que je fasse un audit ! Qualité du code (HTML/CSS/JS), petit test de performance et mon petit test préféré : une consultation du site en mode texte. L’idée peut paraître saugrenue ou même carrément … lol ? Et pourtant ça n’a que des avantages.

« En mode texte ?! T’abuses Fab » …

Je ne sais pas mais ce doit être le vocabulaire qui dérange, je pense que si je remplaçais ces termes par « je test le site comme un robot Google » mes interlocuteurs seraient plus attentif. D’ailleurs pour vous inciter à continuer à lire ce billet vous allez entendre parler de stratégie digitale, de référencement naturel, de bonnes pratiques SEO, de partage de contenu mais aussi de performance, de mobile, d’expérience utilisateur… et j’en oublie !

Tout ça juste en partant d’un simple test d’un site en mode texte ? Tu m’intéresses là.

Travailler sur un projet web est belle aventure … tout du moins pendant la phase dite « phase Bisounours« . C’est la partie où se mêlent les grandes idées, les conceptions graphiques hyper créatives, la toute dernière techno web qu’il FAUT utiliser pour prétendre à un petit « award » à mettre en pied de page … Cette phase prend fin quand le client s’en mêle (quelle idée aussi !) et qu’il demande des résultats (en réalité cette phase est beaucoup plus courte, mais allons à l’essentiel).

A un moment, tôt ou tard, vous devez rendre des comptes sur l’efficacité du projet. Rendre compte à votre client parce que vous lui avez vendu un site qui boosterait son chiffre d’affaire, mais aussi rendre des comptes à vous-même et à l’équipe en charge du projet. C’est essentiel. Il y a les engagements contractuels que vous pourriez avoir pris avec votre client.  Et pour peu que vous aimiez votre métier, il n’est pas concevable de pouvoir conserver une dynamique d’entreprise quand vous savez que personne n’a d’intérêt pour votre travail !

Il y a donc forcément un moment dans le processus de réalisation du projet où vous devez vérifier comment les moteurs de recherche vont « voir » le site.

Tester son site en mode texte : le référencement

Les moteurs de recherche, pour référencer les sites, envoient des petits robots pas très très malins il faut le dire. Ils ne savent pas lire le JavaScript, n’interprètent pas les styles CSS et comble de tout, ne font même pas la différence entre un texte en image et un texte « texte ». Finalement, ils lisent un peu une page web comme nous pourrions le faire si nous consultions les sites web en mode texte : pas d’images, pas de JavaScript, pas de CSS (mise en page).

Les préconisations de Google sont d’ailleurs claires :

Pour vérifier le fonctionnement de votre site, utilisez un navigateur texte tel que Lynx. La plupart des robots d’indexation de moteur de recherche visualisent en effet votre site de la même manière que Lynx. Si certaines fonctionnalités (JavaScript, cookies, ID de session, cadres, balises DHTML ou contenus Flash) vous empêchent d’afficher la totalité de votre site dans un navigateur texte, il est possible que les robots rencontrent des difficultés similaires lors de leur exploration.

Pour ma part, je vous conseille de faire comme moi, c’est plus simple : testez le site via Html2Text, un service en ligne fourni par le W3C. Le rendu est sensiblement similaire à une vue sous Lynx et c’est vraiment plus simple !

Petit test :

Capture d'écran ou l'on voit mon site en mode texte

Nous pouvons voir sur la capture ci-contre, la page « qui suis-je » de mon site. On y voit l’essentiel, la page tel que la voit les robots d’indexation des moteurs de recherche !

J’ai ajouté 2 petites annotations pour mettre en avant des liens de la page. Certaines portions de textes étant des liens, on peut voir les liens complets directement dans la page … et c’est ainsi que les robots parcourent l’ensemble du site.

C’est à ce stade que l’on se rend compte de l’importance qu’il y a à renseigner les attributs « alt » et/ou « title » des liens et des images. Essayez de retrouver en mode texte une image sans ces attributs. Peine perdue, elle n’apparaitra même pas dans la page ! Tout cela plus les soucis potentiels de contenus générés en JavaScript, Iframe, Flash et j’en passe, vous rendez-vous compte des informations perdus pour le moteurs de recherche ?!

Concernant mon exemple ci-dessus, mon site étant très light c’est presque agréable à lire en mode texte, testez quelques sites célèbres et je ne peux que vous souhaiter bon courage pour l’analyse ! En effet la « philosophie » du « Mobile first » (le « pensez mobile en premier ») n’étant pas une généralité (loin s’en faut !) les pages web sont bien trop lourdes, indigestes et finalement illisibles dans la majorité des cas.

L’expérience utilisateur et le « Mobile first »

Comme nous l’avons vu précédemment, la plupart des sites sont quasiment indéchiffrables en mode textes. Ce qui soulève un point particulier. Si une page web doit être très dense en informations (formulaires, menus, diaporamas, pubs, carrousels, textes,…), il est indispensable d’avoir un design et une ergonomie parfaitement pensée pour satisfaire la majorité des utilisateurs du site et éviter de les perdre en quelques secondes.

Si la page est illisible en mode textes, soyez persuadé qu’il y a forcément des problèmes d’ergonomie dans son mode « complet ».

Il est vrai que généralement un site web est pensé, imaginé par un groupe de quelques personnes pour potentiellement quelques milliards. En essayant de toucher « la masse » vous ou plus souvent, votre client, aurez toujours tendance à trop en mettre. « Ces 10 blocs doivent absolument être en page d’accueil ». La zone utile, communément admise, de 1024px de large offre beaucoup d’espace. L’expérience utilisateur peut rapidement devenir un vrai cauchemar.

La philosophie du « Mobile First », comme vous l’aurez deviné, consiste à démarrer un projet web en le pensant d’abord pour un écran d’appareil mobile (smartphone, tablette). A mon sens, le meilleur argument que présente ce concept est que nous avons besoin de penser chaque bloc de contenu d’une page, de la façon dont il doit fonctionner et réagir. En effet en partant sur un minimum de 320px de large, chaque pixels compte et nous oblige à des trésors d’inventivités pour offrir une bonne expérience utilisateur. Nous devons penser « simple« , « riche« , « ergonomique« .

Je vous invite à lire le livre de Luke WROBLEWSKI, « Mobile first ». Les études de cas sont très intéressantes et c’est une excellente initiation à cette « philosophie ». Mais au-delà même de cette notion « Mobile first », ce que vous découvrirez dans ce livre c’est tout simplement que vous devez absolument penser aux mobiles dès maintenant, les chiffres présentés sauront vous convaincre !

Pensez « Mobile first » et la consultation de votre site en mode texte n’en sera que plus cohérente. La lecture en mode texte et sur mobile est un peu similaire : linéaire, du haut vers le bas.

Elevons-nous

Je vous ai parlé de deux notions essentielles sur le web, le référencement et l’expérience utilisateur(ou ergonomie avancée). Nous avons vu qu’un simple test d’un site web en mode texte suffit pour mettre le doigt sur un certain nombre de problèmes potentiels, en systématisant ce type de test, vous acquerrez de quoi développer des argumentaires solides pour cadrer vos clients.

En outre, dans la stratégie digitale que vous proposez à vos clients/prospects une part importante de celle-ci s’appuie sur des principes techniques, en effet comment argumenter sur le référencement (naturelle et/ou payant) sans parler de sémantique HTML, des microformats/micro data, de sites adaptatifs, de performance, de cdn, etc… Voilà d’excellentes raisons pour vous inciter à regarder au-delà du rendu visuel de vos projets.

Conclusion

J’avoue, le titre de ce billet est quelque peu … racoleur, trollesque, et je l’avoue mon objectif était de parler … d’accessibilité ! Oui, en suivant ces quelques recommandations, vous rendrez votre projet web plus accessible. Bien évidement il y a encore du travail pour avoir un site conforme aux différents référentiels d’accessibilités mais allons-y doucement et fixons nous des objectifs … accessibles !

J’ai bon espoir que ce billet attirera ceux qui n’y attachent pas d’importance et leur fera voir que d’une certaine façon l’accessibilité n’est qu’une question de bon sens.

Quand à moi, sachez que je ne suis pas expert en accessibilité, et je sais pourquoi : aucune ligne « optimisation accessibilité » dans les devis. Alors quand les lignes « webmarketing » et/ou « référencement » sont tout en haut, j’y vois tout de même une référence à l’accessibilité et de bonnes raisons de mettre en pratique les règles de bases de l’accessibilité.

J’espère pouvoir continuer la discussion dans les commentaires ci-dessous ;)

Responsive design, petit tour d’horizon

Le responsive design. Il va peut-être être grand temps de franciser ce terme ! Donc juste pour se rappeler ce dont il s’agit, voici un extrait de ce qu’on peut lire sur wikipédia

« …il[ndlr : le terme responsive design] indique globalement qu’un site est conçu pour s’adapter aux différentes tailles d’écran et aux différents terminaux permettant d’afficher le site (navigateur, tablette, mobile, télé connectée, …). Ainsi, les mobinautes pourront avoir une expérience adaptée à leur terminal sans dégradation et sans devoir utiliser les fonctionnalité de zoom (ou un autre type de redimensionnement)… »
 

Au terme de Responsive Design, s’ajoute souvent : Mobile First. Si dès le départ, l’on doit penser son site web adaptif, il est de bon ton actuellement de commencer non pas par une version « complète » du projet, mais plutôt de sa version mobile. Pensez à la version « mobile » de votre projet en premier, puis pour les écrans disposant d’une résolution élevé, enrichissez votre page avec des éléments non essentiels à la navigation/action.

D’expérience, je dirais : « Oui ! pensez Mobile First« . La principale raison est que si la version mobile du projet n’est pas anticipée dès le départ (analyse, wireframe, maquette), vous offrirez toujours une version mobile à minima. Pourquoi ? Tout simplement parce que vous feriez disparaître des éléments potentiellement problématique à grands coups de CSS ou de JavaScript (délais de livraison oblige !). Par exemple un carrousel récalcitrant ne voulant pas s’adapter aux différentes résolutions, l’intégration d’un service tiers aux dimensions fixes (Facebook, Twitter, module de paiment …)  ou encore un menu sur 3 niveaux complètement déstructuré au moindre changement d’orientation du terminal. Je ne saurais trop vous conseiller, aujourd’hui, de démarrer tout projet sur le modèle suivant :

1) Si nécessaire

« Responsive design », « Mobile First » : oui, mais que si votre client le veut et en a besoin ! En effet inutile de proposer une version mobile du projet si votre client a besoin d’un site Internet proposant des coloriages à imprimer ou s’il propose des jeux en ligne pour PC.

2) Le temps des zonnings

Lors de définition des Wireframes (si, si, je sais que vous en faites systématiquement), ayez toujours côte à côte un schéma sur une base de résolution de 1024px et un autre de 320px. Attention, n’oubliez pas l’orientation du terminal, pensez-y ! Après avoir défini les grandes fonctionnalités, et déjà à ce stade, évoquez avec votre client l’ergonomie du projet sur les 2 types de résolution. Par exemple, ce diaporama doit-il être avant ou après le texte sur la version mobile ?

Le contenu doit aussi être abordé à ce stade : doit-on avoir les mêmes contenus sur une version mobile que sur la version de bureau ? Le sujet est un vaste débat, Jacobs Nielsen nous invite à séparer clairement un même site qu’il soit destiné à être affiché sur mobile ou sur un écran de bureau : « Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work. ». Un article paru sur le site de Smashing magazine contre avec efficacité les arguments de Nielsen. Il est évident que je n’aurais pas de réponse ici car tout dépend du projet. Mais il est vital pour le projet d’amorcer cette réflexion avant de passer aux étapes suivantes. Si vous n’avez pas toutes les réponses, vous aurez au moins pointé du doigt les contraintes (nous voulons le diaporama sur la version mobile, mais fixons à 5 visuels maximum, fixons 4 paragraphes par pages et utilisons une pagination si besoin, etc…)

3) La phase de créa : maquettes

Demandez à votre graphiste de travailler selon vos schémas : 2 maquettes en même temps, ainsi il pourra offrir un maximum de cohérence graphique entre les différentes versions. Et surtout insistez auprès de vos graphiste/webdesigner : le design doit pouvoir bouger, s’étirer, être caché entre le shéma 1 de 320px et le second de 1024px et pour le bonheur de ceux qui dispo d’un écran HD, offrez leur encore un peu plus de friandises graphiques !

3′) La phase créa : intégration

« De l’usage d’une bonne grille CSS ». Cette partie devrait quasiment être intégrée dans celle ci-dessus. Il faut que l’intégrateur travaille en étroite relation avec le webdesigner. En effet, qui dit responsive design, dit structure en unité relative (em, pourcentage). L’intégrateur est le seul qui saura dire « Stop » aux folies créatrices du graphiste/webdesigner. Offrir une mise en page capable de passer de 320px à 1024px (pouvant aller jusqu’a 1920px, écran HD) est techniquement complexe. En effet, il s’agit de prendre en compte la gestion des images, du positionnement des éléments, des menus, de la typo, etc… Une grille CSS est un excellent moyen de liaison entre le webdesigner/graphiste et l’intégrateur. Cela oblige le graphiste à aligner les éléments de la maquette sur une grille prédéfinie, ce qui permettra à l’intégrateur une construction HTML/CSS fidèle à la maquette.

Souvent ces grilles sont accompagnées d’autres déclarations CSS utiles, notamment pour l’uniformisation des formulaires, des titres (hn), ou plus globalement d’un « reset CSS » permettant l’uniformisation de l’interprétation qu’on les navigateurs des balises HTML (marges, paddings, font-size,…)

4) Les tests

La partie sans doute la plus délicate. Il est bien loin le temps ou nous devions vérifier le site sur IE et … comment déjà ? ha oui Netscape :) Aujourd’hui, nous avons Internet Explorer en 4 versions encore utilisées, la 5ème arrive bientôt, Chrome, Firefox, Opéra, Safari et … en gros les mêmes mais pour mobile (donc différent … sic !) et je vous épargne les navigateurs exotiques que vous pouvez trouver dans les PS3, TV, Box etc …

Bref, tester votre site Responsive avec toutes ces contraintes, c’est tout simplement impossible ! Du moins physiquement, heureusement pour nous il existe des émulateurs de la plupart de ces terminaux. Je vous propose ci-dessous quelques outils utiles pour vos tests. Faites bien attention cependant, ces outils ne sont qu’a titre indicatif, débrouillez-vous pour trouver les terminaux sur lesquels vous garantissez un rendu fidèle aux maquettes.

Conclusion

Pour conclure, nous avons parlé ici des bonnes pratiques à mettre en place pour assurer la conception d’un site web adaptatif, « Responsive » mais nous n’avons évoqué que les terminaux les plus communs. A savoir le smartphones et les ordinateurs de bureau/portable. Je vous invite à lire un excellent article de Fred Cavazza qui nous explique avec brio que les acteurs du web de demain seront ceux qui sauront proposer une offre selon un contexte multi-écran.

Tâchons dès aujourd’hui d’être maître dans la discipline du responsive Design !

Note du 02 juillet : Je vois que Google préconise l’utilisation de Responsive plutôt que le site mobile dédié : https://developers.google.com/webmasters/smartphone-sites/details 

Atelier JS Puissant, un régal !

Session de JS Puissant du 31-03-2012

J’ai eu la chance d’assister récemment à un atelier (formation) sur JavaScript. Dispensé par un french guru Javascipt : Christophe Porteneuve. Je connais Christophe depuis plus de 5 ans ( par contre, lui ne me connait que depuis cette journée de formation !) Je pense qu’il a sorti le bon bouquin au bon moment : fin 2006, sortie du livre « bien développer pour le web 2.0 ». Au-delà des aspects purement techniques du livre, j’y ai aussi beaucoup apprécié le ton, décalé et bon sang, qu’est-ce que ça fait du bien dans un bouquin où, à priori, on va se prendre la tête !

Lire la suite

Le validateur W3C se retourne contre ses adorateurs

J’ai eu l’occasion de lire un post comme je les déteste sur le forum d’Alsa-Créations. Un être venu de l’underground (dixit lui-même) avec son … [tousse]franc parler[/tousse] soulève un problème dans le fond assez grave.

La problématique qu’a rencontré cette personne est facilement transposable sur tout projet web sur lesquels nous pourrions travailler. Lire la suite

Les facettes du web qui ne rassurent pas …

Depuis quelques temps déjà, les navigateurs nous proposent un mode de « navigation privée ». On se crois donc assez naturellement à l’abris de flicage indélicat. Et pourtant…

Premier exemple, une initiative de L’Electronic Frontier Foundation (EFF) dont l’objectif essentiel de l’EFF est de défendre la liberté d’expression sur Internet (wikipédia) : Vous avez quasiment 85% de chance d’être reconnu par un site simplement par les infos que votre navigateur fourni, http://panopticlick.eff.org/  (je rappelle que vous êtes en mode navigation privée)

Le second est plus inquiétant, il s’agit de evercookie, une API javascript qui permet de créer un cookie dont il est quasiment impossible de s’en débarrasser. http://samy.pl/evercookie/ je vous invite à jeter un coup d’oeil sur la page de Samy Kamkar, pour une démo qui fait froid dans le dos.

Toujours confiant dans la navigation privée ?

Pour en savoir plus : 

http://www.siteduzero.com/news-62-36549-panopticlick-peut-on-etre-suivi-sur-le-web-sans-cookies.html

http://info2aaz.blogspot.com/2010/09/evercookie-suppression-impossible.html

Et bien sur : www.google.fr