Neste post eu traduzo o texto do jornalista e programador Adrian Holovaty escrito em 2006 com o título “A fundamental way newspaper sites need to change”. Holovaty desenvolveu o EveryBlock, um site participativo sobre notícias locais que ilustra este texto por ser um exemplo de produto jornalístico não centrado em narrativa textual.
Esse é o argumento central do post traduzido abaixo:ele afirma que os jornalistas devem combater a visão mundo story-centric, ou seja, centrada na narrativa textual.
O argumento é que os jornalistas são estruturadores de informações: datas de nascimento, preços de produtos, praças, temperaturas, etc. A apuração de informações pode ser facilmente percebida como dados estruturados, mas os jornais apresentam esses dados em longos blocos de textos ou em tabelas e infográficos apenas ilustrativos. Ou seja, transformam a informação apurada de forma estruturada em textos não estruturados e como tais dificilmente legíveis pelos computadores, suscetíveis de fragmentação para serem aproveitados pelo leitor.
Estruturar os atributos de uma notícia é tornar essa notícia em informação armazenável e manipulável. Se a cada notícia de acidente de trânsito na cidade o jornalista colher informações sobre o endereço, os tipos de carros envolvidos, o horário, a idade do motorista, o ano do carro, a velocidade entre outros e estruturar em todos acidentes subsequentes os mesmo atributos, o jornalista terá uma base de dados. A proposta de Holovaty é que os jornais e os jornalistas possam pensar formatações estruturadas desses dados.
Holovaty não está preocupado em como essas informações serão formatadas para diferentes meios – celular, tablets, computadores – mas como elas podem ganhar um propósito diferente se puderem ser lidas por computadores e acessadas pelos leitores com navegação interativa.
A discussão torna-se importante para tempos em que os jornalistas se deparam diariamente com as propriedades do ambiente digital.
________________________________
Uma maneira fundamental para que os sites de jornais precisam mudar
Escrito por Adrian Holovaty em 6 de setembro de 2006
Um post de blog intitulada 9 Formas de Jornais para Melhorar seus sites circulou bastante ultimamente. Eu não escrevo sobre o setor de notícias on-line neste site como eu costumava, mas o artigo citado me inspirou a exibir o meu pensamento atual sobre o que os sites de jornal precisam fazer. Aqui, apresento minha opinião sobre uma mudança fundamental que precisa acontecer.
Tenho um diploma de jornalismo, pelo que vale a pena e trabalhei para sites de jornais desde 1998 (incluindo o jornal da faculdade e os estágios). Os sites: themaneater.com (agora uma sombra pálida de seu antigo self) na Universidade do Missouri, SuburbanChicagoNews.com, ajc.com em Atlanta, LJWorld.com / Lawrence.com em Lawrence, Kansas e, no último ano, washingtonpost.com.
A maioria dos pontos feitos na entrada “9 maneiras” são OK, se um pouco excessivamente específico (“faça o seu conteúdo funcionar em celulares e PDAs”) e na moda (etiquetagem!). Não há nada de errado com isso – a indústria de jornal on-line precisa de todos os conselhos que pode obter. Mas mudanças mais fundamentais precisam acontecer para as empresas de jornal continuarem a ser fontes essenciais de informação para suas comunidades.
Uma dessas mudanças importantes é: os jornais precisam parar a visão de mundo centrada na história (story-centric world).
Condicionadas por décadas de um estilo de jornalismo estabelecido, os jornalistas tendem a ver seu principal papel assim:
Coletar informação
Escrever uma história de jornal
O problema aqui é que, para muitos tipos de notícias e informações, histórias de jornais não funcionam mais.
Muito do que os jornalistas locais coletam no dia-a-dia são informações estruturadas: o tipo de informação que pode ser cortada e cortada, de forma automatizada, por computadores. No entanto, a informação é destilada em uma grande gota de texto – uma história de jornal – que não tem chance de ser repassada.
“Reaproveitada”?
Deixe-me esclarecer. Eu não quero dizer “Exibir uma história de jornal em um celular”. Não quero dizer “Exibir uma história de jornal em RSS”. Não quero dizer “Exibir uma história de jornal no meu PDA”. Esses são bons objetivos, mas são exemplos de alteração do formato, não da própria informação. Reaproveitamento e agregação de informações é uma história diferente, e requer que a informação seja armazenada atômica – e em formato legível por máquina.
Por exemplo, diga que um jornal escreveu uma história sobre um incêndio local. Ser capaz de ler essa história em um telefone celular é bom. Hooray, tecnologia! Mas o que eu realmente quero poder fazer é explorar os fatos brutos dessa história, um por um, com camadas de atribuição e uma infra-estrutura para comparar os detalhes do fogo – data, hora, lugar, vítimas, número da estação de bombeiros , distância do departamento de bombeiros, nomes e anos de experiência de bombeiros na cena, tempo que levou para que os bombeiros chegassem – com os detalhes dos incêndios anteriores. E incêndios subseqüentes, sempre que acontecem.
Isso é o que quero dizer com dados estruturados: informações com atributos consistentes em um domínio. Cada incêndio tem esses atributos, assim como todos os crimes relatados têm muitos atributos, assim como todo jogo de basquete da faculdade tem muitos atributos.
Esses três exemplos são candidatos óbvios para a estrutura, principalmente devido à onipresença. As pessoas estão cortando e cortando estatísticas de esportes por anos. As pessoas estão analisando o crime há anos.
Mas não são apenas esses exemplos óbvios. Se você parar para observar o tipo de informação que os jornalistas colhem, verá a quantidade de informação estruturada extraída. Se eu posso tomar a liberdade de dar exemplos:
Um obituário é sobre uma pessoa, envolve datas e funerárias.
Um anúncio de casamento é sobre um casal, com uma data de casamento, data de noivado, cidade natal da noiva, cidade natal do noivo e várias outras informações felizes e floridas.
Um nascimento tem pais, uma criança (ou filhos) e uma data.
Um graduado da faculdade tem um estado de origem, uma cidade natal, um diploma, um ano de graduação e de formatura.
Um estilo “On the Street” de estilo cebola tem respondentes, respostas e uma data de publicação.
Uma bebida especial tem um dia da semana e é oferecida em um bar.
O cronograma do Congresso dos EUA tem um dia e vários itens da agenda.
Um anúncio político tem um candidato, um estado, um partido político, questões múltiplas, personagens, pistas, música e muito mais.
Todas as eleições do Senado, da Câmara e do Governador nos EUA têm localização, análise, informações demográficas, resultados das eleições anteriores, informações de financiamento de campanha e muito mais.
Todos os detidos conhecidos na Guantánamo têm uma idade aproximada, local de nascimento, taxas formais e muito mais.
Veja o tema aqui? Muitas informações que as organizações de jornal coletam são implacavelmente estruturadas. Isso leva alguém a perceber a estrutura (a parte fácil), e é preciso que alguém comece a armazená-la em um formato estruturado (a parte difícil).
Agora, posso entender por que os jornais são lentos para aceitar esse tipo de pensamento. Os jornalistas não são o grupo mais experiente em tecnologia, eles não são o grupo mais inovador, e eles são (apenas um pouco) resistentes à mudança.
Uma barreira a esse pensamento é uma espécie de arrogância jornalística: “Isso é jornalismo?” Nós somos jornalistas, e fomos treinados para explicar informações complexas às pessoas de forma que possam entender. A exibição de dados brutos não ajuda as pessoas; Escrever um artigo de notícias ajuda as pessoas, porque é em uma linguagem mais simples. “Apresentamos esses conceitos (” jornalismo via programação de computadores “, a importância de dados legíveis por máquina, etc.) em vários eventos do jornalismo-indústria e, inevitavelmente, alguém faz essas perguntas.
Bem, eu tenho algumas respostas.
Primeiro, a questão de “Isso é jornalismo?” é acadêmica. Os jornalistas devem ter menos preocupação com o que é e não é “jornalismo”, e mais uma preocupação com informações importantes e focalizadas que são úteis para a vida das pessoas e ajudam a entender o mundo. Um jornal deve ser esse: um olhar justo sobre informações atuais e importantes para um público.
Em segundo lugar, é importante notar que não estou fazendo uma proposição de tudo ou nada; Não estou dizendo que os jornais devem se transformar completamente em vastas coleções de dados, abandonando completamente o formato de um artigo de notícias. Os artigos de notícias são ótimos para contar histórias, analisar problemas complexos e todos os tipos de outras coisas. Um artigo – uma “grande gota de texto” – é muitas vezes a melhor maneira de explicar os conceitos. As nuances da língua inglesa não mapeiam fontes de dados fáceis de manipular. (Esta entrada, que você está lendo agora, é um excelente exemplo de algo que não pode ser substituído por um banco de dados.)
Quando digo “os jornais precisam parar a visão de mundo centrada na história”, não quero dizer ” Os jornais precisam abolir histórias. “As duas formas de disseminação de informação podem coexistir e se complementar.
Mas, além da arrogância jornalística, outro problema é que o software atual e a configuração organizacional das companhias de jornal desestimulam esmagadoramente qualquer tipo de “formato especial de informações”. Todo o sistema de gerenciamento de conteúdo de site de jornal que eu já vi é incrivelmente centrado na história. Deseja publicar informações do calendário de eventos em seu CMS do site de notícias? Poste-o como um “artigo de notícias”. Deseja publicar listas de crimes recentes em sua cidade? Ele entra como um “artigo de notícias”. Não há muito a fazer sobre isso, porque Oh, nós investimos tanto nesse CMS e / ou no nosso site de jornal não emprega Qualquer Programador de Computador. (O último dos quais faz tanto sentido quanto um diretor de cinema se recusando a empregar cameramen ou editores de video.)
Quando trabalhei na LJWorld.com, escrevemos um CMS desde o início para podermos lidar com todos esses tipos distintos de informações. (E criamos a estrutura da Web Django para nos permitir manipular novos tipos de informações rapidamente). Mas, antes disso, tínhamos um antigo CMS e nossos produtores noturnos, cujo trabalho era copiar e colar tudo do jornal impresso no sistema da Web, publicaria rotineiramente todos os pequenos recursos especiais do jornal como “artigos de notícias”. A característica do jornal “foto do dia” seria postada como uma história sem texto – apenas uma foto. O recurso “On the Street” do estilo Onion seria publicado como um artigo “artigo de notícias” contendo uma pergunta, quatro fotos e quatro respostas. Cada recurso de jornal recorrente foi postado como um “artigo de notícias”, independentemente de ser realmente um artigo de notícias – simplesmente porque esse é todo o sistema de gerenciamento de conteúdo sabia como fazer.
Este é um problema sutil, e nisso reside o esfregaço. Na minha experiência, quando tentei explicar o erro de armazenar tudo como artigo de notícias, os jornalistas não compreendem imediatamente por que é ruim. Para eles, um sistema de publicação é apenas um meio para um fim: obter informações para o público. Eles querem que seja tão rápido e simplificado quanto possível para levar o lote de informações X e colocá-lo no site Y.
Para jornalistas cabeça de texto: O objetivo não é ter dados limpos – é publicar dados rapidamente, com pontos de bônus para uma interface de usuário agradável.
Para jornalistas cabeça de dados: O objetivo para mim, uma pessoa de dados focada mais no longo prazo, é armazenar informações no formato mais valioso possível.
O problema é particularmente frustrante para explicar porque não é necessariamente óbvio; Se você armazena tudo em seu site como artigo de notícias, o site não é necessariamente difícil de usar. Pelo contrário, é um problema de oportunidade perdida. Se todas as suas informações forem armazenadas no mesmo balde “artigo de notícias”, você não pode facilmente retirar apenas os crimes e traçá-los em um mapa da cidade. Você não pode facilmente pegar os eventos para criar um calendário de eventos. Você acaba estabelecendo o menor denominador comum: um site que sabe como exibir um tipo de conteúdo, uma grande quantidade de texto. Esse site não pode fazer as coisas legais que os leitores estão começando a esperar.
Depois, há a vantagem de serendipity. Quando trabalhei para a LJWorld.com, trabalhamos com os meteorologistas locais para criar um site meteorológico que exibisse a previsão dos meteorologistas nos próximos dias. Eu criei-lhes uma interface da Web que permitiu que eles inserissem a alta temperatura prevista, temperatura baixa e condições do céu – tudo em campos de banco de dados separados. Realmente não havia nenhum motivo para usar campos separados para esses valores além do fato de que o design do site exigia a apresentação das temperaturas de uma cor diferente das condições, e não queríamos que os meteorologistas tivessem que se lembrar de inserir o Códigos de coloração HTML no lugar certo. Mas não foi até vários meses depois que conseguimos alguns benefícios reais de base de dados, quando montamos o Game, um banco de dados exaustivo de equipes e jogos de pequenas ligas locais. (Sim, você leu esse direito.) Criamos uma página para cada equipe de liga pequena e todo jogo de liga pouco, e quando chegou a hora de criar as páginas do jogo, um de nós disse: “Você sabe, esses jogos tendem a chover muito. Seria muito legal se pudéssemos exibir a previsão do tempo para cada jogo. “E, boom! Um de nós percebeu que já tínhamos dados de previsão do tempo, em um formato agradável, com corte e dados, graças ao nosso banco de dados preenchido pelos meteorologistas. Dez minutos depois, nossas páginas exibiram previsões meteorológicas. Acaso.
Lise Brenol 