J'ai contacté les organisateurs de la conférence XML Balisage 2008 qui aura lieu du 12 au 15 août à Montréal. Je leur ai offert que le W3Québec organise une de leur soirées de discussions sur XML. La prochaine réunion du W3Québec aura donc lieu à la conférence même et nous y discuterons de l'utilisation du XML en développement Web et plus spécifiquement au s'en va la technologie XML en développement Web. Nous savons que le XHTML à ses détracteurs et que JSON est un compétiteur pour l'échange de données. Il y a aussi Atom et AtomPub qui semblent avoir beaucoup d'avenir. Je suis sur que nous toucherons RDFa, ARIA-Roles, SVG, XHTML 2 et MAthML aussi. De façon peut-être assez haut niveau, mais ce sera certainement assez intéressant de regarder les enjeux de l'utilisation de XML en développement Web. J'espère que des lecteurs de XMLfr pourront venir faire un tour à Montréal pour la conférence, j'aimerais bien vous rencontrer en personne. La réunion aura lieu le 12 août de 19 heures à 20:30 au Best Western Hotel Europa Downtown à Montréal et exceptionnellement, elle aura lieu en anglais (à cause du public). On "switchera" (scusé l'anglicisme) au français si tout le monde dans la salle peut le parler. Les infos plus complètes seront présentes sur le site du W3Québec quand je reviendrai vacances (première semaine de août). A+

Je suis tombé sur un problème hier au sujet de balisage de titre de sections (h1 / h6) dans le cadre de développement dans un portail d'entreprise basé sur la technologie de portlets. (Note: les portlets sont des minis applications que l'on peut placer un peu partout dans un page). Respecter la sémantique des h1 / h6 me semblait difficile. L'utilisation de portails de ce type ne respecte déjà pas en grande partie la façon de faire du Web, la métaphore de document avec un flux ne fonctionne que très peu ou pas du tout. On parle plus ici de bureau de travail contenant plusieurs applications, qui parfois contiennent des documents. Mon premier réflexe était de réinitialiser le flux de document dans chaque portlet, de façon à commencer par un h1 dans chacun d'entre eux. Toutefois, cela fait beaucoup de h1 dans une même page, ce qui va à l'encontre de la manière de construire une page Web (qui respecte un flux de document). Je ne peux pas non plus partir du titre d'une page (ou d'un ensemble d'applications) puisque les portlets peuvent être organisés de façon différentes selon la configuration ce qui peut briser le flux du document. Je suis près de conclure que la sémantique de h1 / h6 ne fonctionne pas avec un portail (bureau de travail) et que je serai obligé d'utiliser un div semantiquement faible avec un class "titre-portlet" ou plutôt "titre-application". Par contre, il arrive souvent qu'un document soit inclus dans un portlet et qu'à ce niveau, la sémantique h1 / h6 fonctionne et serait très utile. Mais ça ne règle pas le problème que si ce document est relié de quelconque façon à la page originale. Ce lien est perdu, puisqu'un portlet par défaut ne doit pas connaître son environnement (pour être réutilisable). La seule façon d'y remédier, serait d'ajouter des éléments de configuration spécifique à une page pour informer le portlet de l'environnement "de document" autour de lui, pour que celui-ci puisse baliser ses titres correctement. Mais vous allez conclure avec moi que le retour sur investissement de ce genre de développement ne vaut pas la peine du tout.

Cela démontre aussi que la sémantique de certaines balises HTML peuvent être dans certains contextes difficiles à respecter. Finalement, la meilleure analogie que je pourrais trouver et qui renforce ma première solution est que c'est comme si nous avions plusieurs iframe ou object dans un page... enfin, je ne suis pas tellement satisfait de cette solution non plus.

Samuel Sirois nous présentera aujourd'hui une introduction au protocole HTTP. En tant que développeurs Web, nous devrions mieux connaître ce standard sur lequel toutes (ou presque) nos applications reposent.Nous allons peut-être nous rendre compte que HTTP est souvent aussi malmené et mal compris que les autres standards comme HTML et CSS.

