HTML 5 : Pourquoi les balises video et audio ne seront pas aussi intéressantes qu’elles pourraient l’être ?

3 juillet 2009

Cette fois-ci je vais essayer d’être un peu moins négatif que la dernière fois, mais il faut quand regarder les choses en face : les balises audio et video ne vont pas simplifier le développement Web lorsqu’on travaille directement en HTML. La simplification, la centralisation et la réutilisation et l’utilisation d’une API sont hypothétiques et ne pourront se produire qui si plusieurs étoiles (dont celles de Microsoft et Apple) s’alignent dans le ciel. Peu probable…

Je m’explique :

En ce moment, en général, sauf peut-être pour les puristes, nous aurons une balise object, un balise embed et le plugiciel flash et un encodage audio – video supporté et payé par Adobe.

Avec video et audio, dans un monde idéal nous aurions un format audio et video ouvert et libre, le même pour tout le monde et une seule balise video / audio dont le visuel et les fonctionnalités sont contrôlés par le css / canvas et javascript. Beaucoup plus simple, mais problématique.

  1. Le support d’un format vidéo audio libre par tous est improbable : ce n’est ni dans l’intérêt de Apple (qui fait de l’argent avec aac et Quicktime), ni dans l’intérêt de Microsoft qui préfère wmv et Silverlight. Le seul format libre et sans brevet est ogg vorbis et theora. On parle de brevets inconnus pour expliquer qu’on ne le supporte pas mais faut pas être dupes, il peut y avoir des brevets sous marins sur à peu près n’importe quoi qu’on utilise en informatique, y compris l’air qu’on respire. Faites-moi pas brailler. Le pire, c’est qu’il semble (pour l’instant) que le Working Group HTML ne mettra pas ses culottes pour imposer un format libre.
  2. Le support même des balises videos et audios va à l’encontre des intérêts de Microsoft, c’est très peu probable que Internet Explorer la supporte un jour. Microsoft préfère Silverlight et je les comprends.

Pour empirer les choses, il y a aura des plates formes qui ne supporteront pas Flash et Silverlight et qui nécessiterons les balises video (je pense au iPhone en particulier, dont l’utilisation en peut plus être ignorée).

Pour être optimal et supporter tout le monde, cela nous prendra une balise video / audio avec Quicktime pour le iPhone, une autre balise video / audio avec ogg pour Linux et les plate formes libres, un object Flash pour Internet Explorer et un embed Flash pour les vieilles plate formes. Un paquet de Javascript pour que ce soit cohérent et je ne parle pas encore d’accessibilité ici qu’il faudra répéter pour chacune des plate formes s’il reste de l’argent. Avec l’historique d’écoute des spécialistes en accessibilité dans le Working Group HTML, je ne sais pas ce qu’il va se passer au niveau de l’accessibilité des balises video et audio… Le pire, ce ne sera pas possible de revenir à l’unique solution Flash puisque ça me surprendrait que Flash soit supporté sur toutes les plates-formes mobile. Avec Microsoft qui pousse très fort Silverlight, on risque d’avoir une plate forme de plus à supporter. Donc je récapitule : Deux video, deux object et deux embed. Oui, on peut générer le tout avec une librairie javascript, mais avouez que ça ne change pas grand chose pour les développeurs.

Dans les intranets se sera probablement plus simple : Silverlight seulement. En effet, Silverlight sera supporté par pas mal tout ce qui peut naviguer sur un intranet, sauf le iPhone, mais celui-ci ne sera probablement pas très conseillé en entreprise. Gageons que les plate formes mobiles d’entreprise (Blackberry et Windows Mobile) vont finir par supporter Silverlight.

Un dernier point : une autre raison que les balises video et audio ne seront pas populaires partout c’est qu’elle faciliterons les téléchargements des vidéos et des audios. Certains sites Web voulant protéger leurs propriétés intellectuelles voudront rendre cette activité plus difficile et je ne crois pas que videos et audio offres des capacités en ce sens. Probablement que c’est possible de coder le tout en javascript avec des clés uniques dans le temps et du streaming, mais je crois qu’il sera plus simple d’utiliser les solutions actuelles en Flash qui seront plus faciles à intégrer (juste d’avoir le vidéo dans le Flash rend invisible le url dans la source HTML, ce qui empêche au moins une partie des téléchargements).

Il faut aussi se poser la question : lorsqu’on ajoute une nouvelle fonctionnalité dans un langage, est-ce qu’on rend possible quelque chose qui n’était pas possible avant ou est-ce que la nouvelle manière est tellement plus simple que l’ancienne manière sera vite abandonnée ? Dans ce cadre, ce n’est pas pour tout de suite que le balise video et audio vont améliorer les choses!

En regardant tout cela, si on était cynique, on pourrait en arriver à la conclusion que la seule raison valable d’avoir les balises videos et audio est pour que Apple, dans sa magnanime et contrôlante personnalité, n’ait pas à supporter Flash dans le iPhone. Si on parle du dernier point que j’ai amené sur le téléchargement mondain, on pourrait parier que le développeurs aient à faire générer les balises videos et audios côté serveur seulement lorsque l’agent utilisateur est Safari de iPhone… facile à contourner, mais bon. Je fais du Web depuis 1996, j’en ai vu des pires…

N’hésitez-pas à complètement détruire les arguments ci-haut. En fait je ne demanderais que cela ;-) (J’aime bien me l’avocat du diable une fois de temps en temps, ce n’est pas mauvais pour la discussion, après tout!)

Petit changement d’orientation (pour l’instant) sur mon blogue

2 juillet 2009

Ceux qui ont lu les quelques derniers billets de mon blogue ont peut-être remarqué un changement de ton un peu. Disons que je me suis rendu compte que quand je faisais trop attention à ce que j’écrivais (trop de relecture, autocensure d’opinions) je finissais par ne plus rien publier. Il faut que j’apprenne à assumer mes opinions, même si parfois elles ne sont pas toujours 100% positives. Alors j’expérimente un peu, je veux voir jusqu’où peux aller dans cet optique. Malheureusement, cela veut peut-être dire un style d’écriture plus difficile à lire, avec plus de fautes de frappes. Au moins le output devrait être plus élévé et il y a plus de chances que la qualité s’améliore un peu avec le temps. Enfin je l’espère.

Le danger des écosystèmes profonds et souterrains ou Internet Explorer 6 / Windows XP / Word 43VER

2 juillet 2009

Personne à l’intérieur d’un bon esprit va vouloir réécrire son système ERP. Et pourtant, il y a de bonnes chances que les interfaces utilisateurs de type Web (mon côté puriste ne les appelleraient pas comme cela, mais bon) soient codées en dur pour Internet Explorer 6. Quand on a un grand succès et qu’on veut empêcher d’autres de coper notre succès par des moyens techniques, lorsqu’on voudra changer de technologie on va tomber sur plein de petits problèmes assez sournois merci au niveau de la rétrocompatibilité. Et on devient son propre pire compétiteur…

