L’usage en production du plan du site

Pour de la production d’un site, comme son nom l’indique, un plan du site fait office de plan de site. Il constitue la structure, le squelette, l’arborescence des pages. Il est donc indispensable de le communiquer au plus vite aux développeurs afin qu’ils aient une idée de l’organisation mais aussi du volume.

Étant une représentation du site, ce plan, cette carte, du site permet aussi de suivre la production en notant les parties en cours de réalisation, finies, livrées ou à faire dans la version suivante. Il s’agit donc d’un document hautement stratégique pour la gestion de projet.

Bizarrement, je n’ai jamais vu une politique d’uniformisation de plan de site dans les agences que j’ai fréquenté. Je trouve ça étrange que des personnes dont le métier est de suivre des projets ne se soient jamais penchées sur les outils nécessaire à leur activité. Ma métaphore du chef de projet, guide de montagne/chef de cordée naviguant à vue (sans carte ni connaissance du terrain) prend toute son ampleur.

Les modes de représentations de plans de site

Nous avons différentes possibilités pour représenter un plan du site aujourd’hui.

1. Le tableur
2. La carte mentale :: xmind
3. La solution en ligne :: slickplan – Jumpchart
4. Une page HTML/CSS

Je vais vous parler de la quatrième solution qui me semble la plus pratique (même si elle peut être couplée avec une autre pour la phase de préprojet avec le client).

Réaliser une page HTML du plan de site

La compréhension de la manière dont fonctionne un CMS permet de se rendre compte qu’un plan du site peut être intégré dès le début de la réalisation du site.

A condition que le plan du site soit validé dans ses grands ensembles, il est très facile d’aller dans l’administration du site (CMS) et de créer toutes les pages correspondantes à ce plan du site. On crée tout simplement une arborescence. On a notre squelette dans le CMS.

J’irai plus loin, pour peu qu’on connaisse la technologie (Drupal, WordPress…) assez tôt, on peut se servir du CMS pour construire son arborescence. Reste la représentation visuelle me dirait vous. Rien de plus simple.

Un plan du site est une grande liste de page avec des sous niveaux (listes imbriquées). Je ne crois pas qu’il soit compliqué de générer l’arborescence d’un site en HTML de nos jours.

Réaliser la CSS du plan du site

Pour la mise en forme, rien de plus simple, prenons un petit fichier CSS qui va mettre en forme cette grande liste imbriquée.

Chez David Legglett, vous pourrez trouver cette fameuse CSS de mise en forme d’un Grand Sitemap.

Si vous avez le courage, vous pourrez aussi ajouter ce petit JS permettant de déployer/refermer des bouts d’arborescenses : jQuery Organisation Chart.

Gérer l’avancée de votre projet grâce à ce plan du site réaliste

Avec ce plan du site à jour et visuellement très compréhensible, vous pouvez imaginer ajouter différents paramètres pour gérer l’avancer de votre site.

Par exemple une page peut avoir différents paramètres (publié, dépublié, ou autres) ; ces paramètres peuvent permettre d’ajouter des classes correspondantes dans votre fichier HTML et ainsi de générer des couleurs : page en cours, finie, à faire en V2…

Conclusion

Une manière très simple de créer et générer un plan du site grâce à un CMS peut permettre d’avoir une vision claire, réaliste et à jour d’un site.

Articles similaires :

1. Le plan Besson et l’accessibilité
2. Construire sa page HTML sans ID ni Class
3. Ava 7 Patterns : des fonds de page pour site web
4. TYPO3 – exemple de site : Screenteam
5. Easy, un FrameWork CSS/HTML/JavaScript

L’apparition du concept de séparation

Durant la première guerre des navigateurs (dans les 90′s), face aux problèmes d’interopérabilités et d’homogénéités du code des sites web, le W3C s’est mobilisé afin de définir des standards. Pour gagner la bataille, il a défendu les technologies comme CSS et xHTML qui concernent pour l’une la présentation et pour l’autre la structure. c’est actuellement de cette manière qu’on code les sites.

Dans les années 2000, cette idée de « séparation » s’est affirmée dans la rédaction de la spécification xHTML 2. L’idée était de défendre une pureté fonctionnelle entre la structure (HTML), la présentation (CSS) et le comportement (JS). Sauf que…

Les couches ne sont pas vraiment séparées

Quand, on rédige une feuille CSS, on dispose de comportement comme :hover (changement de propriété au survol de la souris) ou encore :before & :after (ajout d’un élément dans le document avant ou après une zone de contenu).

