Mon enfant aime toujours les avions, alors j’ai amélioré le radar

 (substack.com/jacobbartlett)
1 points par GN⁺ 2024-01-23 | 1 commentaires | Partager sur WhatsApp
  • L’app radar iOS personnelle Aviator 2.0 fonctionne de nouveau depuis la panne d’OpenSky Network qui durait depuis début décembre, et cette mise à jour corrige d’un coup plusieurs points de friction apparus à l’usage réel
  • Le nouveau menu de contrôle adopte une structure de divulgation progressive qui sépare les actions principales des outils avancés, et il est conçu pour moins masquer l’écran radar grâce aux modal detents de SwiftUI et à l’interaction avec l’arrière-plan
  • Le problème de détection d’avions trop éloignés a été réduit avec un basculeur de zoom binaire, implémenté en faisant passer la distance de caméra MapKit à 70 km ou 100 km
  • En exploitant les données origin_country, d’altitude et category de l’API OpenSky Network, l’app ajoute l’affichage des drapeaux, un filtre basse altitude pour les jours couverts, ainsi que des icônes distinctes pour les hélicoptères, les satellites et les tailles d’appareil
  • Les utilisateurs peuvent employer leurs identifiants OpenSky Network via une authentification HTTP Basic, mais dans la version 2.0 le mot de passe est stocké dans User Defaults, ce qui impose d’éviter toute réutilisation d’un mot de passe sensible

Contexte de la mise à jour Aviator 2.0

  • Aviator — Radar on your Phone est une app radar iOS créée pour repérer des avions avec son enfant
  • Après le billet précédent, il aurait été possible de réfléchir à une nouvelle release ou à des opportunités de monétisation, mais l’app renvoyait des erreurs aux utilisateurs depuis début décembre à cause d’une panne d’OpenSky Network
  • En rouvrant l’app, le son de détection d’avion s’est fait entendre à la place de l’erreur 502 qui s’affichait en continu, confirmant que tout refonctionnait normalement
  • Le travail sur Aviator 2.0 a ensuite été mené sur deux soirées pour intégrer les idées accumulées jusque-là

Une nouvelle interface de contrôle qui masque moins le radar

  • Dans la 2.0, les contrôles ont été déplacés dans un menu séparé, avec les actions importantes en haut et les outils avancés, moins utilisés, en dessous
  • Cette structure utilise la divulgation progressive (progressive disclosure)
  • Le menu est implémenté comme une modal SwiftUI avec deux presentationDetents
    • primary : 0.15 de la hauteur de l’écran
    • extended : 0.4 de la hauteur de l’écran
  • L’indicateur de glissement montre que le menu peut être étendu, et presentationBackgroundInteraction(.enabled) évite que l’interface radar principale soit recouverte par l’ombre
  • Le presentationBackground reprend l’emboss effect de Paul Hudson pour ajouter une texture métallique rappelant un vrai panneau de contrôle radar
  • En 2.1, il est prévu d’utiliser TipKit afin que même les jeunes utilisateurs Apple repèrent plus facilement cette structure à divulgation progressive

Ajustement du niveau de zoom et de la portée du radar

  • Dans la 1.0, le radar fonctionnait presque trop bien, au point de détecter des avions au-delà de l’horizon ou derrière le relief, donc invisibles en pratique
  • Dans un environnement comme la banlieue londonienne, avec son relief en paliers et sa continuité insulaire, cela devenait gênant à l’usage réel
  • Comme il restait possible de voir des avions lointains dans des espaces dégagés, le problème ne pouvait pas être réduit à une simple question de sensibilité
  • La solution a été d’ajouter une fonction de zoom
  • L’implémentation du zoom sur la surface se fait en passant une distance en mètres à la camera du SDK MapKit
    • si zoomed est true : 70 * 1_000
    • sinon : 100 * 1_000
  • Pour une implémentation rapide en vue d’une release du week-end, un cercle radar a été retiré afin de mieux souligner l’interface en mode zoomé
  • Au départ, l’idée était de gérer le niveau de zoom avec un Slider, mais même sur une puce A17 la fréquence d’images n’était pas suffisante ; l’app utilise donc aujourd’hui un basculeur de zoom binaire