Et ce n’est pas que Internet Explorer 6. En fait pas tellement Internet Explorer 6, le vrai centre où tout est relié est Word et Excel (ou Office, mais surtout Word et Excel). Pour la plupart des gens qui travaillent avec un ordinateur, le logiciel le plus souvent utilisé n’est pas un navigateur Web, c’est Word et Excel. Et tout s’y intègre, tout est plogué sur Word et Excel, même la gestion de contenu Web. Le copy paste Word / Web qui amène avec lui la problématique ISO-8859-1 vs Windows 1252. Heureusement que WordPress transforme les guillemets en &8217;, parce que je suis coupable moi même d’utiliser Word pour écrire des articles. C’est beaucoup plus convivial qu’un textarea dans un gestionnaire de contenu, même pour WordPress.

Imaginez que vous voudriez supprimer Word au nom des standards ouverts, vous tomberiez sur plein de problèmes : tout est plogué sur Word. Ton lecteur d’écran ? Marche juste avec Word. Ton outil de gestion de finance, exporte en Excel. Les standards ouverts ne servent à rien s’ils ne sont pas implémentés. J’aurais tendance à dire que pour une moyenne à grosse entreprise, la plupart des systèmes informatiques sont plogués à Word et que si vous enlevez Word, ils ne fonctionneront plus. OpenOffice n’a certainement pas les mêmes API, et les reverse enginerer est sûrement épouvantable, au moins autant que le format .doc lui-même. (Quoique Alfresco essai de le faire pour Sharepoint).

De cette manière, je n’ai pas beaucoup de difficulté à dire que Office a un écosystème aussi gros que le Web, du moins en entreprise. Vous pourriez faire supporter par OpenOffice les standards d’accessibilité pour les connecter au système de texte à voix, ce dernier va probablement mieux marcher avec Word et Windows, qui ont leur propre standard. (Remarque, j’ai peut-être tort et je n’ai pas vérifié, je suis blogueur, pas journaliste, mais j’expose ceci pour faire suivre un raisonnement, pas représenter la réalité dans ses détails). À la maison, moins de choses nous obligent à utiliser Word. À part échanger des documents avec le bureau. C’est un format d’échange de documents passablement utilisés. Mais on peut utiliser autre chose, OpenOffice, ou des documents purement Web, dans certains cas éloignés des PDFs.

Office a été choisi par beaucoup de monde et je suis pas mal certains que nous sommes avec pendant assez longtemps encore. (Ça ne change pas qu’au niveau interface, il est certainement très correct et encore pas mal mieux que Google docs, qui lui a son propre écosystème).

Quand vous choisissez un produit, une solution, vous vous ploguez sur son écosystème. Il est fort possible que plein d’autres décisions soient influencées par cet écosystème. Si, par exemple, tous les éléments de cet écosystème rendent plus complexe et plus coûteuse vos opérations au jour le jour et que venu le jour où les limites de votre patience sont dépassés vous risquez de souffrir (votre portefeuille et votre mental probablement aussi). Placer une entreprise dans un écosystème, c’est comme de mettre une grenouille dans l’eau et de la chauffer tranquillement. Il vaut mieux s’assurer que la température cible ne soit pas fatale.

C’est la grosse question, l’éléphant dans la salle de réunion, pour les outils du cloud computing aussi. Les gens ont encore peur de cet écosystème par contre, et il n’est pas tout à fait évolué, trop Mammouth encore. Mais quand tout le monde va avoir donné ses données à un fournisseur (probablement qu’il y en aura un qui sortira du lot, comme Microsoft l’a fait auparavant), ce sera difficile de se sortir de son pouvoir.

En gros, si les morceaux de l’écosystème ne sont pas déploguables et ne respectent pas des standard ouvert, vous aurez des problèmes lors des mises à niveau et des remplacements. Les coûts risquent d’être élevés. Mais vous avez le choix, je ne les comprends pas encore, mais il doit y avoir des avantages à choisir des standards opaques. En fait oui, il y a des avantages : un certain nombre de choses fonctionnent out of the box. Vous ne partez pas de rien.

