Archives pour la catégorie Guides pratiques

Les guides pratiques s’inscrivent dans une logique d’articles rédigés pour conserver une traces des erreurs rencontrées au cours des projets que lesquels j’ai travaillé.

HTML5 expliqué à mémé – part 1

Ma grand-mère me demande souvent « mais c’est quoi déjà au juste ton métier ?« . C’est vrai, expert web front-end, développeur front-end, architecte web, intégrateur … même moi j’ai du mal !

Alors j’ai pris mon plus beau clavier, et j’ai rédigé une série de billets que je pourrais relire à grand-mère et qui pourraient accessoirement, cher visiteur, vous intéresser !

Commençons.

Comment parler des métiers du web, et plus généralement du web  sans parler d’HTML ?

HTML est un langage (en l’occurrence, de programmation). C’est grâce à lui, chère grand-mère, cher lecteurs que vous pouvez lire ces lignes de textes en ce moment même, que vous pouvez aussi cliquer sur des liens, de voir des photos ou des vidéos … il permet aux navigateurs de structurer la présentation d’une page web. C’est donc grâce à ce langage, que les navigateurs sont capables d’afficher des textes, des images, des vidéos, etc…

Mais avant d’aller plus loin dans les explications d’HTML, j’aimerais juste faire une aparté  sur les navigateurs. Pour naviguer sur le web, vous avez besoin d’un logiciel qui vous permet de le faire (Internet Explorer, Firefox, Chrome, Opera, Safari …)  avec l’avènement du mobile, aujourd’hui nous « consommons » le web de partout (boulot, métro  dodo … ha oui, plage aussi … comment ? ailleurs aussi ?? De partout quoi !). Il y a donc également un navigateur sur les mobiles … mais pas que ! En effet, sur les terminaux nomades (les Smartphones et les tablettes quoi …) il y a les fameuses « Applis » qui (pour la plupart) NE SONT PAS des sites web. Facebook par exemple, son application pour mobile, est un outil complètement différent de la version de Facebook que l’on peut voir sur l’ordi de son bureau. On dit que les applications mobiles sont développées en code natif, elles ne sont pas « lues » par le navigateur et ne sont donc pas en HTML5

Si j’insiste la dessus, mémé, c’est parce que beaucoup de gens confondent Responsive Design et application native. L’application native, c’est comme le logiciel qu’on installe sur l’ordi pour rédiger des documents, classer des photos, écouter de la musique, surfer sur le web ! … Un site en responsive design c’est simplement un site parfaitement lisible sur un écran riquiqui ! Et consultable depuis un mobile via un navigateur ! Il y a des exceptions bien sur, il existe des applis en HTML5, mais là ma petite grand-mère, faut que je simplifie un peu.

Reprenons sur HTML …

HTML fonctionne par des jeux de “balises” imbriqués ou en vis à vis, un peu à l’image des legos de notre enfance. Chaque élément qui compose une page web est encadré (ou est représenté) par un jeu de balise correspondant à sa signification. Par exemple pour les titres, HTML fournit un jeu de balise permettant de déterminer la position hiérarchique d’un titre ou d’un sous titre. Ce sont les balises allant de <h1>à <h6>

<h1>étant la position la plus haute de la structure hiérarchique. Historiquement, ce sont les balises les plus importantes car elles déterminent l’ordre d’importance des éléments d’une page web

Ex :
<h1>Titre</h1>
<h2>Sous-titre</h2>

HTML fournit un large panel de balises permettant de donner un sens, que l’on qualifie de “sémantique HTML” à une mise en page.

  • Pour un paragraphe de texte, nous utiliserons les balises <p>,
  • pour les titres, nous l’avons vu, nous utiliserons les balises  <h1> à  <h6>,
  • pour les images  <img>,
  • pour des liens  <a>,
  • etc…

L’imbrication des balises html, permet ainsi de créer des pages web complète et complexe. Une image (<img>) peut-être encadrée d’une balise de type lien (<a>) qui elle même peut-être à l’intérieur d’un texte qui sera encadré d’une balise <p>

Ex :
<p>
<a href= »lien.html »>
<img src= »image.jpg » />
</a>
blabla bla …
</p>

