Créer du contenu et mettre en place son site web avec un framework

Créer du contenu et mettre en place son site web avec un framework

Quelque soit le framework utilisé, Joomla, WordPress, Drupal, Spip, Typo3, CMS Made simple ou bien d’autres… les CMS nous permettent dans la majeure partie des cas de créer et de mettre en ligne très rapidement du contenu.
Seulement voilà, une fois encore, vitesse et précipitation ne répondent pas systématiquement à un gage de qualité. Bon, bien que tout puisse être discutable et que certains diront que produire un site de type blog ne nécessite rien d’autre que de pondre du contenu, prenons quand même le temps de cet article pour nous poser quelques questions et voir en quoi nous pourrions toujours améliorer le contenu de nos sites, simplement en préparant un minimum notre travail.

Définitions et objectifs du site

Avant toute chose, il est bon de reprendre de manière générale les grandes lignes des définitions et de la mise en place d’un projet de site web. Deux ébauches d’articles, Organisation et mise en place d’un projet de site web et Description d’un projet de site web, permettent déjà de pouvoir mettre en place une liste de points à aborder et à prendre en considération.

Nous pourrons retenir et préciser quelques points pour les propos de cet article

• Bien clarifier, les objectifs du site et la ligne éditoriale
• Définir la ou les cible(s) et les personnes s’y rattachant
• Savoir si le site sera une maquette ou directement un site de contenu

Architecture d’information

La prise en compte, et justement une attention particulière, de l’architecture d’information peut s’avérer très vite productive et porteuse d’intérêts multiples. En effet, il est fréquent de négliger cet aspect et de composer directement avec une arborescence qui peut parfois nous paraître intuitive. C’est bien souvent la meilleure manière de se retrouver rapidement face à des incohérences qu’elles soient de navigation ou encore de catégorisation…
Il est important à ce stade de réflexion de travailler en étroite relation avec les internautes de base à qui s’adresse ce site. Ce sont eux qui vont permettre de mieux définir l’ensemble du vocabulaire contrôlé et des regroupement de thèmes relatifs au domaine d’activité qui les concerne. Le recours à un tri de carte (ouvert ou fermé) peut éventuellement être employé afin de mieux définir non seulement la catégorisation du site mais également son étiquetage. Vous pouvez vous rapprocher de l’article d’Introduction à l’architecture d’information sur ce même site.

Étiquetage, labellisation et autres mots clés

Afin de pouvoir homogénéiser l’utilisation de certains termes tout au long des pages il est très important de travailler sur un vocabulaire contrôlé. Cela permettra non seulement de faciliter la lecture, la mise à jour, l’accessibilité ou encore le référencement du site.
Par exemple un acronyme écrit BMR dans une page et B.M.R dans une autre peut être un piège dans lequel il est facile de tomber. De même et toujours à titre d’exemple est ce que le mot volcanologie ou vulcanologie, ou alors volcanologie (vulcanologie)… bref… vous aurez compris qu’il faut homogénéiser l’emploi des mots forts et clés du contenu. Il est toujours bon de pouvoir composer cette liste dès les premiers travaux en relation avec le client et les utilisateurs cibles.
Afin d’affiner cette étape l’article Taxonomie, Thésaurus et vocabulaire contrôlé peut être d’une certaine utilité. Une fois générée, cette liste de mots clés et propre à l’univers du site en cours de développement pourra être utilisé de manière multiple :

• Pour nommer les rubriques et éléments de menus
• En injection directe dans le contenu des articles
• En nommage de dossiers, nom de classe CSS, ou autre éléments de code
• Comme méta données placées au cœurs des fichiers médias
• Pour alimenter glossaire, index, FAQ ou autre éléments de recherche par mots clés

Outils, technologies et langages

