HTML 5 expliqué à mémé, part2

Laisser une réponse
Twitt

Mémé, je vais parler technique, écoute moi si ça t’intéresses …

HTML5, concrètement c’est quoi ? Si vous n’avez pas lu la première partie de cette suite d’articles, je vous invite à le faire maintenant Nous l’avons vu, HTML permet l’affichage de contenu multimédia sur une page web. HTML5 lui va beaucoup plus loin. Passons en revu les différentes fonctionnalités qu’apporte cette nouvelle version du langage.

Je rappelle ici que je propose une explication volontairement simple des fonctionnalités HTML 5. Pour plus de précisions ou d’infos, n’hésitez pas à consulter le site du W3C, ou la doc de Mozilla : MDN (par exemple)

Les balises

Cette version du langage apporte aussi sont lot de nouvelle balises. Pour rappelle, les balises HTML servent à donner un sens aux contenus qu’elles contiennent. Le web n’étant pas uniquement lu par des humains, le sens des contenus doit-être indiqué. Ceci afin d’aider les robots(les moteurs de recherche par exemple) qui parcours le web de comprendre les pages. html 5 fournit une panoplie beaucoup plus large de balises permettant de donner d’avantage de sens aux pages web. Voici quelques exemples :

<article>

Une balise article est un conteneur global, c’est une partie de la page qui pourrait être prise individuellement et être utilisé ailleurs, comme par exemple un blog, un agrégateur de contenu, un magazine en ligne … Un contenu encadré d’une balise article ne doit pas être dénué de sens une fois “externalisé” le contenu doit-être autonome. Pour cela à l’intérieur de cette balise article nous devrions retrouver une autre nouvelle balise HTML 5 : header

<header>

Comme son nom l’indique une balise header encadre des informations d’entêtes et ce à plusieurs niveaux sur une même page. Nous pourrions avoir une balise header pour la partie haute de notre page web, mais aussi un balise header à l’intérieur d’une balise article. L’entête de la page contiendrait le logo, une phrase d’accroche, un menu peut-être. L’entête de l’article contiendrait lui, le titre de l’article, sa date de parution, l’auteur…

<footer>

Toujours dans notre balise article nous devrions aussi ajouter une autre nouvelle balise html5 : footer. Cette balise au nom équivoque, permet de spécifier des informations de bas de page. A l’instar de la balise header, footer peut(doit) être utilisé à plusieurs niveau de la page web. En pied de page global, mais aussi à l’intérieur de notre balise article. Le footer de la page web contiendrait les mentions légales, un lien de contact, un copyright… Le footer de l’article contiendrait les sources de l’article, une information de bas de page…

<nav>

Une page web contient beaucoup de liens, de différents “niveaux”. Le menu de navigation du site, pour aller de rubrique en rubrique par exemple devrait être encadré d’une balise nav.

<aside>

Si une balise article contient un contenu autonome (un texte, un diaporama, une vidéo…) aside lui, contiendra les contenus annexes de la page web : listes des derniers commentaires, les articles archivés, l’agenda … aside est en quelque sorte la colonne latérale que nous avons l’habitude de voir sur un site web.

<section>

Section doit-être vu comme un conteneur global. Par exemple si nous avons plusieurs articles dans une même pages, nous devrions les encadrer par une balise section.

JavaScript

Cette nouvelle version du langage, apporte non seulement son lot de nouvelle balise, mais elle apporte aussi une pléthore de nouvelle fonctionnalité. Pour ce faire HTML à besoin d’un autre langage : JavaScript. C’est grâce à ce langage qu’il est possible de “piloter” HTML5. Passons en revu quelques-une de ces nouvelles possiblités

Géolocalisation

Sans doute plus utile pour une version mobile d’une page web, cette fonctionnalité permet de positionner dans l’espace (géolocaliser), un utilisateur. C’est ainsi qu’il est possible d’afficher des contenus en rapport avec le lieu duquel vous être en train de consulter une page web. Trouver une restaurant proche de vous, vérifier si un de vos amis Facebook se trouve près de vous, “marquer” votre emplacement actuel sur carte … Cette fonctionnalité existait déjà sous un environnement “natif” comme un Iphone, mais l’avantage d’une utilisation via HTML 5 est qu’il est possible de l’exploiter d’une manière plus interopérable.