Il s’agit donc d’1 élément de comportement & de 2 éléments de structure présents dans la CSS => la séparation n’est pas stricte.

Comment cela ce fait-il que les couches ne soient pas séparées ? Tout simplement parce que les constructeurs de navigateurs l’ont décidé, ce n’est pas (plus) un objectif. Ils pensent que cela n’a pas lieu d’être. Et les spécifications le prouvent ; xHTML 2 est morte.

La divergence

Prenons l’exemple d’un lien avec un effet visuel lors du survol de la souris. Vous avez le choix entre passer par la CSS pour un effet :hover et/ou utiliser une petite pincée de JavaScript pour la gestion d’un comportement plus complexe.

Avec un changement de couleur géré en CSS et un effet (une opacité par exemple) en JavaScript, le comportement du lien est spécifié dans deux couches différentes : c’est ce qu’on appelle la « divergence ». Ce lieu de gestion subtile de l’effet de survol par deux couches différentes.

Avec la logique de « séparation », on est dans le noir&blanc ; avec la logique de « divergence », il y a du noir&blanc mais aussi un peu de gris.

L’intégration n’est pas la collage grossier de différentes couches mais plutôt l’emboîtement subtile de plusieurs technologies (ce qui définit, à mon avis, le principe de l’artisanat).

Conclusion

L’idée de « séparation » a été indispensable pour la défense des standards du web. Cette idée a permis de passer outre les soupes de tags (HTML), les CSS ou JavaScript en lignes. Cependant, l’expérience montre qu’il existe des zones de chevauchements entre ces couches ; qu’on peut nommer « Divergence ».

Si on doit encore défendre les standards avec fougue, il est réaliste d’accepter ce concept de « divergence ». Accepter la tournure prise par les technologies du web, c’est aussi comprendre pourquoi un intégrateur n’arrive à exprimer ses difficultés, pourquoi il faut avoir codé pour les comprendre…

Encore une fois le métier d’intégrateur n’est pas simple. Il faut de l’expérience et de la rigueur pour dompter la « divergence ». Après quelques années, il sera compétent pour faire de la conception d’interfaces à partir de ces principes. C’est pour cette raison qu’il doit devenir concepteur.

Je vous laisse lire l’article en anglais, bien plus complet que celui-ci : The separation of structure, presentation and behavior is dead.

Une idée simple

A la maison de l’outil à Troyes, on peut y visiter une succession de vitrines présentant les outils relatifs à un métier. Dans mon cas, je me suis imaginé gimp à la place du marteau, textmate à la place de l’établi ou encore l’explorateur de fichier en guise de ceinture pour ranger les clous.

Et puis je suis tombé sur cette phrase :

Travailler sur des systèmes abstraits de grande envergure nécessite d’avoir l’ensemble dudit système en tête. Quelqu’un a un jour comparé ce processus à la construction d’une maison faite en cristal précieux. Dès que quelqu’un vous distrait, l’édifice s’écroule et se brise en mille morceaux.

J’ai regardé mon code, je me suis relevé et je me suis dit : « en fait, je suis quoi, un orfèvre ? un calligraphe ? ». Et pensant à un reportage sur les cathédrales diffusés il y a quelques semaines, l’idée m’est revenue qu’on pouvait effectivement nous cataloguer comme des artisans.

Ils étaient bien payés, respectés, valorisés.

On sait que l’artisanat était composé de corporations, de confréries ; la formation de apprentis passait par le compagnonnage ; on y respectait des maîtres (une autorité).

Un centre de formation

Pourquoi pas alors reproduire ce principe de maître/apprenti ? C’est une idée, bien entendu, il faudrait le faire à la sauce web et technologie numérique.

Sans y coller le côté pompeux de titres, grades, etc ; on pourrait imaginer, plutôt que d’attendre qu’un cursus professionnel se mette en place, établir un principe d’apprentissage à partir de niveaux de maîtrise.

Sur des périodes diverses, 2 jours, 3 jours, 2 semaines ; proposer des types de sites (des oeuvres) à réaliser sous l’assistance d’un maître (oui, qu’il faudra trouver des maîtres de la force). Contrairement au milieu d’apprentissage habituel d’agence dans lequel on joue avec le temps ; l’accent serait cette fois mis sur l’excellence, c’est-à-dire la mise en pratique de notions comme l’accessibilité, le référencement, la maintenabilité, l’interopérabilité…

Ce serait un moyen de réfléchir aux méthodologies de travail idéales pour la fabrique de sites web. Cela permettrait de sensibiliser certains, de perfectionner d’autres ou encore de se lancer dans des projets de recherche… tout est permis.

