Problème innerHeight et height en JS sur mobile

Petite astuce qui peut éviter de perdre du temps à débugger.

Si lors de l’utilisation de la méthode .height() ou .innerHeight() vous rencontrez des difficultés pour récupérer la bonne valeur de la hauteur d’un élément (principalement sur mobile), Il faut vérifier dans le content de la méta viewport que la valeur height=device-height est bien présente.

Normalement, cela devrait résoudre pas mal de problèmes.

Installer Polymer

Polymer est une bibliothèque (framework) permettant de créer plus facilement des webcomponents.

Pour pouvoir utiliser Polymer, il faut tout d’abord vous assurer:

  • D’avoir la dernière version de Node.js, disponible sur le site. Prendre la version LTS.
  • D’avoir installé git

Installer Bower

Bower est un gestionnaire de dépendances (jquery, modernizr, twitter bootstrap…).

Il s’installe via npm de la façon suivante (en root si nécessaire)

npm install -g bower

Installer Polymer CLI

Polymer CLI  est une console spécifique à Polymer qui permettra de lancer des lignes de commandes pour faciliter la gestion des projets basés sur Polymer.

Il s’installe lui aussi via npm de la façon suivante (en root si nécessaire)

npm install -g polymer-cli

Si tout s’est bien passé, vous devriez voir la liste des dépendances s’afficher.

Installation polymer CLI

Vous pouvez faire un test en créant un nouveau projet. Tapez

polymer init

Choisissez element (par exemple) et faite entrée.

Polymer

Saisissez les informations demandées comme le nom du projet (qui doit contenir obligatoirement un -) et la description.

Et voilà Polymer va créer votre projet (vide, bien sûr :)). C’est à vous de jouer maintenant.

Polymer

Les assistants personnels virtuels, une alternative aux formulaires traditionnels ?

Actuellement, la collecte de données (sur un site web/application) afin que celles-ci puissent être traitées par d’autres personnes ou même par un logiciel, passe principalement par l’utilisation de formulaires plutôt standards.

Bien que notre métier de développeur/webdesigner a pour but de rendre la saisie par l’internaute, la plus agréable possible, notamment en lui offrant des formulaires au design toujours plus travaillés et jolis, un formulaire, malheureusement, ça reste froid.

De plus, nous devons très souvent imposer des contraintes dans la saisie de certaines informations (cohérence de données et qualités de celle-ci oblige), ce qui rend l’expérience encore plus frustrante pour l’internaute.

Ce manque d’interaction social entre l’utilisateur et le formulaire, n’invite pas l’internaute à répondre avec le maximum de précision, le poussant parfois même à omettre certaines informations précieuses et utiles pour terminer le plus rapidement la saisie du formulaire.

Alors, l’utilisation des assistants personnels virtuels pour récolter des informations pourrait-elle être une solution ?

Possible, d’aprés cet article The Future of Web Forms.

D’après lui, utiliser un assistant virtuel permettrait d’ajouter cet interraction social qui manque cruellement dans nos formulaires traditionnels.

L’expérience utilisateur serait alors plus humanisée et naturelle, ce qui permettrait à l’internaute de donner des réponses plus précises et plus détaillées.

En tout cas, certains se sont déjà penchés sur la question et ont déjà commencé à utiliser ces assistants pour offrir à leurs internautes une meilleure expérience utilisateur.

Sourcehttps://blog.prototypr.io/the-future-of-web-forms-4578485e1461#.84rri3t3a

Découverte de Verlet-JS

Verlet-Js est une librairie javascript qui permet de créer des formes plus ou moins complexes dans un monde 2D. Pour cela, il faut utiliser un système de particules/contraintes assez complexe à gérer.

Ces formes peuvent être utilisées pour la réalisation de jeux vidéos mais aussi dans des simulations à but scientifique.

Pour télécharger et utiliser la librairie Verlet-JS, un dépôt gitHub est disponible à cette adresse https://github.com/subprotocol/verlet-js

Pour comprendre plus en détail le fonctionnement de cette librairie et comment réaliser des formes plus ou moins complexes. Il existe plusieurs sites ou tutos, comme notamment :

 

Pseudo-classes hover et active : bien les utiliser en responsive

En responsive, on utilise souvent les pseudo-classes pour styliser des éléments comme les liens par exemple.

Sur la version desktop, on souhaite souvent utiliser l’animation au survol avec la pseudo-classe :hover. Par contre, sur les versions tablettes et mobiles, le survol (:hover) n’a pas de logique et on préfère souvent donner de l’effet lorsque nous appuyons dessus en utilisant la pseudo-classe :active par exemple.

Pour que ces pseudo-classes fonctionnent correctement et pour éviter les effets de bord, il faut penser à bien séparer les 2 dans le css à l’aide des médias queries. Dans l’exemple ci dessous, Le :hover c’est pour le desktop et le :active pour mobiles et tablettes.