Canvas

Ce nouvel outil, permet de faire quelque chose que vous connaissez très bien mais via un autre outil : Flash. Canvas nous permet, sur une zone dédiée d’une page web, de dessiner, manipuler des images, animer des éléments, … Quel intêret d’utiliser un nouvel outil si Flash le fait depuis de nombreuses années ? Tout simplement Flash n’est pas (plus) disponible sur mobile ! Pour la réalisation de jeux sur mobile, Canvas est parfaitement adapté.

Audio / video

Pour lire des vidéos ou écouter des pistes audio sur un navigateur (de bureau ou mobile), l’outil le plus souvent utilisé pour cela est Flash. Celui-ci propose des interfaces simple et intuitive pour cela (en plus de prendre en charge les formats d’encodage, bien sur). Avec les API’s Audio et Vidéo, Html5 standardise ces outils. Plus besoin de flash, puisqu’il est possible de prendre en charge les sons et les vidéos directement en HTML via les balises <video>, <audio>. A l’instar de Flash, une interface paramétrable permet de gérer le volume, le lancement ou la pause, le temps écoulé depuis le lancement du média …

Il existe bien d’autres nouvelles balises (<figure>, <details>, <command>…), je vous rappelle que pour aller plus loin, n’hésitez pas à vous procurer le livre de Rodolphe Rimelé aux editions Eyrolles : HTML5

Et bien d’autres !

Voilà ma petite mémé, ça c’était pour la partie technique … tu peux te réveiller maintenant.

Pour toi lecteur (Grand-Mère dort encore) : pour la prochaine partie de cette série de billets, nous parlerons de CSS, ou quand se rencontre le graphiste et le développeur.

Le QR code, c’est trop’orible !

1 réponse
Twitt

Le QR code, LE QR CODE … une révolution, la mort du lien, un petit bout de carrés qui stocke tout. Que n’a t’on pas dit à son propos ? Il est moche, trop petit, trop haut, trop noir ?

Je déteste les QR code. Pour leur désagréable air de famille avec les codes barres de mes paquets de nouilles. Pour leur utilité douteuse. Pour la verrue qu’ils représentent sur une belle composition graphique.

Je les déteste comme on déteste le lait trop chaud. Je les déteste comme on hait la neige qui recouvre la route ou le soleil qui nous fait suer à grandes gouttes…

…mais le QR code sait se rendre utile parfois et même que, il sait se faire beau ! Alors si le QR code cache un lien direct vers quelque chose d’utile, de bien pensé et qu’en plus il se part de ses plus beaux habits … je dois l’avouer : je l’aime quand-même.

violet vert rouge rose noir gris brun Basic RGB bleu blanc

Quelques sources :

HTML5 expliqué à mémé – part 1

2 réponses
Twitt

Ma grand-mère me demande souvent « mais c’est quoi déjà au juste ton métier ?« . C’est vrai, expert web front-end, développeur front-end, architecte web, intégrateur … même moi j’ai du mal !

Alors j’ai pris mon plus beau clavier, et j’ai rédigé une série de billets que je pourrais relire à grand-mère et qui pourraient accessoirement, cher visiteur, vous intéresser !

Commençons.

Comment parler des métiers du web, et plus généralement du web  sans parler d’HTML ?

HTML est un langage (en l’occurrence, de programmation). C’est grâce à lui, chère grand-mère, cher lecteurs que vous pouvez lire ces lignes de textes en ce moment même, que vous pouvez aussi cliquer sur des liens, de voir des photos ou des vidéos … il permet aux navigateurs de structurer la présentation d’une page web. C’est donc grâce à ce langage, que les navigateurs sont capables d’afficher des textes, des images, des vidéos, etc…

Mais avant d’aller plus loin dans les explications d’HTML, j’aimerais juste faire une aparté  sur les navigateurs. Pour naviguer sur le web, vous avez besoin d’un logiciel qui vous permet de le faire (Internet Explorer, Firefox, Chrome, Opera, Safari …)  avec l’avènement du mobile, aujourd’hui nous « consommons » le web de partout (boulot, métro  dodo … ha oui, plage aussi … comment ? ailleurs aussi ?? De partout quoi !). Il y a donc également un navigateur sur les mobiles … mais pas que ! En effet, sur les terminaux nomades (les Smartphones et les tablettes quoi …) il y a les fameuses « Applis » qui (pour la plupart) NE SONT PAS des sites web. Facebook par exemple, son application pour mobile, est un outil complètement différent de la version de Facebook que l’on peut voir sur l’ordi de son bureau. On dit que les applications mobiles sont développées en code natif, elles ne sont pas « lues » par le navigateur et ne sont donc pas en HTML5