La fondation Mozilla, dans un souci de rendre HTML plus simple d’utilisation, met à disposition de tous : Thimble, un outil en ligne pour se familiariser avec l’html (en anglais). Cet outil se veut avant tout pédagogique, cependant il est tout à fait possible de créer une véritable page web, de l’héberger sur les serveurs de Thimble et de récupérer un lien unique permettant de diffuser votre page. (Cher lecteur, pour débuter ou uniquement pour comprendre rapidement ce qu’est HTML, n’hésitez pas à tester cet outil.)

Structurer le contenu, pas le “looker”

HTML permet donc aux navigateurs d’afficher une mise en page voulue, cependant il n’est pas fait pour faire de la représentation graphique (tout du moins dans ses dernières versions). Il permet de structurer la page, mais ne doit pas être utilisé pour “looker” celle-ci. L’aspect visuel d’une page web est à confier à CSS, Cascading Style Sheets, ou feuille de style en cascade. Mais nous verrons CSS plus tard… c’est une autre histoire.

A présent que nous comprenons un peu ce qu’est html intéressons nous à son histoire

Sir Tim Berners-Lee  »l’inventeur du web » a développé la première version d’HTML à la fin des années 80, il répondait ainsi au besoin d’un langage simple permettant de structurer et créer des pages web qui afficherait des textes, mais aussi des images et d’autres types de fichiers multimédia.

Note : Je te dis ça comme ça, mémé, mais le web n’est pas Internet !

Le web est la couche graphique utilisant un des protocoles utilisé par Internet. Berners-lee a donc créé ces premières interfaces graphiques en se basant sur HTML.

Pour bien comprendre l’importance qu’a eu l’invention du web, il faut se rappeler qu’a cette époque, Internet n’était utilisé dans le monde que par des informaticiens au fait de technologies balbutiantes et tout en ligne de commande ! L’invention du web à tout simplement permis à tous d’avoir accès aux informations présentées de manières claire, compréhensive et structurée. HTML de son coté s’est donc naturellement épanoui durant cette période de forte croissance pour le web.

Ça va se compliquer un peu, il va falloir suivre …

Le langage HTML a connu 4 versions majeures durant les années 1990-2000. Le web évoluant très vite, le W3C (« l’académie Française » du web), organisme chargé de rédiger les spécifications du langage a décidé de faire évoluer HTML vers xHTML. HTML étant jugé trop laxiste il convenait aux yeux du W3C de rigidifier le langage sur une base plus solide : XML (d’ou le x … mémé ? je t’ai perdu ? … ha non, reprenons …). C’est ainsi que html 4.0.1 est la dernière version en recommandation encore en vigueur aujourd’hui. La branche xHTML a connu de son coté 2 version majeures : xHTML 1 et xHTML 2.

Durant les années 2000, il fut décidé que la future norme d’HTML serait xHTML 2.0, en 2004 certains membres du w3c et de développeurs de navigateurs trouvant qu’xHTML  était trop rigide (sic !), ont décidé de fonder un groupe de travail pour travailler sur la version future d’HTML, le WHATWG.

C’est ainsi que durant 2 ans le w3c continuait à travailler sur xHTML tandis que le WHATWG sur la nouvelle version d’HTML (la 5 en l’occurrence, oui, oui d’où « HTML5″). Finalement, fin 2006 le W3C laissa tomber xHTML, et décida de partir sur le travail du WHATWG pour établir HTML5 comme futur standard pour la création de page web. Les deux organismes ont ainsi travaillés ensemble à la définition des spécifications du langage. A l’heure ou j’écris ces lignes le WHATWG vient de décider de continuer à travailler sur HTML seul de son coté, afin de ne plus être ralenti par les processus de validation du W3C.

Pour simplifier (heu…)

HTML se dirige pour être un langage vivant, plus de numéro de version, juste de nouvelles fonctionnalités. C’est plutôt une bonne chose dans le sens ou cela va simplifier considérablement son approche (syntaxe simplifié, on oubliera, html(x), xhtml(x), une seule spécification,…). Mais aussi c’est aussi une mauvaise chose, car sans numéro de version, pas de recommandations définitives et donc un support aléatoire des fonctionnalités par les navigateurs.