Je vous propose l’idée pour ceux que ça intéresse. Je réfléchis très sérieusement à me lancer dans la formation et à animer ce genre de lieu. Je me dis que plutôt que d’avoir une équipe de développeurs qui développent, avec un telle considération, on pourrait plutôt avoir des équipes dans lesquelles les intervenants seraient réellement mis en valeur pour leurs compétences.

A suivre…

La génèse

Une des première dans le genre (à ma connaissance) fut bien évidemment « Ben the bodyguard », dont voici la vidéo :

On se servira de ce genre de présentation pour mettre en avant un contenu scénarisé avec des étapes bien déterminées.

Le principe

Techniquement, comment cela marche-t-il ? On met en place une grande page, avec un décor statique (fond) et des éléments animés. On place dans cette page des ancres, comme autant d’éléments de votre scénario : étape 1, étape 2, étape 3… Puis à chaque ancre, on associe une animation (ou plusieurs animations).

Donc pendant que vous descendez dans la page, votre navigateur détecte des bornes (ancres), à chaque borne une fonction permet d’activer un événement. Visitez la page de Google green – Better web. Better for the environment..

Les plugins

Je vous propose de regarder deux plugins jQuery

1. jQuery waypoints :
Un plugin qui permet de détecter l’activation d’ancres et de pouvoir lancer un événément JavaScript de son choix. Peut-être utile pour du scroll infini, la détection de bas de page…
jQuery Waypoints

2. jQuery scrollorama :
Un peu plus fin, il pointe directement un élément et permet d’appliquer un événement d’animation sur cet élément. Il semble plus destiné à des effets visuels.
jQuery scrollorama

Articles similaires :

1. jQuery : 5 nouveaux plugins de novembre
2. jQuery Accessible RIA : fonctionnalités jQuery accessibles
3. Galerie d’images avec bxGallery sous jQuery
4. ColorBox, plugin lightbox pour jquery
5. jQuery : plugin ARIA

• Est-ce que mon client sait ce qu’il veut ?
• Combien de solution demanderont-ils ?
• Le contenu aura-til des chances d’arriver en temps voulu ?
• Mon client veut les source
• Au secours, mon client me poursuit ?
• Le projet finira-t-il un jour ?
• Le client vient de casser le site, il veut que je le répare
• Ils ont perdu leur mot de passe
• Payeront-ils un jour ?
• Trouver de bons conseils

Lire Bulletproof Web Design Contracts.

Articles similaires :

1. Quelques conseils pour une installation sécurisée de TYPO3

Le site exemple

Le site pris pour exemple présente un logo trop petit, une navigation peu claire, un colonnage trop constant… des objectifs non affirmés (tient ça me rappelle des trucs).

Les propositions

Quelles sont les propositions des différents groupes, faites pour cette page d’accueil :

• Devenir membre
• Appel au don
• Proposition d’un jeu pour se familiariser avec le produit
• Navigation explicative sur les objectifs du site

La conclusion

La proposition de différentes idées pour la refonte de cette page a permis de dégager de réels parti pris. Même si on ne peut pas se réduire à penser que chaque idée est une bonne idée ou que le cumul de toutes les idées peut favoriser l’optimisation de cette page ; le dialogue a été très porteur.

D’ailleurs bien plus que quand une seule personne se charge de la conception.

If one person in charge of this page only relied on their own ideas, we may not [be] able to achieve the highest level of success,”

Il est fort probable que la refonte d’une page laissée à une seule personne ne permette pas d’atteindre un succès optimal. Le web est collaboratif, il est possible que la conception des sites doivent l’être aussi.

Articles similaires :

1. TYPO3 : les avancées après le T3UXW09
2. WhiteHouse.gov : la maison blanche participe au développement de Drupal
3. Un FrameWork mobile, mb.ile
4. Un calendrier partagé dans Thunderbird

Il y a trois mois, nous avons décidé de refondre le FrameWork que nous utilisions pour notre tableau de bord ; tout à été refait du côté client grâce à node.js.

Ce choix a été dirigé face après la constatation que la structure LAMP (Linux-Apache-MySQL-PHP) était morte. Depuis une vingtaine d’années que cette structure existe, beaucoup de virages ont déjà été réalisés concernant les contenus, les protocoles, les serveurs ou encore les clients.

Nous pouvons dégager, d’ailleurs, trois âges du web :

1991-1999 : l’âge du HTML

