<C²: webløg />

Courriel - email address

archives de juillet 2004

Avatar Denis

lundi 26 juillet 2004
par Denis Boudreau

16ième rencontre de W3Québec

Pour ceux d'entre vous que ça intéresse, W3Québec tiendra ce soir sa rencontre mensuelle dans les locaux du RAAMM. À l'ordre du jour, de nombreux points à aborder, dont notamment :

  • l'incorporation de l'organisme
  • les avancements sur le brand, le design et sur la solution backend du site
  • le statut sur les sections à construire en v1.0
  • la rédaction de contenus dans un modèle collaboratif
  • les opportunités de formation à webÉducation
  • le retour de rencontre sur le Web sémantique qui se tenait le 21 jiullet dernier
  • la situation actuelle avec le rapport Gautrin.

Bref, beaucoup de pain sur la planche, et que du bon ! Au plaisir de vous y retrouver, pour une première fois, ou à nouveau !

Note : Oui, je sais, je vous dois toujours un billet sur les raisons m'ayant motivé à abandonner XHTML 1.1 au profit de XHTML 1.0 strict. Ça s'en vient. Je me flagelle quotidiennement de culpabilité pour ne plus tenir le rythme auquel je vous ai si amoureusement habitué. Que voulez-vous, ce serait quand même indélicat de me plaindre d'avoir trop de boulot. ;-)

Denis Boudreau | 2004.07.26 @ 10:00 | 2 commentaires | 0 trackbackretour au début de la page

Avatar Denis

dimanche 18 juillet 2004
par Denis Boudreau

De l'intérêt du bouton reset

Ce soir, je rembourse une vieille dette. Il y a très très longtemps de cela (mai 2004), katsoura me faisait parvenir un courriel dans lequel il me questionnait sur la pertinence d'un bouton reset dans nos formulaires de commentaires et de contact sur C². Son argument allait sensiblement ainsi : à quoi ça sert, ce n'est rien de plus qu'une source potentielle d'erreurs au moment de la validation, qui pourrait bien vouloir vider un formulaire après l'avoir rempli, etc. Les commentaires sur son billet allaient également en ce sens. La plupart des blogues n'en ont d'ailleurs pas non plus dans leurs formulaires et par défaut, un outil comme Dotclear ne le prend pas en charge non plus. Bref, de manière générale, la majorité d'entre nous semblont faire fi de ce champ de formulaire en remettant en cause sa pertinence.

Pour être complètement honnête, malgré le fait que je m'en serve encore, j'ai tendance à être d'accord avec eux tous. Le bouton reset semble promettre à l'utilisateur plus de frustrations que de bénéfices. Si ce n'est du fait que traditionnellement, un formulaire venait avec un bouton d'effacement et un bouton de soumission, je ne vois plus forcément de raisons valables pour les utiliser sur un carnet Web ou n'importe quel autre site n'impliquant pas un échange de données véritablement sensibles. C'est donc dire que si je prenais le temps de faire une telle mise à jour du code sur C², je considérerais peut-être de l'enlever... j'hésite encore.

Toutefois, il y a des situations dans lesquelles un tel bouton me semble nécessaire. Je pense entre autre à un formulaire de transaction lors d'achats en ligne ou lors de transmission de données personnelles sensibles, comme un numéro de carte de crédit ou un numéro d'assurance sociale. Si un utilisateur en cours de saisie décidait de changer d'idée en cours de route (indépendamment des raisons motivant un tel choix), sa meilleure garantie de ne pas transmettre des informations contre son gré demeurerait le bouton reset. On clique et hop, le formulaire se vide. On a l'esprit tranquille et on poursuit sa vie, bien peinard.

Mais dans de tels cas, le problème de l'erreur potentielle demeure entier... J'imagine la frustration d'un utilisateur qui commettrait l'erreur du mauvais clic après plusieurs minutes passées à remplir un formulaire à cause du bête erreur d'inattention. Pour contribuer à éviter un tel drame, il faudrait simplement inculquer de bonnes pratiques autour de son utilisation :

  • Le placer systématiquement à gauche du bouton de soumission ;
  • Lui donner un aspect visuel différent du bouton de soumission ;

Ainsi, facilement, on diminuerait le risque d'erreurs. Évidemment, c'est loin d'être infaillible, mais ce serait déjà moins risqué si on persistait à l'utiliser. Alors, vous en pensez quoi ? On le vire ou on le conserve ?

Denis Boudreau | 2004.07.18 @ 21:42 | 20 commentaires | 1 trackbackretour au début de la page

Avatar Paginus

vendredi 09 juillet 2004
par Normand Lamoureux

