INDEX
Des « Best Practices » : pourquoi ?
- Vous donner un aperçu, chers Clients, de la manière dont le maçon va construire votre maison
- Vous assurer que nous avons un référentiel commun
- Standardiser les projets par une méthode éprouvée et pérenne
- Démontrer que nous prenons au sérieux la notion de Qualité.
Ces bonnes pratiques sont le fruit d’une décénie d’expériences accumulées sur plus de 300 projets, de veille technologique, et d’échanges entre collègues, collaborateurs, clients, concurrents. Cet article est régulièrement mis à jour.
Il n’est pas question de les substituer à votre cahier des charges. Mais comme 99% des projets démarrent sans charte d’intégration, voici comment vos livrables seront codés en standard. Cet article est mis à jour régulièrement.
Règles d’or
Validation W3C, oui mais…
Notre markup est toujours valide (X)HTML/CSS. Notez cependant que certaines exigences génèrent des erreurs, par exemple :
- Si vous demandez des iframe
- Si vous insérez du code externe (comme les appels aux « embed » vidéo YouTube, boutons « Like » Facebook)
- Si c’est pertinent : qui voudrait charger tout un framework javascript et une librairie externe si un simple « onLoad » (qui ne valide pas) fait le job en une ligne ?
Le validateur CSS retourne souvent des avertissements, par exemple :
- La même couleur est utilisée en tant que couleur et couleur de fond
- Vous n’avez pas de couleur de fond définie avec votre couleur
- Vous avez des longueurs absolues et relatives
- Vous êtes encouragés à proposer une famille générique comme dernier choix
Ces messages ne signifient pas que le code soit invalide ni qu’il doive être obligatoirement corrigé.
DRY (Don’t Repeat Yourself)
Le temps c’est de l’argent alors évitons les redondances de code :
- En CSS, mutualisons les déclarations autour de plusieurs propriétés
- En JS, privilégions la programmation procédurale (objets, fonctions) à la programmation séquentielle
- En jQ, faisons appel aux fonctions en utilisant les sélecteurs multiples
- Nos fichiers sources JS comportent des includes non-natifs, nos fichiers CSS ont une syntaxe simplifiée et hiérarchique. Nous utilisons ensuite CodeKit pour traiter les fichier Less, Sass, Stylus et générer des fichiers « minifiés » pour la production. La syntaxe est vérifiée automatiquement avec JSLint.
Cependant…
Parfois (ex. mise à jour d’ancien projet) dupliquer le code permet de réaliser en 30 minutes une tâche qui nécessiterait 2 heures pour être factorisée. Tiraillés entre les Bonnes Pratiques et la rentabilité, nous vous laisserons le choix…
/* No comment */
Le code doit tojours être indenté et commenté :
- Pour faciliter la compréhension entre les équipes lorsque le dév back n’est pas réalisé par le dév front
- Pour permettre la communication entre ces équipes, en insérant un nameblock en en-tête
- Pour diminuer le temps d’adaptation lorsque nous faisons évoluer d’anciens projets
- Pour regrouper les fonctions de code par secteur (ex. :
/* Styles du menu de navigation principale */). Ce n’est pas parce que le code est parfois self-explainative qu’il ne doit pas être rangé !
Les commentaires ont aussi vocation à rendre le code lisible et son parcours cohérent, voire agréable. Pour que cela soit efficace il est nécessaire d’en harmoniser la rédaction, aussi utilisons-nous des outils adaptés :
Inspiré de JavaDoc et PHPDoc, CSSDoc permet de générer les blocs faciles à lire :
Ex. : En-tête d’une feuille de style (ne figurent pas dans la version « minifiée »)
/** * Mon nouveau projet * * @copyright Nom de l’agence ou du client * @author Nom du développeur * @version Version * * @revision Revision * @lastmodified Last Modified Date */
Ex. : Nouvelle section dans la feuille de style
/** * @section Styles de textes * * Utilisés dans les blocs RTE générés par le CMS * @see Enter an optional reference url */
Lorsque cela est pertinent, explications sur @bugfix et @workaround
/** * Enter bugfix description * * @bugfix * @affected Enter affected browsers (e.g: IE 5.x/Win, IE6) * @css-for Enter browsers that are adressed by the workaround (e.g: IE 5.x/Win, IE6) * @valid Enter validation status (yes|no) */
Pour le javascript, JSDoc est utilisé :
/** * Describe what this method does * @private * @param String|Object|Array|Boolean|Number paramName Describe this parameter * @returns Describe what it returns * @type String|Object|Array|Boolean|Number */
En matière de commentaires HTML il s’agit plus souvent de jalonner le code de repères de lectures que de donner des explications fonctionnelles.
Nous utilisons la syntaxe auto-générée de Emmet (anciennement Zen coding) :
<!-- #page --> <div id="page"> <!-- .title --> <p class="title">Lorem ipsum dolor sit amet...</p> <!-- /.title --> </div> <!-- /#page -->
Notre leitmotiv : rester organisés. Nous parsemons donc le code de plusieurs lignes séparatrices et de blocs de commentaires servant à se repérer. Le code fonctionnel peut prendre des formes raccourcies (ex. : syntaxe abrégée d’un if) mais nous nous évitons les blocs de JS massifs. Pour le code de présentation, les single line CSS (1 ligne par déclaration) sont bannies (c’est illisible), sauf s’il s’agit du format d’origine d’une CSS externe (ex. : CSS issue d’un plugin).
Les faux includes en JS sont rendus possibles grâce à CodeKit.
Conventions HTML
Doctypes
Les développements démarrés en HTML5 s’inspire du HTML5 Boilerplate :
<!doctype html> <!--[if lt IE 7]><html class="no-js ie6 oldie" lang="en"><![endif]--> <!--[if IE 7]><html class="no-js ie7 oldie" lang="en"><![endif]--> <!--[if IE 8]><html class="no-js ie8 oldie" lang="en"><![endif]--> <!--[if gt IE 8]><!--><html class="no-js" lang="en"><!--<![endif]--> <head> <meta charset="utf-8"> ...
Pour les développements nécessitant un markup plus ancien, nous utilisons le doctype XHTML 1.0 strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> ...
Les newsletters héritent en général d’un doctype XHTML 1.0 transitional :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> ...
Charset
Sauf demande expresse, tous les fichiers sont en UTF-8.
Métas
Dans la mesure du possible, nous essayons d’intégrer les balises meta minimales : titre, description, et depuis peu celles utilisées par Facebook en version standard ou OpenGraph. Plus de détails dans notre article consacré à ce sujet.
Favicon
Si le fichier est fourni, nous l’appelons avec :
<link rel="icon" href="favicon.ico" type="image/x-icon" /> <link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
Convertir un .png en .ico avec ConvertIcon
Styles et scripts
- Les styles sont appelés dans le
headà l’aide de la baliselink - Les styles sont minifiés et combinés en 1 ou 2 feuilles séparées par page maximum (hors scripts externes)
- Les scripts sont appelés de préférence en fin de page
- Les scripts sont minifiés et divisés en librairies combinés, scripts globaux, scripts par page.
Server-Side Includes (SSI)
Sur les projets imposants il est pertinent d’inclure une partie d’un fichier (ex. : header.html) dans une page utilisant SSI (ex. : homepage.shtml).
Cela facilite la lecture du code par les équipes front et back, respecte notre moto DRY (Don’t Repeat Yourself) en évitant les redondances, accélère les itérations, respecte la norme SGML sans nécessiter PHP (plus d’infos sur les SSI).
Ex. : homepage.shtml
... <!-- #container --> <div id="container"> <!--#include file="header.html" --> <!--#include file="nav.html" --> <!-- #main --> <div id="main"> Lorem ipsum dolor sit amet... </div> <!-- /#main --> <!--#include file="footer.html" --> </div> <!-- /#container --> ...
Pour autoriser l’exécution des SSI dans l’hôte Apache (MAMP), on doit ajouter quelques lignes dans le .htaccess :
AddType text/html .shtml AddHandler server-parsed .shtml
Structure de page
Dans la mesure du possible, les pages comprenant les éléments standards définis ci-dessous doivent suivre la dénomination appropriée, au niveau du nommage des identifiants.
Il est conseillé de se référer à l’ébauche actuelle du futur HTML 5 pour des exemples d’utilisation.
- wrapper – destiné à contenir d’autres éléments
- nav – menu de navigation principal
- subnav – menu de navigation secondaire
- search – bloc contenant le champ de recherche
- q – champ de recherche principal
- article – section de contenu
- sidebar – barre de côté
- header – en-tête de page
- footer – pied de page
Exemple de structure basique de page HTML5 :
<!DOCTYPE HTML> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Nom du site</title> </head> <body> <header> <nav> <ul> <li> <a href="articles.html">Articles</a> <ul> <li><a href="photos.html">Photos</a></li> <li><a href="pages.html">Pages</a></li> </ul> </li> </ul> </nav> </header> <main> <section> <article> <header> <h2>Titre de l'article 1</h2> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p> <p>Donec venenatis, enim ac sodales suscipit, enim nibh viverra libero, eu rutrum nulla orci vitae mi.<br> Aliquam hendrerit ultricies odio.</p> </header> <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p> </article> <article> <header> <h2>Titre de l'article 2</h2> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p> <p>Donec venenatis, enim ac sodales suscipit, enim nibh viverra libero, eu rutrum nulla orci vitae mi.<br> Aliquam hendrerit ultricies odio.</p> </header> <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p> </article> </section> <aside> <h2>Pour aller plus loin</h2> <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Nemo, voluptates.</p> </aside> </main> <footer> <p>Copyright © 2014</p> <ul> <li><a href="#">Lorem ipsum dolor.</a></li> <li><a href="#">Quos, distinctio, rem!</a></li> <li><a href="#">Vero, hic, eum.</a></li> <li><a href="#">Repellendus sint, ullam!</a></li> </ul> </footer> </body> </html>
L’équivalent XHTML 1 :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"> <title>Nom du site</title> </head> <body> <div id="header"> <img src="logo.png" alt="Logo" /> <h1>Titre de la page</h1> </div> <div id="nav"> <ul> <li> <a href="articles.html">Articles</a> <ul> <li><a href="photos.html">Photos</a></li> <li><a href="pages.html">Pages</a></li> </ul> </li> </ul> </div> <div id="wrapper"> <div class="article"> <h2>Titre de l'article 1</h2> <div class="intro"> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p> <p>Donec venenatis, enim ac sodales suscipit, enim nibh viverra libero, eu rutrum nulla orci vitae mi.<br/> Aliquam hendrerit ultricies odio.</p> </div> <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p> </div> <div class="article"> <h2>Titre de l'article 2</h2> <div class="intro"> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p> <p>Donec venenatis, enim ac sodales suscipit, enim nibh viverra libero, eu rutrum nulla orci vitae mi.<br/> Aliquam hendrerit ultricies odio.</p> </div> <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p> </div> <div class="sidebar"> <h3>Pour aller plus loin</h3> <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Nemo, voluptates.</p> </div> </div> <div id="footer"> <p>Copyright © 2014</p> <ul> <li><a href="#">Lorem ipsum dolor.</a></li> <li><a href="#">Quos, distinctio, rem!</a></li> <li><a href="#">Vero, hic, eum.</a></li> <li><a href="#">Repellendus sint, ullam!</a></li> </ul> </div> </body> </html>
Conventions liées au balisage sémantique et optimisations SEO
Nous ne reviendrons pas sur l’utilisation évidente des usual suspects que sont h1-6, p, alt etc.
Pour faciliter le theming, notamment dans le cas où les pages doivent être transformées en thèmes pour WordPress, Drupal ou autre CMS, nous appliquons des classes génériques sur certaines éléments en suivant les recommandation d’implémentation du W3C sur les pseudo-classes (qui ne sont hélas pas suffisamment supportées).
Ex. : Utilisation de first et last dans une liste
<ul> <li class="first"><a href="#">Lien 1</a></li> <li><a href="#">Lien 2</a></li> <li class="last"><a href="#">Lien 3</a></li> </ul>
Lorsque cela est pertinent, nous préférons l’utilisation des listes de définition par rapport aux listes énumératives ou à la multiplication illisible des div :
Exemple issu de pompage.net :
<dl class="gallery"> <dt><img src="flower.jpg" alt=""></dt> <dt>Ici le titre</dt> <dd>Ici la description</dd> </dl> <dl class="gallery"> <dt><img src="flower2.jpg" alt=""></dt> <dt>Ici le titre</dt> <dd>Ici la description</dd> </dl> <dl class="gallery"> <dt><img src="flower3.jpg" alt=""></dt> <dt>Ici le titre</dt> <dd>Ici la description</dd> </dl>
Enfin, les formulaires comportent des tags fieldset, label, et les types de boutons appropriés. Les placeholders sont secondés par un fallback JS pour les navigateurs ne supportant pas cet attribut nativement.
Conventions CSS
Généralités
- Remise à zéro des styles avec un CSS Reset (Eric Meyer)
- Blocs flottants ajustés grâce aux clearfix
- La syntaxe « shorthand » est privilégiée (et simplifiée, avec Less ou Sass ou Stylus)
- La syntaxe BEM (Block, Element, Modifier) est appliquée dans la mesure du possible
Pour les projets HTML5
- Les styles hérités du HTML5 Boilerplate sont utilisés en sus
Pour les projets mobiles (sites BlackBerry, Android, iPhone, iPad
- Nous précisons les règles d’utilisation du viewport (balise permettant de définir les règles de redimensionnement d’une page sur les écrans mobiles)
- Nous indiquons au devis quels sont les OS de test, et éventuellement les devices
- Les media queries sont intégrées à part (puis fusionnées dans la CSS minifiée de production)
- Utiliser le moins de CSS possible, au profit des balises
font(à placer dans destablebien entendu…). Les reset et clearfix ne s’appliquent pas. - Le CSS se déclare inline
- Utiliser quelques hacks comme évoqué précédemment dans cet article
- Il est de bon aloi que le Client se renseigne sur les tendance directement chez de vrais spécialistes (comme Campaign Monitor ou MailChimp, qui sont autrement plus utiles que Nielsen et le JDN). On apprend par exemple dans cet article que l’utilisation de règles CSS3 permet d’adapter le layout d’une newsletter pour les périphériques mobiles, bien entendu cela demande un travail de conception et de design en amont de la phase d’intégration.
Techniques modernes
- Nous privilégions CSS3 pour les ombrages, arrondis, ombres de textes, dégradés. Sauf cas (très) exceptionnels, nous n’intégrons plus les images de calage, les ombres en absolute, les dégradés avec plusieurs JPG, et autres techniques qui étaient en vogue sous l’ère Chirac.
Voir la liste des propriétés prises en charges selon les versions des navigateurs - Les textes dans des polices spécifiques sont intégrés à l’aide des propriétés
font-facegénérées par FontSquirrel, au détriment des images-textes. Les polices directement issues de Google Web Font sont les bienvenues !
Les anciennes méthodes comme Cufon, SIFR, FLIR, ne sont plus supportées.
Voir la comparaison des systèmes de font-replacement.
IMPORTANT : veuillez vérifier avant de commencer votre maquette que vous disposez des polices dont les droits autorisent une utilisation web et une conversion en webfont. Nous ne convertissons pas de polices pour lesquelles nous ne détenons pas les droits (même la DIN que tous les graphistes mettent quand ils n’ont pas d’idée). - Nous supportons les systèmes de grilles suivants : 960.gs ; Blueprint Grid, et bien entendu Bootstrap (v2 ou v3) qui accélèrent considérablement la phase d’intégration. Attention : s’il a été convenu au devis qu’une grille serait utilisée, mais que la maquette livrée ne l’utilise pas (ou mal) nous ne pourrons pas commencer l’intégration HTML.
Hacks
- Nous utilisons de préférence des feuilles spécifiques appelées grâce aux commentaires conditionnels, par exemple :
<!--[if lte IE 8]> <link rel="stylesheet" href="css/ie.css" type="text/css" media="screen,projection" /> <![endif]--> - Cependant certains projets ne nécessitent que très peu d’adaptations. Il nous apparaît alors opportun d’utiliser 2 ou 3 hacks parmi plusieurs centaines de déclarations, que d’alourdir le code html en commentaires + ajouter un hit par page.
- N’oublions pas par ailleurs que d’autres navigateurs nécessitent parfois des hacks
- Le bug des PNG transparents sous IE6 est résolu (au mieux) avec l’adjonction du script DD_belatedPNG
Conventions JS
- Les développements sont réalisés à l’aide du framework jQuery (dernière version systématiquement)
- Dans la mesure du possible, les widgets et effets seront issus de jQuery UI
- Nous utilisons les sélecteurs multiples afin d’éviter la redondance du code, et faisons massivement appel aux plugins externes pour ne pas réinventer la roue.
Arborescence type
-
.htaccesscontient un fix de header pour les fichiers fonts sous FF - /css
ie.cssstyles spécifiques IEtools.lessreset css, clearfix, contraintes extérieuresglobal.lessstyles communs à tout le projetXXX.lessstyles propres à la page XXX.shtmlYYY.lessstyles propres à la page YYY.shtmlZZZ.lessstyles propres à la page ZZZ.shtmlresponsive_1024.lessmedia queries iPad / small desktopresponsive_640.lessmedia queries Galaxyresponsive_320.lessmedia queries iPhonestyles.cssfichier minifié incluant la version compilée de tous les fichiers Less (ou SASS, ou Stylus)
- /fonts
/imageséléments d’interfaces. On privilégie le PNG.bg_xxx(_left right top bottom)btn_xxx(_active _inactive _hover)- header_xxx
- ico_xxx
- nav_xxx
picto_xxx(_ffffff_ltr _000000_rtl ff0000_ttb 0000ff_btt)
/includesheader.htmlinclude de l’en-têtenav.htmlinclude de la navfooter.htmlinclude du pied de pagesidebar.htmlinclude de la sidebar
- /js
- /lib
jquery-version.min.jsdernière version minifiedjquery-UI-version-custom.min.jsdernière version minified
/vendorplugin-name.js(selon nommage de la source)plugin-name2.js(selon nommage de la source)plugin-name3.js(selon nommage de la source)
main.jsscripts communs à tout le projetmain.min.jsversion de production minifiéeXXX.lessscripts propres à la page XXX.shtmlYYY.lessscripts propres à la page YYY.shtmlZZZ.lessscripts propres à la page ZZZ.shtml
- /lib
XXX.shtmlpremier gabarit intégré (faisant appel aux fichiers situés dans /includes)YYY.shtmlsecond gabarit intégré (faisant appel aux fichiers situés dans /includes)ZZZ.shtmltroisième gabarit intégré (faisant appel aux fichiers situés dans /includes)/tempvisuels utilisés pour le montage, qui seront remplacés dynamiquement lors du dév back (ex. : thumbnails des articles)
FAQ Procédures et tests
Pour une bonne compréhension de notre workflow, consultez cet article : Environnement de travail sous Mac pour développeur web
- Comment un projet démarre-t-il ?
Après brief, émission d’un devis, réception d’un bon de commande.
Nous générons une URL unique pour votre projet sur notre serveur de développement, qui comprend un accès au repository GIT, un accès à l’outil de tickets pour a la recette, et une URL de preview « live » (protégée par mot de passe).
- Partez-vous de zéro ?
Non, nous utilisons une matrice par type de projet (projet XHTML, projet HTML, projet Mobile, projet Newsletter…). Cette matrice inclut notre Arborescence-type (cf. ci-dessus) et un certain nombre d’éléments de base énumérés ici même. Les matrices évoluent très souvent, et elles sont versionnées. Cela vous garanti de toujours bénéficier des dernières innovations que nous mettons en œuvre dans l’ensemble de nos projets.
- Votre intégration est-elle « pixel-perfect » ?
Oui, nous plaçons temporairement un JPG de votre page en background ou en overlay et construisons le layout de la page en accord (grâce à une extension qui, justement, s’appelle PixelPerfect. Il n’y a pas de hasard, dans la vie). Notez que les maquettes reçues comportent parfois des incohérences qu’il nous faut corriger (exemple : interlignes inconsistants dans un même paragraphe, texte qui déborde des cadres à cause d’un mauvais calage, superposition hasardeuse de plusieurs transparences…)
- Dans quelle langue sont intégrés les fichiers ?
Par défaut : noms de classes, blocs, images, etc. en anglais (ex. : #header, #search, .column, .post)
Contenu précis d’une page : adjonction de la langue d’origine (ex. : title_h1_nos_offres_speciales.png)
Lowercase privilégié
Séparateur underscore privilégié
Nous savons intégrer, stocker, manipuler, afficher les contenus en caractères non-latins (cyrillique…) et lus en RTL (right-to-left) (hébreu, etc)
- Comment puis-je voir l’avancée de la programmation ?
Chaque « commit » GIT envoyé nos serveurs de test devient instantanément consultable via navigateur web.
Vous pouvez également télécharger des ZIP à la demande depuis l’interface de tickets.
- Comment sont testés les sites ?
Nous disposons d’une machine virtuelle par version de navigateur (une pour IE6, une autre pour IE7, une autre pour IE8, 9, 10, 11, la dernière version de FF, la dernière version de Chrome, etc). Sauf cas très exceptionnels nous ne développons plus pour les anciennes versions de Chrome et Firefox. Ces navigateurs se mettent à jour automatiquement. Un supplément est demandé pour assurer la compatibilité IE6. Un autre supplément est demandé pour assurer la compatibilité IE7.Nous développons sous Mac avec : la dernière version de Safari, la dernière version de Chrome, la dernière version de Firefox, et nos machines virtuelles. Il s’agit de VM officielles éditées par Microsoft, nous n’utilisons pas d’émulateur, les navigateurs sont donc réels.Nous pouvons également tester vos développements sous les dernières versions de iOS et Android. Les spécifications des devices de tests sont toujours indiquées sur le devis.Nous pouvons inclure des copies d’écran du rendu de chaque page dans chaque navigateur (à réserver aux milestones importants).
- Comment sont testées les newsletters ?
Physiquement (pour le dév) : Apple Mail, Outlook 2007, Outlook 2010, Gmail, iPhone, Android.
Par un service de screenshots à distance (pour la validation) : à votre demande, une 30aine de mailers sont disponibles chez Campaign Monitor et Litmus App (des frais supplémentaires s’appliquent), notamment toutes les versions d’Outlook, de Lotus, etc.
- Comment sont testés les développements mobiles ?
BlackBerry : des machines virtuelles faisant tourner les émulateurs officiels (RIM) de la gamme BB de votre choix. Quelques mobiles physiques disponibles (Bold et Curve). iOS et Android : directement sur mobile Samsung Galaxy, Apple iPhone ou iPad (généralement dernière ou avant-dernière version de l’OS).
Versionning et mise à disposition
Nous utilisons Git pour le versionning.
Les livrables sont à votre disposition via :
- Repository Git privé
- Zip download privé
- URL « live » de test pouvant être protégé par
.htaccess
Éléments nécessaires au démarrage de la production
- Avant tout : un bon de commande !
- Maquettes : PSD RVB 72 DPI avec calques. Si vous utilisez un profil colorimétrique, veuillez l’inclure au fichier afin d’éviter les différences de teintes. Pour vos icones compatibles Retina pensez à utiliser toujours des shapes vectorielles.
Nous n’intégrons plus les fichiers Illustrator ni Fireworks. - JPG de contrôle : merci de joindre à vos PSD un JPG des pages/états (rollovers, étapes intermédiaires d’animation).
- Achat d’art : images Fotolia, Corbis, etc. à inclure dans le PSD (et non en externe) afin d’éviter toute différence de recadrage, colorimétrie, etc.
- Polices : TrueType ou OpenType. Les « valises de polices » (type Adobe ATM (Type Manager), Adobe AFM (Front Metrics) ne peuvent être converties pour raison légales. De même, les polices PostScript peuvent être protégées contre l’importation.
- Textes : de préférences en Word ou PowerPoint, à défaut nous utilisons ceux du PSD ou du « Lorem ipsum » (faux-texte)
- Toute information technique en provenance de votre DSI est la bienvenue !
