Weather.gov 2.0

Weather.gov está siendo reconstruido como “Weather.gov 2.0”, con un nuevo sitio basado en Drupal y un diseño liderado en colaboración con equipos de servicio digital de EE. UU., con el objetivo de hacer que los pronósticos y la información de peligros del NWS sean más fáciles de encontrar, entender y usar. Los comentaristas elogian el servicio actual y sus pronósticos gráficos detallados y bucles de radar, pero temen que la nueva versión pueda sacrificar simplicidad, rendimiento y acceso directo a los datos en favor de interfaces JavaScript más pesadas y analítica. El proyecto también pone de relieve problemas más amplios de gobernanza de los datos meteorológicos públicos, la fragmentación entre agencias y la presión política para no competir con demasiada fuerza con los proveedores meteorológicos comerciales.

Pila tecnológica: Drupal en 2024

  • Varios comentaristas se sorprenden de que Drupal siga siendo la opción en 2024, calificándolo de elección “interesante” o anticuada.
  • Un hilo argumenta que la arquitectura de plugins/temas de Drupal es “insegura por diseño”; otros replican que cualquier CMS que ejecute código arbitrario de terceros comparte un riesgo similar en la cadena de suministro.
  • Algunos señalan la base Symfony de Drupal y similitudes modernas con Laravel, y destacan que muchos sitios gubernamentales ya usan Drupal por motivos de personal y soporte del ecosistema.

Coordinación de open source gubernamental

  • Varias personas desearían que existiera una organización unificada estilo “usa-gov” en GitHub que listara todo el OSS federal.
  • Se citan soluciones parciales existentes: code.gov, government.github.com y varios repos específicos de agencias/organizaciones.
  • Se menciona que la indexación unificada original de code.gov mediante code.json se ha deteriorado por cambios de financiación y de política.
  • Algunos sugieren GitLab y opciones autohospedadas con organizaciones jerárquicas, pero otros sostienen que un único host de código para todo el gobierno es irrealista; es preferible un catálogo entre distintos hosts.

Uso de Weather.gov, APIs y herramientas de terceros

  • Muchos dependen de weather.gov como una fuente sin adornos, sin anuncios y estable, especialmente tras el cierre de Dark Sky.
  • Se comparten varios paneles caseros y clones que usan api.weather.gov u otras APIs abiertas (como Pirate Weather).
  • Los comentaristas valoran mucho el Area Forecast Discussion y los productos de pronóstico gráfico como algo singularmente honesto y detallado.
  • Algunos desearían que 2.0 diera más énfasis a las APIs y a herramientas de última milla, especialmente para gestión de emergencias y casos de uso especializados; se dice que api.weather.gov está fuera del alcance de este proyecto.

Radar, UX y accesibilidad

  • La anterior “gran actualización del radar” es ampliamente criticada por ser lenta, compleja, pesada en JS y peor que los antiguos bucles GIF.
  • Otros defienden radar.weather.gov como rápido, sin anuncios y eficaz en muchos dispositivos.
  • Se aprecia que los bucles GIF heredados (nacionales y locales) sigan existiendo, aunque no sea obvio encontrarlos.
  • Se plantean preocupaciones sobre la mala mejora progresiva y la accesibilidad sin JS.

Gobernanza, transparencia y política

  • Se elogia la admisión sincera del README sobre los silos organizativos y la Ley de Conway por su rara transparencia.
  • A algunos les preocupa que “feedback/monitoring” justifique scripts de analítica y banners de cookies; otros señalan el enfoque ya existente de analytics.usa.gov del gobierno.
  • Varios comentarios mencionan presiones políticas históricas para evitar que los productos del NWS compitieran demasiado con empresas meteorológicas comerciales, y la preocupación por intentos de privatizar la predicción.

Estado y futuro de Weather.gov 2.0

  • El proyecto está pasando de la fase de prototipado a la de MVP; la hoja de ruta apunta a alrededor de mayo.
  • Se descubren endpoints de staging y beta, pero el sitio de referencia sigue siendo el actual weather.gov.
  • Algunos están entusiasmados y lo ven como un modelo de servicios digitales federales modernos; otros temen un rediseño con “JS inflado” que degrade las páginas actuales, muy valoradas por su densidad de datos.