En attendant, HTML5 est la norme actuelle pour tout site web qui se respecte. Le status de recommandation pour html5 est prévu pour 2014.

Note : Mémé je te le dit : si ton navigateur fétiche ne supporte pas une fonctionnalité d’HTML5 exige une alternative pour ton navigateur(bugtrackers, prestataire, cousin qui fait des sites…).

… Tu comprends un peu mieux mon métier ma petite Grand-Mère ? Non ? … pas grave je suis sur que d’autres apprécieront :)

Si le sujet vous a plu, continuez la lecture : HTML5, raconté à mémé – part2

Github

Aujourd’hui, petit détour sur github pour utiliser ce gestionnaire de version aux abords pas évident.

1ère étape : créer son compte sur github puis créez un dépôt qui servira pour stocker notre projet en ligne.
2ème étape : installer Git sur son poste (sous windows) http://git-scm.com/download, cela permettra d’utiliser un terminal pour la ligne de commande.
3ème étape : se rendre dans le répertoire en local qui contient le projet puis clic droit le repertoire et cliquez sur « Git bash here ». Cela aura pour effet de lancer un terminal pointant directement dans le repertoire du projet.

Voilà pour le principal en préparation. Maintenant passons aux différentes commandes possibles pour gérer son projet avec Github.

1) git init // pour créer le dépôt en local
2) git add . // ajouter le repertoire courant
git add *.php // ajouter tous les fichiers php dans le repertoire courant
git add index.php // ajouter le fichier index.php
3) git commit -m « Initial commit » // le -m permet de spécifier directement en ligne de commande le message, sinon un éditeur s’ouvre
3 bis)git commit -a // pour pousser les modifs dans le dépôt
4) git remote add origin git@github.com:bachkoutou/test.git // pour mettre en ligne sur github
5) git push origin master // on met à jour !

Cet article est en cours de rédaction, merci de votre clémence :)

réf: http://www.berejeb.com/2009/10/apprendre-a-utiliser-git/

Guide pratique d’une intégration réussie – les couleurs

Rappel : les guides pratiques d’une intégration réussie concernent le travail d’analyse d’avant projet, et de la partie conception/réalisation de la maquette graphique. Ils sont destinés aux intégrateurs, aux graphistes et aux clients.

Contraste

La palette de couleurs est généralement le fruit d’un travail créatif sur une maquette. Et à fortiori, elle peut être très subjectif. Cependant dans la cadre d’un projet pour les administration, collectivités et autres services publiques, il est obligatoire de respecter le « Référentiel Général d’Accessibilité pour les Administrations »  ou le RGAA (voir cette autre billet pour les aspects sur l’accessibilité). Celui-ci stipule en autres (concernant les couleurs, évidement) que si le rapport de contraste entre la couleur du texte et celle de son arrière plan est supérieur ou égal à 4.5, le test est validé, sinon le test est invalidé (se référer au guide pour plus de détails).

La solution :

On peut lire sur le réferentiel (1.4.3.) : « rendre perceptibles les contenus visuels indépendamment de la capacité à percevoir les contrastes de couleurs. ».  Plus facile à dire qu’a faire !  déjà il faut connaître ce fameur rapport. Pour cela il existe heureusement des outils : Contrast Analyser 2.2, Colour Contrast Analyser 1.5 . A défault d’avoir de réelle solution, il convient d’une part de demander en amont au webdesigner de respecter un rapport de contraste défini dans le RGAA, et d’autre part de bien vérifier ce point lors de la validation par le client.

Guide pratique d’une intégration réussie – l’orthographe

Rappel : les guides pratiques d’une intégration réussie concernent le travail d’analyse d’avant projet, et de la partie conception/réalisation de la maquette graphique. Ils sont destinés aux intégrateurs, aux graphistes et aux clients.

Orthographe

Il arrive sur les maquettes proposés par le graphiste que les titres (par exemple), soient définis en tout en majuscule, tout en minuscule ou une fois sur deux une majuscule en début de mot.

La solution :

Il faut uniformiser et faire valider le principe par le client. Soit on commence avec les majuscules … soit sans ! Il convient de bien vérifier l’orthographe sur la maquette.

