Weather.gov 2.0

Artigo original ↗ Discussão no Hacker News ↗

O Weather.gov está sendo reconstruído como “Weather.gov 2.0”, com um novo site baseado em Drupal e design liderado em parceria com equipes de serviço digital dos EUA, com o objetivo de tornar as previsões do NWS e as informações de risco mais fáceis de encontrar, entender e usar. Os comentadores elogiam o serviço atual e seus detalhados gráficos de previsão e loops de radar, mas temem que a nova versão sacrifique simplicidade, desempenho e acesso direto aos dados em favor de interfaces JavaScript mais pesadas e de analytics. O projeto também destaca questões mais amplas sobre a governança dos dados públicos de clima, a fragmentação entre agências e a pressão política para não competir com demasiada força com empresas meteorológicas comerciais.

Pilha de tecnologia: Drupal em 2024

  • Vários comentaristas ficam surpresos de o Drupal ainda ser a escolha em 2024, chamando-o de uma escolha “interessante” ou datada.
  • Um fio argumenta que a arquitetura de plugins/temas do Drupal é “insegura por design”; outros rebatem que qualquer CMS executando código arbitrário de terceiros compartilha risco semelhante de cadeia de suprimentos.
  • Alguns observam a base Symfony do Drupal e semelhanças modernas com Laravel, e enfatizam que muitos sites do governo já usam Drupal por causa de disponibilidade de pessoal e suporte do ecossistema.

Coordenação de open source no governo

  • Várias pessoas gostariam que existisse uma organização GitHub unificada no estilo “usa-gov” listando todo o OSS federal.
  • Soluções parciais existentes são citadas: code.gov, government.github.com e vários repositórios específicos de agências/organizações.
  • Há menção de que a indexação unificada original do code.gov por meio de code.json se deteriorou devido a mudanças de financiamento e de política.
  • Alguns sugerem GitLab e opções auto-hospedadas com orgs hierárquicas, mas outros argumentam que um único host de código para todo o governo é irrealista; um catálogo entre hosts é preferível.

Uso do Weather.gov, APIs e ferramentas de terceiros

  • Muitos dependem do weather.gov como uma fonte sem firulas, sem anúncios e estável, especialmente após o encerramento do Dark Sky.
  • São compartilhados vários painéis caseiros e clones usando api.weather.gov ou outras APIs abertas (como Pirate Weather).
  • Comentadores valorizam fortemente o Area Forecast Discussion e os produtos gráficos de previsão como algo exclusivamente honesto e detalhado.
  • Alguns gostariam que a 2.0 enfatizasse mais APIs e ferramentas da última milha, especialmente para gestão de emergências e casos de uso especializados; diz-se que api.weather.gov está fora do escopo deste projeto.

Radar, UX e acessibilidade

  • A anterior “grande atualização do radar” é amplamente criticada por ser lenta, complexa, pesada em JS e pior do que os antigos loops em GIF.
  • Outros defendem que radar.weather.gov é rápido, sem anúncios e eficaz em muitos dispositivos.
  • Há apreço pelo fato de que os loops GIF legados (nacionais e locais) ainda existirem, embora a descoberta não seja óbvia.
  • Levantam-se preocupações sobre pouca melhoria progressiva e falta de acessibilidade sem JavaScript.

Governança, transparência e política

  • A admissão franca no README sobre silos organizacionais e a Lei de Conway é elogiada como uma transparência rara.
  • Alguns temem que “feedback/monitoramento” seja usado para justificar scripts de analytics e banners de cookies; outros observam a abordagem já existente do governo com analytics.usa.gov.
  • Vários comentários mencionam a pressão política histórica para impedir que produtos do NWS competissem demais com empresas meteorológicas comerciais, e a preocupação com tentativas de privatizar a previsão do tempo.

Status e futuro do Weather.gov 2.0

  • O projeto está passando de prototipagem para MVP; o roadmap aponta metas em torno de maio.
  • Endpoints de staging e beta são descobertos, mas o site autoritativo continua sendo o weather.gov existente.
  • Alguns estão animados e o veem como um modelo para serviços digitais federais modernos; outros temem um redesign “JS inchado” que degrade as páginas hoje muito valorizadas, ricas em dados.