Si j’insiste la dessus, mémé, c’est parce que beaucoup de gens confondent Responsive Design et application native. L’application native, c’est comme le logiciel qu’on installe sur l’ordi pour rédiger des documents, classer des photos, écouter de la musique, surfer sur le web ! … Un site en responsive design c’est simplement un site parfaitement lisible sur un écran riquiqui ! Et consultable depuis un mobile via un navigateur ! Il y a des exceptions bien sur, il existe des applis en HTML5, mais là ma petite grand-mère, faut que je simplifie un peu.

Reprenons sur HTML …

HTML fonctionne par des jeux de “balises” imbriqués ou en vis à vis, un peu à l’image des legos de notre enfance. Chaque élément qui compose une page web est encadré (ou est représenté) par un jeu de balise correspondant à sa signification. Par exemple pour les titres, HTML fournit un jeu de balise permettant de déterminer la position hiérarchique d’un titre ou d’un sous titre. Ce sont les balises allant de <h1>à <h6>

<h1>étant la position la plus haute de la structure hiérarchique. Historiquement, ce sont les balises les plus importantes car elles déterminent l’ordre d’importance des éléments d’une page web

Ex :
<h1>Titre</h1>
<h2>Sous-titre</h2>

HTML fournit un large panel de balises permettant de donner un sens, que l’on qualifie de “sémantique HTML” à une mise en page.

  • Pour un paragraphe de texte, nous utiliserons les balises <p>,
  • pour les titres, nous l’avons vu, nous utiliserons les balises  <h1> à  <h6>,
  • pour les images  <img>,
  • pour des liens  <a>,
  • etc…

L’imbrication des balises html, permet ainsi de créer des pages web complète et complexe. Une image (<img>) peut-être encadrée d’une balise de type lien (<a>) qui elle même peut-être à l’intérieur d’un texte qui sera encadré d’une balise <p>. 

Ex :
<p>
<a href= »lien.html »>
<img src= »image.jpg » />
</a>
blabla bla …
</p>

La fondation Mozilla, dans un souci de rendre HTML plus simple d’utilisation, met à disposition de tous : Thimble, un outil en ligne pour se familiariser avec l’html (en anglais). Cet outil se veut avant tout pédagogique, cependant il est tout à fait possible de créer une véritable page web, de l’héberger sur les serveurs de Thimble et de récupérer un lien unique permettant de diffuser votre page. (Cher lecteur, pour débuter ou uniquement pour comprendre rapidement ce qu’est HTML, n’hésitez pas à tester cet outil.)

Structurer le contenu, pas le “looker”

HTML permet donc aux navigateurs d’afficher une mise en page voulue, cependant il n’est pas fait pour faire de la représentation graphique (tout du moins dans ses dernières versions). Il permet de structurer la page, mais ne doit pas être utilisé pour “looker” celle-ci. L’aspect visuel d’une page web est à confier à CSS, Cascading Style Sheets, ou feuille de style en cascade. Mais nous verrons CSS plus tard… c’est une autre histoire.

A présent que nous comprenons un peu ce qu’est html intéressons nous à son histoire

Sir Tim Berners-Lee  »l’inventeur du web » a développé la première version d’HTML à la fin des années 80, il répondait ainsi au besoin d’un langage simple permettant de structurer et créer des pages web qui afficherait des textes, mais aussi des images et d’autres types de fichiers multimédia.

Note : Je te dis ça comme ça, mémé, mais le web n’est pas Internet !

Le web est la couche graphique utilisant un des protocoles utilisé par Internet. Berners-lee a donc créé ces premières interfaces graphiques en se basant sur HTML.

