Une fois n'est pas coutume, le petit projet dont je parlais était très égoïstement pour moi tout seul : cela fait presque 8 ans que j'ai refondu ce site, et curieusement, l'interface d'administration que j'avais faite à l'époque n'a pour ainsi dire pas bougé.
Son côté extrêmement spartiate… mais très pratique (rapide, léger et sans fioriture) m'a permis de tenir à jour ce site de manière efficace, comprenez par là que cela ne me prenait pas trop de temps. Entre Noël et maintenant, je me suis amusé à la refaire en utilisant le frameworkjQuery Mobile, sorti en version finale le 16 Novembre 2011.
Plutôt qu'un long discours, voici une petite salve de captures d'écran :
| |
| |
Autant le dire : je ne suis pas à la base un fanatique des frameworks… néanmoins, je reconnais qu'après un essai de jQuery Mobile sur un projet concret, je suis très agréablement surpris par le résultat. Je ne cache pas que mon idée était surtout d'utiliser cette interface sur mon iPad.
Les points forts de jQuery Mobile sont les suivants :
C'est relativement simple à apprendre, hormis quelques éléments de syntaxe, les divers éléments s'utilisent très simplement, en tout cas, je n'ai rien trouvé d'extrêmement complexe à l'utilisation,
le rendu du design est plutôt bon, pas besoin de se soucier de paramétrer beaucoup de choses pour avoir un résultat très satisfaisant, beaucoup de choses sont prises en charge automatiquement (chargements, transitions, etc.),
un très bon point : très peu de styles à ajouter ou redéfinir, j'ai dû ajouter quelques petites bricoles, et encore, ce n'était pas de l'ordre de l'impératif. Le rare cas échéant, il est assez aisé de les surcharger.
Les formulaires sont plaisants et assez simples à travailler, sans pour autant perdre en fonctionnalités.
Et détail important, ça fonctionne diablement bien, que je le teste sur iPad, iPod, Firefox ou Chromium, le résultat est homogène et fonctionnel.
Au passage, je me suis amusé à ajouter quelques balises d'HTML5 (les formulaires et la sémantique), la géolocalisation en page d'accueil, un cache manifest pour un mode hors-ligne, et je compte bien ajouter d'autres bricoles du genre.
Bref, jQuery Mobile colle tout à fait à la définition que je me fais d'un framework : réellement se simplifier la vie dans un cadre donné, et non pas reporter l'apprentissage d'un langage sur un framework (dans ce cas, je préfère apprendre le langage plutôt que le framework, question de point de vie).
Autant j'étais sceptique quant à la réelle utilité d'utiliser un framework pour du web mobile, autant jQuery Mobile a levé ces doutes pour montrer sa puissance et sa simplicité. Je ne peux que vous recommander de l'essayer !
Voici une bonne pratique que je regrette de voir souvent oubliée… y compris par moi-même parfois.
Si dans vos intégrations CSS, vous avez un bloc qui comporte une image de fond, comme par exemple sur ce site #bandeau via :
background: url(top.jpg) 0 0 no-repeat;
Et si ce bloc contient du texte, ayez ceci à l'esprit : si l'image ne se charge pas pour n'importe quelle raison, le texte qui va être dans ce bloc sera sur la couleur de fond héritée. Si vous n'avez pas indiqué de couleur de fond, il est possible que la couleur héritée pose un problème d'accessibilité.
Voici l'exemple sur mon site, simulé avec Firebug :
Comme vous pouvez le voir, le contraste n'est vraiment pas fameux.
C'est d'autant plus énervant que c'est très simple à régler, il suffit de spécifier la bonne couleur de fond dans la règle CSS qui appelle l'image de fond de votre bloc. Dans mon cas :
background:#EEEBDA url(top.jpg) 0 0 no-repeat; (j'ai juste rajouté une couleur de fond)
Si je reprends l'exemple sur mon site, simulé avec Firebug :
Comme vous pouvez le voir, c'est bien meilleur ainsi.
Pensez-y : c'est très simple à prévoir, et cela peut éviter de fâcheux désagréments.
Feu mon grand père avait une expression qui m'a toujours interloqué étant petit : quand il entendait quelqu'un dire « on », il disait :
« On », pronom imbécile, définit celui qui l'emploie.
L'expression était livrée telle quelle, sans service après-vente, de but en blanc. J'avoue que je n'en voyais pas le sens réel, si ce n'est que dire « on » le faisait râler.
Environ 25 ans après, au hasard de discussions avec des personnes extrêmement branchées développement personnel masculin, ils me racontent dans une longue diatribe (je résume) qu'il est important de personnifier ses paroles, autrement dit, de dire « Je vais faire ça, Je compte faire ceci, tu dois faire ceci, etc. », ce que ne permet pas le « on », qui par définition est impersonnel.
Même si je ne suis pas autant branché développement personnel que ces personnes (pour qui cela tourne à l'obsessionnel, mais c'est une autre histoire), je ne peux qu'être d'accord. Et là, je me suis souvenu de cette expression. Étonnant, j'ignore s'il mettait le même sens dans sa phrase, néanmoins, il y a de quoi tiquer.
Je pourrais en tirer de longues conclusions sur le développement personnel, sur mon grand père, etc. mais je préfère juste en tirer un petit sourire…
Un peu d'humour en ce début d'année, j'ai de nouveau imaginé ce que seraient les nouvelles bonnes résolutions… des clients d'agences web, l'année précédente était un bon cru, mais cette année comporte quelques pépites :
Si j'ai une demande, et que cette dernière impacte fortement une tâche qui doit par exemple se dérouler le Mardi à 15H, je ne vous contacterai plus le Mardi à 14H55, mais plus tôt.
Je ne vous appellerai plus juste après vous avoir envoyé un e-mail pour discuter dudit e-mail, c'est une perte de temps, je sais que vous lisez vos e-mails.
Corolaire de la résolution précédente : je ne vous téléphonerai plus pour vous dire que je vous vais vous envoyer un e-mail, c'est également une perte de temps.
Non, je ne lancerai plus un site un Dimanche, je sais maintenant que vos développeurs ont une vie privée ET une vie sociale.
Corolaire de la résolution précédente : lancer un site un Vendredi en fin de journée n'est PAS une idée géniale.
Je ne mettrai plus la Terre entière en copie quand je suis énervé, car il est possible que dans votre réponse, vous mettiez également la Terre entière en copie, et si c'est moi qui ait tort, cela va me mettre dans l'embarras (et accessoirement, cela ne concerne que vous et moi).
Si je ne connais rien à un domaine, par exemple l'intégration, je n'essaierai plus d'avoir l'air malin, je ferai mes demandes en bon français, et charge à vous de traduire ça dans votre langage.
Je comprends que vous demander un petit rabais est envisageable, néanmoins, je comprends aussi que diviser votre prix par deux ou par trois impliquera de vous demander deux à trois fois moins de travail.
Corolaire de la résolution précédente : non, je ne demanderai plus un développement d'un site complexe en espérant que vous me ferez un prix ridiculement bas.
Note : c'est toujours de l'humour… nous ne sommes absolument pas parfaits non plus.
Il y a quelques années, j'ai pu mesurer l'importance de miser sur les standards du web, et surtout des standards ouverts et libres.
La société précédente qui m'employait avait son intranet, programmé avec amour par mes soins. En bon convaincu des standards, j'avais programmé ce dernier en utilisant PHP, MySQL, XHTML/CSS.
Cet intranet gérait beaucoup de choses :
plein de types de factures (et leur version imprimable via CSS),
les vacances (ça c'est le plus important),
divers processus plus ou moins complexes de feuilles de travail pour les employés, etc.
Le tout était consultable dans n'importe quel navigateur. Pour un certain confort d'utilisation, je recommandais Firefox à l'époque, entre autres notamment pour ses onglets et pour pouvoir naviguer rapidement dans des select avec de nombreux choix (on pouvait taper "Dur" pour accéder aux entrées commençant par "Dur", Internet Explorer ne permettant d'atteindre que la première lettre, donc on ne pouvait chercher qu'à partir de "D", ce qui est moins pratique).
A l'époque, j'avais également programmé un petit intranet pour un grand compte. J'avais utilisé l'ASP et Access (qu'on m'avait imposés), mais le rendu des pages était fait via XHTML/CSS.
Un matin, j'arrive à la pause café, et je vois nombre de collègues en grande discussion avec des personnes que je ne connaissais pas. Ces dernières étaient en fait responsables de l'informatique et des intranets dudit grand compte, lequel avait fait le choix pour leurs intranets du tout Microsoft, "proprio et ActiveX" comme je disais en riant.
On me présente à ces personnes comme étant le responsable des deux intranets mentionnés ci-dessus, et s'engage une discussion d'une heure assez surréaliste (je résume) :
— (s'adressant à moi) Vous devez être sous perfusion de stress ces temps-ci ! — Heu non, pas en particulier, pourquoi me dites-vous cela ? — Bin avec la migration, ça tourne à la catastrophe chez nous. — Quelle migration ??? — Bin on va passer à Internet Explorer 7, et c'est pas triste avec nos intranets. — (interloqué) Et pourquoi donc ? Ça fait un bout de temps qu'il est sorti, ça marche plutôt bien, et honnêtement ça a pas changé grand chose par rapport au 6. — Vous plaisantez ? Les intranets avec ActiveX ne fonctionnent plus correctement, on a des bugs de rendu, ça fait des mois et des mois qu'on bosse à cette migration, et on a problèmes sur problèmes ! — Ah bon ???
(à partir de ce moment, je me suis rendu compte qu'on parlait de deux mondes complètement différents)
— L'intranet dont vous vous occupez pour nous n'a pas de problème ? — Bin pourquoi voudriez-vous qu'il en ait ? Le rendu est le même, j'utilise pas ces cochonneries d'ActiveX, et ça fonctionne sur n'importe quel navigateur à partir d'Internet Explorer 6. C'est un peu plus agréable avec Firefox, mais c'est du petit confort en plus. — Vous n'avez pas de problème de rendu ? — Pour être honnête, j'ai repris le design corporate au pixel près, mais je l'ai réintégré en CSS histoire de ne pas me faire ch… suer. — Nous c'est stress test depuis des mois pour une centaine de développeurs, plein de problèmes de compatibilité… heureusement qu'on n'a qu'Internet Explorer. Quand y a un nouveau navigateur, vous faites comment pour vos intranets ? — Biiiiin… je fais pas grand chose, un rapide tour d'horizon, et tout fonctionne. J'ai eu une fois en 4 ans un problème de rendu dans les versions imprimables des factures, je l'ai corrigé en au moins… 10 bonnes minutes ! — Mais c'est pas possible ça ! — Je peux vous assurer que je n'y passe pas plus de 3 minutes en temps normal. Vu que ce sont des pages web, je n'ai pas à m'en soucier. Par acquis de conscience, je vérifie quand même pour pouvoir garantir que mes collègues puissent mettre à jour leur navigateur le jour même, mais tant qu'ils utilisent un navigateur récent, à la rigueur, je m'en fous, je sais que ça fonctionne, surtout que chacun de mes collègues utilise un navigateur différent. Et heureusement, car je suis tout seul au développement et je m'occupe d'autres trucs, vous imaginez si je devais passer une semaine à chaque fois, ça serait pas possible ! (en riant) — Etc.
Soyons honnêtes, l'échelle n'est pas la même. Quoique l'intranet que j'avais fait pour eux, même modeste, tournait sur 4 continents sans souci.
La différence était un choix de départ, j'avais fait un choix de standards libres et ouverts, ils avaient fait le choix du propriétaire avec plein de dépendances complexes.
Résultat, j'ai eu la nette sensation de voir deux mondes antagonistes ne pouvant même pas se comprendre. Là où je voyais de la simplicité et aucun problème particulier, en face des problèmes extrêmement complexes. Là où une personne suffisait à gérer le tout, en face de grosses équipes peinaient.
Et encore, je ne parle pas de la réactivité, de l'extensibilité, des prix des licences, du coût de maintenance et des autres navigateurs… et le plus drôle, c'est que j'ai ouï dire que l'intranet que j'avais fait pour eux tourne encore 5 à 6 ans après. Quant à celui de mon ancienne boite, il tourne toujours depuis plus de 7 ans.
Définitivement, je crois que les personnes responsables de ces choix devraient mesurer l'importance des standards libres et ouverts, de ce qu'ils garantissent de facto, des économies qu'ils permettent, et plus largement que leur universalité n'est pas une option à sous-estimer.
Encore quelques efforts, et une partie très ancienne de mon site va être totalement refondue… et quand je dis ancienne, je pèse mes mots, vu qu'elle était déjà là depuis le début, c'est-à-dire depuis 8 ans !
Comme cette refonte implique un changement plutôt radical et des techniques relativement modernes, elle sera présentée de manière assez exhaustive en temps et en heure.
J'ai eu le plaisir de lire "HTML5 pour les web designers", un petit livret sur les nouveautés d'HTML5 écrit par Jeremy Keith.
Le format plutôt léger (moins de 100 pages) peut paraître surprenant à côté d'ouvrages plus volumineux, néanmoins c'est un de ses points forts (le livre se lit très vite).
L'auteur aborde divers points :
l'histoire d'HTML5, en substance "comment en est-on arrivé là", avec l'échec de XHTML2, etc.,
les changements dans le balisage : les balises obsolètes, les nouveaux sens sémantiques de certaines balises existantes,
les médias riches comme video et audio sont bien abordés, Canvas l'est également mais de manière très rapide,
les web forms sont traités de manière assez complète,
dans une partie assez conséquente, la sémantique des nouvelles balises, qui est à mon humble avis le point fort du livre. Les nouveaux modèles de contenus et de segmentation de documents sont bien expliqués, les nouveautés pas si anodines que ça sont bien traitées.
Une partie finale sur la mise en place de ces nouveaux éléments d'HTML5 clôt le livre, avec de bons points à savoir.
L'auteur élude complètement les nouvelles APIs en les présentant très succinctement… et ce parti pris totalement assumé noir sur blanc est à mon avis une très bonne idée : l'auteur se concentre sur le balisage, et le fait très bien.
C'est assurément une bonne lecture pour débuter en HTML5 ou pour parfaire ses connaissances sur la sémantique d'HTML5.
Au menu : suite à une remarque sur Twitter, le choix des radio et autres select est rendu plus pratique, et j'ai ajouté l'attribut class sur les champs, que j'avais curieusement omis depuis le début du projet.
D'autres améliorations devraient être rapidement ajoutées !
Édit : tiens, premier billet posté depuis l'iPad ! Et sûrement pas le dernier vu ce que je prépare…
Amusante expérience de ce matin : je viens de tester avec succès la mécanique de la lancée d'un troll (sujet volontairement polémique) ou d'un buzz (un sujet qui va avoir un relai certain, positif ou négatif).
L'idée a été toute simple, j'ai juste indiqué sur Twitter la phrase suivante : Allez, montrons l'exemple : plus de méta description ou keywords sur mon site, une cochonceté en moins.
Immédiatement, j'ai eu plusieurs réactions, des personnes qui se et me questionnent, d'autres qui bondissent (à juste titre)…
La technique est simple, lancez :
soit un titre choc, une aberration au sens commun (Chrome est le nouvel IE6, très beau celui-là),
ou un sujet imprécis,
ou encore un sujet… sujet à interprétation,
ou un sujet ne prenant qu'un aspect en compte, etc.
Mon exemple était particulièrement parfait, faisant presque partie de tous les cas ci-dessus.
En l’occurrence, c'est vrai, j'ai supprimé ces balises de mon code. Ce qui appuie ma démonstration, vu que je l'ai fait. Ceci dit, la réalité est bien autre.
En référencement naturel pour Google, la balise méta keywords est effectivement ignorée selon plusieurs sources. Quant à la balise méta description, toujours uniquement chez Google, elle sert surtout dans certains cas dans les résultats, elle est affichée en-dessous de la page trouvée. Ce propos n'est donc valide que pour le référencement naturel pour Google. Et en toute honnêteté, je suis bien incapable de dire si c'est le cas pour les autres moteurs de recherches.
Comme me l'a vite fait remarquer Élie que je cite : Les mots-clés et descripteurs ne sont pas des trucs pour Google mais des outils de la documentation.
Je rajouterais bien : Les mots-clés et descripteurs ne sont pas uniquement des trucs pour Google…. Là, Elie montre rapidement que mon propos ne prenait en compte tout l'aspect de la question.
Désormais, avant de foncer sur un titre ravageur (Apple est mort, Google est le nouveau Microsoft, les standards du web sont le nouvel intégrisme, etc.), relativisez. Avant de relayer une info, vérifiez-la. Ou du moins, situez bien le cadre de cette information. Et admettez que le cadre peut en être limité, même si vous êtes un expert dans le cadre dont vous parlez.
Quant à la suppression de ces balises, je les ai virées effectivement, non pas pour soutenir mon propos, mais plutôt parce que leur qualité laissait franchement à désirer en l'état actuel des choses sur mon site (encore une imprécision volontaire de mon propos). Et je prie ceux que mon tweet a interpelés de m'excuser (en même temps, c'est vendredi, et c'est le jour du troll).
Au menu, je reprends une de mes premières images Terragen 2, une des plus longues à calculer à l'époque, je crois qu'il m'avait fallu plus de 1000 heures de calcul sur mon ancien ordinateur. Des surplombs, de la réflexion… et beaucoup, beaucoup de calme.
Définitivement : c'est quand même mieux en version animée !
J'avais commencé à lire "HTML5 : De la page web à l'application web" il y a un certain temps déjà, mais quelques aléas m'ont empêché de le finir rapidement. Toutefois, cet étalement dans la lecture est désormais réglé, je viens de le finir ce matin même !
Comme les auteurs Jean-Pierre Vincent et Jonathan Verrechia font dans ce livre, je vais droit au but : c'est une lecture très plaisante, riche et intéressante.
Les auteurs ont un point de vue très pragmatique sur toutes les nouvelles possibilités qu'offre HTML5, c'est à mon sens le point fort du livre : ici point de délire qui fonctionne sur un navigateur en version alpha, c'est du concret.
Le livre commence en douceur par une rétrospective de l'arrivée d'HTML5, les nouvelles balises et attaque ensuite les nouvelles possibilités des formulaires.
Jusqu'ici, vous pourriez me dire que si vous avez déjà lu CSS avancées, vers HTML5/CSS3 de Raphaël Goetter, point de grosse nouveauté… et vous n'auriez pas totalement tort.
Toutefois, il serait vraiment dommage de s'arrêter là, car à mon avis, le livre se différencie totalement de celui de Raphaël à cet instant et prend à mon humble avis son envol avec Microdata, ARIA, le livre glisse doucement vers les applications et sort de l'intégration pure.
La deuxième partie sur les API confirme cette sensation (et le titre du livre !) : Audio et Video, Canvas, Drag and Drop, File, la géolocalisation, le web déconnecté… c'est très dense et toujours vu d'un œil très pratique et pragmatique. A l'aide d'exemples très simples, les auteurs nous montrent des possibilités assez fantastiques et très prometteuses.
Le livre se finit sur un partie assez pointue sur WebSockets (où l'intérêt et la compétence reconnue des deux écrivains en matière de performances web se ressent particulièrement), et offre en annexe des fiches pratiques pour chacun des sujets abordés, une sorte de trousse à outils numérique si j'ose dire.
Assurément, si vous faites un minimum de veille technologique ou si vous vous affublez du titre de développeur Front-end, il est impensable de passer à côté de ce livre "HTML5 : De la page web à l'application web". Il se lit bien, c'est concret, sérieux sans se prendre au sérieux.
