Lexik c’est qui ?
Une société basée à Montpellier depuis 5 ans, avec 10 personnes et une ambiance sympa.

On fait quoi chez Lexik ?
Nous sommes spécialisés dans le développement d’applications web en Symfony2. Nos projets reposent sur les méthodes agiles et un développement de qualité via la mise en place de tests unitaires et fonctionnels.

Quels types de clients ?
Des start-ups qui recherchent un appui technique sur la mise en place de leur projet, des PME et collectivités locales ayant un besoin d’accompagnement en conseil et réalisation.

Lexik, c’est quoi d’autre ?
Des scrum meetings quotidiens, des points techniques presque tous les mardi, des idées communes pour des projets internes, du développement en équipe et comme dirait Laurent, le vendredi c’est sushis !

Et si on résumait tout ça techniquement :

• spécialistes du framework Symfony2 ;
• contributions à des bundles Open Source sur Github ;
• un blog technique ;
• développement frontend avec jQuery, Twitter Bootstrap, websockets, etc. ;
• méthodes agiles avec Scrum ;
• intégration continue avec Jenkins et tests fonctionnels avec Behat.

Description du poste :

Vous êtes motivé et passionné par votre métier, vous suivez avec attention l’évolution des frameworks et des derniers langages à la mode. Vous avez déjà travaillé en équipe et vous aimez ça.

Vous bénéficiez d’une bonne expérience à titre privé ou professionnel dans les technologies suivantes :

• PHP 5.3, OOP ;
• HTML5 / CSS3 ;
• SQL (MySQL, SQLite, PostgreSQL, …).

Une expérience ou un intérêt dans les domaines suivants seront un atout :

• Framework symfony 1.4 / Symfony2 avec l’ORM Doctrine ou Propel2 ;
• Gestionnaire de version (Git / SVN) ;
• Javascript, jQuery, node.js ;
• Tests unitaires et fonctionnels, intégration continue, Behat ;
• Méthodologie de développement agile (Scrum).

Détails :

Envoyez-nous votre CV et lettre de motivation par email à l’adresse : recrutement@lexik.fr

• Type de contrat : CDI
• Lieu : Pérols
• Début du contrat : ASAP
• Télétravail : non
• Rémunération : selon profil

Si l’on reprend quelques bases de bonnes pratiques de développement javascript, on constate :