Mais toute cette intégration va à l’encontre de la compartimentation des outils logiciels, fondement des architecture orientés services. Quand on réussit à avoir une vraie architecture orientée services (ou plutôt dans le cas des contenus standardisé (ouvertement) une architecture orientée ressources, c’est plus facile de choisir une composant qui respecte le standard et choisir celui qui est le meilleur et non celui-qui vient avec la solution ou un de ceux qui fonctionne avec l’écosystème et qui est fortement intégré lui aussi. Les interfaces utilisateurs des outils se ventant d’être des architectures orientés services ont tendances à ne pas respecter la philosophie de base, mais bon je sors du sujet (il y en avait un ?)

On ne choisi pas le meilleur produit, on choisi le meilleur qui s’intègre avec notre architecture. Par contre, si on suivait des standards ouverts simples (je dis simples, parce qu’il y a des standards ouverts foutaisement compliqués), on aurait plus de choix. (Des fois trop c’est comme pas assez, mais bon…)

Personnellement, je pense que le HTML (même le 5) est trop mal foutu pour créer une base à un nouvel écosystème. Par contre je pense que les navigateurs sont la base de l’écosystème du cloud computing (côté client en tout cas, regardez, je parlais de Word, un logiciel client, c’est pourtant probablement l’outil qui a le plus d’impact sur les architectures d’entreprise et ça me surprendrait qu’ils soient présent dans les graphiques d’architecture, remarquez, moi non plus je ne le mets pas, il est comme on peut dire implicite). Non, je retire ce que j’ai dit, HTML est assez mal foutu pour faire parti d’un écosystème complexe, .doc a bien réussi, c’est clair que HTML peut le faire aussi. Il faut juste bien définir tous ses quirks et tous ses bogues et ses mauvaises manières de faire et on pourra bâtir n’importe quoi dessus, y compris des patentes mal faites et épouvantables, mais qui vont fonctionner suffisamment bien pour nous faire sauver plus de temps qu’il nous en fait perdre. Mouaip, c’est bien ce que HTML 5 est en train de faire hein? Là voilà la recette secrète de Google, définir les bogues pour pouvoir bien construire par dessus!

C’est drôle, parce qu’il faut regarder la fondamentale inertie des systèmes informatiques pour bien comprendre toute l’affaire.

J’ai un pool énorme de documents mal foutu (en .doc ou .html) et je veux les garder utilisables dans le futur (pérennité), et je veux même en créer d’autres de la même manière parce que j’y suis habitué. Je veux aussi créer un paquet de trucs qui les utilise parce que les contenus de tous ces documents sont la source de l’intelligence que je veux utiliser.

En fait, ce qui fait qu’il est difficile de ne plus utiliser l’écosystème Word, ce n’est pas ou peu le format .doc, mais bien les couches applicatives par dessus. De la même manière, on pourrait utiliser un format libre et ouvert (mettons comme le HTML) le rendre suffisamment moche pour avoir besoin de créer des couches par dessus pour faire du vrai travail et ensuite c’est cette couche sur lequel un écosystème se créer et qui ensuite peut forcer à utiliser certains produits faisant parti de cet écosystème. Il faudrait que cette couche par dessus soit aussi ouverte et standardisée que celle en dessous et n’appartienne à aucun revendeur. En fait, lorsqu’on travaille avec des outils de portail, c’est un peu aussi ce qui se passe. Pour être capable de faire fonctionner la personnalisation (comme exemple les boîtes minimisables dans un portail) on ajoute un paquet de javascript dont l’utilisation se fait par génération (outils de portlets de base, JSF sur les portails Java, ou encore du .net comme les Web parts de Sharepoint).

Ces morceaux s’intégrent mal au concept de flux de documents et sont difficilement personnalisables (je parle en termes de programmation CSS) et il faut utiliser les outils des revendeurs au lieu des standards HTML et CSS que l’on serait supposé utiliser normalement. Et je ne parle pas des problèmes que cela cause aux outils d’accessibilité, parce que ceux-ci sont plogués sur le standard de la technologie de base et non pas celle de la couche au dessus. Quoique cela pourrait changer. En fait j’imagine un jour ou l’on pourrait ploguer une technologie d’assistance à l’une de ces couches applicatives au lieu de HTML et rendre cette couche plus accessible que le HTML lui même. Ce serait vraiment Mal de faire cela et j’espère n’avoir donné l’idée à personne. Par contre, j’ai l’impression que ce serait pour le moins très compliqué…

Les outils de portails n’ont pas tellement bien fonctionné en industrie sauf dans les cas où l’on met l’effort nécessaire (c’est pourquoi ceux qui comprennent que mettre beaucoup d’énergie et de gouvernance dans un projet portail d’entreprise (et de comprendre leurs limitations et leurs forcent) finissent par réussir à avoir qqch de fonctionnel et qui réponds aux besoins, je le sais j’ai réussi deux fois dans ma carrière à contribuer à faire marcher Websphere Portal, et là je vais peut-être m’attaquer à Sharepoint – watch this space).

Pour dire que si l’on veut gagner les coeurs de tout le monde, pas juste les architectes d’entreprise, il va falloir trouver une couche applicative par dessus le HTML qui est intéressante pour les développeurs autant pour les technos propriétaires que libres. Attention, la techno elle-même pourrait être libre et ça ne changerait rien, si elle se plogue super facilement aux services de qqun (du cloud computing tiens!) et qu’elle facilite l’appropriation des données (et c’est là le champs de bataille) on va tous être pris à utiliser cet écosystème dans le futur. Dans un autre ordre d’idée, même si tout le monde pourrait revendre par exemple JBoss, personne le fait parce que l’expertise du produit appartient à une seule compagnie. Si la création elle même de la couche applicative est suffisamment complexe, pas personne d’autres que son créateur va pouvoir se l’approprier. Pour qu’elle soit complexe, cela va prendre une couche de base moche et mal foutue, c’est-à-dire HTML + CSS + Javascript + DOM.

Cette pattente là super compliqué, mais facile à utiliser sera accessible par trois morceaux de technologies : les navigateurs (équivalent de Word), les moteurs de recherches (le système d’exploitation) et les outil de cloud computing (l’équivalent de toutes les applications qui font parti de l’écosystème). (Bon ok, ma comparaison est bouetteuse, mais bon… je voulais montrer un point). Cette couche applicative devra être aussi facile d’utilisation que Visual Basic si on veut qu’elle réussisse (je pense que Visual Basic est l’une des raisons pourquoi l’écosystème Word est si grand en ce moment, mettons que c’est .NET maintenant, une très bonne évolution).

La même raison pourquoi le format .doc est si mal foutu, accable le HTML, le don’t break the Web, ou en français la rétrocompatibilité. Aussi le pave the cowpath, ou encore en français, le continuer à faire les mêmes erreurs parce que c’est plus facile. (Bon, je l’ai dit ce que je pensais des orientations du WG de HTML et pourquoi je ne me sens pas capable d’y participer intelligemment et positivement).

XHTML a essayé de briser ce cercle vicieux et à échoué lamentablement, je dirais qu’à cause de manque de support de application/xml+xhtml des outils de l’écosystème Word (les gestionnaires de contenus où le copy paste Word est mandaté, à commencer par Frontpage). Ben oui, encore Word, on est chanceux que l’encodage de base du Web ne soit pas Windows-1252.

Il faudrait donc, que quelqu’un crée cette couche avant qu’un revendeur le fasse, la rende facilement utilisable avec un support génial chez tous les éléments de l’écosystème et out-Microsfter Microsoft et Google. Je pensais que HTML5 serait cette technologie et qu’on aurait pas besoin de créer une couche applicative je suis de moins en moins certain que c’est possible. Je pense que HTML 5 + CSS 4 + Javascript x devraient avoir des composants natifs qui font la même chose qu’un GWT, un JSF ou un ASP.NET et standards + un mapping avec un langage côté serveur qui remplacerait la partie vue des JSP, ASP et PHP de ce monde. (Imaginez, le langage de vue, (dans le sens modèle vue contrôleur) serait le même que vous travailliez en Java, en PHP, en C# ou en Ruby… ça ça serait cool! Pour voir à quoi je pense que ce langage devrait ressembler, regarder la technologie Facelets (ça se plogue avec JSF). Mais pour faire cela, ça prendrait de la vision et beaucoup beaucoup beaucoup d’énergie et d’argent, du genre à ce qui a servi à créer Java dans les années 90s.

Tout ça aussi pour dire que pour sortir IE 6 des entreprises (et par conséquent Windows XP) va falloir beaucoup d’effort encore et que cela va prendre du temps! et que pour faire mieux que HTML 5 faudrait encore plus d’efforts et de temps (et probablement une vision moins fermée du Web que celle des revendeurs de navigateur Web) ! Finalement Karl a raison, nous sommes tous dans nos grottes.

Quelques commandes MySQL : Parce que je m’en rappelle jamais

30 juin 2009

Bienvenue sur une nouvelle série sur mon blogue qui sera peut-être ou pas éphémère : Les parce que je m’en rappelle jamais. Cette série se veut un hommage au manque de mémoire et au déficit d’attention. Vous n’y trouverez pas des bonnes pratiques, mais simplement des exemples de commandes que j’ai eu besoin de faire un moment donné. Sans plus tarder, une première mouture : Quelques commandes MySQL :

Partir l’interpréteur / moniteur MySQL :
mysql --user=le_nom_de_l_utilisateur le_nom_de_la_bd
Créer un utilisateur dans MySQL :
CREATE USER le_nom_user IDENTIFIED BY 'motdepasse'
Faire que MySQL écoute sur le port 3306 sous Unix
dans my.cnf (peut être dans /etc/my.cnf)

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
port=3306
bind-address=l'adresseipduserveurmysql
Restarter le serveur MySQL sous CentOS :
/etc/init.d/mysqld restart
Droits des utilisateurs pour se connecter à distance à partir de partout (ne pas faire cela sur un serveur de prod) :
GRANT ALL ON *.* to 'root'@'%';

Petite note pour moi : Faut que je refasse les css de code, dl et pre. Merci.

Billet fantôme 1 : Le front-end architecte

24 juin 2009

Je vous ai écrit dernièrement que je pensais publier des articles billets incomplets sur mon site, question de les faire vivre un peu, même si j’ai manqué d’énergie / d’intérêt pour les terminer. Qui sait, peut-être qu’avec votre aide, je pourrais les compléter. Je vous les laisse sous licence libre (documentation GPL).

Le premier est un article que je prévoyais essayer de faire publier par un vrai newsletter. Après quelques réécritures et discussions avec des gens de mon entourage, j’en suis venu à la conclusion que je n’arrivais pas à expliquer le sujet comme il faut, ce qui faisait que l’objectif même de l’article semblait un peu utopique. Puis j’ai cessé de vouloir devenir un architecte front-end pour être un architecte technique conventionnel (j’ai eu le temps de parfaire mes connaissances en back end depuis ;-) )

La dernière version de cet article a été écrite un peu avant la présentation du Combo sur la qualité à Intracom Québec 2008. Pour ceux qui y était, vous allez y voir des liens.

Sans plus tarder :

L’architecte de présentation : un rôle clé dans les projets Web ?

Pourquoi les projets Web de grande envergure sont si difficiles à gérer technologiquement ?
Les dépassements de budget et des fonctionnalités limitées par rapport aux attentes sont malheureusement choses courantes dans ce type de projet. Pourtant, les technologies de base formant un site Internet sont relativement simples, mais le sont-elles vraiment ?

Dans cet article, nous allons faire un tour d’ensemble de toutes les préoccupations et défis techniques reliés à la présentation d’une application Web et cerner le niveau de complexité de ceux-ci. Nous allons ensuite valider si l’ajout d’un nouveau type de ressource, l’architecte de présentation, peut aider à gérer cette complexité.

Avec l’avènement du Web 2.0 et des interfaces utilisateurs riches de la compétition entre sites Web pour une bonne place dans les moteurs de recherche, le rôle d’un site Web n’est plus seulement de présenter des documents statiques aux utilisateurs. Et même lorsque c’est le cas, ceux-ci doivent présenter plusieurs qualités pour qu’ils aient la chance de rejoindre les internautes de façon efficace.

Chaque solution technique répondant à une préoccupation reliée à une métrique de succès a de fortes chances d’avoir un impact sur un autre aspect technique. Et malheureusement, cet impact est souvent négatif. Par exemple, le choix d’une plate forme technique d’intégration qui améliore la productivité des développeurs peut rendre pratiquement impossible l’accessibilité et un bon placement dans les moteurs de recherche. Une technique qui augmente le placement dans un moteur de recherche à court terme, peut briser la structure des documents, être potentiellement incompatible avec le gestionnaire de contenu et diminuer la maintenabilité de ceux-ci. Par contre dans certains cas, ces solutions sont viables. Il est nécessaire de bien connaître les impacts des choix technologiques et s’assurer que ceux-ci maximisent le potentiel du succès du projet. Pour ce faire, il est nécessaire d’aller plus loin que la technique. Des connaissances en ergonomie, en design et en communications sont utiles. Il faut faire le lien entre ces disciplines et celles d’architecture conventionnelles. Il est nécessaire dans une application Web d’envergure d’avoir le juste millieu entre toutes les demandes techniques de façon à ce que les choix respectent le budget, la qualité, le temps de développement, la maintenabilité et les orientations courts et longs termes du projet et du client.

Voici quelques préoccupations qui touchent à la couche présentation ou frontale d’une application et qui doivent dans la plupart des cas couvertes lors de l’analyse et du développement d’une application ou d’un site Web.

La maintenabilité : Nous parlons ici de s’assurer que les choix technologiques et la méthodologie de développement facilitent l’évolution du projet Web et minimisent les coûts d’opérations de celui-ci. Certains compromis sont parfois faits entre la rapidité initiale du développement et la facilité de mises à jour par la suite.

L’architecture d’information : La cueillette et l’organisation des informations et ressources disponibles sur un site application ou portail doit faciliter la recherche et favoriser l’accès rapide. Cette activité requiert des connaissances différentes de l’informatique, du design et de l’ergonomie, même si elles sont complémentaires et très interreliées.

L’utilisabilité : L’ergonomie des interfaces utilisateur est

[Incomplet]

Ajouter une citation d’un spécialiste en utilisabilité.

Lorsque le Web devient la plate forme principale de communication avec vos clients et employés, l’accessibilité et l’utilisabilité deviennent incontournables.

L’accessibilité : L’accessibilité est l’une et une des plus grandes forces du Web.
L’accessibilité veut entre autres dire que les fonctionnalités du site Web doivent rester utilisables même si l’utilisateur final possède un handicap quelquonque. On parle souvent des aveugles, mais on oublie de penser au daltonisme, aux problèmes d’ouie, de mobilité (utilisation de la souris) et aux problèmes légers au niveau cognitif. L’accessibilité, c’est bien plus que de faire fonctionner un site Web avec un lecteur texte (quoi que c’est un bon départ).

On peut parler ici de dégradation élégante : les fonctionnalités restent les mêmes, mais elles requièrent parfois plus d’étapes, sont simplifiées et leurs visuels moins complexes.

Note : Ajouter une citation d’un spécialiste en accessibilité

L’optimisation pour les moteurs de recherche (SEO) : La plupart des internautes utilisent les moteurs de recherche pour retrouver les contenus et les sites de commerce électronique sur le Web. Pour tout type de site ou application Web, l’optimisation pour les moteurs de recherche est devenue primordiale. Ceci est tout aussi vrai pour les applications internes en entreprise qui sont parfois difficiles à retrouver et à utiliser à l’intérieur de portails. L’évolution des techniques est très rapide, entre autres puisque les charlatants et les pourriposteurs essaieront toujours de manipuler les moteurs de recherche.

Le respect des conventions et normes du Web : Celles-ci peuvent s’appliquer en utilisabilité comme au niveau du protocole réseau. Par exemple le soulignement qui signifie un lien ou les conventions REST au niveau des services Web et savoir quelle norme de HTML ou XHTML choisir.

Gestion de conversations entre l’utilisateur et l’application : Les exemples les plus simples sont les formulaires s’échelonnant sur plusieurs pages. Toutes les applications Web comportant le concept de connexion ou de session doivent gérer des conversations. Les plus complexes amènent les applications Web à ressembler à des applications bureautiques et client serveur conventionnelles.

La sécurité : Quand on parle sécurité, nous pensons généralement à la protection de nos bases de données et à l’intégrité de nos serveurs. Or, la plupart des failles de sécurité se retrouvent sur les interfaces utilisateurs et les attaques se font vers les utilisateurs du système plutôt que vers les serveurs. On parle ici de failles comme le Cross Site Scripting et le Cross Site Request Forgery. Même plusieurs attaques conventionnelles, comme celle de l’injection SQL, passe par la couche présentation avant de se rendre aux bases de données. Certaines technologies, comme Ajax offrent aux bidouilleurs de nouveaux vecteurs d’attaques. La gestion des mots de passe, questions secrètes, authentification et autorisation, se passent aussi dans les interfaces utilisateurs. L’impact peut être important sur l’utilisabilité d’un système.

La gestion de contenu : L’objectif des outils de gestion de contenu est de rendre la maintenance et l’évolution d’un site Web ou d’une application Web possible par des personnes qui ne connaissent ni les conventions du Web, ni la programmation Web. Le défi ici est à deux niveau, il est nécessaire de s’assurer que les créateurs de contenu et les approbateurs puissent bien utiliser le gestionnaire et s’assurer qu’aucune entrée de contenu puisse briser le site ou l’application Web. Or les utilisateurs sont habitués à pouvoir contrôler directement l’apparence de leurs documents, en particulier avec des outils comme Microsoft Word, ce qui en soi peut causer beaucoup de problèmes d’intégration. Les données entrées dans un gestionnaire de contenu, qui gèrent l’ensemble des menus, liens entre contenus, pages, images, contenus dynamique et autres éléments riches peuvent devenir si complexes, que même les meilleures bases de données peuvent y perdre leur latin.

L’intégration de progiciels : On parle ici d’outils comme des applications de commerce électronique, des rapports d’utilisations, etc. Ces progiciels sont très utiles, car ils peuvent diminuer le temps de développement et augmenter la productivité des développeurs d’applications complexes et transactionnelles. Le défi des développeurs est d’intégrer ces produits tout en respectant les préoccupations de la couche présentation de l’application Web. Ces produits dans leur configuration de base ignorent souvent l’optimisation pour les moteurs de recherche, l’accessibilité et le respect des standards ouverts Web. Il est important de bien connaître les impacts en termes de développement du produit final.

Plates formes, modèles de développement et patrons de travail : Dans le cadre d’architecture orientés services par exemple, si le HTML servant à construire les pages de l’application proviennent de plusieurs sources. Le contenu statique peut venir d’une source et le contenu applicatif d’une autre. il est nécessaire de s’assurer de la compatibilité du HTML de chacune de ces sources ou prévoir une transformation préalable.

L’envoi de courriels :La compatibilité avec les divers moteurs de courriels en lignes (HotMail, Yahoo, GMail,etc) est en soit un sujet complexe que même les standards du Web ne peuvent complètement assurer. La problématique que les courriels ne doivent pas être considérés comme étant du pourriel. (SPF, configuration serveur de courriels). Encore une fois, le design du courriel, les textes utilisés ainsi que les configuration serveurs et réseaux ont tous un impact sur la bonne réception des courriels.

Interface de programmation Web 2.0 et Services Web : En effet, l’intercommunication entre sites et applications Web nécessite d’envoyer des messages en format javascript ou en services Web conventionnels (SOAP). Une connaissance ici des protocoles de communication utilisés en Ajax (JSON) et javascript sont nécessaires.

Le Web mobile : On parle ici de versions épurées des interfaces Web utilisés sur les téléphones cellulaires, les organisateurs personnels et les nouveaux gadgets mobiles comme le iPhone et les nouveaux iPod. Dans le type de projets visant ces utilisateurs les questions comme la dégradation élégante ou s’il est nécessaire d’avoir plusieurs versions du site Web vont se poser. Cela a un impact du design au choix des patrons de travail en passant par le gestionnaire de contenu. Certaines technologies, comme Flash et Java, ne sont pas toujours disponibles et lorsqu’elles le sont, ce ne sont pas les mêmes versions que sur le Web conventionnel. Les questions de compatibilité et d’interopérabilté se posent ici.

Les applications riches Internet (RIA) : Plus encore que les applications Web 2.0 les RIA font converger les applications bureautiques standards comme Word ou Outlook et les applications Web. Les prochaines versions des navigateurs offriront certaines fonctions rendant les RIAs de plus en plus puissantes. Pensons aussi aux produits comme Adobe Air et Silverlight de Microsoft qui entrent dans la mêlée.

L’assurance qualité : Un effort particulier doit être fait au niveau de l’assurance qualité. La dichotomie application Web et document Web fait parfois que la perception de simplicité des documents Web diminue le temps de tests alloué aux sections moins dynamiques d’un site. Plusieurs outils existent pour aider à tester les applications, ceux-ci doivent être bien intégrés au projet et ne remplacent pas les tests exécutés par des humains, particulièrement au niveau de l’utilisabilité.

L’analyse d’utilisation : Après l’implantation d’un site, il est judicieux de vérifier si les Internautes utilisent bien le site et quelles sont les pages les plus populaires du site. L’analyse de ces données servira à prioriser les prochaines étapes d’amélioration du site et de marketing. Plusieurs outils existent pour faciliter cette tâche. L’analyse des données peut toutefois vite devenir complexe pour les plus grands sites et une attention particulière doit y être faite. Si les opérateurs d’un site Web ne savent pas si celui-ci sert vraiment et s’il est apprécié, il sera difficile de justifier les efforts pour l’améliorer et l’utiliser à sa juste valeur.

Nous avons qu’effleuré plusieurs aspects du développement de site et applications Web et il en existe plusieurs autres. Chacun de ceux-ci individuellement pris peuvent parfois être simples, mais vus ensemble, ils peuvent devenir une source de complexité difficile à gérer.
Il est nécessaire de valider les recommandations dans l’une ou l’autre de ces préoccupations lorsque celles-ci proviennent de spécialistes qui ne connaissent pas les impacts de celles-ci.

Plusieurs de ces éléments sont parfois gérés par un architecte technique, organique ou de données d’un système. Ces architectes ont toutefois d’autres préoccupations aussi importantes (performance, intégrité des données, productivité des développeurs) qui vont parfois prendre le dessus sur la plupart des préoccupations reliés à la présentation. Les connaissances des architectes conventionnels ne couvrent souvent pas ces techniques et leur complexité risque d’être parfois ignorée. Lorsqu’ils le sont, la valeur d’un site ou d’une application Web peut être fort diminuée et même suffire à transformer un projet qui semble en bonne route en un échec.

Un nouveau type d’architecte

Nous avons déjà des architectes de données, (DBA) des architectes d’infrastructure, des architectes organiques et des architectes d’information. Plusieurs experts pensent qu’il est maintenant temps de spécialiser un autre type d’architecture : l’architecture de présentation, architecte frontal ou front-end architect en anglais.

L’architecte de présentation est responsable d’assurer un suivi sur tous les aspects dont nous avons présenté ci haut. Il est un lien très important entre l’humain, le besoin d’affaire et la technologie Web. Il peut, selon le besoin d’affaire, mettre plus d’emphase sur un élément d’architecture de présentation. Au même titre que les autres architectes, il conseille le chef de projet sur les décisions à prendre. Dans certains cas, il peut même représenter le client au niveau technique puisque celui-ci doit avoir une bonne connaissance des interfaces utilisateur et de l’ergonomie. L’architecte de présentation défini la stratégie de gestion de contenu, les stratégie de tests unitaires et fonctionnels de la couche de présentation. Il définira les normes de réalisation selon les besoins réels du projet. L’architecte de présentation est responsable de la gestion des connaissances sur tous les éléments qui impactent la couche de présentation Web et s’assure qu’aucun choix technologique n’ait d’impacts négatifs sur les réalisations.

L’architecte de présentation est en général un développeur Web senior, il peut provenir autant des équipe de programmeurs Web ou des graphistes Web.

L’avènement des architectures orientés services et d’application par couche séparent les préoccupations dorsales, frontales et données, la spécialisation au niveau de l’architecture devient possible et dans plusieurs cas souhaitable. Étant donnée l’importance accrue des applications Web, il est nécessaire d’avoir de plus en plus une stratégie à moyen ou même long terme sur les choix technologiques et la qualité et dans ce sens, l’architecte de présentation est une ressource clé pour définir cette stratégie.


L’article a encore besoin d’être retravaillé, il faudrait peut-être le couper en plusieurs partie. Le public cible de l’article n’est pas toujours clair non plus. Il est toujours mieux ici que dans le fond de mon disque dur…

Les billets fantômes et l’optique Twitter

12 juin 2009

Si vous vous demandiez ce que je faisais durant tout le temps où il n’y avait pas de billets sur mon blogue, (et même si vous vous le ne demandiez pas), sachez que je n’ai pas vraiment arrêté d’écrire. Je n’ai juste pas publié ce qui j’écrivais. C’est vrai par contre que j’écrivais moins, j’avais moins de choses à dire depuis que mon mandat au W3Québec s’est terminé. J’ai aussi commencé à utiliser un peu plus Twitter à ce moment-là. Mais si on regarde comme il faut mon output comme blogueur en 2008, ce n’est pas grand-chose non plus : plusieurs annonces d’événements, quelques petits billets d’opinions et d’anecdotes. Vous savez, les anecdotes, les annonces d’événements, Twitter /identi.ca Facebook sont des bien meilleurs médias pour cela. Il reste les articles d’opinions et les articles techniques plus poussés, les idées originales et un peu de mon quirk mode / bizzareries que je vais écrire une fois de temps en temps. Mais tout cela, ça prend plus de temps, et je suis malheureusement lent pour écrire, et il m’arrive de trop tergiverser jusqu’à ce que le billet devienne désuet avant que je finisse de l’écrire ou que je ne trouve plus qu’il soit assez intéressant.

En fait, je crois que j’ai besoin de motivation aussi, et c’est l’un des buts de ce billet. Je vais vous donner une liste d’articles que j’ai commencé à écrire et que je n’ai pas fini. J’aimerais que vous votiez pour que j’en finisse un.

Bien sûr, si personne ne me répond (je comprends, soit je suis peu lu et ce n’est pas si grave que cela ou comme moi-même vous êtes plus consommateur que producteur, je ne vous en voudrai pas, ce ne serait pas très éthique, surtout si vous n’existez pas, j’aurais peut-être l’air un peu fou) je vais continuer mon petit chemin comme je le fais en ce moment. Si par contre j’ai trois-quatre réponses (je ne m’attends pas à plus que cela) ça va peut-être me faire grouiller un peu et finir les billets que j’ai commencés. Je peux même les publier sans les finir si vous pensez que c’est une bonne idée!

  • L’architecte de présentation : je l’ai commencé, il y a un bon deux ans, mais il est peut-être encore d’actualité. C’est une dissertation sur le rôle des professionnels du front-end en Web. Front end architect en anglais. Faudrait que je le retrouve par contre.
  • Qu’est-ce qu’on reproche à Microsoft au sujet du respect des standards. Mon collègue et nouveau président du W3Québec (François Viens) avait posé cette question sur la liste du W3Québec, il y a quelques semaines. Personne ne lui a répondu, et moi j’ai voulu lui répondre sur mon blogue, mais j’ai fini par abandonner le billet (il était pas mal long).
  • L’impact de l’achat de Sun par IBM (le temps que j’ait fini d’écrire le billet c’était rendu Oracle)
  • Je n’ai pas eu le temps de commencer celui-là, mais je veux le faire depuis un bon 6 mois : Comprendre Oauth en utilisant Groovy et l’API de Praized.
  • Article de fond sur Facelets et Ajax4JSF
  • Quelques opinions sur HTML 5 vs Accessibilité et XHTML, extensibilité
  • La définition / évolution des applications Web : après avoir discuté sur la définition d’application Web avec Denis Boudreau et Karl Dubost sur Twitter, j’ai commencé à penser que la définition était peut-être limitée par rapport à ce qui est faisable de faire avec les technologies aujourd’hui. Je crois avoir quelques idées qqprt sur un billet qui porterait là-dessus.
  • Bon, j’en ai peut-être d’autres auxquels je ne me rappelle pas, je les rajouterai s’il cela me revient.

Et l’autre but de ce billet : je me rends compte que Twitter a un impact sur la manière de bloguer et même sur l’utilité de bloguer. J’en parle en tant que blogueur occasionnel qui n’a pas comme objectifs de vendre qqch par son blogue. (En fait oui, je me vends un peu par mon blogue, mais c’est plus une conséquence qu’un but, l’objectif pour moi est de m’impliquer dans mon travail et d’améliorer mes connaissances, ça veut dire bloguer parce que le meilleur moyen d’apprendre c’est de le faire… faut avoir du temps par exemple… pas toujours évident. L’autre objectif est d’avoir une présence sur le Web qui me représente, tant au niveau professionnel que personnel). L’élément marketing est faible. Dans cette optique, le blogue va avoir :

  • des petits billets d’anecdotes
  • des petits billets d’opinion sur des technologies
  • des petits billets d’opinion générale
  • des petits billets de références technologique (aye, j’ai trouvé qqch de cool pour le projet x)
  • des annonces d’événements en TI
  • quelques éléments purement personnels (je suis en vacances)
  • des articles de fonds en technologies Web
  • des articles d’opinion sur les technologies Web
  • des articles d’opinion meta

En fait, pas mal tout ce qui prends moins de 5 minutes écrire va s’en aller sur Twitter. Il reste les articles. Ce que je veux dire, c’est que l’avènement de Twitter / microblogging rends caduque plusieurs blogues de type journal. Tout ce qui peut entrer en 140 caractères et qui est éphémère n’a plus sa place dans un blogue. Et si je regarde ce que j’ai écrit depuis mettons 2 ans dans mon blogue, il ne reste plus grand-chose en terme de quantité. Intéressant, ça veut dire qu’il faut mettre un effort plus grand si on veut garder son site Web, sa présence Web (autre que celle des réseaux sociaux). Faut-il qu’un blogue soit plus professionnel pour qu’il résiste ? En tout cas, mon pagerank a pas mal baissé dernièrement. Et on redevient anonyme…. Je suis curieux de voir ce que je vais faire d’ici quelques mois par rapport à cela (et non, je n’ai pas de plan… pas encore en tout cas!)

J’ai d’ailleurs lu il n’y a pas si longtemps que la plupart des blogues étaient maintenant abandonnés. Pour l’instant, je n’ai pas le goût que cela arrive au mien.

Soirée conférence du W3Québec lundi prochain (15 juin) à ne pas manquer!

12 juin 2009

Cela faisait un petit bout de temps que je ne vous ai pas parler du W3Québec (après deux ans à la présidence, j’avais bien droit à un peu de repos :-) ! ). La prochaine soirée conférence sera particulièrement intéressante : Sylvain Carle et François Lafortune, tous deux de Praized Media, nous parlerons de leur expérience sur la publication de contenu structuré, leur vision et leur méthode de travail. Définitivement à ne pas manquer! À moins d’un imprévu (ces temps-ci ma petite famille est souvent enrhumée) je devrais y aller. Le tout se passe au Laika, lundi le 15 juin 2009 à 18h30.