Très rapidement il va nous falloir définir quelques éléments de technologies à utiliser et à commencer par le type de framework sur lequel nous allons nous appuyer (log, CMS, Wiki,…), puis ensuite sur quelle solution ou versions… WordPress ? Drupal ?… Joomla ? 1.5?, 1.6 ?… 2.5 ???. Parfois le choix est imposé par le client car celui-ci, ou un de ses partenaires, utilise déjà une application basée sur une solution particulière. Parfois le choix peut être purement subjectif et relatif à une préférence personnelle…
Dans la majeure partie des cas il est conseillé de s’appuyer sur une réponse à un besoin qui soit pris en compte par l’outil choisit et dont les éventuelles extensions seront compatibles. Un petit tour du coté des forums spécialisés ou du site CMSMatrix peut s’avérer intéressant.
Un autre élément à prendre en compte va être le type de DOCTYPE que nous allons utiliser, HTML 4.01, xHTML 1.0 ou HTML5. Si les deux premiers ne portent quasiment que sur la propreté du code HTML employé, le dernier lui va engendrer non seulement une prise en considération forte des navigateurs cibles, et des adaptions qu’il en découlent, mais également sur le panel de balises structurelles et sémantiques qui sont à disposition.
Il peut également être envisagé dans un premier temps de travailler en HTML 4.01, ou xHTML 1.0, et de préparer le balisage en usant de <div class= »header »> en lieu et place de <header> ce qui peut permettre une montée plus douce vers une bascule sur HTML5.

Structure des pages

L’architecture d’information, ne doit pas être réduite à une simple catégorisation et labellisation du site de manière globale. Bien au contraire, il faut également prendre en compte une granularité plus fine à commencer par la structure de la page elle même.
Sa composition et son découpage en zone de fonctionnalité et d’affichage; en tête, navigation, pied de page, contenu… puis continuer en détaillant la moindre structure d’information présente comme les notes avec leur titre, sous titre, chapeau, lien en savoir plus, citation éventuelle, illustration… ou encore les encarts de contenu qui peuvent se décliner en autant d’éléments que de contexte…
Bref la description de nos pages peut s’avérer devenir un véritable travail de découpage, d’organisation, de structuration, et ce travail n’est après tout que la continuité du premier travail effectué sur l’architecture d’information.

Dans un premier temps, la page peut elle même être découpée en divers contexte :

• Contenu textuel, pages de base et de contenu
• Catalogue produit
• Fiche d’évaluation ou de présentation
• Détails d’information
• Sous navigation et menu contextuel
• Formulaires de communication ou de retour d’information
• etc…

Chacun de ces contextes devra être nomenclaturé et architecturé sous forme de balises HTML. En partant du sectionnement <section>, <article>, <div> ou encore <span>, en passant par les menus d’entêtes <h1>, <h2>…. intégrant la finesse de la granularité de l’information, les éléments de navigation primaire et secondaire <nav>, <ul>… jusqu’aux éléments de description de contenu <aside>, <blockquote>, <q> et autres balises pouvant définir de manière à la fois structurelle et sémantique le contenu des pages.

Donc dans un second temps la granularité de découpe peut définir divers sous-éléments composés de :

• Divers niveaux de titre
• Description courte ou longue, divers niveaux de détails
• Référence en citation courte ou longue et liens complémentaires
• Illustrations et galerie
• Contenu principaux et assimilés…

Gardons à l’esprit que grand nombre de sites web basés sur une architecture de CMS ou de blog, déroulent leur contenu de manière linéaire sans baliser le moindre aspect du contenu qu’ils déversent, juste des titres et des paragraphes… Aucune citation, niveaux de détails, liens contextuels, encarts…. Pensons à ne pas commettre les mêmes erreurs, et pensons à ajouter à notre back office un éditeur HTML digne de ce nom pour nous aider à aller plus loin…

• En commençant par utiliser les deux lignes de l’éditeur par défaut de WordPress
• En musclant un peu l’éditeur par défaut de WordPress
• en utilisant un autre éditeur interne par exemple
  • foliovision
  • CKEditor
  • JCE Editor