Le HTML, facile ?

La déconstruction d'un mythe

On sous-entend trop souvent et on concède trop rapidement que le HTML est facile ; qu'il ne demande que peu ou pas de connaissances techniques ; qu'il est aisé à manier et relativement rapide à apprendre. C'est faire l'économie des contradictions qui sommeillent en lui. C'est occulter les aléas de son histoire et les difficultés qu'il recèle. Bref, c'est aller un peu vite en besogne. Aussi vais-je tenter de mettre en évidence la relative complexité qui se cache derrière cette apparente simplicité.

Le HTML est tellement facile, serais-je tenté d'objecter, que les personnes avisées ne s'entendent pas toutes sur la différence à faire entre <abbr> et <acronym>. Et encore moins sur l'opportunité de maintenir une distinction si subtile au sein de ce qui se veut la langue commune du Web.

Tellement facile, qu'on rencontre encore des développeurs professionnels se demander l'intérêt qu'il peut y avoir à remplacer <b> par <strong>, vu l'allongement du code que cela représente, ou <i> par <em>, étant donné que l'un comme l'autre aura pour effet d'afficher le texte en italique. Dans la plupart des navigateurs, du moins.

Tellement facile, que des auteurs sérieux ne sont pas loin de penser que des éléments aussi peu utilisés que var, address, samp, dfn ou tt n'ont de raison d'être que celle qui sied au poids du passé et qu'on gagnerait en simplicité en les éliminant. Comme si une spécification pouvait se permettre de changer aussi souvent que les versions d'un produit, et comme si c'était la fréquence d'emploi d'un élément qui était garant de sa valeur pérenne.

Tellement facile enfin, que la plupart des agents-utilisateurs sont expressément conçus pour tolérer les erreurs HTML les plus fréquentes. Une solution de facilité que certains voient d'un bon oeil par souci d'ouverture et d'universalité, mais qui fait craindre à d'autres que le Web ne s'écroule sur lui-même d'ici quelques années, faute de rigueur et de consistance.

La maîtrise du HTML est si triviale en fait, qu'on n'en finit plus de compter les tutoriels, foires aux questions, forums et autres ressources mises de l'avant pour venir en aide aux débutants et pour en expliquer les subtilités aux codeurs plus expérimentés qui se croyaient parvenus. Inventaire au sein duquel se trouve toute une constellation de blogues où on s'emploie tantôt à dénoncer les mauvais usages du HTML, tantôt à en promouvoir les bonnes pratiques. C'est dire l'état du Web... et le capharnaüm auquel l'illusion de la facilité peut conduire. Si le HTML était facile, on n'aurait besoin d'y revenir ou d'en corriger si souvent l'usage.

Le HTML est à ce point sympathique et facile à maîtriser, que certaines firmes se sont empressées de créer des outils pour en contourner les difficultés et permettre à quiconque de publier rapidement sans avoir à se soucier de la moindre ligne de code, donc sans avoir à l'apprendre. Pareille entreprise n'a de sens, on s'en doute, que parce que le HTML n'est ni simple ni intuitif. Si le HTML est si trivial qu'on le dit, comment expliquer alors que plus de 94 % des sites Web analysés dans le cadre d'une étude sur leur accessibilité ne passent même pas le test du validateur ? En fait de facilité, on peut rêver mieux.

En réalité, le HTML rebute et fait peur. De plus, il faut comprendre l'anglais pour s'y sentir à l'aise. Et ce, que l'on soit japonais, arabe ou inuit. Allez, soyez honnêtes, qui d'entre vous songerait un seul instant à rédiger une lettre ou une carte postale en commençant par dire, en anglais, que le texte sera écrit en français, suivant un alignement de gauche à droite, et que le jeu de caractères utilisé sera l'alphabet latin étendu tel que défini dans la norme ISO 8859-1 ?

Facile, le HTML ? Le petit nombre d'éléments dont il se compose et la simplicité des règles qui en régissent la syntaxe pourraient le laisser croire, mais il n'en est rien. Car l'un et l'autre varient en fonction de la version qu'on utilise.

Tenez. Êtes-vous en HTML 4.01 ? Vous pouvez marquer vos paragraphes avec une balise ouvrante <p> sans avoir à vous soucier de la refermer ensuite, car c'est facultatif. Aucun navigateur ne vous en tiendra rigueur. Aucun validateur non plus. Êtes-vous en XHTML 1.0 ou 1.1 ? Il vous faudra impérativement les refermer, car c'est devenu obligatoire. Bien plus, il vous faudra même penser à écrire différemment la finale des balises pour lesquelles il n'existe pas de balise fermante, tel img, br, hr, link ou meta. Il se peut que les navigateurs ne vous en tiennent pas rigueur si vous passez outre, et que votre page s'affiche tout de même comme prévu, mais le validateur, lui, ne manquera pas de vous signifier la présence d'erreurs dans votre code.

