Je fais suite à cet article de Kaelig sur sa méthodologie d’intégration, en vous présentant la méthodologie que j’applique actuellement sur l’intégration web et le développement front-end.

Etude

  • Questions-réponses avec le chef de projet sur la faisabilité de nouveaux éléments.
  • Questions-réponses avec le directeur artistique sur la faisabilité de certains blocks.
  • Réception officielle du projet.
  • Phase d’étude de l’intégration : Dimensions, Couleurs, Polices, Objets CSS utilisables, à styliser, & nouveaux objets.
  • Ecriture du bilan de l’étude, avec stockage dans un dossier public, Redmine, ou sur le bureau selon le projet.

Intégration

  • Création des fichiers de base, à partir d’un pillage en règle de CSSNormalize et de quelques snippets.
  • Intégration du header.
  • Intégration du footer.
  • Création d’une liste d’objets CSS récurrents sur le site : Boutons, formulaires, tableaux, etc.
  • “Torture” du fichier Objets : Textes trop longs, Images trop larges, HTML inséré là où il ne devrait pas, etc.

  • Intégration block par block:

    • Ecriture du HTML (sémantiquement correct).
    • Ecriture des commentaires CSS correspondant aux sections du block à intégrer.
    • Découpage du PSD fourni en images.
    • Ecriture du CSS.
    • Traduction du contenu dans les autres langues.

  • A la fin de chaque étape, et pour chaque “block” intégré, je suis cette checklist :

    • Café

    • Vérifier que le block fonctionne indépendamment.

      • Un block ne clear pas le flottant d’un autre block.
      • Dans le cas d’un espacement entre deux blocks, supprimer un des deux blocks supprime également l’espacement.
      • Elargir le container élargit également le contenu. (Intégration « liquide »)
      • Bouger ce block dans la page ne modifie pas son aspect/fonctionnement général.
    • “Torture” du block : Textes trop longs, Images trop larges, HTML inséré là où il ne devrait pas, etc.
    • Vérifier le HTML avec le validateur du W3C (ou plugin équivalent).
    • Vérifier le CSS avec CSSLint (ou plugin équivalent).
    • Calages par rapport à la DA. (Pas de pixel perfect, mais un design propre)
    • Débug FFx Mac — FFx Windows — Chrome Windows — IE 7–8–9
    • Ajout de liens entre les templates afin de pouvoir y naviguer avant le début du développement.
    • Rangement du CSS avec CSSLisible
    • Rangement du HTML avec HTMLLisible
    • Conversion des pictos PNG (–200octets) en base64 avec IMG2data:uri
    • Commit / Pull / Push sur Git :)

Finalisation

  • Livraison de l’inté.
  • Suivi avec le développeur.
  • Contre-pillage du projet : les nouveaux objets intéressants, les corrections et autres améliorations sont versés dans CSSNormalize.
  • Grosse sieste. (Cette étape tient plus du rêve.)

Notes

  • La phase d’étude oscille entre une heure et une journée.
  • J’appelle « Block » une zone du contenu avec une utilité distincte : un formulaire, un widget, etc …
  • Je regroupe souvent plusieurs petits blocks pour la checklist de fin de block, afin de gagner du temps.
  • La checklist de fin de block prend habituellement entre 2 et 15 minutes.
  • CSSLisible & HTMLLisible sont utilisés au travers de leur API dans TextExpander.

Oui, cet article fait une belle pub pour Darklg Labs. So what ? ; )

Votre méthodologie diffère beaucoup de la mienne ?

Tags : , , ,