Pour bien comprendre l’importance qu’a eu l’invention du web, il faut se rappeler qu’a cette époque, Internet n’était utilisé dans le monde que par des informaticiens au fait de technologies balbutiantes et tout en ligne de commande ! L’invention du web à tout simplement permis à tous d’avoir accès aux informations présentées de manières claire, compréhensive et structurée. HTML de son coté s’est donc naturellement épanoui durant cette période de forte croissance pour le web.

Ça va se compliquer un peu, il va falloir suivre …

Le langage HTML a connu 4 versions majeures durant les années 1990-2000. Le web évoluant très vite, le W3C (« l’académie Française » du web), organisme chargé de rédiger les spécifications du langage a décidé de faire évoluer HTML vers xHTML. HTML étant jugé trop laxiste il convenait aux yeux du W3C de rigidifier le langage sur une base plus solide : XML (d’ou le x … mémé ? je t’ai perdu ? … ha non, reprenons …). C’est ainsi que html 4.0.1 est la dernière version en recommandation encore en vigueur aujourd’hui. La branche xHTML a connu de son coté 2 version majeures : xHTML 1 et xHTML 2.

Durant les années 2000, il fut décidé que la future norme d’HTML serait xHTML 2.0, en 2004 certains membres du w3c et de développeurs de navigateurs trouvant qu’xHTML  était trop rigide (sic !), ont décidé de fonder un groupe de travail pour travailler sur la version future d’HTML, le WHATWG.

C’est ainsi que durant 2 ans le w3c continuait à travailler sur xHTML tandis que le WHATWG sur la nouvelle version d’HTML (la 5 en l’occurrence, oui, oui d’où « HTML5″). Finalement, fin 2006 le W3C laissa tomber xHTML, et décida de partir sur le travail du WHATWG pour établir HTML5 comme futur standard pour la création de page web. Les deux organismes ont ainsi travaillés ensemble à la définition des spécifications du langage. A l’heure ou j’écris ces lignes le WHATWG vient de décider de continuer à travailler sur HTML seul de son coté, afin de ne plus être ralenti par les processus de validation du W3C.

Pour simplifier (heu…)

HTML se dirige pour être un langage vivant, plus de numéro de version, juste de nouvelles fonctionnalités. C’est plutôt une bonne chose dans le sens ou cela va simplifier considérablement son approche (syntaxe simplifié, on oubliera, html(x), xhtml(x), une seule spécification,…). Mais aussi c’est aussi une mauvaise chose, car sans numéro de version, pas de recommandations définitives et donc un support aléatoire des fonctionnalités par les navigateurs.

En attendant, HTML5 est la norme actuelle pour tout site web qui se respecte. Le status de recommandation pour html5 est prévu pour 2014.

Note : Mémé je te le dit : si ton navigateur fétiche ne supporte pas une fonctionnalité d’HTML5 exige une alternative pour ton navigateur(bugtrackers, prestataire, cousin qui fait des sites…).

… Tu comprends un peu mieux mon métier ma petite Grand-Mère ? Non ? … pas grave je suis sur que d’autres apprécieront :)

Si le sujet vous a plu, continuez la lecture : HTML5, raconté à mémé – part2

J’écris moins ici, mais plus ailleurs

Laisser une réponse
Twitt

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é

5 réponses
Twitt

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 !

10 réponses
Twitt

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

5 réponses
Twitt

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 

Développeur web, les liens utiles à garder sous le coudes

Laisser une réponse
Twitt

Les outils, c’est toujours quand on a besoin que l’on ne le retrouve plus ! Je prend sur moi et vous offre une liste de ressources vraiment utiles à garder sous le coudes (un autre traitant du sujet à lire par ici). D’ailleurs il faut vraiment le garder sous le coude puisque  j’ajouterai au fur et mesure d’autres liens (merci d’en soumettre en commentaire ;) ) Lire la suite →

Silex, une mini appli avec un bout de caillou

Laisser une réponse
Twitt

Silex framework PHPJ’ai récemment eu besoin de faire un dev pour une mini application permettant de récupérer les abonnés pour une mailing liste. Classique, rien de compliqué puisqu’il s’agissait d’un processus habituel : formulaire -> validation / erreur, gestion des différents retour (inscription validée que fait-on ? Erreur, comment informer l’utilisateur, etc…) . Lire la suite →

Atelier JS Puissant, un régal !

4 réponses
Twitt

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 →