Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Web Design
  2. HTML
Webdesign

Le développement pour les designers : Comprendre le front-end

by
Length:MediumLanguages:

French (Français) translation by Henri Lotin (you can also view the original English article)

Tout au long de cet article, nous allons faire un grand bond en avant dans le développement front-end et voir comment il s’intègre dans notre vue d'ensemble. Voici ce que nous allons couvrir :

  1. Comprendre le front-end stack
  2. Limites du DOM
  3. Considérations
  4. Comprendre les événements, les états et la réactivité

Comprendre le front-end stack

Rendre les sites web peut être tout une tâche. Avec une foule de dispositifs, navigateurs, points d’accès, bandes passantes, langages de programmation et environnements, il peut être difficile de construire des expériences web cohérentes. Grâce aux navigateurs et à un organisme de standardisation (le W3C), nous avons quelques piliers en place pour donner du contrôle lorsque c’est possible ; Ces piliers sont HTML, CSS et JavaScript.

Combinés, nous appelons ces piliers le front-end stack. Chaque langage a son propre but et les développeurs passent beaucoup de temps à s'assurer qu’ils ne brouillent les lignes d'aucun d’entre eux car ils peuvent s'ingérer les uns dans les autres. Alors, posons les bases ici. Les navigateurs modernes, qui sont disponibles dans le commerce : comme Safari, Edge, Chrome et Firefox peuvent seulement comprendre HTML, CSS et JavaScript. C’est ça, trois langages. À l’exception de Javascript, HTML et CSS sont des langages statiques déclaratifs. Par là je veux dire que vous n’avez pas nécessairement à « programmer » dans un d’eux étant donné qu’il est sans véritable logique d’écriture (avec quelques petites exceptions). JavaScript, qui a explosé à chaque coin d’internet ces dernières années, cependant, est un langage de programmation.

Quand j’ai essayé d’expliquer le front-end stack aux étudiants dans le passé, j’ai toujours trouvé utile de faire référence au corps humain. Étant donné que nous parlons dans le cadre du design atomique, cela soit dit en passant prolonge ma métaphore !

Un corps, hier.

HTML : Hyper Text Markup Langauge

HTML est votre squelette. Il détermine votre structure et votre posture. Un certain niveau de signification peut être dérivé d’une telle structure. Votre tête arrive toujours en premier, cou, cage thoracique, hanches, jambes, pieds, tout le chemin jusqu'à vos phalanges.

HTML, ew

L’ordre des éléments que je viens de décrire est votre homme typique. Il peut être différent pour une baleine ou un tigre. Ainsi, le HTML peut être différent pour les blogs, les magasins de commerce ou les plates-formes. HTML est tout au sujet de la signification et décrit à un navigateur web de façon signifiante, de quoi il est question dans une page web. C'est devenu tout à fait une science dernièrement comme l'algorithme de Google lit essentiellement cette structure et en dérive le sujet de la page.

À retenir : Gardez à l’esprit que HTML fournit une structure pour votre expérience web.

CSS : Cascading Style Sheet

CSS est ce à quoi vous ressemblez. Couleur des cheveux, couleur des yeux, teint, musclé, poilu, long bras, longueur des ongles d'orteils etc.. C’est encore la manière dont vous stylez vos cheveux, ou le maquillage que vous mettez sur pour avoir votre apparence.

Son seul but est de styler ce qui serait autrement du HTML très simple et ennuyeux. Si nous nous promenions tous dans nos squelettes, l'attraction serait un problème. Il en va de même pour les expériences web.

JavaScript

JavaScript c'est vos manies et vos interactions. Tout, que ce soit cliquer sur vos phalanges, cligner des yeux, sourire, tousser, votre façon de marcher, si vous décidez de sauter ou non, tout est question d’interactivité. La chose importante à retenir à propos de JavaScript est que lorsque vous fermez votre navigateur tout est oublié (en général), donc nous pouvons penser à JavaScript comme étant l’interactivité dans un site Web qui se passe pendant que vous êtes dans une « session » ou interagissez activement avec le site Web. Pensez au fait de cliquer sur les fenêtres pop-up ou sur les menus déroulants de navigation.