Après un tout petit peu de repos (trop peu je dois admettre) c'est le temps de faire un petit retour sur Intracom Québec 2008 qui j'ai comme l'impression a été un des meilleurs sinon le meilleur depuis ses débuts. Tous les gens que j'ai croisés étaient très satisfaits et j'ai bien hâte de voir ma note pour les présentations auxquelles j'ai participé. Personnellement, je suis bien satisfait de ma prestation, et comme un geek gêné de parler en public je trouve que je me suis pas mal bien débrouillé merci. Surtout que j'ai un message qui est parfois difficile à traduire en termes non techniques, ce qui est un défi à relever en soi.

Ce que j'ai fait à Intracom va dans la direction que je me suis donnée comme président du W3Québec soit de donner un visage plus business aux standards Web (sans oublier le côté social). Le travail n'est pas terminé, le message doit encore être amélioré, mais je pense que j'ai atteint une étape de plus vers cette direction. Pour la première fois aussi, j'ai l'impression de ne plus être dans l'ombre de l'ancien président et fondateur du W3Québec qui est un excellent communicateur.

Assez parlé de moi, je vais vous parler d'un des highlights pour moi de la conférence : La présentation de Hydro-Québec sur Comment intégrer plusieurs systèmes dans une page Web était très intéressante. Elle donnait un point de vue architecture sur l'intégration de plusieurs systèmes d'entreprise dans un même site Web. Le présentateur démontrait que la solution la plus facile à implémenter était (entres autres) d'avoir une norme de développement pour tous les éléments de présentation qui incluait la séparation structure et présentation et les standards Web et le respect des standards Web, pour que les bouts de HTML provenant de plusieurs systèmes puissent être bien intégrés ensemble. Tout cela, sans avoir de contrainte autre que de supporter Internet Explorer 6. Il a toutefois ajouté que l'avantage de supporter les autres navigateurs était présent, même si cela ne faisait pas partie des contraintes de base. J'ai trouvé ce discours très rafraîchissant, particulièrement puisque les solutions proposés demandent en général l'utilisation d'outils très lourds de portails qui ne respectent ni les standards ouverts, ni l'accessibilité out of the box (et cela coûte cher de rétrofitter les concepts de base du Web dans ces outils, parlez moi en d'expérience). L'approche du présentateur était assez haut niveau, top down même, et j'ai pu y trouver plusieurs arguments que je pourrai réutiliser.

Petite note : ces temps-ci j'écris un peu moins. Je vais probablement poster encore quelques billets sur les retours d'Intracom 2008, puis je vais tomber dans une petite hybernation, le temps de migrer mon blogue à une autre technologie plus facile à mettre à jour et qui est mieux sécurisée contre le pourripostage. Si vous avez des suggestions la dessus, n'hésitez pas à me contacter. J'hésite des fois à coder le truc moi-même parce que je ne trouve rien qui me plaît en ce moment. Sauf que je si je fais cela, vous risquez de ne plus entendre parler de moi pendant un bon bout.

Les diapos sont disponibles ici.

Les préparations pour le prochain Intracom au centre de congrès de Québec le 29, 30 avril et 1ier mai vont bon train et le W3Québec y présente une conférence et un combo. Le tout risque d'être fort intéressant et j'espère bien de vous y voir en grand nombre et que vous y trouverez votre compte avec les nombreux conférenciers de renom (dont votre humble serviteur ;-) ). Voici sans plus tarder les conférences que le W3Québec présente :

Guerre des navigateurs 2.0 : des nouveautés au 2008

Serait-ce possible ? Une nouvelle guerre des navigateurs ? Doit-on s'attendre au pire des excès de la fin du 20e siècle ?

Avec l'avènement du Web 2.0, les interfaces riches, du Web social, une meilleure compréhension des standards ouverts et la létargie du géant Microsoft pendant le début du 21e siècle, de nouveaux navigateurs Web ont pris une bonne part du marché et proposent de nouvelles manières de voir et d'expérimenter le Web. Ces joueurs collaborent ensemble pour réinventer le Web avec le futur standard HTML 5.

• Quels sont ces navigateurs et quels seront leurs impacts sur nos réalisations Web ?
• Quels sont les autres technologies qu'ils complémentent ou compétionnent ?
• Auront-ils des impacts sur les géants Google, Microsoft, Adobe et Apple ?

Combo : Amélioration de la qualité des réalisations Web