La vision originale de Tim Berners-Lee du web fut celle d’une grande bibliothèque en ligne. Le web était défini comme un corpus de documents statiques, codés en dur, en grande partie formatés par le niveau de rendu des navigateurs clients.

Pour résumer, nous avions des documents statiques disponibles pour des clients statiques.

2000-2009 : l’âge LAMP

La période LAMP fut très lié à celui des bases de données. La conception du web n’était plus orienté sur les documents, mais plutôt sur les principes LAMP, ou similaire. C’est-à-dire, une série de gabarit HTML intégrant des données provenant d’une base de données.

Nous avions bien un contenu dynamique, mais toujours un client statique.

2010-?? : l’âge du JavasScript

Dans cette troisième décennie nous entrons dans l’ère du flux. La page web n’est plus une page. Le modèle basé sur l’objet document existe toujours, mais plus en tant que structure (fixe). Le DOM (arbre structurelle d’une page) est chargé dans la mémoire du navigateur et une partie de celui-ci peut être modifié à l’aide de JavaScript.

L’architecture LAMP est morte en raison dans la mesure où, désormais, peu d’applications proposent d’actualiser l’ensemble d’un page en réponse à un événement (demande utilisateur minime) ; il suffit d’actualiser une partie du DOM grâce à JavaScript.

Nous passons de l’âge du document (HTML), à celui de l’affichage d’un gabarit (LAMP), pour arriver à celui de l’envoie de données. Le rôle principal du server est de passer d’une application vers un client (JavaScript), en passant par un formatage de données (JSON), et insérer ce contenu dans le document, ou plutôt le DOM.

Le deuxième rôle du serveur est d’être à l’écoute des événements côté client (édition, message…) et de renvoyer une réponse correspondante.

Node.js correspond aux demandes qu’on peut faire à un serveur en 2010. Il est asynchrone et très rapide. Il utilise HTTP 1.1, garde les connections ouvertes, il peut gérer des centaines de connections.

Les données deviennent de simples paquets, JSON semble s’imposer pour leur transfert. Il s’agit d’un format géré nativement par node.js.

Le JavaScript nous rapproche du web qui ne se résume plus à la grande bibliothèque numérique, mais plutôt à un système nerveux numérique.

Articles similaires :

1. dygraphs JavaScript Visualization Library
2. Graphiques (Charts) avec JavaScript
3. Easy, un FrameWork CSS/HTML/JavaScript
4. 15 Carrousels d’images en Javascript
5. Calendrier d’insertion de date en JavaScript avec raccourci clavier

Le catalogue produit

Elle est belle ma centrale, elle fournit une électricité propre qui permet aux jeunes de s’éclater dans un appartement en plein centre ville. Tout comme pour le nucléaire ou tout autre secteur, l’appétence passe par une mise en scène élaborée destinée à mettre en valeur l’intérêt d’un produit pour un acheteur potentiel.

Encore sous l’influence du secteur de l’imprimerie, le print comme on dit, les équipes chargées de la relation client élaborent de superbes planches créations. On va y apposer les plus belles couleurs, de beaux effets, des alignements au pixel, des textes à la lettre. On insérera ces belles images dans une présentation dite « powerpoint » et on ira finaliser la conception dans les bureaux d’un client séduit par la beauté des visuels et la promesse de nombreuses options personnalisées.

C’est ainsi qu’on vend une voiture, objet sortit tout droit de chaines de production standardisées et aux options limitées et onéreuses. Éduqué à la lecture sur feuille de papier, le monde de la communication fonctionne sur ce principe plutôt simple, statique, jetable dans lequel un seul sens est sollicité : la vue.

La conception des usages

Parce que c’est le langage (a priori) que tout le monde comprends, les images, la phase de conception des usages reste basée sur ce principe de déclinaison de visuels. De cette manière, le client peu instruit sur les problématiques et règles de fonctionnement technique a la possibilité de faire évoluer ses idées au fur et à mesure.

Si on se restreint au domaine de la conception (d’interfaces) web, deux cas de figures : un dans lequel le client est moteur et où un graphiste va concrétiser les désirs d’un client sur une planche ; et un autre où l’agence est moteur et va faire des propositions, elles aussi sur une planche. Dans un cas comme dans l’autre, la méthodologie de communication et de conception reste basée sur les visuels, c’est-à-dire un moyen imparfait pour discerner et décliner l’ensemble des concepts à valider.

Tout au long du projet, les visuels constitueront la base de référence graphique et fonctionnelle pour l’ensemble des équipes de production. L’image catalogue statique, présentée selon une perspective délibérée, représentera l’objectif à reproduire.

