Ma méthodologie d’intégration web

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.

Avant le projet

  • 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.

Etude du projet

  • Phase d’étude de l’intégration : Objets CSS utilisables, nouveaux, à styliser …
    • Taille du container principal & Viewport.
    • Couleurs utilisées pour le texte, dont les :hover et la couleur de base.
    • Polices utilisées, y compris leurs tailles de graisses
    • Interlignage de base & taille des textes par défaut.
    • Responsive ou non: breakpoints ?
    • Animations: effets au hover, transitions ?
    • Blocs administrables: Texte intégré au push, éditable ?
  • Ecriture du bilan de l’étude, avec stockage dans un dossier public, Redmine, ou sur le bureau selon le projet.
  • Mise en place des données dans votre éventuel fichier de config Sass ou Less.

Intégration

  • Création des fichiers de base, à partir d’un pillage en règle de CSSCommon 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.

Vérification

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.
    • La modification du background du parent n’a pas d’incidence sur la cohérence de la DA.
  • “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).
  • Débug FFx Mac — FFx Windows — Chrome Windows — IE 7–8–9.
  • Calages par rapport à la DA. (Pas de pixel perfect, mais un design propre)
  • 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.
  • Optimiser le code: Dédoublonner le CSS, vérifier que la compression CSS ou HTML ne brise rien.
  • Optimiser les images avec ImageOptim.
  • Conversion des pictos PNG (–200octets) en base64 avec IMG2data:uri.
  • Documenter la section.
  • Vérifier si l’impression d’une page exclut certains blocs inutiles.
  • Visite des pages principales du site pour vérifier l’absence de régressions.
  • Commit / Pull / Push sur Git 🙂

Finalisation du projet

  • 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 CSSCommon.
  • 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 ?

Partager cet article

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

  • Je ne comprends pas l’intérêt de « piller » le CSSNormalize quand celui-ci est utile du début à la fin.

    Perso j’intègre de haut en bas, en organisant ma CSS par parties et j’utilise le h5bp, ce qui a réduit mes temps d’inté de presque 50%.

  • Le terme « pillage » sous-entend la récupération d’éléments intéressants. Comme toute librairie, tout n’est pas bon à récupérer pour un projet précis.

  • Merci pour ta méthodologie, je la trouve intéressante 🙂 Par contre, autant sa me gène pas que tu fasses de la pub pour tes labs, autant s’ils pouvaient être sur GitHub, ça serait quand même plus cool 😉 😛

  • Etant novice dans l’intégration dite d’entreprise, je n’ai pas de méthode d’intégration particulière même si je reconnais 2 3 points que tu soulèves, mais je tends à écouter de + en + mon sensei qui me dicte des règles à suivre donc peut être que d’ici 4 5 mois je répondrai à cet article ! o/

  • Merci pour cette méthodologie. C’est toujours très intéressant de voir ce qu’il se fait chez les autres.
    Tu n’a pas parlé du temps de production moyen par projet. Dans ma boite une inté peut prendre de 2 jours jusqu’à 2 semaines selon le projet.

    En tout cas merci pour ce partage !

  • Pour ma part je fais tout à l’envers :
    1. Le client expose son projet, ses objectif, ses contraintes.
    2. On liste ensemble tous les contenus attendus.
    3. Le client produit un échantillon significatif de chaque type de contenu. Je fais la sieste pendant ce temps-là.
    4. L’étude des échantillons de contenus me permet de lui proposer quelques idées concrètes.
    5. Le client produit TOUS les contenus qu’il désire que j’intègre à la livraison du site. Je pars quelques semaines au soleil pendant ce temps-là. Le client bosse dur car il n’a pas le droit au début d’une maquette tant qu’il n’a pas fourni tout ça.
    6. Sur la base des contenus fournis on finalise le projet : architecture de l’info, arbo, fonctionnalités.
    7. On parle graphisme.
    8. Les contenus sont intégrés dans mon CMS préféré, avec tous les plugins requis, le js qui va bien. J’ai donc tout le site sur un serveur de test.
    9. Je code les templates les plus significatifs afin d’avoir ma matière première : des vraies pages avec quasi tout le code, dans les mêmes conditions qu’un site en production.
    10. Là et seulement là je dégaine mon éditeur css préféré. Je choisis quelques pages significatives que je style. Je fais deux ou trois css différentes afin de proposer autant de pistes graphiques au client : il peut ainsi voir ses maquettes non pas en jpeg mais directement sous forme de « vraies » pages web avec le rendu dans son navigateur préféré.
    11. Le client choisit une des pistes graphiques proposées et s’ensuit une série d’itérations. Je peaufine simultanément le code des templates et les styles css en validant chaque portion au fur et à mesure (validité du code, accessibilité, compatibilité crossbrowsers…).
    12. Le site a été entièrement développé, stylé, corrigé et testé au fil des itérations. Lorsque le client donne son bat final le site est donc fini. Il ne reste qu’à l’installer sur le serveur de production…

  • Ma méthodologie est assez proche sauf que je ne bois pas de café (et j’aimerais faire plus de sieste aussi 😉

  • Bonjour,

    Merci pour ce billet, c’est très intéressant de voir comment cela ce passe chez les autres.

    Bonne continuation.

  • Salut,
    l’article est très intéressant, c’estbien de voir des méthodologie quand on en a pas forcement soi-même :=)
    Par contre, quel est l’apport de l’étape « Conversion des pictos PNG (–200octets) en base64 avec IMG2data:uri » ?
    Ca ne me parle pas du tout :/

    Merci :=)

  • Super article !

    Quand on aime le travail bien fait ça fait plaisir à lire ^^

    Dans les grandes j’utilise la même méthodologie (avec autant de café), avec quelques outils en moins que je vais m’empresser d’utiliser.

  • La nouvelle partie sur l’étude du projet me semble de plus en plus importante pour maîtriser l’intégration globale : factoriser ses CSS autour d’un contexte de base permet de bien mieux gérer la modularité et la maintenabilité du code produit.

    C’est aussi une bonne solution lorsqu’on utilise un (micro)framework CSS : en répertoriant les besoins de l’intégration en amont, on peut se permettre de zapper certaines parties de l’outil choisi (pas besoin de grilles flottantes ? On les vire !).

    Cela dit, ça n’est vraiment pas un exercice facile !

    Pour le reste de la méthodologie ça ressemble assez à mes pratiques, en plus poussée je pense (je n’utilise pas d’outils pour « ranger » mon code par exemple, j’ai préféré définir une convention d’écriture) mais dans l’ensemble c’est assez proche.

    Et le contre-pillage est effectivement très important lorsqu’on développe ses propres outils (WP-Utilities <3 en passant !), mais aussi pour affiner un framework. Par exemple je me base souvent sur mon mix de Knacss & Röcssti, et il s'affine au fil des intégrations, tout comme mon thème de base pour WP.

    Selon les cas je rajouterais seulement une étape de recette / audit avec des outils comme Tanaguru, OpQuast reporting et consorts 🙂

    Merci pour cette présentation, c'est limpide !

  • En effet, l’étape de recette est importante, à condition de bien se souvenir qu’on ne s’occupe ici que de l’intégration. Du coup, ne se concentrer que sur la qualité du code produit et son accessibilité, et pas sur le fonctionnel 🙂