Fonctions ajoutées grâce aux données d’OpenSky Network

  • Affichage des drapeaux

    • L’API OpenSky Network collecte de nombreuses informations via les transpondeurs d’avion, mais la 1.0 n’exploitait pas vraiment ces données
    • Dans la 2.0, un bouton permet d’afficher le drapeau emoji du pays d’origine sous chaque icône d’avion
    • L’implémentation s’appuie sur la valeur origin_country
    • L’app reçoit la chaîne de texte du pays d’origine fournie par l’API
    • Elle la convertit en code pays à 2 lettres à partir d’une liste de noms de pays trouvée en ligne
    • Le code pays est ensuite converti en scalaires Unicode pour former l’emoji de drapeau
    • Quand l’utilisateur active la fonction, flight.flag est affiché comme texte dans l’annotation MapKit

  • Mode temps couvert

    • Lors des journées couvertes au Royaume-Uni, une grande partie des avions affichés dans l’app restaient invisibles car cachés par les nuages
    • Un bouton a été ajouté pour masquer les appareils en altitude, permettant de basculer entre un mode ciel dégagé et un mode pluie
    • Cette fonction utilise les données d’altitude fournies par OpenSky Network, avec un seuil de base de nuages bas fixé à 2,5 km
    • Si geo_altitude < 2500.0, alors isLowAltitude vaut true
    • Si le réglage cloudy est activé, seules les annotations MapKit des avions à basse altitude sont affichées

Amélioration des icônes d’avion

  • Lors d’un test dans un parc, un hélicoptère est passé juste au-dessus de la tête, mais Aviator l’a affiché avec une icône d’avion classique
  • L’API OpenSky Network peut fournir l’attribut category, qui indique le type d’aéronef auquel appartient le transpondeur, si l’on ajoute un paramètre de requête
  • Cette catégorie peut inclure notamment :
    • des aéronefs légers de moins de 15 500 livres
    • des aéronefs lourds de plus de 300 000 livres
    • des voilures tournantes comme les hélicoptères
    • des véhicules spatiaux / transatmosphériques
    • des parachutes ou parachutistes
  • La dernière mise à jour distingue désormais les classes de taille d’aéronef et affiche des icônes séparées pour les satellites et les hélicoptères
  • Dans l’enum AircraftCategory, les images, emojis et valeurs d’échelle sont séparés
    • rotorcraft utilise le SFSymbol xmark.circle.fill
    • spaceTransatmospheric utilise l’emoji 🛰️
    • small, large, heavy appliquent respectivement les échelles 0.6, 1, 1.5
  • L’emoji d’hélicoptère paraissait trop rond une fois converti en aplat monochrome, d’où le choix d’un SFSymbol plus abstrait en forme de croix dans un cercle
  • Pour traiter l’emoji comme une image, un Text est mis à l’échelle puis utilisé comme masque d’un Rectangle, auquel sont appliqués la couleur et l’effet d’écran CRT

Identifiants OpenSky Network de l’utilisateur

  • Une fonction permet désormais aux utilisateurs de saisir directement leurs identifiants OpenSky Network
  • C’était l’une des demandes les plus fréquentes après la version Android, notamment pour éviter le rate limiting de l’usage non authentifié de l’API
  • Les informations de compte peuvent être saisies depuis le menu de contrôle complet, avec aussi un lien vers la page d’inscription
  • L’interface repose sur TextField et SecureField de SwiftUI
    • @AppStorage("username")
    • @AppStorage("password")
  • Dans la 2.0, pour aller vite vers la production, le mot de passe est stocké dans User Defaults
  • La prochaine release prévoit un stockage dans le Keychain ; en attendant, il ne faut pas réutiliser de mot de passe sensible
  • Le nom d’utilisateur et le mot de passe saisis sont encodés en Base64 puis ajoutés à l’en-tête Authorization des requêtes API via l’authentification Basic

Conclusion

  • Aviator 2.0 est une mise à jour qui continue d’améliorer une app pensée pour jouer avec son enfant
  • L’auteur invite à proposer en commentaire des idées de fonctionnalités ou des conseils ASO, et demande de télécharger puis d’évaluer Aviator — Radar on your Phone 2.0

À lire aussi

1 commentaires

 
GN⁺ 2024-01-23
Commentaires sur Hacker News

  • Il s’agit d’une suite d’un billet qui avait eu pas mal de succès il y a deux mois
    0: https://news.ycombinator.com/item?id=38435908 My toddler loves planes, so I built her a radar (1304 points, 56 days ago)

  • En voyant l’app, ça m’a rappelé des problèmes que j’avais à l’époque où je programmais des DVD. Avec un bouton bascule, on ne sait pas clairement quel mode est actuellement actif
    On ne sait pas si l’icône de drapeau ou de nuage montre le mode actuel, ou s’il faut appuyer dessus pour passer à ce mode. Même chose pour la bascule météo : on a l’impression inverse, on ne sait pas si appuyer sur le nuage affiche le mode nuageux ou fait revenir à un écran dégagé
    Dans un projet sur lequel je travaille en ce moment, des boutons +/- ajustent aussi la taille de la fenêtre de plage horaire, mais pour l’heure de début, + réduit la valeur en secondes et - l’augmente. Pour l’heure de fin, c’est l’inverse. Du point de vue de la taille de la fenêtre, les deux comportements sont cohérents, donc il faut au final bien clarifier le point de vue de l’utilisateur

    • C’est exactement ce que je déteste le plus dans l’UX moderne, et c’est particulièrement courant dans les apps TV. Quand l’un des deux éléments du menu est en blanc gras et l’autre en noir gras, je ne sais jamais ce que je suis sur le point de cliquer
      La bascule des sous-titres YouTube alterne aussi entre texte blanc sur fond noir et texte noir sur fond blanc, donc il faut appuyer, puis si les lèvres bougent mais qu’aucun sous-titre n’apparaît, essayer l’autre état de l’icône
      J’ai l’impression qu’avec le passage aux écrans tactiles, le bon sens autour du retour d’entrée positionnel avec état a disparu
    • Remarque tout à fait juste. J’ai peut-être trop insisté pour que ça ressemble à un panneau de contrôle plutôt que pour rendre l’UX bonne
      Et oui, c’était bien source de confusion. Lors d’une correction de bug de dernière minute, j’ai publié l’icône de nuage à l’envers par rapport aux autres

  • Ce serait vraiment génial que le balayage radar fasse clignoter l’avion lorsqu’il passe dessus, puis que sa position reste fixe en s’estompant progressivement jusqu’au balayage suivant
    Il serait aussi intéressant de prendre l’altitude et la position GPS actuelles de l’appareil, puis d’utiliser les bâtiments, collines et altitudes alentours d’OpenStreetMap pour calculer la ligne d’horizon visible selon chaque azimut. On pourrait alors l’afficher sur la carte comme un masquage radar. Un peu comme un sondeur qui passe au-dessus d’un rondin, ou un radar naval avec des bateaux masqués par d’autres navires
    Si tu faisais ça, les gens du secteur se gratteraient la tête en se demandant comment un téléphone arrive à faire un balayage radial
    [1] https://www.researchgate.net/figure/Occlusion-percentage-for...

    • Toutes ces idées sont bonnes. Pour l’instant, l’app se rapproche surtout d’une version Pareto d’un produit potentiellement réalisable à 100 %

  • C’est une réflexion que j’avais laissée sur le blog, mais en tant que parent d’un jeune enfant, je suis d’accord pour dire que le choix des couleurs est la partie la plus importante
    Comme c’est un projet annexe amusant, il y a quelques idées de fonctionnalités qui n’ont peut-être pas encore été implémentées. D’abord, une vue en direct qui utilise l’appareil photo du téléphone et les fonctions AR de l’iPhone pour afficher un point à l’emplacement approximatif de l’avion. J’avais déjà bricolé un peu de code qui le calcule à partir de la position de l’utilisateur et des données ADS-B
    Ensuite, on pourrait marquer un avion comme « vu » ou « manqué », et utiliser ce retour pour ajuster ce qui est affiché
    Enfin, des badges et des statistiques. Si ta fille ressemble à notre enfant, elle aimera probablement obtenir des badges dans l’app. On pourrait enregistrer l’historique localement dans une base de données et suivre des choses comme « nombre de compagnies aériennes vues », « nombre de types d’appareils vus », « vol le plus long », « vol le plus court ». Cela dit, je comprends tout à fait les problèmes que pose la gamification dans une app destinée aux enfants

    • Ça peut paraître un peu vieux jeu, mais j’essaie constamment de faire comprendre à mon enfant qu’il vaut mieux devenir producteur de technologie que simple consommateur
      Je lui explique souvent pourquoi il ne faut pas dépenser 30 dollars en monnaie numérique comme les Robux. Ce n’est pas la même chose que des objets ayant une vraie valeur, comme une raquette de tennis ou des chaussures
      C’est pour ça que je résiste à la gamification et que j’essaie de lui donner des outils pour ne pas se laisser aspirer dans des heures de tâches répétitives juste pour obtenir des badges ou des artefacts numériques sans valeur
      Pour une app destinée aux enfants, il vaudrait mieux ne pas inclure ce genre de fonctions. On peut montrer qu’il existe des apps sans publicité, sans gamification, qui ajoutent pourtant une vraie valeur à la vie
    • Merci beaucoup pour ces idées. Je me demande si je pourrais mettre la main sur un Vision Pro pour la première

  • Y aurait-il parmi les gens de HN quelqu’un pour lancer un projet open source participatif afin de porter ça sur Android ?
    Je suppose pour la licence que la personne qui créera le dépôt GitHub initial pourrait reprendre la phrase de l’auteur : « j’attends qu’un ingénieur Android entreprenant le porte lui-même ; j’ai mis assez de détails dans le billet. Vous pouvez le faire tant que c’est gratuit pour tout le monde »

    • Merci pour cette suggestion. Je n’ai jamais créé d’app mobile, mais j’aimerais apprendre
      Même si je ne pouvais pas contribuer à une app Android de haute qualité pour ce radar, ce serait sans doute bien employé de consacrer du temps à porter quelque chose qui s’inscrive dans le paradigme « An app can be a home-cooked meal »[0]. Comme c’est conçu autour d’une vision et d’un paradigme uniques, sans lourdeur, publicité, tracking, etc., le code a de bonnes chances d’être plus facile à comprendre
      Cette proposition pourrait même me conduire à retrouver le plaisir de programmer
      0: https://news.ycombinator.com/item?id=38877423
    • Je n’aurais pas la capacité d’assurer la maintenance sur le long terme, mais je pourrais sans doute contribuer un peu. Mon e-mail est dans mon profil

  • C’est un peu un autre sujet, mais en tant que personne avec un mauvais sens de l’orientation, la fonction la plus importante sur un téléphone est à quel point la petite flèche sur la carte indique précisément la direction dans laquelle je regarde
    J’utilise Android, et quand il n’est pas sûr, il affiche un cône d’incertitude bleu, et parfois il me demande de bouger le téléphone en forme de 8 ou de pointer les bâtiments autour de moi pour le recalibrer
    Techniquement, quelle est la limite ici ? L’iPhone est-il meilleur qu’Android ? Est-ce le matériel, l’accéléromètre, la boussole, le signal GPS ou le logiciel qui pose problème ? Je suis encore assez souvent désorienté et le cône pointe dans une mauvaise direction. Si l’iPhone fait vraiment mieux, c’est assez important pour que je sois presque prêt à changer

    • Content que tu le dises. J’avais fait la même observation dans le billet d’origine
      Je pensais qu’il devait y avoir une limite du côté du GPS, mais le delegate de direction de CoreLocation renvoie une orientation parfaite, du moins au taux de rafraîchissement de 120 Hz de mon appareil
      Google Maps est peut-être simplement médiocre
    • En utilisant les deux aussi souvent l’un que l’autre, j’ai l’impression qu’Android laisse davantage passer les valeurs brutes des capteurs, alors qu’iOS semble ajouter une sorte de latence de debounce et d’estimation
      Les deux se trompent à peu près aussi souvent sur la valeur d’orientation. Mais ce n’est qu’une impression basée sur l’expérience d’usage, pas un fait établi
    • Les produits Apple et leurs animations ajoutent en général plus de lissage et d’hystérésis. On dirait qu’ils masquent l’imprécision à l’utilisateur pour éviter que la flèche ne tremble trop, tandis que l’interface Android semble montrer plus directement les artefacts issus d’une fusion GPS/IMU bruitée et de l’imprécision intrinsèque du magnétomètre
      Sur les anciennes versions d’iOS, la flèche lente était assez agaçante, mais maintenant que le matériel est plus rapide, la flèche qui saute des autres plateformes se remarque davantage
      En résumé, la plupart des matériels récents ont des capacités assez comparables pour déterminer leur position dans l’espace et le temps. En revanche, la qualité de l’estime de trajectoire et de l’estimation d’attitude à partir des données courantes, ainsi que la manière de gérer le filtrage du bruit attendu par l’utilisateur quand le téléphone est tenu à la main, varient d’un logiciel de navigation à l’autre

  • C’est à cause des jeux Tony Hawk que je me suis mis au heavy metal. Motörhead avec “Ace of Spades” dans THPS3 et Iron Maiden avec “Number of the Beast” dans THPS4 ont été le déclic, donc il existe peut-être une piste de miettes de pain menant des jeux de plateforme au heavy metal

  • Beau travail, au sens où l’utilisateur le plus important a clairement été rendu heureux

  • Génial. En plus, ça me donne envie de mettre un !remindme dans 18 ans pour vérifier si ta fille a réussi l’examen de contrôle aérien

    • Elle a 2 ans pour l’instant, et on peut obtenir une licence d’élève-pilote à partir de 16 ans, donc il faut régler le rappel sur dans 14 ans
    • Si ta fille devient pilote, est-ce qu’on peut avoir des vols gratuits ? Tu rates peut-être une occasion de l’orienter discrètement vers les STEM

  • Je me demande si, même dans le monde d’après le 11-Septembre, les enfants peuvent encore être invités dans le cockpit

    • Mon père était pilote, et on faisait souvent coïncider les vacances familiales avec son planning de vols. Quand j’étais petit, rien ne m’a rendu plus fier que d’être invité dans le cockpit après le pushback pour « démarrer les moteurs »
      Je me souviens vaguement d’avoir appuyé sur un bouton pendant que mon père me montrait les instruments qui bougeaient. Mais le sentiment très net, en retournant à mon siège, d’être le plus grand enfant du monde, lui, est resté
      Après le 11-Septembre, ce genre de chose est clairement devenu beaucoup plus difficile
    • Si l’enfant veut voir le cockpit, j’ai vu sur internet un conseil disant qu’il vaut mieux ne pas demander avant le décollage. À ce moment-là, les pilotes ont déjà beaucoup à faire avec les checklists et la préparation
      En revanche, après l’atterrissage, demander si l’enfant peut voir le cockpit a beaucoup plus de chances de marcher
    • Nos enfants ont pu entrer dans le cockpit même après le 11-Septembre. Mais il faut que ce soit avant le décollage
      En vol, même le personnel de cabine n’y entre presque jamais, sauf parfois le chef de cabine. Les enfants demandent quand ils embarquent, si la porte du cockpit est encore ouverte
    • Le 1er janvier 2024, mon enfant de six ans a été invité dans le cockpit pour la première fois. Jusqu’à ce moment-là, je me posais la même question
      C’était sur un vol intérieur JetBlue aux États-Unis
    • J’ai déjà vu ça se produire quand on est encore à la porte d’embarquement. Les pilotes laissent souvent la porte ouverte, donc on peut s’approcher et demander. Au pire, on essuie un refus, donc ça vaut le coup d’essayer
      J’ai encore quelque part l’insigne en forme d’ailes de Delta qu’on m’a donné après avoir vu le cockpit pendant un vol quand j’étais enfant. C’était une expérience formidable dont je me souviens encore, et j’espère que d’autres enfants pourront en vivre au moins une partie