• N’hésitez pas à googler sur le sujet et à nous faire part de vos préférences

Accessibilité

Trop souvent ignorée, l’accessibilité des sites devrait devenir un des éléments majeurs de nos préoccupations en tant que développeurs intégrateurs. N’oublions pas que se pencher sur cette problématique c’est permettre à tout un chacun, et donc au plus grand nombre, d’accéder de manière confortable à l’information que le site distribue.
De même, au niveau de l’optimisation des contenus pour le référencement, les sites qui sont accessibles, seront forcement mieux visités par les moteurs de recherche et de ce fait, à contenu équivalent, auront plus de chance d’être mieux positionnés. Dans les deux cas c’est que du bon. Donc en avant, accessibilisons!
L’article « Introduction et notions d’accessibilité » encore en cours d’écriture, devrait être publié prochainement… si cela n’est pas le cas lorsque vous lirez ce contenu, n’hésitez pas à nous le rappeler. En résumé et bien que l’accessibilité soit d’un aspect très volumineux et engage un grand nombre de prises en compte, nous pouvons dégager une liste (non exhaustive), d’éléments majeurs pouvant figurer dans l’intégration de nos contenus de CMS.

Points à prendre en compte

• Les documents téléchargés (PDF, type Word, Tableurs, etc…) se devraient d’être accessibles
• Les éléments multimédias, images, animations, vidéos doivent diriger vers un contenu alternatif et éventuellement proposer un sous titrage
• Si l’identité visuelle n’est pas optimisée, il est bon de prévoir une feuille alternative accessible depuis le navigateur
• L’ensemble des balises structurelles doivent avoir recours à l’attribut aria-role
• Les formulaires doivent permettre une saisie complète sans l’utilisation de la souris
• La structure des pages et du site doit être optimale, pensez aux lecteurs d’écrans

Optimisation pour le référencement

Certes, il n’est pas possible de résumer en quelques lignes les principes d’optimisation de pages en vue d’un meilleur référencement naturel, mais il est possible déjà d’en fortifier quelques base élémentaires. Surtout, si l’architecture du site et la structure des pages ont été optimisés, une grande partie du travail est déjà réalisée.
Récupérons le document du vocabulaire contrôlé, et établissons une liste parallèle de mots et expressions clés que nous souhaiterions retenir. Munis de ces deux listes, il faut maintenant s’assurer qu’un certains nombres de points soient pris en compte . Pour cela, et page par page, une liste de deux ou trois mots clés des plus appropriée va être retenue. Le référencement est une affaire de pages et non de site.

Vérifier pour chaque page que :

• Les titres de page, balises <title> et principales balises de header <h1>, <h2>… contiennent ces mots ou expressions clés
• Ces mêmes mots clés devront être également utilisés dans des balises d’emphases <em>, <strong>, <small>…
• Un certains nombres de liens utilisant ces mots clés devront pointer vers des pages externes, ou internes, au site et de même des pages externes, ou internes, au site devront pointer vers cette page. Attention à ne pas tomber dans de l’échange de liens qui peut au contraire nuire à un bon positionnement.
• Il faut s’assurer que l’ensemble des abréviations ou acronymes contenu dans la page sont correctement balisés en <abbr> et que leur attribut title est bien renseigné.
• Bien que pour l’instant les moteurs ne s’appuient pas sur les balises <meta keywords> cela ne coute rien de les renseigner, et surtout de préciser avec un texte court la balise <meta description> qui elle est souvent utilisé par les moteurs pour remplir le snippet.

Lorsqu’un grand nombre de pages utilisent ou font référence aux mêmes mots et expressions clés, il est bon de prévoir des pages d’atterrissage afin de concentrer les mots en un points et non pas de les édulcorer dans la masse du site.

Le site doit il être responsive ?

