La peor primera impresión que puede dar una app del tiempo es un cuadro de búsqueda vacío. Un visitante abre la página porque quiere saber si lloverá hoy y, en lugar de una respuesta, recibe un aviso que le pide escribir primero el nombre de una ciudad, un paso adicional para obtener información que la app debería poder deducir razonablemente.
Una app del tiempo resolvió esto determinando una ubicación inicial aproximada en el momento en que se cargaba la página, en el servidor, antes de renderizar nada. /v1/ip tomaba la dirección IP del visitante y devolvía coordenadas junto con la ciudad y la región, lo que daba a la app una ubicación para la que solicitar un pronóstico de inmediato. El pronóstico en sí procedía del propio proveedor de datos meteorológicos de la app, que usaba esas coordenadas como entrada, de modo que la consulta de ubicación y los datos del tiempo eran dos piezas separadas que trabajaban juntas en lugar de un único servicio que intentara hacer ambas tareas.
La app trataba la ciudad detectada como una suposición inicial que el visitante siempre podía corregir, ya que la ubicación basada en IP tiene límites reales: refleja la red desde la que llega una conexión, que suele estar cerca de la ubicación real del visitante pero a veces no lo está, sobre todo en la red de un operador móvil, donde una IP puede corresponder a un nodo regional en lugar de a la localidad exacta del visitante. Justo al lado de la ciudad detectada había una forma bien visible de buscar otra ciudad, así que corregir una suposición errónea costaba un clic en lugar de dar la sensación de que la app había fallado.
Este pequeño cambio convirtió el dato más importante de la app, el pronóstico de hoy para la zona del propio visitante, de algo que el visitante tenía que pedir en algo que ya estaba en pantalla cuando la página terminaba de cargar. En una app del tiempo en concreto, donde toda la propuesta de valor es la rapidez para llegar a la respuesta que alguien busca, eliminar el paso de búsqueda en el caso habitual de "qué tiempo hace justo aquí" importó más que casi cualquier otra función que la app lanzó ese año.
La app también usaba la región detectada para decidir qué unidades mostrar por defecto, ya que un visitante detectado en un país que usa grados Celsius y otro detectado en un país que usa Fahrenheit tienen expectativas distintas sobre lo que significa "72 grados", y acertar con la unidad predeterminada en la primera carga evitaba tener que rebuscar en los ajustes, algo que la mayoría de los visitantes nunca se habría molestado en hacer y que los habría llevado a irse en silencio con una impresión equivocada del pronóstico.
Cada carga de página generaba una consulta, lo que en una app con un tráfico considerable supera con bastante rapidez la cuota gratuita diaria y pasa al crédito prepago o a una clave Unlimited, según lo predecible que sea el patrón de tráfico de la app. En una app del tiempo, el tráfico es famoso por dispararse con las tormentas y el tiempo inusual, justo cuando el coste mensual fijo de una clave Unlimited resulta más fácil de planificar que una factura prepaga variable que podría subir de golpe precisamente cuando la app necesita dar lo mejor de sí.
Acertar con la primera pantalla, sin necesidad de escribir nada, es una pequeña decisión técnica que determina cómo se percibe toda una app. La documentación del endpoint está en /docs/ipv4-lookup/ y /docs/ipv6-lookup/, y los precios de las opciones de crédito y Unlimited están en /pricing/.