Il y a relativement peu d'éléments en HTML. Mais il faut connaître les possibilités et les limites de chacun pour se servir du lot d'une manière adéquate. Ce qui suppose que l'on connaisse tout l'attirail des attributs dont on peut les affecter, ainsi que le genre de valeur qu'on peut y mettre, mais aussi et surtout de savoir réfléchir. Car une chose est de composer un document, une autre de savoir en marquer la structure avec un jeu de balises approprié.

Un florilège, par exemple, est bien un recueil de citations, n'est-ce pas ? Or il n'y a pas d'élément HTML qui soit spécifiquement conçu pour baliser pareille chose. Normal, puisque le HTML n'entend pas tout prévoir. Il faut donc inventer quelque chose à partir de ce qui existe. En y réfléchissant on pourrait penser que la solution consiste à encadrer chaque citation d'abord avec <q> et ensuite avec <li>, de façon à ce que l'ensemble forme une liste... heu... à moins que ce ne soit mieux de les encadrer d'abord toutes avec <p> et d'encadrer le tout avec <blockquote> ? ...ou chacune avec <p> et <blockquote>, puis l'ensemble avec <div> ? Trivial, n'est-ce pas ?

Le dernier cas est un peu exceptionnel, j'en conviens. N'empêche que rien que pour écrire un document HTML d'une phrase avec une image, un lien hypertexte et un lien courriel, il faut recourir à URI, HTTP et au système d'adressage propre au courriel ; soit trois protocoles différents. Et à cela, il n'y a rien d'exceptionnel. Derrière son apparente simplicité donc, le HTML suppose un ensemble de connaissances et de savoir-faire dont la complexité finit pas passer inaperçue aux habitués, mais qui ne manque pas d'être source de difficultés pour les nouveaux-venus.

Conclusion

En un sens, le HTML n'est pas difficile. Car à bien y penser, la puissance de pénétration intellectuelle requise pour en comprendre les éléments n'a rien d'exceptionnel. Et de ce point de vue, le HTML reste - fort heureusement - relativement facile.

Mais en un autre sens, le HTML se montre difficile. Car dans la pratique, il faut connaître beaucoup de choses pour se tirer d'embarras, éviter les erreurs et se servir de tout cet arsenal d'outils d'une manière adéquate. D'où la relative complexité du HTML.

Difficile, donc, le HTML. Pas au sens d'« inaccessible », mais au sens de « complexe ». Voilà ce que j'ai voulu montrer. Et j'ai voulu le faire essentiellement pour deux raisons.

D'abord pour mettre en évidence la prodigieuse souplesse de ce merveilleux langage. Car on ne s'étonne pas assez, me semble-t-il, de ce que le HTML permet d'intégrer en un seul et même document des choses aussi disparates que du texte, du son, des métadonnées, des animations, des images, des liens, des scripts et des formulaires.

Mais aussi pour bien faire sentir qu'on ne peut pas maîtriser cette merveilleuse boîte à outils sans un minimum de compréhension de ce que l'on fait. Or cette compréhension, il faut l'acquérir. Et cela prend du temps. Aussi est-ce pourquoi je me méfie de tout ce qui a tendance à laisser croire qu'on peut apprendre le HTML en une heure, une journée, voire une semaine. Car à tout prendre, l'art du HTML ne réside pas dans ses outils, mais dans l'usage qu'on en fait. Et c'est l'art qui est difficile.

Normand Lamoureux | 2004.07.09 @ 22:11 | 53 commentaires | 2 trackbacksretour au début de la page

Avatar Denis

jeudi 01 juillet 2004
par Denis Boudreau

Opquast, un réferentiel de qualité Web

Voilà plusieurs jours que j'essaie de me botter le derrière pour refaire surface sur C², mais une surchage de boulot et l'intérêt phénoménal du billet de Bleizig auprès de vous tous m'ont convaincu de demeurer muet pour un temps et de laisser plus de visibilité encore au texte sur gMail. Enfin, jusqu'à présent. Dîtes, entre vous et moi, pouvez-vous encore nommer une personne aujourd'hui dans votre entourage n'ayant pas entendu parler de ce webMail, soit en bien ou en mal ?