En analysant la qualité de la réalisations de projets Web, nous remarquons souvent des écarts assez importants par rapport aux bonnes pratiques de développement. Ce combo réunira 5 experts de champs de domaines différents relié de près au Web : Stratégie et analyse, optimisation pour les moteurs de recherche, sécurité, utilisabilité et développement. Chacun d'eux nous parlera de comment améliorer la qualité d'une réalisation Web par rapport à son champs d'expertise.

Nous allons ensuite tourner notre attention vers des enjeux en qualité représentés par des exemples précis que les panelistes commenteront. Pourquoi des recommandations d'experts peuvent être incompatibles entre elles et comment faire les bons choix lorsque cela arrive.

Les panelistes pour le combo sont :

• Jean-François Renaud, de Adviso Conseil
• Nathalie Berger, de Idéactif et Utilisabilité Québec
• Guillaume Séguin, de Okiok
• Samuel Lavoie, de NVI Solutions et W3Québec
• et moi-même, Benoit Piette de W3Québec et Nurun

Pour en savoir plus, faites un tour sur le site officiel d'Intracom 2008.

Quand j'essaie de convaincre les intervenants en dehors des développeurs des avantages de s'assurer de la conformité des réalisations Web dont ils sont responsables, j'hésite souvent de leur parler directement des standards Web. J'ai l'impression que c'est un peu stérile de dire :"Vous devriez vous assurer que vos sites valides parce que x, y et z". Même si x y et z sont très valables, le lien avec le besoin d'affaire est pas toujours clair. J'ai l'impression de répeter toujours la même chose à des gens qui ne s'intéressent pas aux détails d'implémentation. Quelque part, ce que j'ai le goût de faire en ce moment qui je pense sera plus positif à long terme est d'essayer de connaître et de bien comprendre les vrais objectifs derrière la réalisation de projets Web. Les objectifs d'affaire, opérationnels et de ventes. Je sais que l'application correcte des standards Web aident ces objectifs, mais ils sont un moyen, parmi d'autres de les atteindre et de les atteindre mieux et plus rapidement. Mais je ne veux pas m'arréter là, je vais même appliquer un doute cartésien aux standards ouverts par rapport à ces objectifs. Pourquoi pas ? Il y a je pense des sites Web, qui par leurs buts plus mondains et leur moyens plus limités n'ont pas besoin de se conformer. Après tout, c'est l'une des forces du Web de pouvoir faire des choses vraiment imparfaites qui réussissent à rejoindre peut-être pas tout le monde, mais assez de gens pour que cela soit profitable. Il y a rien de mal à cela, et même qu'à partir de là, les besoins évoluent jusqu'à un point ou une meilleure conformité, une meilleures utilisabilité et accessibilité vont avoir un retour sur investissement qui réponds aux objectifs de base. Je n'ai pas de réponse exacte à tout cela, mais j'y réfléchi pour pouvoir ajuster le discours de promotion des standards ouverts Web pour qu'il soit le plus pertinent possible. Il faut admettre aussi qu'il y a des modèles d'affaires qui vont complètement à l'encontre des standards ouverts et je dirais même pour lesquels les standards ouverts sont néfastes. Dans ce cas-ci, on arrive à être contre des modèles économiques qui vont à l'encontre d'une morale sociale. On tombe ici dans le socio-politico-éthique-économique qui quelque part va aussi donner un autre pourquoi aux standards ouverts. C'est la dichotomie libre versus ouvert qui existe aussi pour les standards ouverts. Un autre point sur lequel il est important de se pencher. On peut limiter nos arguments à des arguments économiques ce qui est très valable en soi. Les arguments sociaux et éthique sont aussi importants. L'argument social pour l'accessibilité est un bon exemple. Si l'argument économique pour exiger qu'un site Web respecte l'accessibilité est que sinon vous allez être poursuivi, il n'y a dans le fond que l'argument social, éthique et par le fait même politique qui pousse indirectement ces sites Web à être accessibles. Pour pousser à l'interopérabilité, qui est le fer de lance de la pérénité par les standards ouverts, il faut parfois aussi empêcher des monopoles par des lois. On ne passe pas à côté de cela. On sait aussi que les brevets logiciels, s'ils ne sont pas contrôlés et on peut aller jusqu'à dire abolis, sont néfastes et mêmes contraires à la pérénité de l'interopérabilité. Je ne vous apprends rien en vous disant que brevet = monopole et que monopole != interopérabilité.

