Le but de cet article est de chercher plus loin dans les fonctionnalités de base proposées par Symfony pour l’élaboration de notre backend.

La Homepage

Proposer à l’administrateur l’affichage d’une page de listing d’un modèle, dès le login effectué, est bien sûr une mauvaise idée. Une page d’accueil doit être présente et peut présenter les différentes informations pertinentes et vitales pour l’administrateur :

Accueil du backoffice : Statistiques et accés

Dans cette capture, l’accueil permet dès l’authentification, de connaitre les différentes statistiques du site et d’avoir un accés direct aux actions redondantes mais nécessaires : Utilisateurs en attente de validation, Visualisation de messages suspects etc…

Pour aller plus loin, vous pouvez afficher certaines indications propres à la fréquentation sur votre site. Si vous possédez un compte Google Analytics, c’est l’occasion d’en profiter ! En effet, une API pour accéder à ses statistiques est disponible depuis peu, et devinez quoi ? Il existe un plugin Symfony pour l’utiliser : sfGoogleAnalyticsPlugin. Alors plus d’excuses pour ne plus proposer une page d’accueil efficace à votre client.

Un listing précis et concis

Par défault, Symfony propose un listing complet des différents champs de votre modèle. Cela est souvent beaucoup trop confus et non adapté pour les besoins d’un client :

Il apparait comme essentiel de sélectionner et de renommer les différentes colonnes de votre modèle que vous souhaitez afficher. De même, selon la complexité de votre objet, il peut être intéressant de fournir des informations « associées » : Pour un objet Article de Blog, il est pertinent d’afficher le nombre de Commentaires associés. Dans mon cas, j’affiche le nombre d’utilisateurs associés à un projet :

Concernant les valeurs, il est déconseillé d’utiliser des IDs. Ils apportent aucune information quantitative ou qualitative pour l’administrateur. De plus, il est préférable de créer une action pour les tâches répétitives. Cela simplifie grandement l’administration pour un client et on évite ainsi de l’envoyer directement sur les pages d’éditions.

La documentation de Symfony étant très complète sur ce sujet, nous allons continuer notre tour d’horizon avec les filters.

Les filtres au service de la navigation

Symfony permet à l’aide du générateur d’administration, de trier vos modèles en fonction de filtres spécifiques. Mais comme pour la partie précédente, les problèmes sont similaires : Trop de champs renseignables, souvent complexes et non traduits. Outre la documentation de Symfony qui vient encore une fois à notre aide, il faudra faire un tour sur cet article pour compléter la traduction des filtres sur le backend.

Mais la véritable force des filtres, c’est leur utilisation de manière transparente par le client. En effet, si on reprend l’exemple de notre page d’accueil, on propose un lien « 3 projets en attente » sensé rediriger sur les projets concernés.

Comment cela est-il possible ?

Tout simplement en créant le filtre qui nous permet de trier nos projets, dès le chargement de la page. La manière la plus simple est de passer nos filtres dans l’URL.

Mise en place

Il faut d’abord surcharger notre action index du module concerné :

    public function executeIndex(sfWebRequest $request) {
        if($request->getParameter('filter')) {
            $this->setFilters($request->getParameter('filter'));
        }
        parent::executeIndex($request);
    }

On vérifie si l’on passe un paramètre « filter » lors du chargement de la page. Le cas échéant, on applique les filtres renseignés.

Mon lien permettant de voir seulement les utilisateurs en attente de validation aura le routing :

@user_user?filter[is_active]=0

Pour mes projets en attente de validation, c’est la pratiquement la même chose, on indique en plus le type de l’argument.

@project_project?filter[state][text]=1

Pensez à bien regarder la structure de vos filtres en cas d’erreur.

Allez plus loin

Maintenant que vous savez filtrer directement à partir d’un lien, vous allez pouvoir vous servir de cette astuce autre part que sur la page d’accueil. Revenons sur nos listing. Nous avons vu qu’il était pratique pour le client d’afficher par exemple le nombre d’objet Commentaire associés à un objet Article. Nous sommes maintenant capables de rediriger directement vers les objets associés.

On ajoute une méthode d’affichage sur notre objet Article :

    public function getCountPositioning() {
        return link_to($this->getComments()->count(),'@comment_comment?filter[article_id]='.$this->Id());
    }

On retourne ainsi le lien contenant le filtre permettant de trier les commentaires en fonction de l’ID de l’article. Il suffit de modifer notre action index afin de correctement afficher notre entité HTML :

    public function executeIndex(sfWebRequest $request) {
        sfConfig::set('sf_escaping_strategy', false);
        if($request->getParameter('filter')) {
            $this->setFilters($request->getParameter('filter'));
        }
        parent::executeIndex($request);
    }

Voilà pour nos petites idées pour vous aider à parfaire votre back office. N’hésitez pas à parlez de vos astuces dans les commentaires.

Mise à jour

La désactivation de la stratégie d’échappement des caractères (sfConfig::set(‘sf_escaping_strategy’, false)) est utilisée pour éviter l’affichage des balises <a> obtenues depuis notre modèle. Cette méthode à deux limites : D’une part, elle est inhérente à certaines failles de sécurité provoquées par une injection de code malicieux (cf commentaire de @Niko) ; D’autre part, on perd l’avantage lié à notre MVC en faisant parvenir le lien directement depuis le modèle.

Il est alors conseillé de déclarer dans notre generator.yml l’utilisation des partials pour afficher nos liens filtrants :

display: [_countComments]

Il suffit alors de créer notre partial _countComments.php dans le dossier templates/ de notre module :

<?php echo link_to($article->getComments()->count(), '@comments_comments?filter[article_id]='.$article->getId());?>

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.