Guide pratique d’une intégration réussie – tailles et dimensions

Rappel : les guides pratiques d’une intégration réussie concernent le travail d’analyse d’avant projet, et de la partie conception/réalisation de la maquette graphique. Ils sont destinés aux intégrateurs, aux graphistes et aux clients.

Les photos plein pot en background

Attention au poids ! Une maquette reposant sur le principe d’une image de fond est souvent maquetté sans anticiper les différentes tailles d’écrans, d’ou un soucis de mise en page éventuelle lors de l’affichage sur le navigateur.

Solution en plusieurs points :

  • Centrer le visuel sur le contenu puis préparer le fondu vers un aplat ou une transparence sur une couleur de background
  • Agrandir le visuel selon la taille de l’écran. Attention cependant aux pages à fort contenu qui risque de s’étaler verticalement et qui du coup engendrerais un agrandissement trop important. Prévoir par exemple un degradé vers un aplat
  • Prévoir un jeu graphique quand l’écran est plus grand que prévu, par ex un background à motif.

Guide pratique d’une intégration réussie – les menus

Rappel : les guides pratiques d’une intégration réussie concernent le travail d’analyse d’avant projet, et de la partie conception/réalisation de la maquette graphique. Ils sont destinés aux intégrateurs, aux graphistes et aux clients.

Ombre portée

Il est tentant de mettre de jolies ombres portées sur les sous menu. Mais la réalisation de ces « détails » graphiques est très complexe

Solution :

Il est possible en css3 de mettre ces fameuse ombres portées sur des éléments html. Mais je n’ai jamais essayé sur des éléments li de sous menu.

Guide pratique d’une intégration reussie – les formulaires

Rappel : les guides pratiques d’une intégration réussie concernent le travail d’analyse d’avant projet, et de la partie conception/réalisation de la maquette graphique. Ils sont destinés aux intégrateurs, aux graphistes et aux clients.

Les fonds de formulaires

La gestion des éléments de formulaire tel que input, textarea, select… au sein d’un element form(padding, margin, position,…) et d’un navigateur à l’autre il est parfois compliqué de garantir une taille fixe.

La solution :

D’une manière générale, toujours envisager l’étirement d’un formulaire, si par exemple le fond du form est un dégradé, prévoir la zone d’aplat pour l’étirement. Ainsi il sera également possible d’utliser un fond unique pour tous les form du site.


Les liste déroulantes

Les listes déroulantes sont interprété différements d’un navigateur à l’autre (plus de détails). Si l’on fixe une largeur fixe à un select, sous IE, les éléments de la liste seront tronqués à l’affichage.

La solution :

Penser au contenu du select, si sa largeur est fixe il faut être sur que son contenu ne dépassera pas cette largeur. Il faut donc de préférence permettre au select de pouvoir s’étirer horizontalement. On peut aussi envisager d’utiliser du JavaScript pour remédier au problème.


Les case à cocher et autres boutons radios

Il n’est pas possible de looker ces éléments. Il font parti du système d’exploitation et ne sont donc pas modifiable (plus de détails).

La solution :

remplacer en javascript ces éléments par des éléments html personnalisable, comme des span ou div. Javascript se chargeant également de les faire réagir comme des champs normaux. Exemples sous mootools


Le bouton valider

Il est trop souvent oublié. En soit ce n’est pas réellement grave, ce qu’il l’est plus ce qu’apriori le designer n’a pas réfléchi au traitement et aux retours de traitement du dit formulaire.

La solution :

designer ce fameux bouton et surtout maquetter le cycle complet de traitement du formulaire et des retours d’informations. (voir ci-dessous)


Exemple cycle de traitement d’un formulaire :

  1. Affichage du formulaire
  2. remplissage du formulaire
  3. validation d’envoi
  4. correction du formulaire si nécessaire
  5. validation d’envoi
  6. affichage des retours de confirmation de reussite ou d’erreurs

Guide pratique d’une intégration réussie – Les zones de contenu

Rappel : les guides pratiques d’une intégration réussie concernent le travail d’analyse d’avant projet, et de la partie conception/réalisation de la maquette graphique. Ils sont destines aux intégrateurs, aux graphistes et aux clients.