La question majeure a se poser sur la cible utilisateur, va être basée sur le type d’appareil utilisé pour naviguer sur ce site. En clair, est ce que les appareils mobiles doivent ils être pris en compte pour afficher le contenu ?
Cette réponse influera en grande partie sur le choix et la mise en place du template mais dans un premier temps au court de cette rubrique uniquement dédié à l’aspect responsive il y a déjà quelques éléments à prendre en considération et sur lesquels il faut se positionner.

Responsive ou non ?

• Bien s’assurer qu’il s’agit d’un site web mobile et non pas d’une application web mobile
• Les contenus sont ils identiques ou différents en fonction de la plateforme ? En clair devra t on jouer sur l’affichage / masquage de certaines zones ou bien les contenus HTML sont ils distincts ?
• Une approche mobile first est elle adoptée ?
• Prendre en considération l’ensemble des multimédia (image, vidéo, animation…) de manière réactive
• Bien s’assurer que des unités de mesures proportionnelles soient employées dans les CSS, em, rem et %

Amélioration de l’interface utilisateur ou UX Design ?

Qu’il s’agisse d’un site responsive ou non, il existe un grand nombre d’amélioration concernant l’expérience utilisateur qui doivent être pris en compte.
Cette approche à la fois d’ergonomie et d’utilisabilité doit placer l’utilisateur au cœur de ses préoccupations. Non pas une représentation de l’utilisateur sous forme de personas, mais bel et bien faire appel à de vrais utilisateurs et si possible avec de vrais rencontres présencielles et non pas au travers de visioconférences. L’intérêt est de pouvoir ainsi constater la manière de naviguer, d’accéder aux services, d’utiliser le site…. que les utilisateurs adoptent.
Plusieurs travaux sur l’utilisabilité ont été menés par l’incontournable Jacob Nielsen et son site useit, il existe également une mine d’information sur le site usability.gov. Vous trouverez également de nombreuses sources de publications en line qui abordent l’UX Design de manière plus large en incluant également l’objet plateforme de navigation. Smashing magasine réserve une rubrique entière sur le sujet, UX Magazine ou UX Booth centralisent également un grand nombre d’information.
Attention si le site s’oriente largement vers la distribution à destination d’appareil mobile de garder une réflexion qui respecte le ‘Finger-friendly design’.

Template sur mesure ou personnalisation d’un template ?

A bien y regarder l’étape, ou du moins la prise en compte de l’affichage et de visuel n’arrive que maintenant… c’est à dire bien après que le projet ait été architecturé, structuré, optimisé, réfléchi, liquéfier et rendu utilisable ….
Cela peut paraître bizarre, mais très souvent lorsque quelqu’un parle d’un site, cela se passe d’entrée de jeu autour d’une interface à la Photoshop… donc un peu comme si tout ne passait uniquement que par le visuel… et c’est parfois, pour ne pas être trop pessimiste, là l’erreur.
Ne tombons donc pas dans le piège d’un site qui se veuille avant tout esthétique. L’un n’empêche pas l’autre, mais le travail de réflexion sur le contenu et son architecture passe avant, le visuel ne venant qu’au dernier moment pour accentuer et mettre en valeur certains points de l’interface utilisateur.
L’ensemble des étapes précédentes devrait donner lieu à la mise en place d’un prototype. Chaque étapes aura affiné ce prototype en utilisabilité, en ergonomie, en architecture et structure, et se sera nourri d’expérience utilisateur… bref… le prototype donnera alors les grande lignes de ce que l’on recherche comme modèle d’affichage et de visuel. A coté du bon vieux papier stylo ou de la méthode du scrapbooking, les outils de prototypage sont nombreux et parmi les grands classiques on retrouve :

• Omnigraffle
• Fireworks
• Axure
• Balsamiq mockups
• Microsoft Visio
• Invisonapp

