sandglassJ'ai eu l'occasion récemment d'écrire un formulaire de contact ainsi que son traitement PHP pour une entreprise de construction canadienne qui cherche à recruter du personnel.

Je commence à écrire le code. Je connais bien les formulaires étant donné que c'est l'un de mes premiers scripts (2001 si je ne m'abuse). Je place le script sur mon serveur, commence ma batterie de tests histoire de pallier toutes les situations auxquelles un utilisateur lambda peut être confronté. Le code que je livre est en en CSS3 et XHTML 1.1 valides.

Tout s'affiche impeccablement dans tous les navigateurs. Je me dis que c'est une affaire qui roule lorsque le client m'envoie quelques emails pour me demander quelques corrections, additions, et l'intégration du script dans son site.

C'est là que le vent a commencé à tourner.

Une correspondance diurétique

Je me plie à toutes ses exigences qui, au départ étaient bien maigres mais qui ont grossi bien vite au fil de notre correspondance : telle fonction de Gmail devait être implémentée, des destinataires multiples ajoutés en copie cachée invisible, tel champ devait être numérique seulement... Il m'a même demandé de retirer la bordure noire qui apparaît lorsque l'on sélectionne le bouton soumettre d'un formulaire. Si jamais on vous demande cela un jour, sachez que c'est impossible, ce focus est une fonctionnalité/restriction des navigateurs afin que l'utilisateur sache que le bouton est sélectionné.

J'ai aussi bien apprécié de recevoir un mail toutes les 3 minutes pour me faire remarquer que les étoiles des champs requis n'étaient pas en rouge ou qu'un des champs du formulaire était un peu décalé. Et tout ça en changeant de sujet à chaque fois, histoire de bien surcharger ma boîte de réception, me forçant à répondre à plusieurs mails différents. Productivité maximale à ce niveau-là.

A lire :  Re-développement de Mail-it Now!

Premiers tests sur le serveur

Son serveur - limité, très limité, trop limité... mais c'est quoi ce serveur ??? - a lui aussi pas mal joué avec mes nerfs. Il est tellement rapide qu'une pièce jointe ne peut dépasser, tenez-vous bien, 157 Ko. Wow. C'est sûr que cela valait le coup de me faire écrire un bout de code pour rajouter des champs d'upload de fichier à la volée à la Gmail ! Espérons que le client final aura un serveur décent pour faire tourner le script.

L'intégration avec le site

Le client me paie. Je lui livre le script fonctionnel, même sur son serveur. Une demi-heure plus tard, il me demande de l'intégrer sur son site parce qu'il est "designer" et non "codeur". Cela se tient. Je me dis que allez, de toute façon ça ne va pas me prendre longtemps. Je me trompais.

Il m'envoie l'adresse de son site ainsi que ses identifiants FTP (j'ai eu les bons au 5ème email, la situation s'améliore). Un petit clic droit sur le code source m'indique que celui-ci n'est pas du tout valide : des tableaux qui s'imbriquent sur trois voire quatre niveaux, du code javascript pour préloader les images, des styles appliqués aux différents éléments dans le code même au lieu d'utiliser une feuille CSS... bref, le cauchemar. Je dis adieu à ma belle validation. J'intègre.

La correspondance reprend de plus belle. Il lui prend l'envie de modifier son code au dernier moment. Re-intégration. Tiens, je m'aperçois qu'il a aussi rajouté des champs dans le formulaire. Et accessoirement, modifié le script PHP pour me le planter sur une variable incorrectement attribué. Décidément, j'ai un grand vainqueur. Il me parle alors des boutons : il veut styliser ses boutons en noir et blanc. Il me dit ça comme ça. Ok. Ah non, il veut moins d'espace, m'envoie une capture d'écran. Je modifie. Ce n'est pas encore ça, il faut que le comportement du bouton change quand on passe la souris dessus. Hmm. Il m'envoie alors un exemple de ce bouton qui se trouve déjà sur son site... Dites, c'est pas un vainqueur que j'ai là, c'est le champion du monde de la perte de temps.

A lire :  Nouveautés du site : été 2010

Je lui règle tous ses soucis CSS. Il me remercie comme si j'étais le Messie. Je crois que j'ai eu la patience d'un saint quand même. Une semaine plus tard, re-mail. Il me dit que cela s'affiche bien dans Internet Explorer mais pas dans les autres navigateurs. L'insulte suprême.

Régler le problème des hauteurs de cellule d'un tableau sous Mozilla/Opera

Le problème : il y avait des espaces entre les lignes des tableaux, ce qui ne devrait pas être. Le tableau apparaît correctement sous IE mais pas sour Firefox ou Opera par exemple. Il s'avère que Mozilla et Opera, entre autres, formatent les hauteurs des cellules différemment : selon mon observation empirique, Mozilla doit utiliser une sorte de doctype sniffing. Le navigateur évalue le doctype de la page et décide de quelle manière rendre la hauteur des lignes du tableau.

La solution a été toute simple : étant donné que son code était tout crade, j'ai supprimé la déclaration doctype. Tout est rentré dans l'ordre et s'affiche de la même manière dans tous les navigateurs.

Conclusions

Cela fait pas mal de mois que je n'avais pas travaillé avec nos cousins du continent américain et finalement, cela ne m'a pas manqué. Le gros problème des clients, c'est leur manque de clarté et de vision quant au projet qu'ils essaient de boucler. Leur vision est approximative et évolue sans cesse, ce qui pose pas mal de problèmes lorsque l'on se trouve derrière notre clavier pour résoudre leurs problèmes et respecter leurs exigences.

Ce projet m'aura donné de nouvelles règles de conduite :

A lire :  Tailles et distances des planètes de notre système solaire

  1. s'assurer que le cahier des charges est au point et baser le devis sur ce cahier des charges.
  2. toute fonctionnalité supplémentaire entraînera un surcoût.
  3. voir le site sur lequel sera intégré le script au préalable. Cela peut faire gagner du temps.
  4. une seule et même correspondance, avant le projet et après l'achèvement du projet. Pas pendant.
  5. s'assurer des capacités du serveur du client. Ce qui fonctionne sur 99% des serveurs risque de ne pas fonctionner chez lui. Pourquoi ? Parce que c'est le client.

Voilà. Cet article a une visée totalement cathartique. J'essaierai de me rappeler ces quelques règles le jour où je démarrerai un autre projet.

Pour développer votre projet WordPress ou Woocommerce, faites appel à mon expertise pour réaliser un site rapide, performant et fonctionnel.

Contactez-moi

Si vous avez trouvé une faute d’orthographe, informez-nous en sélectionnant le texte en question et en appuyant sur Ctrl + Entrée s’il vous plaît.

Articles en rapport:

De l'importance du cahier des charges du développement web

par Matt Lecture: 6 min
15

Pin It on Pinterest

Share This

Spelling error report

The following text will be sent to our editors: