Un plugin de typographie française pour Sketch

Résumé : j’ai créé un plugin Sketch pour respecter auto­ma­ti­que­ment les règles typo, espaces insé­cables et bien plus.

icone du plugin
Typographie frenchy

Tout a commencé par une inter­face comme celle-ci :

screenshot de boite de dialogue

… Dans le titre, un magni­fique point d’ex­cla­ma­tion seul sur sa ligne, problème récur­rent dans une appli­ca­tion mobile sur laquelle je travaillais. Je me suis demandé comment résoudre ce problème, sans demander aux déve­lop­peurs de mémo­riser chaque règle et d’in­sérer systé­ma­ti­que­ment des carac­tères spéciaux à la main. Ces carac­tères, ce sont les espaces insé­cables, qui collent la ponc­tua­tion au signe précé­dent. Sur le web ça implique de taper des choses sympa­thiques comme   ou d’uti­liser d’obs­curs raccourcis clavier.

Une meilleure alter­na­tive est d’au­to­ma­tiser le problème, soit en début de chaine (comme le fait Word), soit en fin de chaine (comme ce plugin pour WordPress ou comme le fait nati­ve­ment SPIP). Vu qu’il faudrait attendre long­temps que chaque système ait son plugin de typo, j’ai choisi d’ex­plorer la première piste en créant un plugin pour Sketch. Ca ne règle pas le problème du contenu saisi direc­te­ment dans l’in­ter­face de contri­bu­tion des diffé­rents CMS, mais, de même qu’un déve­lop­peur peut copier-coller un code RGB depuis Zeplin ou Invision, l’idée est que des gens pour­raient copier et coller du texte d’in­ter­face, par exemple celui d’une barre de menu. On est d’ac­cord que c’est opti­miste : si demain ce texte change, il y a peu de chance qu’il soit ressaisi d’abord dans Sketch.

Mais c’est une voie inté­res­sante. Après tout, Invision, Figma ou Framer génèrent des maquettes de plus en plus compa­tibles avec du HTML/CSS. Cette proxi­mité entre concep­tion et réali­sa­tion pour­rait aussi s’ap­pli­quer au texte.

Dans un tout autre angle, voir aussi Kopie, outil de rédac­tion colla­bo­ra­tive synchro­nisée avec Sketch.

Ajoutons que le plugin apporte aussi quelques embel­lis­se­ments direc­te­ment dans les maquettes, indé­pen­dam­ment de ces ques­tions de work­flow :

  • De " à «
  • De double tiret (--) à tiret demi-quadratin ( – )
  • Certaines frac­tions (½, ⅓, ¼ )
  • Suffixes ordi­naux : de 2e à 2ᵉ
  • Points de suspen­sion…
  • De N° à №

Bref. Plugin de typo­gra­phie auto­ma­tique. C’était fun à faire. Retours bien­venus.

Expérimenter avec une tétière inversée

Résumé : sur mobile j’ai changé la barre de menu du blog.

Pendant long­temps, quand on ouvrait mon blog sur télé­phone on voyait ça :Navigation blogmobile v1

Ça fait un gros pâté de texte non ? Nom du blog, puis liens, puis titre de l’ar­ticle. Les liens du menu, notam­ment, sont plus directs et effi­caces qu’un menu-burger, mais ils font très lourds sans vrai­ment être parlants ou inciter à cliquer. Comment rendre ce menu plus discret sans perdre en utili­sa­bi­lité ? Une solu­tion : un menu-tiroir masqué par défaut, mais pas un menu-burger pour autant. Pour l’ou­vrir, il suffit de scroller vers le haut ou d’ap­puyer sur la mani­cule. Essayez de vous-même sur un télé­phone, une fenêtre étroite ou regardez cette vidéo :

Pourquoi ce choix ? J’avais envie d’expérimenter autour de l’idée de la page web comme canevas infini (pour reprendre une expres­sion de Scott McCloud). Une page web n’est pas un rectangle avec des fron­tières claires ni un sens de lecture prédé­fini.

Image prise à Frank Chimero

Ça ne veut pas dire qu’on peut faire n’im­porte quoi : les limites sont celles de la compré­hen­sion du lecteur. Ici on reste sage et ce menu inversé est même plus ergo­no­mique qu’un menu-burger. D’abord il est tout à fait décou­vrable : la mani­cule est bien mise en évidence, on peut appuyer dessus ou sur toute la largeur de l’écran et le menu est suggéré par une saillie. Ensuite, parce qu’au lieu de devoir repérer et viser un bouton, il suffit d’un simple geste de scroll. Comme le dit Joshua Porter, « le défi­le­ment est une conti­nua­tion, le clic une déci­sion ». Enfin, ce geste n’est pas arbi­traire mais cohé­rent avec la manière dont le menu appa­rait : scroller vers le haut fait appa­raitre progres­si­ve­ment plus de page, c’est le prin­cipe même du scroll. Alors que dans l’ab­solu un bouton-burger pour­rait être placé n’im­porte et le menu pour­rait appa­raitre n’im­porte comment.

Bref, je trouve ça pas mal. Me bercé-je d’illu­sions ? Un avis ? Avez-vous croisé des idées simi­laires ?

You do the meth : tous les jeux de mots des génériques de Bob’s Burgers

Vous voyez dans le géné­rique des Simpsons le texte que Bart écrit depuis 25 saisons ? Dans Bob’s Burgers c’est pareil, il y a deux jeux de mot dans le décor, presque toujours nouveaux. Je me suis amusé à les extraire avec un petit script basé sur ffmpeg (et peu d’huile de coude pour capturer les photo­grammes ayant des time­code diffé­rents).

Il y a 126 photo­grammes pour 134 épisodes (de la S1 au milieu de la S8), ce qui fait 8 épisodes sans géné­rique.