Éliminer le BIP incessant d’un DELL Latitude D630

4 juin 2009

Au travail j’utilise en ce moment un Dell Latitude D630. Assez bonne machine qui fait la job (c’est pas un Macbook Pro, mais bon… c’est ben correct). Cette machine a moyen problème : son beep de système est très fort, et quand un logiciel (par exemple un logiciel de virtualisation ou de connexion à distance) n’a pas accès directement à la carte de son, à la moindre petite erreur, on entend un BIP particulièrement fort qui traverse facilement plusieurs cubicules et les timpans de ses occupants. Ça fait un bout de temps que je cherche à le tuer, mais aucun contrôle visible n’a d’effet (disabler la carte de son, mettre le son à off… marche pas). J’ai finalement trouvé la solution, décrite en anglais sur ce blogue, que je vais vous traduire de ce pas. Allez sur l’icône du Bureau poste de travail, puis bouton droit et propriétés. Choisissez l’onglet Matériel, puis le bouton Gestionnaires de périphériques. Ensuite (et c’est la le truc) utilisez le menu Affichage, puis Afficher les periphériques cachés. Vous allez voir apparaître dans l’explorateur la liste Pilotes non Plug-and-Play. Ouvrez cette partie et vous allez voir un périphérique aptement appelé BEEP. Double-cliquez dessus et suivez les instructions pour le désactiver. Redémarrez votre machine, et voilà : plus de stupide BEEP.

