La pire première impression qu'une application météo puisse donner, c'est un champ de recherche vide. Un visiteur ouvre la page pour savoir s'il va pleuvoir aujourd'hui et, au lieu d'une réponse, on lui demande d'abord de saisir le nom d'une ville, une étape supplémentaire pour une information que l'application devrait raisonnablement pouvoir deviner.
Une application météo a résolu ce problème en déterminant une position de départ approximative dès le chargement de la page, côté serveur, avant d'afficher quoi que ce soit. /v1/ip recevait l'adresse IP du visiteur et renvoyait des coordonnées ainsi que la ville et la région, ce qui donnait immédiatement à l'application une position pour laquelle demander une prévision. La prévision elle-même provenait du propre fournisseur de données météo de l'application, avec ces coordonnées en entrée : la recherche de position et les données météo étaient donc deux éléments distincts qui fonctionnaient ensemble, plutôt qu'un seul service essayant de faire les deux.
L'application traitait la ville détectée comme une première estimation que le visiteur pouvait toujours corriger, car la localisation par IP a de vraies limites : elle reflète le réseau d'où provient la connexion, généralement proche de la position réelle du visiteur mais parfois décalé, en particulier sur un réseau d'opérateur mobile où une IP peut correspondre à un nœud régional plutôt qu'à la ville exacte du visiteur. Un moyen bien visible de rechercher une autre ville se trouvait juste à côté de la ville détectée, si bien que corriger une mauvaise estimation prenait un clic, sans donner l'impression que l'application avait échoué.
Ce petit changement a fait passer l'information la plus importante de l'application, la prévision du jour pour la zone du visiteur, du statut de donnée à demander à celui de donnée déjà affichée à la fin du chargement de la page. Pour une application météo en particulier, dont toute la valeur tient à la rapidité d'accès à la réponse recherchée, supprimer l'étape de recherche dans le cas courant du « quel temps fait-il ici » a compté davantage que presque toutes les autres fonctionnalités livrées par l'application cette année-là.
L'application utilisait aussi la région déterminée pour choisir les unités affichées par défaut, car un visiteur détecté dans un pays qui utilise les degrés Celsius et un visiteur détecté dans un pays qui utilise les degrés Fahrenheit ne donnent pas le même sens à « 72 degrés », et choisir la bonne unité par défaut dès le premier chargement évitait d'aller fouiller dans des réglages que la plupart des visiteurs n'auraient jamais pris la peine de chercher, repartant discrètement avec une idée fausse de la prévision.
Chaque chargement de page déclenchait une recherche, ce qui, pour une application au trafic conséquent, dépasse assez vite le quota gratuit quotidien et passe soit sur le crédit prépayé, soit sur une clé Unlimited, selon la prévisibilité du trafic de l'application. Pour une application météo, le trafic est notoirement irrégulier lors des tempêtes et des épisodes météo inhabituels, précisément quand le coût mensuel fixe d'une clé Unlimited devient plus facile à planifier qu'une facture prépayée variable qui risque de s'envoler au moment où l'application doit être à son meilleur.
Réussir le premier écran, sans aucune saisie, est une petite décision technique qui façonne le ressenti de toute une application. La documentation de l'endpoint se trouve sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/, et les tarifs du crédit comme de l'option Unlimited sont sur /pricing/.