Vous ne le savez peut-être pas, mais depuis le 6 février, le W3Québec a 5 ans. En effet, la première réunion du Web Standard Meetup Group de Montréal, qui n'avait pas encore le nom de W3Québec, a eu lieu le 6 février 2003. Beaucoup de choses ont changés depuis 5 ans!

Voici quelques sujets que j'aimerais retrouver à l'une des prochaines réunions mensuelles du W3Québec.

Si vous seriez intéressé à venir parler d'un de ces sujets, n'hésitez-pas à me contacter

• Développement d'interfaces Web riches avec Adobe Air et Flex
• Développement d'interfaces Web riches avec Silverlight et .NET
• Développement d'interfaces Web riches avec Mozilla, XUL et Prism
• Développement Web avec les librairies javascript (Dojo, ou YUI ou jquery ou prototype ou autres)
• Accessibilité des applications à interfaces riches
• Intégration d'application Google (Google Maps, Google Apps, etc)
• Présentation d'application Web 2.0 québécoises (startups et autres)

Il a Samuel Sirois qui va venir nous parler de HTTP dans quelques mois, ce sera certainement intéressant. Ma présentation sur REST ma démontré que nous n'en savions pas assez sur le protocole qui est à la base de presque tout ce que l'on fait!!! J'avoue que je n'ai pas tout compris sur les différences entre POST et PUT (leur idempotence entre autres)

D'autres sujets sont les bienvenus aussi. Il manque de XML la dedans... (ben dans le fond il y en a indirectement)

Lors de la réunion mensuelle du W3Qc hier, je parlais avec Samuel Sirois (Trigosoft) qui suit présentement le cours de Jean-Marie D'Amour sur l'accessibilité. Nous discutions des éléments et attributs en accesibilité que HTML 5 prévoit peut-être laisser tomber, comme l'attribut summary pour les tableaux. L'argument est sensiblement celui-ci : lors de tests d'utilisation de l'attribut, il a tendance à ennuyer les utilisateurs plutôt qu'à les aider.

Or, Samuel me disait, cela est différent selon le type de document. Dans une application que quelqu'un utilise souvent, l'attribut summary est répété à chaque fois. Il est donc particulièrement désagréable (surtout s'il est long). Par contre, sur un site Web visité très peu souvent, l'attribut est beaucoup plus intéressant puisqu'il aide l'utilisateur à se faire un modèle mental du tableau avant que celui-ci soit exprimé.

Dans le premier cas, le modèle mental existe déjà et il est redondant. Dans le 2e cas, il est vraiment utile. La solution ici est bien plus au niveau d'utiliser l'attribut à des bons moments (sur un site Web plutôt que dans des applications Web, par exemple), ou encore que les agent utilisateurs donnent la possibilité aux utilisateur de ne pas faire répéter les descriptions de contenus qui ont déjà été exprimés.

Une solution pourrait être que pour une session, l'agent utilisateur ne répète pas les descriptions des éléments qui ont le même id ou la même class. Cela vaudrait peut-être un attribut spécial en css pour le spécifier.

En utilisabilité, on dit que c'est important de ne pas se répèter, en accessibilité aussi! Ce que je comprends, c'est qu'il y a beaucoup de méconception sur l'accesibilité et qu'il faut réfléchir bien comme il faut plutôt que suivre des recettes toutes faite qui peuvent si mal utilisées diminuer l'accessibilité au lieu de l'améliorer. Je crois aussi qu'il ne faut pas mélanger les fonctionnalités d'un langage et les bonnes pratiques. Les bonnes pratiques ne sont pas des recettes, mais des méthodes avec une philosophie derière. Si un élément d'un langage est le plus souvent mal utilisé, ce n'est pas le rôle de standardiseurs du langage d'enlever l'élément du langage, mais bien le rôle de ceux qui font la promotion des bonnes pratiques de promouvoir les bonnes utilisations de l'éléments (et ce, même s'il y en a des mauvaises). Cela passe effectivement par comment l'élément du langage est utilisé dans la vrai vie, et d'y trouver des bonnes utilisations. Il est vrai qu'il peut y avoir des éléments de langage qui n'ont pas assez de bonnes utilisations pour être retenus, mais je ne pense pas que ce soit le cas pour l'attribut summary.

Reste maintenant à spécifier quelques bons cas d'utilisation et en parler sur la liste du Working Group de HTML...