Il ne nous reste plus qu’à mettre en place le template… La principale question est alors… hem, doit-on créer un template depuis une copie blanche, doit on récupérer un template qui réponds plus ou moins à nos objectifs et l’adapter au mieux, ou doit-on partir du template de base du framework (JA-Purity pour Joomla, Twenty Ten pour WordPress… etc…) et construire le notre.
La question trouvera réponse au cas par cas dans l’une ou l’autre des possibilités. Il existe à ces propos quelques tutoriels très intéressants sur la réalisation de templates, notamment celui de Françis Chouquet, Créez votre thème WordPress de A à Z, ou celui de Cédric Keiflin, Tutoriels pour les templates Joomla! 1.6.
Enfin notez le tout nouvel article Create a responsive, Mobile first WordPress theme de Ellen Bauer sur Smashing.

Utilisation de plug in ou AJAX à la sauce perso !

Enfin il se peut qu’une fonctionnalité nécessaire à notre projet de site ne trouve pas de solution tip top parmi la panoplie généralement très étendue des plug in gravitant autour des divers frameworks. Le premier réflexe serait d’en développer un.
Si cette tâche peut s’avérer abordable pour certains, il n’en reste pas moins que le développement d’un plug in ne peut pas être pris à la légère afin de garantir une bonne évolution dans le temps et une bonne compatibilité avec les évolutions futures du cœur du framework.
En fonction des besoins, il est parfois possible d’injecter directement du code PHP au sein d’un article, ou bien d’avoir recours à un bon vieux XMLHttpRequest, ou tout autre approche similaire s’appuyant sur jQuery, Mootools, Dojo, Prototype… etc… également injecté au sein d’un article, afin d’ajouter certaines fonctionnalités de présentation ou d’interaction à nos contenus.
Afin de pouvoir interpréter ce code placer dans les articles les frameworks proposent toujours un plug in, qui prend en compte cette possibilité. Par exemple Code Sourcerer chez Joomla ou Exec-PHP du coté de WordPress. De ce fait, il a été plus simple et plus rapide de développer le tableau de Livres et Magasines du site de Puce et Média en utilisant cette méthode, plutôt que de développer un plug in adapté.

Nature du contenu

Enfin la dernière question concerne le remplissage du site de contenu… Le client nous a t-il fait parvenir des éléments, lui avons nous donné un accès au back office pour que de manière simultanée et progressive du contenu soit saisi… ou alors allons nous devoir faire appel à du contenu de substitution afin de rendre la maquette utilisable.
Plusieurs alternatives sont possibles… dans le cas de texte et images de remplissage il faut se tourner vers des images libres de droits si possible gratuite, et du bon vieux Lorem Ipsum. Attention, malgré l’aspect fictif du contenu, il ne faut pas négliger les étapes d’optimisation en accessibilité, structure et référencement.

Dans le cas ou du faux texte et des fausses images devraient être utilisées… voici quelques liens qui peuvent être utiles :

• Lorem Ipsum Generator
• Joomla extensions
• Wordpess extensions
• Free photos
• Open Photos
• Free images
• PD Photos
• Photo Edu

Et enfin la mise en ligne

Bien que cet aspect soit traité en fin de parcours, il est préférable d’user d’une adresse de test en ligne bien avant afin de permettre à l’équipe de participer à distance, de faire intervenir le client pour un éventuel début de remplissage, de tester le bon fonctionnement et l’utilisabilité générale… bref d’anticiper toutes les étapes qui peuvent être longues et fastidieuses.
Il existe diverses solutions d’hébergement qui permettent de manière gratuite de pouvoir déposer et utiliser ces contenus, voici quelques liens qui ont retenus notre attention, et sur lesquels quelques applications sont actuellement toujours en cours de tests et d’évaluation….
Attention certaines solutions d’hébergement gratuits nécessitent une mise à jour régulières des contenus pour éviter que les robots contrôleurs ne retirent votre site de leurs serveurs.