Code Camp Montréal Samedi prochain

26 mai 2009

Pour ceux qui travaillent avec les technologies Microsoft, ou tout simplement ceux qui s’intéressent de près ou de loin à ces technologies, le http://www.codecampmontreal.com/ Code Camp de Montréal est l’endroit à aller chaque année. C’est gratuit, et les présentateurs y sont vraiment excellents (aussi bons que dans des conférences payantes, et peut-être même plus!). Cette conférence vise spécifiquement les développeurs, ce qui la rend encore plus intéressante. Malheureusement, je ne pourrai y être cette année, (pour deux raisons, 1 c’est complet au moment d’écrire ces lignes et 2 le mois de mai est un moment difficile pour un banlieusard de se libérer la fin de semaine). Il y aura entre autre Laurent Duveau comme conférencier, qui est venu présenter Silverlight au W3Québec l’année passée. C’est donc un événement à ne pas manquer pour ceux qui ont eu le temps de s’inscrire! Parlant de Laurent, il donnera une formation sur Silverlight 3 en août à Québec et à Paris en juin et septembre. Je ne suis pas encore rendu à utiliser cette technologie (vous savez, je préfère de beaucoup les standards ouvert Web), mais je crois qu’elle a quand même de l’avenir dans les intranet et pour remplacer certains type d’applications Visual Basic. J’espère aussi qu’elle aura un meilleur potentiel d’être accessible que les applications client serveur traditionnelles. À quand une implémentation de Canvas performante en utilisant Silverlight de façon transparente ? Faudrait que je demande à Laurent ☺