Attention, je n’ai pas dit que « le :active, c’est uniquement pour les tablettes et mobiles ». Il peut très bien s’utiliser sur desktop.

Codepen - hover et active

Si je n’avais pas séparé, qu’est-ce qui ce serait passé ?

Codepen - hover et active

Sur desktop, pas trop de problèmes. Le hover remplirait bien son job et on aurait aussi un effet lors du clic avec le :active (ce qui n’est pas le plus génant).

Maintenant sur mobiles et tablettes, c’est une autre histoire. Le :hover est tout de même reconnu lorsque l’on appuie dessus (pas pour tout les mobiles et tablettes, mais pour beaucoup). Le problème, c’est qu’il n’a pas le comportement que l’on attend.

Si j’appuie sur mon lien, le :active fonctionne correctement, et au tout début mon lien devient bien rouge. Par contre, dès que je relâche, le :hover s’est lui aussi déclenché et le bouton va devenir bleu en permanence. Ce n’était pas du tout l’effet recherché.

bouton_rouge

bouton_bleu

 

Tout ça pour dire de bien ranger les choses au bon endroit, en séparant bien à l’aide de médias queries pour obtenir le résultat attendu et ne pas avoir de mauvaises surprises.

Le code source utilisé pour l’exemple est disponible sur le lien http://codepen.io/SoisNet/pen/VKEJJm .

Remplissage automatique d’un formulaire d’adresse avec Google Place autocomplete

Dans le but d’améliorer l’expérience utilisateur des internautes, l’aide au remplissage des formulaires de façon automatique peut être intéressante.

Pour cela Google Place autocomplete permet de remplir automatiquement les champs d’adresses (rue, ville, code postal, pays) à partir d’une proposition de Google.

google_place_02 google_place_03

 

 

 

 

Pour commencer dans votre page html, faire appel à l’API Javascript Places Autocomplete

<script src="https://maps.googleapis.com/maps/api/js?libraries=places&amp;key=votre_cle_api" type="text/javascript">

N’oubliez pas de remplacer votre_cle_api par votre api key que vous pouvez obtenir ici.

Maintenant, dans votre fichier HTML, il faut créer un formulaire comme celui-ci

<form>
    <div>
      <label>Adresse</label>
      <input id="user_input_autocomplete_address" placeholder="Votre adresse...">
    </div>
 
    <div>
      <label>Numéro</label>
      <input id="street_number" name="street_number" disabled>
    </div>
 
    <div>
      <label>Route</label>
      <input id="route" name="route" disabled>
    </div>
 
    <div>
      <label>Code postal</label>
      <input id="postal_code" name="postal_code" disabled>
    </div>
 
    <div>
      <label>Ville</label>
      <input id="locality" name="locality" disabled>
    </div>
 
    <div>
      <label>Pays</label>
      <input id="country" name="country" disabled>
    </div>
 
    <div>
      <label>Latitude</label>
      <input id="latitude" name="latitude" disabled>
    </div>
 
    <div>
      <label>Longitude</label>
      <input id="longitude" name="longitude" disabled>
    </div>
  </form>

L’id de chacun des champs a son importance pour que toutes les informations de l’api soient correctement replacées dans les champs appropriés.

Maintenant, un peu de javascript pour faire la liaison entre l’api et le formulaire.

<script type="text/javascript">
  // Lie le champs adresse en champs autocomplete afin que l'API puisse afficher les propositions d'adresses
  function initializeAutocomplete(id) {
    var element = document.getElementById(id);
    if (element) {
     var autocomplete = new google.maps.places.Autocomplete(element, { types: ['geocode'] });
     google.maps.event.addListener(autocomplete, 'place_changed', onPlaceChanged);
    }
  }
 
  // Injecte les données dans les champs du formulaire lorsqu'une adresse est sélectionnée
  function onPlaceChanged() {
    var place = this.getPlace();
 
    for (var i in place.address_components) {
      var component = place.address_components[i];
      for (var j in component.types) {  
        var type_element = document.getElementById(component.types[j]);
        if (type_element) {
          type_element.value = component.long_name;
        }
      }
    }
 
    var longitude = document.getElementById("longitude");
    var latitude = document.getElementById("latitude");
    longitude.value = place.geometry.location.lng();
    latitude.value = place.geometry.location.lat();
  }
 
  // Initialisation du champs autocomplete
  google.maps.event.addDomListener(window, 'load', function() {
    initializeAutocomplete('user_input_autocomplete_address');
  });
</script>

Et voilà, une façon simple de proposer aux internautes une aide à la saisie pour la partie adresse.

Source : https://www.lewagon.com/blog/tuto-google-place-autocomplete