L’intégrateur, seul au monde

Dans cette méthodologie, exclusivement tournée sur les images, l’intégrateur est le premier a avoir le produit en vrai devant lui et à l’observer selon son usage courant. Jusqu’à ce qu’il commence le projet, à aucun moment, le projet n’est sorti des perspectives construites pour une présentation « powerpoint ».

Pour remédier à cela, on a déjà évoqué de nombreuses méthodes comme la réalisation de wireframes, de maquettes, des schémas fonctionnels, la présence d’un responsable de l’ergonomie… tout cela évolue. Pourtant, la communication visuelle reste très prégnante.

Dans la cas d’une conception « classique », avec les visuels, entre la finalisation des créations graphiques et la livraison du site, un énorme trou noir dans lequel une partie des déclinaisons sont réellement intégrées et une autre partie fonctionnelle lourde doit être construite.

Comprendre que souvent un client se focalisera sur cette fameuse page d’accueil (la maison, une sorte de vitrine), une page intérieure et ne sera que très peu mis au courant de l’existence de sens de lecture, de cohérence de superposition de zones, de dynamisme de contenu, de messages d’erreurs, d’alternatives textuelles…

Autant d’éléments qui demandent une définition précise fonctionnelle dépendante des objectifs éditoriaux et pour lequel il n’y a que rarement de spécifications.

Loin de travailler dans une centrale, d’avoir la responsabilité d’une explosion nucléaire ; les intégrateurs se sentent parfois comme des travailleurs invisibles, eux aussi. Non intégrés à la phase de conception, considérés comme des exécutants, responsable de la conformité de la totalité d’une site et de la qualité du code… ils ont souvent complètement cernés et bitus.

Prenez soin de vos intégrateurs et faites les voir un peu la lumière. Victime de la communication visuelle qui ne correspond pas à leur besoin, il est nécessaire de changer de manière de discuter et de définir les projets.

Les publicité areva et edf, les événements du japon, la découverte de la réalité et de la merde derrière la carton pâte devrait nous inciter à changer radicalement les choses et à finir avec ce phénomène de cour et de faveur.

Articles similaires :

1. Shrink Pic, redimensionner les images à la volée lors d’un upload
2. Le gilet par balle de la négociation de contrat web

Lire Why Designers Should Learn Programming. Now.

Articles similaires :

1. L’ipad modifie la façon de coder les sites
2. CSS – Orienté Objet, ce qu’il faut savoir
3. La petite histoire de Mainframe
4. L’histoire des jeux videos
5. Tobias Stretch Reel I

Illustrator gère la création d’éléments vectoriels. Comme vous le savez, l’avantage du dessin vectoriel est de ne pas souffrir de perte de qualité lors du redimensionnement. Il est possible de zoomer à l’infini sur un élément sans perte de qualité. Autre avantage, les points sont définis selon leur position dans l’espace, ces positions peuvent être modifiées tout au long du projet sans aucune perte de qualité.

Le dessin vectoriel est bien pratique mais pas aussi précis que le dessin au pixel de Photoshop qui possède sa palette d’effets et de filtres pour la manipulation d’images.

Oui mais le pixel, c’est « has been », c’était tellement CSS 2.0 ; maintenant c’est le CSS 3, le canvas, le SVG, le vectoriel. Ce changement d’époque, Adobe l’a bien sentit en sortant un package pour Illustrator.

En utilisant CS5, les développeurs peuvent exporter une page qu’ils ont créé dans Illustrator vers une page web. La capture ainsi faite ne comprend pas l’ensemble des fonctionnalités d’Illustrator, afin pour les créateurs de pouvoir revenir en arrière et de faire des modifications sur la page initiale, a admis David Macy, mais il ajoute que cette fonctionnalité réduirait considérablement le temps de conception pour différentes plates-formes.

On avait vu le package HTML5 pour DreamWeaver avec la possibilité d’éditer du code pour différents interfaces (PC, mobile, tablet) avec les media query ; le add-on pour Illustrator doit permettre aux graphistes d’exporter leurs créations compatibles HTML5-CSS3 et de pouvoir les modifier, par la suite, à volonté.

Lire :

• Illustrator adopte HTML5
• Adobe Illustrator Goes HTML5
• Adobe Illustrator CS5 HTML5 Pack

Articles similaires :

1. Trousse à outils pour commencer HTML5
2. Exemples de structure HTML5
3. Les outils indispensables pour le HTML5 et le CSS3
4. Humble Finance: graphiques dynamiques avec HTML5
5. Le futur avec HTML5 par Bruce Lawson