Ceci est quelqu'un qui marche

Certains d'entre vous à ce stade pourraient se demander où est le cerveau ou la « logique », mais nous allons y arriver. La chose la plus importante à retenir de cette section est que HTML, CSS et JavaScript vivent dans le navigateur, ils travaillent tous ensemble pour créer une expérience web « statique » que nous pouvons ensuite ramener à l'Atomic Design pour affiner.

Limites du DOM

DOM signifie Document Object Model. Le DOM est la vie, la respiration résultant de HTML, CSS et JavaScript coexistnnt dans une session activée par l’utilisateur.

Parce que le DOM est une représentation vivante du code source, il est important de comprendre qu’il a des limites. Le code que vous écrivez dans les fichiers HTML, CSS et JavaScript sur votre ordinateur est connu comme le code source. Cette source imite très attentivement ce que vous voyez dans le DOM, mais ce n’est pas la même chose. Le DOM est le produit dérivé de la manipulation et de la collation de ces fichiers remplis de code source. Lorsque ces fichiers sont demandés à partir d’un navigateur les langages sont « interprétés » et un site Web ou une page Web est né. Si vous modifiez le code source, la représentation de ces fichiers source doit être actualisée afin d’afficher la version mise à jour dans votre navigateur.

Chaque langage possède ses propres limites. CSS, par exemple, n’a pas un moteur de mise en pages particulièrement fort. Cela signifie ça peut être tout un processus pour générer des mises en pages complexes dans le navigateur. HTML n’a aucune capacité de mise en pages et n’est capable de fournir qu'une structure et une hiérarchie qui permettent au site Web d’être compris. JavaScript, étant un langage de programmation, a la possibilité de manipuler HTML et CSS. Dû au fait que nous utilisons un empilement de trois couches pour créer le front-end d’un site Web donné, ils ont tous besoin de bien se combiner entre eux, mais aussi de se conformer à certains paramètres supplémentaires. Dans notre cas, ces paramètres font référence à différents navigateurs, périphériques, systèmes d’exploitation, les versions des navigateurs et plus encore. Le DOM est plus ou moins pareil dans tous les types de navigateurs et distributeurs, mais à cause de cela, il y a beaucoup de règles à respecter afin de créer une expérience cohérente.

Considérations

CSS emploie un concept appelé le modèle de boîte. Le modèle de boîte comporte les propriétés suivantes :

  • Contenu : la zone de contenu réelle, remplie de texte peut-être.
  • Marge intérieure : marge supplémentaire qui entoure la zone de contenu et augmente l’arrière-plan.
  • Bordure : une bordure, au-delà de la marge intérieure.
  • Marge : pousse la forme elle-même, loin des autres éléments.

Voici un schéma qui l'explique un peu mieux.

Petites boîtes, sur une colline

Lorsque vous créez une forme telle qu’un carré, l'espace réel, qu'il occupe comprend les éléments ci-dessus.

« Les impairs ne sont jamais en votre faveur »

Oui, une grille à cinq colonnes ne présage rien de bon pour les développeurs. Il est généralement plus facile de travailler avec les pairs qu'avec les impairs. Les développeurs ont tendance à utiliser des frameworkd front-end comme Bootstrap ou UIKIT qui viennent avec des grilles pré-calculées contenant dix colonnes, douze colonnes ou peut-être plus. C’est vraiment une bonne idée de demander à un développeur quel framework il a l’intention d’utiliser, le cas échéant, afin d’aligner votre design avantageusement avec le code HTML et CSS

De l’eau, pas de glace

Ils s'en sont allés, les vieux jours de web. Dû au fait que la majorité des sites s’orientent vers le respondive, la nécessité d’une mise en page fluide est devenue très évidente. Grilles sont maintenant élaborées avec des pourcentages (10%, 30%, 50%) des conteneurs, qui se rompent à certains points d’arrêt qu'un développeur peut spécifier.

Les polices de caractères ne sont pas vos amies