J’espère que vous n’avez pas trop me chicaner de parler de technologies Microsoft, il y en a quand même quelques unes de très bonnes, et il s’améliorent, douloureusement oui, mais quand même avec quelques standards ouverts Web. Et je promet de parler plus souvent des événements sur les logiciels libres au Québec aussi. J’ai été un peu paresseux de ce côté dernièrement.

Mise à niveau du Mac Mini 2009, troisième partie

20 mai 2009

Je suis un peu en retard pour vous donner la dernière partie de la mise à niveau du Mac Mini 2009. C’est la partie pourtant centrale au projet, mais d’une certaine manière, celle qui a pris le moins de temps et presque la moins intéressante puisqu’il existe déjà plusieurs articles à ce sujet sur le Web. Je ne vais pas tenter ici de simplement les répéter, mais de vous donner quelques conseils basés sur mon expérience et sur l’ensemble des recherches que j’ai faites sur le Web avant d’effectuer l’opération.

La dernière fois que je vous ai écrit, j’ai essayé en vain d’ouvrir le Mac Mini avec une spatule plastique très mince. J’ai toutefois augmenté un peu le mince espace où l’on peut insérer un objet, plus gros et je l’espère assez solide, en enlevant un peu de plastique. Nous avons chez nous une grosse et vrai spatule en métal, mais au moment où j’essayais d’ouvrir le Mac, elle était dans le lave vaisselle. Il a donc fallu que j’attende le lendemain.