• que vos javascripts doivent être non-intrusifs, autrement dit là pour améliorer l’expérience utilisateur et en aucun cas être indispensable au fonctionnement d’une page ;
• que les javascript doivent être combinés en 1 seul fichier et minifié (ceci afin de limiter le nombre de requête HTTP et car le chargement de la page est arrêté à chaque balise script, notamment à cause d’un éventuel document.write(); ;
• que l’appel au javascript doit être en bas de page ;

Cette liste est bien entendu non exhaustive, vous trouverez une liste plus détaillée par ici.

Toutes ces bonnes pratiques de développement Javascript n’ont pas toujours été facilitées dans symfony, notamment à la grande époque des helpers link_to_remote() & co. qui en ont ravi certains et fait cauchemarder d’autres. Et aujourd’hui encore bon nombre de widgets de formulaire retournent directement du code javascript (dépendant de jQuery ou autre) et qui ne fonctionneront évidemment plus dès lors que vos javascripts se trouveront en bas de page.

1. Où placer les javascripts dans le document

Idéalement et selon les recommandations de Yslow, en bas de page, donc juste avant la balise fermante de votre layout.php. Ceci afin de ne pas ralentir inutilement le début du chargement de votre page, puisque chaque balise script bloque le chargement de la page (notamment pour gérer le document.write();).
Source : http://developer.yahoo.com/performance/rules.html#js_bottom

Si cette méthode ne vous gênera pas pour les librairies tierces telles que jQuery, qu’en est-il par contre de vos codes javascript ? Ils doivent également se trouver dans des fichiers séparés, dissociés de votre document HTML. Néanmoins comme je vois souvent le besoin pour les développeurs d’avoir le code javascript au sein du template symfony, voici une technique pour qu’il soit tout de même placé en fin de page : via un slot.

Un petit exemple de code :

// indexSuccess.php :
<?php slot('javascript') ?>
<script type="text/javascript">
  console.log('javascript @ bottom');
</script>
<?php end_slot() ?>
 
// layout.php :
<?php include_javascripts() ?>
<?php include_slot('javascript') ?>

Vous pourrez ainsi éditer votre code javascript depuis votre template PHP, bénéficier par exemple de valeurs dynamiques de PHP et pour autant que le code soit bien inclus en bas de page. Toutefois je vous recommande d’écrire du javascript là où il doit se trouver, à savoir dans un fichier JS…

De plus l’inconvénient majeur du slot est qu’il ne peut contenir qu’une valeur, il est écrasé à chaque utilisation. La technique fonctionne mais est très limitée. Pour ces besoins nous avons écrit chez Lexik un petit plugin « lxJavascript », très similaire à l’utilisation d’un slot mais optimisé pour l’inclusion de javascripts. Il gère donc le multiple ajout, supprime les éventuelles multiples balises script pour en conserver qu’une seule, etc. Vous en saurez plus demain, le plugin sort en OpenSource sur le Github de Lexik.

2. Compression

La compression des javascripts (c’est valable aussi pour les CSS) est une des tâches d’optimisations les plus importantes et également une des plus simples, du moins via les plugins symfony. Cette technique consiste à compresser tous vos fichiers javascript en 1 seul et surtout d’y appliquer un numéro de version (un timestamp le plus souvent) afin de prévenir des problèmes de cache dans vos mises à jour.

Les principaux plugins :

• sfCombinePlugin
• npAssetsOptimizerPlugin
• swCombinePlugin

Chez Lexik, nous utilisons npAssetsOptimizerPlugin, un plugin de Nicolas Perriault, extrêmement simple à installer et paramétrer. Sur votre environnement de production, vous obtiendrez ainsi un fichier javascript compressé /js/optimized.js?1294759429 qui contient un timestamp permettant à chaque modifications des fichiers d’être prises en compte sans problème de cache.

Nous n’appliquons pas la compression pour les librairies externes telles que jQuery que nous déléguons aux serveurs CDN de Google, cela apporte ces avantages notables :

• l’avantage du CDN, à savoir de proposer des données statiques via un réseau de multiples serveurs dans de multiples points géographiques, afin de permettre un accès très court ;
• les navigateurs sont limités sur le nombre de connexions HTTP simultanées sur un même domaine, le téléchargement d’un javascript sur les serveurs de Google se fera en parallèle ;
• les librairies du CDN ont les bonnes en-têtes de cache, par exemple la version 1.4.4 de jQuery restera en cache pendant 1 an sur le client, cela signifie également qu’un internaute peut bénéficier du cache téléchargé depuis un autre site, pas forcément sur le votre.

3. Accéder à certaines données dynamiques depuis javascript

Il peut parfois être très utile depuis javascript d’accéder à certaines données dynamiques telles que la culture de l’utilisateur, du routing pour des appels Ajax ou encore de l’i18n. Il suffit de s’appuyer sur un simple fichier de configuration via un tableau de données JSON généré depuis une action symfony. J’ai écrit sur mon blog personnel un article détaillé sur le sujet Configurations Javascript dynamiques en Symfony.

4. Javascript depuis les widget

Maintenant que vos inclusions de javascripts se trouvent en bas de page, jQuery par exemple, que faire de nos chers widgets jQuery Autocompleter sfWidgetFormJQueryAutocompleter et autre Datepicker sfWidgetFormJQueryDate qui retournent des champs de formulaire et le javascript d’initialisation du composant ? Eh bien, ne plus les utiliser… Simplement car ils seront inclus avant jQuery et vous aurez donc droit à l’erreur « jQuery is not defined ». Sans être aussi extrême, vous pouvez charger jQuery en haut de page (via les CDN de Google) et votre script compressé en bas de page, les widgets de formulaire seront alors à nouveau fonctionnels.

Cela fait déjà quelques temps que chez Lexik nous avons fait le choix d’enlever tous ces widgets pour les ré-écrire et les adapter à nos besoins. Les javascripts des widgets passent par notre plugin lxJavascript ce qui permet de les inclure là où on le souhaite. Egalement, le javascript retourné par ces widgets correspond à une utilisation basique du composant, dans un cas concrêt il est souvent nécessaire d’en ré-écrire une bonne part. Il peut être pratique par contre que le widget retourne seulement la sémantique HTML adaptée, par exemple dans le cas d’un Autocomplete un champ hidden pour stocker la valeur et un champ texte pour l’autocomplete, aussi nos widgets ont une option pour retourner ou non le code javascript.

5. Optimisation frontend

Presque aussi important que la compression, la configuration d’apache pour mettre en cache certains de vos fichiers statiques. Typiquement, maintenant que vos fichiers javascripts et CSS sont compressés en 1 seul et possèdent un timestamp unique par version, il serait dommage de les recharger à chaque chargement de page… Vous devez donc configurer le module Expires d’apache via le fichier de config du vhost ou via le .htaccess, en voici un exemple :

  ExpiresActive on
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType text/javascript "access plus 1 year"

Vos fichiers javascript et CSS seront ainsi en cache pendant 1 an, attention du coup à ne pas avoir de fichier sans numéro de version, car ils resteraient en cache et vos internautes ne bénéficieraient pas de vos mises à jour…

Dernière chose, si ce n’est pas encore fait, installez et testez Yslow pour trouver des pistes d’optimisations de performance de vos sites.

1. Qu’est ce qu’un prototype / user-story ?

Dans le cadre de réunion autour d’un projet Web, on voit souvent quelqu’un sortir une feuille de papier, prendre un crayon, dessiner quelques traits hasardeux, des blocs par ci, par là, afin de présenter à un client ou un graphiste le rendu souhaité d’un site Internet ou d’un logiciel. C’est l’idée du wireframe, en beaucoup moins brouillon ! Le wireframe atteint un vrai niveau de précision, lorsque ce dernier est finalisé, on a une vision cohérente du futur rendu, il ne reste plus qu’au graphiste à ajouter sa touche graphique…

2 logiques pour les prototypes / user-story :

On peut globalement définir 2 styles de prototypes d’interfaces :

1. le wireframe « graphique » : il s’agit d’un prototype / scénario dont le but est de s’approcher au maximum du rendu final du site Internet. Dans un premier temps, on place les différentes zones à l’écran, cette étape s’appelle le zoning, elle permet d’organiser la page. Dans un second temps, on se concentre sur l’ergonomie, la communication générale, qui se clôture par le wireframe. A ce stade là, le wireframe détaille à la fois l’organisation de la page mais également l’ergonomie générale, l’étape suivante est naturellement la charte graphique.

Note : le wireframe peut faire l’objet d’une validation auprès du client et joue un rôle de support dans la communication avec le graphiste.

On comprend bien l’intérêt de toutes ses étapes qui nous approche de manière réfléchi et construite vers la maquette graphique, cela peut se résumer par :

zoning > wireframe > charte graphique

Quelques outils :
- Balsamiq Mockup ;
- iPlotz.

2. le user-story ou histoires d’utilisateur implique un besoin moins statique, 1 seul écran ne suffit pas. L’idée est de présenter un cas, un besoin, une problématique sur plusieurs écrans, dans une idée de séquences. Ce type de wireframe est beaucoup moins lié au graphiste, d’ailleurs la touche graphique y est beaucoup moins importante. On est plus proche de la couche métier du projet et ces outils sont plus destinés au client et au développeur. C’est pour moi une étape parallèle au wireframe « graphique », cet article n’en détaillera pas plus le fonctionnement.

Les gains d’un wireframe ?

Les gains sont multiples, en effet pour en arriver au wireframe, plusieurs briefs ont été réalisés. L’objectif final, les éléments à mettre en avant, l’ergonomie et la communication générale ont été débattus et travaillés. Le résultat n’en est que positif ! Imaginez si vous vous étiez lancés directement sur la maquette graphique, les changements a posteriori sont beaucoup plus longs et couteux.

2. Balsamiq Mockup ?

Ce logiciel possède une interface claire et intuitive, les différents composants sont très variés (environ 70 répartis en : formulaires, blocs, player vidéo, calendrier, tree view, nuage de tags, etc.). Il possède des fonctionnalités basiques mais très pratiques telles que les raccourcis clavier et la sélection multiples d’objets à la souris.

Il est possible de grouper les composants graphiques entre eux afin de les déplacer ensemble ou encore de les positionner l’un au dessus des autres, etc. Il est également possible d’inclure de véritables images, l’intégration au milieu de l’effet crayonné est étrange, mais peut s’avérer pratique dans le cadre d’un logo (cf. le cas pratique). Le logiciel inclut également une série d’icônes, dans un style crayonné, qui complète très bien certains manques de composants, notamment dans les boutons.

J’ai particulièrement apprécié dans le cadre d’un drag n’ drop le clip des objets afin de les aligner de façon horizontale ou verticale. Avec un peu d’entraînement on peut presque se baser sur des grilles, très utiles en webdesign, ce qui permettrait plus tard de faire l’intégration avec un framework CSS, mais je m’avance, nous verrons ceci dans un futur article…

Le point fort de Balsamiq Mockup est son rendu crayonné et monochrome qui permet de le détacher du rendu final. En effet le danger dans un wireframe est qu’un client l’imagine comme maquette définitive ou encore qu’il s’attarde sur des problématiques graphiques qui ne seront vu qu’en étape suivante.

La version desktop est écrite en Adobe AIR ce qui lui confère l’avantage d’être multi-plateforme.

Balsamiq Mockup n’est pas complètement exempte de défauts, j’ai eu droit à quelques plantages avec plusieurs mockups ouverts et comme je le précise ci-dessus, il manque encore quelques composants graphiques, notamment sur les boutons.

Un autre défaut est qu’il ne permet pas de faire des liens entre prototypes. En ce sens, Balsamiq Mockup s’arrête au rang d’outil de création de prototypes « graphiques », il ne permet pas de réaliser des scénarios / séquences d’écrans, ou plus communément appelé user-story (cf. ci-dessus).

3. Cas pratique : Lexik

Vous avez la chance, via cet article, de voir les premiers wireframes du futur site de Lexik.fr :

Quelques liens :
- une présentation du zoning et des wireframes chez pixenjoy.com ;
- le user-story version frenchies ;
- présentation de quelques outils en ligne de conception de wireframes.