Codeur JUNIOR confiné - Episode 3, Application connectée : les textos (partie 1)

Troisième projet familial de code. Depuis le début, on a eu l'occasion de recevoir une seconde puce - et on s'est dit : "autant les faire communiquer" (par radio, puisque c'est possible).

S'est alors dessiné un projet un peu ambitieux : et si on s'envoyait des messages de l'un à l'autre ? Problème : saisir du texte risque d'être rock and roll...

• D'abord, on n'a pas de clavier. Comment taper du texte avec deux boutons ?
• Ensuite, on n'a pas non plus d'écran digne de ce nom. Pour lire un message, ça ne pose pas de souci : il défilera. Mais pour écrire, comment faire ?

Les textos

L'expérience utilisateur

Pour les développeurs professionnels, l'aspect UX (User eXperience) se résume parfois, à tort, à "choisir la bonne police, la bonne couleur et la taille du bouton". C'est effectivement dans le périmètre de l'expérience utilisateur, mais ça n'en est qu'une partie infime ("l'ergonomie").

Dans une vision plus large, on peut expliquer ce concept à nos enfants, en leur posant simplement la question suivante : "si tu voulais envoyer un message, tu ferais comment ?"

Pour faire court, quelles sont les différentes fonctionnalités qu'on attend ? Quelles sont les enchainement ?

Le déroulé de l'application

Après une belle discussion, nous sommes arrivés aux fonctionnalités suivantes :

• Le "mode" : une des deux cartes devra démarrer en mode "Emission" et l'autre en mode "Réception"
• La saisie : il faut pouvoir saisir un message en mode Emission. La saisie implique de pouvoir

1. saisir des lettres (comment ?)
2. éventuellement en effacer (comment ?)
3. pouvoir relire son message (comment ?)

• L'envoi : le message saisi en mode "Emission" doit pouvoir être envoyé par radio
• La réception : le message envoyé par radio doit pouvoir être capté en mode "Réception" et affiché à l'envi
• La boucle : lorsque l'émission est terminée, il faut passer en mode réception et vice-versa.

Cette liste nous permet de concevoir un peu mieux notre produit, mais il reste toujours quelques questions, notamment concernant la saisie.

Les entrées

Pour pouvoir alimenter notre programme avec de l'information, nous disposons d'assez peu d'entrées : les plus visibles sont les deux boutons, A et B. C'est peu (trop peu), mais heureusement, on dispose de beaucoup d'autres options !

• les boutons A et B peuvent être pressés en simultanés. On obtient alors un combo "A+B" qui serait un troisième bouton
• Le capteur gyroscopique peut aussi être utilisé : pencher la carte est une manière d'entrer de l'information, la secouer aussi, ...
• Et enfin, le signal radio lui-même peut servir d'entrée ! On y reviendra beaucoup plus tard.

La saisie

Réfléchir à un mode de saisie efficace a été, en soi, un exercice intéressant qui nous a occupé un bon moment. La technique utilisée : toujours questionner pour distinguer le besoin de sa solution. Les PM (responsables produits) ont un exemple assez bateau : "j'ai besoin d'une pelle". En réalité, le "besoin" n'est pas une pelle, c'est plus probablement d'avoir un trou, la pelle n'étant qu'une "solution". Le trou lui même n'est peut-être pas le besoin réel : pourquoi un trou ? etc...

Le déroulé, en accéléré, a été grosso modo :

• J'ai besoin de plus de boutons ==> Pourquoi faire ?
• Pour faire un clavier ==> Pourquoi faire ?
• Pour taper mon message ==> Ok, le besoin est de taper un message
• C'est quoi un message ? ==> des lettres
• C'est tout ? ==> Ah non y'a des espaces aussi

Ok, imaginons alors un système en deux temps.

1. On trouve une lettre
2. On l'ajoute au message

Un peu comme une Dymo des années 80 😁 ("c'est quoi une Dymo ?" 😂)

La saisie - à deux boutons

La première approche a été de dire : deux boutons suffisent, B fait défiler l'alphabet ("tourner la roue" sur la Dymo), et A ajoute la lettre ("presser la gâchette" sur la Dymo)

Question : "si tu veux écrire 'hihi', tu fais comment ?"

"J'appuie sur B jusqu'à H, puis sur A. J'appuie une fois sur B pour aller à I, puis sur A. Ensuite... ah ben je dois faire 25x B pour revenir sur H"

Pas génial...

La saisie - à 3 boutons

L'approche suivante a été : A pour faire défiler l'alphabet à rebours, B dans l'ordre alphabétique, et A+B pour choisir une lettre.

Question : "Et si je me suis trompé ?"

"Ah ben on recommence tout... et c'est pas très pratique"

Accessoirement, ça fait presser un max les boutons. Je ne suis pas entré dans les concepts d'usure et d'obsolescence programmée mais bon j'aime autant éviter de presser des boutons 500 fois...

La saisie - au gyroscope

On a ensuite enchainé avec l'idée suivante : l'alphabet défile grace à l’inclinaison de l'appareil. Sur la droite : ordre alphabétique, sur la gauche : à rebours. A : ajouter la lettre, B : supprimer la lettre.

La fin de la saisie

Reste à indiquer au système qu'on a fini de taper notre message. Il nous reste le combo "A+B" qu'on n'a pas encore exploité.

Le POC

On a, en théorie, résolu notre souci de saisie. On va quand même faire un premier prototype dédié à la saisie, pour valider l'idée. Cela nous a aussi permis de trouver des améliorations.

Initialisation

Pour commencer, on initialise nos variables. Le texte qu'on souhaite taper ("message"), l'alphabet utilisé, et la position dans cet alphabet.

A ce stade, il faut mentionner deux choses :

• d'abord, l'utilisation d'une chaine plutôt que d'un tableau - je souhaite garder les tableaux pour plus tard...
• et ensuite l'indice qui démarre à 0 - il faut bien l'expliquer aux enfants sinon ils sont perdus ensuite

Ma première fonction

On s'est vite rendu compte que les instructions pour garder position entre 0 et 26, et celles pour obtenir la bonne lettre pour cette position, étaient répétées rapidement partout dans notre code. On a donc codé notre première fonction 😁

Le gyroscope et les boutons

Et voilà. Traduction : incliner à droite ou à gauche fait défiler l'alphabet, A ajoute la lettre en cours, B supprime la lettre, et A+B affiche le résultat.

Les feedbacks

Suite à ce POC, on a pu tester la mécanique d'édition. Plusieurs points ont été remontés.

1. Pencher, c'est bien, mais c'est pas pratique. Pour chaque décalage il faut "re-pencher". Un défilement automatique, sans revenir à l'horizontale, serait plus efficace !
2. L'espace est assez fréquent. Il faudrait trouver un autre moyen de l'ajouter directement. On gagnerait du temps
3. Il est assez fréquent de faire une erreur et de ne pas s'en rendre compte. Du coup, l'étape "Relecture du message" doit permettre de revenir à l'édition si besoin est.

Au final, le point 1 a été adressé grace à des boucles pour vérifier si on est toujours penché; le point 2 : A+B ajoute un espace (et la fin d'un message est indiquée par l'action "secouer l'appareil"); et le point 3 a été ajouté à notre workflow.

Le résultat final

On n'a pas terminé notre programme, loin de là. Mais on a pu y réfléchir suffisamment pour arriver à dessiner un diagramme à états pour décrire le comportement global de toute notre application !

L'implémentation fera l'objet d'un autre article, mais elle a été passionnante aussi 😍😍😍