Les polices sur les sites Web fonctionnent très différemment du print. Lorsque vous construisez un site Web sur votre propre ordinateur, vous pouvez utiliser n’importe quelle police installée sur votre système. C’est parfait pour vous, mais dès que ces fichiers sont déplacés vers un autre ordinateur, le code source ne peut pas faire référence à la police installée sur votre ordinateur, pas plus, car il n’a aucun lien avec elle.

Il existe plusieurs façons de contourner ce problème, mais vous entendrez souvent un développeur demander aux designers d'utiliser des Google Fonts. Les Google Fonts sont un ensemble de polices hébergées sur un CDN (Content Delivery Network), qui est accessible par n’importe quel ordinateur disposant d’une connexion active à Internet, signifiant que même si je n’ai pas la police spécifique installée sur mon ordinateur, elle peut toujours s'afficher sur mon site. Soyez conscients de ceci. Certaines polices ne sont pas aussi conçues pour le rendu sur des moteurs web. Elles pourraient paraître radicalement différentes lorsque vues dans, disons, Photoshop, comparé à un navigateur web. Chaque programme restitue les polices avec des moteurs de rendu différents.

Événements, états et réactivité

Maintenant que nous avons couvert quelques principes de base, nous allons jeter un coup d’oeil à certains points dont les designers tendent à ne pas tenir compte dans leur design mais qui sont vraiment importants pour l’expérience utilisateur.

Événements

Les événements sont des actions qu’un utilisateur pose lorsqu'il interagit avec votre site Web. JavaScript a pas mal de chose à prendre en compte, mais pour simples exemples on peut citer « click », « scroll », « mouseon » ou « mouseout » et « keydown » ou « keyup ». Si vous voulez lire un peu plus sur les événements JavaScript, visitez Mozilla. Certains des événements que vous voyez ici ne sont pas nécessairement declenchés par une interaction avec l’utilisateur.

Du point de vue d'un designer, il est primordial de comprendre ce qui arrive à certains éléments ou sections sur votre site une fois qu’un utilisateur a agi sur eux. Que se passe-t-il quand un bouton est cliqué, par exemple ? Ou y at-il une animation appliquée à une fenêtre modale lorsqu’elle se ferme au clic ? Voici les questions auxquelles vous devez apporter des réponses, surtout si votre projet a une portée prédéfinie. Selon le budget et les échéances, « Interaction Design », comme il est surnommé dans les communautés du web, peut coûter un temps précieux dans un projet.

État

Après la survenance d’un événement, les éléments sont laissés dans des « états ». Un exemple courant étant les liens. Les liens ont un certain nombre d’états : activefocushover À quoi ressemblent vos liens quand ils ont été cliqués ? Lorsque vous  êtes en train de cliquer dessus ? Lorsque la souris les survole ? Ou quand ils sont touchés sur mobile ?

l'Atomic Design peut vraiment devenir ici très pratique car vos guides de style peuvent facilement expliquer ces états tout en construisant un atome tel qu’un bouton. L'état peut avoir des conséquences dramatiques sur votre expérience d’utilisateur, donc en tenez-en compte lorsqu’il s’agit des sites plus complexes.

Réactivité

Le mot buzz de « réactivité » a buzzé depuis un bon moment maintenant. En tant que développeurs, nous devons faire en sorte que nos expériences web sont compatibles avec tous les périphériques. Si vous êtes pigiste, presque chaque client demandera que son site soit réactif (responsive). C'est est devenu le « gagne-pain » du web. CSS fournit aux développeurs une technologie utile, telles que les requêtes de médias (media queries) qui permettent aux développeurs de personnaliser des mises en pages à certains « points d’arrêt ».

Les frameworks front-end comme Bootstrap et Foundation visent à rendre le responsive beaucoup plus facile à mettre en œuvre en concevant des grilles en pourcentages pour les rendre disponibles aux développeurs. Le plus grande chose à retenir ici n’est pas comment les grilles responsive fonctionnent, mais plus ce pourquoi elles ont été conçues.

Conclusion

C’est tout, pour cette fois ! Dans l'article suivant, nous jeterons un œil sur le back-end et comment nous pouvons utiliser un état d’esprit Design Atomic pour améliorer notre compréhension de la logique et des compétences de programmation.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.