VOIR LES IMAGES EN PLEIN ÉCRAN Lire la suite

Leçons ergonomiques et techniques d’un projet perso

Il y a quelques mois j’ai publié un outil pour calculer une addi­tion en terme de tickets resto (le post de l’époque est ici). Je sais, rien ne m’ar­rête. Voici une mise à jour, avec notam­ment des visuels plus travaillés, ainsi qu’un clavier sur mesure et toujours présent à l’écran.

Vous pouvez le charger ci-dessous en cliquant sur le screen­shot ou l’ou­vrir depuis votre ordi­phone préféré.

Pourquoi un thème sombre ?

Parce que c’est repo­sant pour les yeux, surtout quand l’arrière-plan est très présent, comme ici, et que mon télé­phone et son OS (Moto G et Android vanillé) sont déjà sombres.

Pourquoi un clavier sur mesure ?

Se limiter à ce que fournit l’OS oblige à utiliser :

  • sur iOS, un clavier pensé pour la saisie de numéros de télé­phone, donc pas top
  • Sur Windows Phone et Android, un clavier plus adapté, sans carac­tères inutiles et avec un sépa­ra­teur décimal. Malgré cela je n’aime pas trop leur dispo­si­tion (voir plus bas).

De plus, le clavier natif appa­rait à l’appui sur un champ. C’est bien dans une page complexe, mais ici il est plus perti­nent d’avoir une mise en page sans scroll, avec les champs fixes et le clavier toujours présent.

Enfin, pour utiliser le clavier numé­rique natif, il faut que l’élé­ment <input> soit de type number. Ca pose certaines contraintes, car l’API a été pensée pour un contrôle de vali­dité dyna­mique mais après coup : c’est seule­ment quand l’uti­li­sa­teur sort du champ que le champ signale l’er­reur, par exemple s’il a saisi des lettres au lieu de chiffre. Ca rend diffi­cile le contrôle a priori que je voulais, puis­qu’on n’a aucun accès program­ma­tique au texte inva­lide d’un champ (value devient vide). De plus, une valeur du genre « 10, » est consi­dérée comme inva­lide, alors qu’il faudrait qu’elle corres­ponde à un état « en cours de saisie », comme c’est le cas dans les bonnes biblio­thèques de gestion des masques de saisie.

Ajoutons qu’en fran­çais le sépa­ra­teur décimal correct est la virgule mais certains navi­ga­teurs (Firefox Mobile) ne le loca­lisent pas correc­te­ment.

C’est pas une mauvaise pratique de réinventer des comportements natifs ?

Totalement. C’était juste­ment instructif pour moi de voir le nombre de choses qu’il faut réim­plé­menter comme on peut. Le chemi­ne­ment a ressemblé à ça :

  1. Je ne voulais pas du clavier, alors qu’il appa­rait par défaut, un compor­te­ment théo­ri­que­ment non modi­fiable.
  2. Du coup, on triche en faisant perdre le focus à un champ dès qu’il le gagne.
  3. Du coup, il faut en garder en mémoire quel champ on a sélec­tionné. Un focus custom, quoi. Il faut égale­ment recréer un curseur et le placer au bon endroit.
  4. Ah merde, il faut calculer à la main la posi­tion du curseur.
  5. Et bien sûr ça oblige de bidouiller pour obtenir la largeur d’un carac­tère (l’unité ch aurait été parfaite mais Chrome ne la supporte pas). Donc l’outil ne marche qu’avec des polices à chasse fixe (mono­space).

Je vous passe les subtiles diffé­rences de compor­te­ment entre navi­ga­teurs, notam­ment dans la gestion des évène­ments focus et click. Bref, le tout marche mais n’est pas ultra robuste ni fran­che­ment réactif et le code est sans doute encore moins propre et modu­laire que la dernière fois.

Pourquoi cette disposition de clavier ?

Vu qu’on est dans la saisie de monnaie je me suis rapproché de la conven­tion des calcu­lettes, avec le 9 en haut à droite. En plus, la progres­sion des chiffres du bas vers le haut suit le mouve­ment de la main ou du doigt propre au mobile.

Un bidule optimisé pour la main mais codé avec les pieds

EDIT : Infos plus récentes ici.

S’il y a bien un moment où je n’ai pas envie d’uti­liser mes faibles capa­cités de calcul mental, mais plutôt un arte­fact cognitif adapté (en fran­çais : dégainer une calcu­lette), c’est quand il s’agit de payer en tickets restau­rant. Étant toujours à la recherche d’oc­ca­sions concrètes d’ap­prendre à programmer, j’ai donc bricolé un petit outil qui affiche le nombre de tickets à donner et le reste en liquide.

Le bidule est pensé pour une utili­sa­tion sur petit écran et une saisie au pouce. J’ai essayé de rendre le formu­laire dyna­mique, pour empê­cher la saisie de lettres ou des montants mal formatés. C’est un parti pris ergo­no­mique (blocage versus message d’er­reur), mais c’est égale­ment instructif de voir à quel point le déve­lop­pe­ment de web app peut être CHIANT si on tombe sur la mauvais combi­naison de cas – en l’oc­cur­rence, combiner un contrôle à la saisie et un clavier adapté à la saisie numé­rique sur mobile. Par exemple, l’outil bloque la saisie d’une seconde virgule après « 1,01 », mais après « 1, » ou « 1,00 ».

Avertissement : on parle d’un truc opti­misé pour la main mais codé avec les pieds. Donc pas de support de Safari <9 ni d’Internet Explorer (et tempo­rai­re­ment de Firefox sur Android, grrr). et un code d’une qualité très rela­tive.

C’est ici.

Screenshot_2016-01-03-00-05-00