Généralement,

Lorsque l’on propose a son client des solutions pour les contenus(zone d’affichage, mise en forme, ergonomie, …) celui-ci peut être d’accord sur les principes, mais une fois les principes mis en place il peuvent le perturber :

« oui mais la vot’ truc, j’avais pas vu ça comme ça, je pensais que… la faudrait mieux que ce soit comme ça, ou plutôt comme ça … »

En tout cas, le problème est que la validation d’un principe fonctionnel dont on ne le voit pas en action(j’insiste :  pour un cas particulier avec les contenus fournis), il ne faut en aucun considérer cette validation comme définitive. En effet, soit l’on refuse (les principes ont été validés, on refait un avenant), soit on s’exécute (en marmonnant pour la perte de temps et donc d’argent) dans les 2 cas : c’est mauvais !

La solution :

Dans la mesure du possible, mettre en place les principes proposés, rapidement pour que l’on puissent avoir une idée précise du rendu quasi final. Mais aussi et sans doute bien avant même de proposer quoi que ce soit : il faut impérativement prendre en compte tout type de  contenus dont le client pourrait avoir à mettre dans son site. Ex : rubrique e-commerce, gallerie photo, listing divers, tableaux … (voir point suivant). Ceci afin de permettre de proposer un axe graphique, une ergonomie et des principes fonctionnels adaptés à son projet.

Les zones d’affichages des contenus dynamique

Question d’avant projet :

« Que contiendra la zone de contenu principale de votre site ? », réponse « Ho, un peu de texte et quelques photos… ».

Cependant on constate bien souvent que pour la phase de remplissage du site, le client préfère ré exploiter le contenu existant (même si il voulait à la base « tout refaire ») et ce contenu à été adapté à un type de conteneur qui ne correspond plus. D’ou de gros soucis à devoir tout reprendre pour le faire rentrer dans une zone trop petite, ou trop grande.

La solution :

Il faut toujours anticiper sur des contenus existants que le client voudra remettre dans son nouveau site (tableau incompressible, montage photo, ou texte à rallonge, …). Il faut aussi et surtout insister pour obtenir les contenus ou au pire de prévenir des contraintes potentielles de mise en page avant la validation de la maquette. A mon sens il convient de responsabiliser les 2 parties (client/prestataire) en n’acceptant de commencer la phase de développement que sur réception d’un courrier/fax signé, validant la charte graphique ET les principes fonctionnelles établies par le prestataire sous forme d’un cahier des spécifications. Ceci obligeant les deux parties à réellement étudier le projet.

Zone de contenu, exemple de contenu pouvant être problèmatique et donc à anticiper :

  • tableau, genre grille tarifaire qu’il serait très long et compliqué à refaire
  • texte très long, donc zone de contenu potentiellement très longue (zone vide autour)
  • photos pour illustrer les articles. Souvent le client trouve ça petit si la zone est petite et du coup il aimerait qu’on puisse la voir en grande taille.
  • contenu en iframe d’un site tiers dont on ne peux modifier la taille
  • ajout d’un composant déjà mis en forme, comme par exemple :
    newsletter listing, e-commerce, agenda, composant, module, …

Lancement du blog

« Chronique d’un designer/développeur web »

Découvrez au travers de ce blog les problèmes rencontrés au quotidien par un designer/développeur web.

De la gestion de projets en passant par la phase créative du maquettage, du découpage/intégration, mais aussi et surtout du développement, j’évoque les problèmes rencontrés. Evidement je n’en reste pas à simplement mettre le doigt sur les soucis, je propose aussi des solutions, des réflexions ou j’espère avoir des retours dans les commentaires afin d’échanger sur certains sujets.

Ce blog étant aussi un lieu me permettant de centraliser mes recherches/trouvailles sur le net, vous y trouverez également une rubrique ressources, pour le webdesign et le développement.

Les rubriques « mes travaux » dans « Webdesign » et « Développement » me permette de présenter les différents projets sur lesquels j’ai travaillé (collaboré, pour être plus juste), j’y détail mes interventions et les outils utilisés.