Déterminer la ligne de flottaison

Lorsque l’on développe un site internet, il est important de réfléchir en amont à l’agencement des informations et encore plus à l’emplacement des informations principales et importantes pour l’internaute.

Sur les différents terminaux, il existe une limite virtuelle entre ce que l’internaute voit à l’écran dès le chargement de la page de ce qu’il ne voit pas si il n’utilise pas la barre de défilement, c’est ce qui est couramment appelé la ligne de flottaison.

image_ecran_flotaison_2

Cette limite de flottaison varie forcément en fonction du terminal utilisé, de la définition de son écran, de l’utilisation ou non de la barre de favoris. Il est donc impossible de la déterminer avec certitude.

Du coup, pour la déterminer au mieux, il faut regarder dans les statistiques quelle est la résolution la plus utilisée.

Dans l’exemple que je vais vous donner, je me suis basé sur une résolution qui domine ces dernières années et qui continue de progresser il s’agit de la résolution 1366×768 .

Sur ces 768px, il faut retirer la partie haute du navigateur (environ 90px) et la barre des tâches du bas (environ 40px). Ce qu’il fait qu’il reste  768-90-40 = 638px pour la zone au dessus de cette ligne.

La recherche de cette ligne peut être utile notamment dans le développement d’un e-commerce mais pour le reste des sites, des études tendent à montrer que la partie située sous la ligne est de plus en plus regardée et parfois plus longtemps que la zone située au dessus de la ligne.

A chacun de faire son choix.

Un peu d’interactivité avec la pseudo-classe :target

Menu, onglet, modal, pourquoi ne pas amener un peu d’interactivité sur un site sans forcément passer par du JS ?

Il existe en CSS une pseudo-classe très intéressante :target.

Si on regarde la définition du W3C de cette pseudo-classe, il s’agît d’un élément qui est la cible d’un lien (comme les ancres par exemple).

Prenons un petit exemple, pour montrer l’intérêt de ce :target.

Vous pouvez retrouver le code sur Codepen, c’est par ici.

Imaginons un bouton, représenté par une div qui portera l’id  bouton_menu, et que sera entouré d’un lien pointant sur l’ancre #menu dont le but sera de faire afficher le menu.

Puis un autre bloc, qui sera ce fameux menu et qui portera l’id menu

Le but va être d’afficher le bloc menu (qui par défaut est caché) en cliquant sur notre lien Afficher le menu.

Pour cela, dans la feuille de style, il suffit d’ajouter l’id ici #menu suivi de la pseudo-classe :target et d’ajouter entre accolade, le code qui va permettre de venir afficher le menu (en utilisant des transitions, si vous voulez faire du joli).

Pseudo classe :target

Faîtes un petit test en cliquant sur Afficher le menu. Génial, non?

Et tout cela en CSS.

Pour l’exemple, j’ai ajouté aussi un petit bouton Fermer pour que cela soit plus pratique.

Comme vous le voyez, cette pseudo-classe peut se révéler extrêmement pratique pour limiter l’utilisation du javascript tout en apportant une touche de dynamisme.

Concernant la compatibilité des navigateurs

La pseudo-classe :target est actuellement supportée par la plupart des navigateurs sauf IE8 et inférieur

Si vous souhaitez connaître exactement tous les navigateurs supportés, vous pouvez consulter cette page.

:target compatibilité

I18n – Ajouter une variable dans un fichier yml avec ruby on rails

Si vous gérez des sites multilingues, vous devez sûrement connaître la gem I18n et les fameux fichiers .yml que l’on place dans le dossier config/locales.

Ces fichiers, permettent de traduire plus facilement des parties de texte d’un site en plusieurs langues.

Dans ces fichiers, il est parfois nécessaire d’ajouter des variables comme dans l’exemple suivant.

J’ai besoin de traduire en anglais et allemand la phrase

« Bonjour Antoine, bienvenue sur le site »

Antoine étant une variable prenom, changeant en fonction de l’utilisateur connecté.

Dans le dossier config/locales, il y’a donc 2 fichiers en.yml et de.yml dont voici le contenu.

Dans en.yml

en:

phrase_accueil: "Hello Antoine, welcome to the website"

Dans de.yml

de:

phrase_accueil: "Hallo Antoine, willkommen auf der Website"

Alors comment remplacer Antoine par n’importe quel prénom (variable).

Dans en.yml et de.yml, il suffit de remplacer Antoine par %{prenom}. Ce qui donne

en:

phrase_accueil: « Hello %{prenom}, welcome to the website »

Maintenant dans la vue où sera appelée la traduction,  il suffira d’ajouter à la fonction de traduction t(:phrase_accueil) un paramètre supplémentaire prenom

t(:phrase_accueil, prenom: le_prenom_souhaite)