Aller au contenu

Silex

Membre
  • Compteur de contenus

    3
  • Inscrit(e) le

  • Dernière visite

Réputation sur la communauté

0 Neutre
  1. Exactement. Ca peut paraître ingrat a priori, mais tu comprendras mieux. Commence par écrire du HTML pur avec un éditeur de texte amélioré. Crimson Editor fait aussi très bien l'affaire. Gratuit et simple d'utilisation. Ensuite, tâte un peu de CSS. Tu verras l'immense potentiel que tu peux en tirer. Côté bouquin, je recommanderais HTML 4.01 La Référence de l'éditeur O'Reilly. C'est un pavé mais c'est un éditeur sérieux. Ce livre devrait te donner l'envie d'expérimenter ensuite d'autres aspects du web (JavaScript, etc.). Evite les pièges du web "gadget". Regarde le code source des pages que tu trouves bien faites. Si tu veux des exemples simples et bien structurés, regarde par exemple le code source de la documentation d'un logiciel que tu trouve bien mise en page. Petit à petit, modifie pour obtenir ce que tu souhaites. Commence par le classique. Les aspects "fun" que tu recherches peut-être viendront naturellement au fur et à mesure que ton expérience grandira. Si j'ai un conseil à donner : évite de copier-coller du code que tu ne comprends pas. Beaucoup font cela avec des bouts de code JavaScript. Ils sont ensuite totalement incapables de comprendre pourquoi ça ne fonctionne pas avec leur site. Bon vent!
  2. Merci à vous tous. J'ai aussi ce sentiment que critiquer mon prédécesseur ne me ferait pas gagner des points. En même temps, je pense qu'il est important que le client perçoive bien ce qu'on lui offre afin d'éviter qu'il saute sur le premier concurent "low cost". Dans mon cas, j'ai effectué une sorte de petit audit. Je n'ai pas critiqué mon prédécesseur. J'ai expliqué que la structure construite correspondait à un site simple et qu'en prévision des futures traductions certains changements dans la structure des pages étaient souhaitables. Le client a compris pourquoi et j'étais content. J'aurais par contre dû mieux analyser les détails du code; toutes les scories. (Je pense cependant qu'on ne peut pas rentrer dans un trop grand niveau de détail avec les clients. Leur temps est compté.) Le "problème" du test W3C, c'est que certaines pages peuvent être tout à fait valides, mais structurées de façon absurde. Par exemple, les titres peuvent être implémentés avec <p class="titre1"> plutôt qu'avec <h1>, etc. Tous les styles peuvent être définis dans la page et le validateur du W3C n'y trouvera rien à redire. Ceci dit, c'est vrai qu'un mauvais balisage passera difficilement le test de validation. à thick : C'est vrai qu'un webmestre peut être stressé par un trop petit budget. Personnellement, je préfère renoncer au boulot si le budget est vraiment trop faible. C'est une question de respect de son propre travail. J'admets qu'on renonce aux descriptifs d'images si on est à la bourre, mais là je parle de code vraiment mal structuré, à la WYSIWIG et de tableaux imbriqués jusqu'à 4 niveaux avec une indentation cahotique. C'est un esprit de graphiste et pas de programmeur. à Dadou : Je trouve vos remarques pertinentes pour un nouveau site. Mais c'est un peu plus dur à expliquer lorsqu'on est face à un site déjà créé. Ca donnera l'impression au client qu'on considère qu'il a mal choisi son webmestre. Il risque de se demander s'il n'a pas affaire à un illuminé qui veut repartir de zéro. à baulet : Bonnes idées pour un site commercial, mais il n'en est pas ainsi de tous les sites. Le site Internet de nombreuses PME n'a qu'un but de présentation de l'entreprise. Je n'ai pas accès aux statistiques, le client désirant faire lui-même le transfert des fichiers par FTP. à pluriels : Pour la lecture du site sans CSS, je ne vois vraiment pas mon avantage. Le site de celui qui a utilisé des <font> à gogo conservera une belle apparence, alors qu'une implémentation plus évoluée avec l'apparence gérée par CSS souffrira au rendu. La démo avec des feuilles de style différentes me semble en revanche une bonne idée. Le "code" à l'ancienne ne me dérange pas en soi, même si CSS a apporté un sacré progrès. Que le code soit à l'ancienne ou non, il y a des personnes qui "codent" avec soin et d'autres non. à ghost : Intéressant. C'est également mon point de vue. Je pense que si j'y perds un peu sur la première traduction, j'y gagnerai si d'autres me sont confiées. Mon client souhaite pouvoir éditer lui-même son site. J'ai simplifié le code pour qu'il puisse le faire. J'espère toutefois qu'il continuera de me confier les gros travaux, de type traduction complète. C'est difficile d'investir sur le long terme si on n'est pas certain de pouvoir garder le client sur la durée. Pour terminer, j'ai pensé qu'un système de notation, avec un formulaire tout fait, pourrait être intéressant. Divers critères de qualité seraient utilisés et on noterait le site "avant" et "après" les modifications. Chaque note correspondrait à certaines exigences. Par exemple, pour obtenir une note élevée sur le critère de la lisibilité, une page devrait pas avoir trop de caractères sur la même ligne, une indentation agréable, etc. Quelques craintes quant au sucroît de travail administratif toutefois... La discussion reste ouverte.
  3. Bonjour, J'aimerais lancer un petit débat sur la difficulté de valoriser la qualité en matière de développement web. En tant que webmestre indépendant travaillant principalement pour des PME, je suis confronté à 3 problèmes récurents : 1) Des erreurs de conception grossières par le webmestre qui m'a précédé. 2) Un balisage HTML généré automatiquement et bourré de "scories", doublé d'un trop faible usage des feuilles de style. 3) La difficulté à deviser autant d'heures qu'il faudrait alors que je passe déjà pour cher. Depuis toujours, j'ai le soucis d'une conception et d'une implémentation de qualité. J'édite mes pages HTML et mes feuilles de style manuellement, etc. Or souvent, je suis amené à modifier des sites qui ont été écrits n'importe comment. Généralement, le balisage a été généré automatiquement depuis une interface WYSIWYG. Le marquage est bourré de <span> vides, etc. Actuellement, je suis confronté au problème de la traduction d'un site. Presque tout le balisage doit être refait pour que la traduction et d'éventuelles autres traductions futures puissent s'effectuer de manière rationnelle. Refaire le balisage est plus long que l'implémentation de la traduction. Même si je n'ai pas compté toutes les heures nécessaires, je passe forcément pour cher. Alors que j'hérite du boulot de cochon de mon prédécesseur. Pire: si mon client devait changer de webmestre, mon successeur hériterait d'un code tout propre et passerait alors pour quelqu'un de très rapide et de bon marché! Comment faire comprendre à son client la différence entre son sérieux et le travail d'un charlatan ? Dans mon cas, le site est l'oeuvre d'un "graphiste". (Je met les guillemets par respect de ceux qui font du bon boulot.) Pour le novice, le site présente bien et a l'air bien conçu. Rendre pareil site "compatible W3C" serait dantesque. Pas sûr non plus que le client perçoive ce que ça signifie. J'hésite à montrer au client le code sous ses états AVANT et APRES, mais j'ai peur de l'ennuyer. De plus, je crains que le client pense simplement que je suis jaloux de mon prédécesseur. Bref, les charlatans font du tort aux développeurs web sérieux. Quelles techniques employez-vous pour faire comprendre la différence ? Existe-t-il des cercles de 'développeurs' de qualité en vue d'une sorte de certification ? Sorte de compagnonage du web ?
×
×
  • Créer...