Assurez-vous que votre spatule est bien sèche et qu’il ne reste aucun morceau de bacon incrusté avant de commencer l’opération!

Come to spatula city and find the right spatula to open your Mac Mini !

Come to spatula city and find the right spatula to open your Mac Mini !

J’avoue que même avec une spatule solide, c’est relativement difficile d’ouvrir le boîtier du Mac Mini. Après avoir entendu les clics et clacs signifiant que le boîtier est en train de se déloger, j’ai réussi à sortir un premier côté. Ce fût assez difficile de déloger un deuxième côté parce que le premier côté se remettait en place à chaque tentative. L’espace est encore plus restreint sur les autres côtés, à cause de la pression exercée et aussi parce que ces côtés n’ont pas (ou peu) été travaillés lors de la première tentative avec la spatule plastique. La solution est de placer le boîtier sur le côté avant de travailler sur un côté perpendiculaire au premier avec la spatule. C’est une information qui n’est pas claire sur les vidéos d’OWC et qui m’aurait sauvé un peu de temps si je l’avais su en avance.

Après avoir enlever le boîtier, on peut voir les petits morceaux de plastique arrachés lors de l’opération, presque de la poudre. C’est un peu inquiétant au départ, mais sans danger d’après mon expérience. Après avoir soufflé sur le boîtier, on pourrait dire qu’il est neuf.

Ouf! Le Mac Mini est maintenant ouvert!

Ouf! Le Mac Mini est maintenant ouvert!

On peut maintenant admirer le génie de design interne de Apple. Entrer autant de petits connecteurs, d’antennes et d’autres matériels dans un si petit boîtier! En fait, le reste de la procédure n’est pas si difficile, mais il faut vraiment faire attention à tous ces petits fils, j’ai vraiment passé proche d’en briser un et j’ai pu voir sur les différents forum qui discutent du Mac Mini en anglais que plusieurs avaient cassé un ou plusieurs de ces connecteurs en faisant une erreur de manipulation.

Attention aux antennes

Attention aux antennes

L’étape suivante est d’enlever chacune des antennes comme expliqué dans les nombreux vidéos disponibles sur le Web. L’un de ceux-ci est accroché avec un papier collant qu’il faut retirer et le plus gros s’enlève en pinçant sa base. Il ne faut pas déconnecter complètement les antennes, simplement les retirer de leurs socles et les mettre hors du chemin.

Ensuite, il faut retirer le petit connecteur en avant qui relie la section des disques à l’autre section. Faites très attention à ce petit connecteur, c’est celui que j’ai presque écrasé vers la fin de l’opération. Encore une fois, les vidéos disponibles sur youtube et ailleurs sont indispensables. J’ai utilisé mes doigts pour le retirer, mais il est conseillé d’utiliser un outil spécialisé. Je n’en avais pas.

Pour la partie suivante, utilisez un petit (très petit) tournevis pour dévisser les quatre vis sur chacun des côtés du Mac Mini et garder les en lieu sûr. Notez que la vis en avant à droite est plus difficile d’accès que les autres. Personnellement, j’ai été chanceux et je n’ai eu aucun problème à la déloger. J’avais toutefois un très petit tournevis et cela m’a bien servi.

Vous pouvez maintenant déloger la section des disques. En ce faisant, vous pouvez voir que le disque dur à remplacer est dans la partie inférieure à cette section et que la mémoire à rajouter est sur la carte mère juste en dessous. La mémoire est facile à remplacer, mais il faut faire attention à un détail que dans mon impatience, j’ai oublié sur le coup. Il faut insérer la mémoire dans un angle de 30 degrés. Si vous avez de la difficulté à l’insérer, il y a de bonnes chances que vous ne l’insérer dans le bon angle. Pour la retirer, il suffit d’utiliser les petites clips sur le côté de la mémoire comme spécifié dans les vidéos.

C’est tout pour la mémoire. Le disque c’est plus difficile. La première chose à faire est de retirer le détecteur de température sur le devant du disque dur. Ce connecteur adhère au disque dur par de la colle. Il restera assez de colle pour qu’il adhère au nouveau disque dur. Faire extrêmement attention à ce détecteur. Il ne faut pas le déconnecter de son socle, mais seulement le déconnecter du disque dur lui-même Celui-ci est supposément très fragile et peut se briser. J’ai lu quelques horreurs à ce sujet sur les forums du Mac Mini (*). Le mettre de côté comme vous l’avez fait pour les antennes.

Retirer les quatre vis du disque dur, le mettre en lieu sûr et retirer le disque dur de son socle (comme sur les vidéos). Sous le disque dur, il y a deux petit morceaux de foam collés. Le retirer et les faire adhérer sur le nouveau disque dur au même endroits. Vous pouvez mettre le nouveau disque dur dans le socle, remettre les vis et recoller le détecteur de chaleur au même endroit où il était.

On continue! Vous devez maintenant replacer la section des disques sur la carte mère. Faire très attention au divers fil des antenne et surtout au petit connecteur dont je vous parlait tantôt. Je l’ai écrasé par mégarde et j’aurais pu le briser. Il est très facile de remettre la section en place, et je n’étais pas sûr si je l’avais fait correctement. Je dirais qu’il faut faire attention à cette partie sur laquelle on se concentre peut-être moins.

Replacer les divers connecteurs fût toutefois facile, et même les vis. J’aurais pensé perdre deux trois fois la vis plus difficile du devant, mais je fût chanceux. J’espère que vous le serez aussi. N’oubliez pas aucun connecteur et antennes : 1 connecteur + 3 antennes dont une est collée sur le côté (le papier collant devrait encore adhérer à la surface de la section des disques.

Vous êtes sûr maintenant de ne rien oublier ? Bon, c’est le temps de remettre le boîtier en place. Clic, clac et c’est fait. En replogue et on croise les doigts. Juste pour être certain, j’ai installé mon ancien disque dur dans un boîtier externe et plogué le port USB, juste au cas. Ça a bien servi puisque j’avais mal formatté mon nouveau disque dur et que j’ai booté de l’ancien. Il a fallu que je réinstalle tout à partir du DVD d’installation (long). Toutefois, à part cela tout est parfait. L’ordinateur est suffisamment rapide et je peux installer les logiciels que je veux. Au moment d’écrire ces lignes, cela fait plusieurs semaines que le Mac Mini est up 24 heures sur 24 et je n’ai pas eu aucun problème. La température des composantes reste normale et la fan roule toujours à 1500RPM. Le tout est très silencieux et aucun autre problème. Étant donné mon utilisation du Mac Mini (écoute de films sur télé), je n’ai pas vraiment remarqué une grosse différence de vitesse, sauf peut-être lorsque j’écoute quelque chose en même temps que je télécharge. Sinon, cela fait une belle machine qui roule très bien.

(*) Petite note, je vais ajouter des références pour cette article lorsque j’aurai le temps. Il faut que je le retrouve et que je les classe.