Ce qui a tout d'abord débuté comme un amusement enfantin face à la popularité du billet de Bleizig est rapidement devenu une pure fascination au fil des jours. Et pour cause... a t-on déjà vu une campagne de marketing viral aussi bien frapper la cible ? Ah si, une fois, si ma mémoire est bonne : c'était au lancement d'un certain moteur de recherche, il y a quelques années... Comme quoi tous les génies ne travaillent pas pour Apple.

Jamais dans l'histoire de C², un billet n'avait suscité autant de réactions que ceui de Bleizig. Je vous avouerai que nous n'en sommes pas peu fiers, ayant même poussé l'amusement à faire des paris sur le nombre de commentaires qui seraient générés par ce billet. Regarder le compteur s'incrémenter jour après jour au fil de vos interventions a été un réel plaisir... Ça prenait bien un évènement majeur, comme le lancement préliminaire d'Opquast pour me sortir de ma torpeur et rompre avec ce silence réjuvénateur qui commençait dangereusement à me plaire. D'ailleurs, autant vous l'avouer, remettre la machine en marche n'est pas facile du tout. C'est qu'il est rouillé papy Denis. En de telles circonstances, autant bien foncer droit au but. Après tout, écrire, c'est comme le vélo, ça ne se perd jamais complètement. Suffit simplement d'avoir le courage d'enfourcher la selle et de donner le premier coup de pédale. Je m'élance donc.

Mesurer la qualité des services en ligne

Opquast. Comment vous décrire en quelques mots le projet Web le plus ambitieux, le plus stimulant, le plus gratifiant et le plus passionnant auquel j'ai eu le privilège de participer de toute ma vie ? Et je n'exagère pas ; je ne suis pas en train de vous servir le discours encenseur de l'acteur hollywoodien qui doit essayer de faire passer son prochain navet pour un Lars Von Trier ; je le pense vraiment. Certes , à première vue, l'outil Opquast peut sembler banal ; un petit référentiel de 170 bonnes pratiques pour construire un site Web de la bonne manière, avec des recommandations regroupées en trois niveaux de qualité, redécoupées en types de sites, ça peut sembler une vulgaire marche à suivre. Pourtant, Opquast est tout sauf banal. Le prétendre, ce serait avouer ne rien y comprendre.

Mais plutôt que de vous parler du projet, je vous inviterai plutôt à le mettre à rude épreuve et à l'appliquer sur votre propre site. Comment votre site s'en sort-il lorsque vous le comparez à notre vision d'un site Web de qualité ? Fait-il bonne figure ou est-ce la catastrophe ? Essayer Opquast, dans un contexte réel de mise en application concrète, c'est découvrir tout le potentiel de l'outil.

Déjà, l'ami Tristan en a rapporté la nouvelle hier suite à la publication de notre communiqué officiel et quelques commentaires commencent déjà à fuser parts et d'autres. Certes, le site est en version beta, le design reste à venir (je vous en promet d'ailleurs tout un), le code nest pas encore à point, l'accessibilité demeure à améliorer, la sémantique aussi, mais tout cela n'a pas vraiment d'importance à ce point-ci. Nous sommes entre nous et nous faisons suffisamment confiance à votre maturité pout attardervotre attention sur les points importants du moment. Nous savons tous que le code sera irréprochable au lancement officiel de l'outil, prévu pour la fin septembre. Ce qui importe pour le moment, ce sont les idées. Les nôtres, mais aussi les vôtres. Vos opinions, vos impressions, votre appréciation, vos commentaires.

Ainsi, je vous invite tout bonnement à venir donner vos opinions sur les bonnes pratiques mises en place jusqu'à présent et bien sûr, à y proposer les vôtres si vous songez à certaines qui mériteraient de figurer au rang des bonnes pratiques Opquast. Sachez qu'il y en aura plusieurs autres bien sûr, puisque le référentiel, dans sa forme actuelle, n'est pas encore tout à fait au point. Ne serait-ce qu'au niveau des recommandations basées sur le respect des normes et des bonnes habitudes de développement HTML et CSS accessibles, il demeure encore beaucoup de prncipes qui méritent d'être soulignés.

Secrètement, j'aimerais bien un référentiel de 256 items  il y aurait là un petit concept sympathique, vous ne trouvez pas ? Bon aasez discuté, je retourne à mes codes surces. Cybercodeur non plus n'est pas parfait. Nous avons du boulot aussi ! D'ailleurs, pendant que nous sommes sur le code, je vous annonce que mon prochain billet parlera du passage vers XHTML 1.0 strict. Fini le XHTML 1.1 pour C². Tous les détails prochainement... juste au cas où ça vous intéresserait.

Denis Boudreau | 2004.07.01 @ 00:43 | 4 commentaires | 3 trackbacksretour au début de la page