O jornalista Marc Frons, “chief technology officer” de operações digitais do New York Times, responde a perguntas dos leitores. Entre outros assuntos, fala da integração entre os tecnólogos (technologists) e os jornalistas:
Shortly before I joined The Times, the print and digital sides of the newspaper decided to merge their operations — what we call “integration.” I’m sure there were many people who thought this was a terrible idea, that the ink-stained Luddites of the print newsroom (the Web stereotype) and the arrogant, illiterate Digerati (the print stereotype) would never find common ground.
We’ve certainly had our moments. But the truth is integration has been a huge success. I don’t think any of the things we have achieved over the past two years in terms of interactive journalism, technology or our business would have been possible without it.
There are many reasons for this, and a few key individuals who made it all work. But as someone who has long had a foot in both worlds, my perspective is we have succeeded largely because beneath the obvious cultural (and sartorial) differences, journalists and technologists are really kindred spirits. The best of them, anyway, are passionate about their calling (because it’s much more than just a job), are skeptical of conventional wisdom and focus groups, like to trust their instincts, yet pride themselves on their analytical abilities and their almost religious devotion to the facts. And for disciplines where teamwork is vitally important, they also tend to share an individualistic, sometimes anarchistic bent, which as a manager is either a constant source of aggravation or amusement, depending upon how much sleep I’ve had the night before. In the end, technologists and journalists like to get stuff done, which makes them ideally suited to one another.
The trouble is they view the world from opposite ends of the telescope. The instincts that serve you so well as a print journalist often don’t work online (and vice versa) because the rules of the mediums are so different. But once journalists and technologists start to breathe the same air, they begin to understand one another. While we still have some distance to travel, that has certainly been the case at The Times.
We’ve accelerated this process through some fairly unconventional means. Last year, we formed a new software group called Interactive News Technologies, a team of journalistically minded techies (led by a technically minded journalist named Aron Pilhofer) who sit side by side with our editors, reporters and graphics journalists in the newsroom and produce Web applications at daily deadline speed. They have already been responsible for some terrific applications that use interactive databases that we wouldn’t have able to build as fast otherwise, or perhaps at all because we would not have had anyone focused on developing that technical capability.
While there will always be differences between journalists and technologists, I think we are in the midst of a vast generational shift. In the not-too-distant future, the majority of working journalists will be “digital natives” who cannot remember a world without the Internet, and who read most of their news online. That is bound to lead to some profound changes as this Facebook generation begins to assume leadership positions in newsrooms around the country. This next generation is going to have a much greater understanding of the possibilities and limitations of technology, as well as an innate sense of what works (and what doesn’t) online.
Em outra resposta, disse o que vem por aí:
In the next few months, we hope to announce more innovations in multimedia and data visualization as we link these platforms to our strategy around user generated content and APIs.
E também mostrou como o NYT entende e trabalha pra usar ao seu favor as mudanças causadas pela web no jornalismo, principalmente na questão bloco de texto vs. informação estruturada:
In the past, we treated all this structured information as plain text. So there was no way to search, sort and filter all this information or link it to anything else. There was no useful metadata (a term that basically means data about data), no “tags” or other information to help our online readers find all this rich information we were producing every day.
But for the past several months, we’ve been building systems to ensure that everything we produce is tagged at the outset so that it can be placed in a database where it can then be accessed by software developers using the APIs I talked about earlier. We’re doing this not just for structured data but for articles as well so that there will be much richer and more descriptive information about everything we’re ever written going all the way back to 1851.
We have many ideas around creating much richer and more collaborative Times Topics pages and more enhanced articles and multimedia in general. Much of this is necessarily vague because we’re not yet ready to talk about all the things we’re doing in this area. But part of the idea behind creating this vast database of articles and data, making it available, and then giving people the tools to manage it and recombine it with other information, is to tap into the incredible creativity made possible by the Web. We’re really not sure what applications our own developers, external developers and our readers will create using all this information — and to me, that’s the beauty of it.
Tenho falado aqui do livro “Here Comes Everybody”, do Clay Shirky. Desde 2005 ele vem discutindo as idéias do livro e resume quase tudo - com os mesmos exemplos - nesse vídeo:
Continuação do resumo das partes mais interessantes do livro “Here Comes Everybody”, do Clay Shirky. Leia a parte 1 aqui.
A facilidade extrema de publicação possibilitada pela internet transforma qualquer um em uma editora. De fato, quem escreve na internet tem o potencial de atingir qualquer pessoa no mundo todo. Mas Shirky alerta para um fenômeno que muitos estudiosos da comunicação online deixam passar: a maioria das pessoas que escreve em blogs, no twitter ou em redes sociais não está nem aí para o público global. O público delas é a roda de amigos.
Se você fuçar nos scraps das pessoas no Orkut vai encontrar um monte de piadas internas, referências a amigos mútuos e outras informações que só interessam ao pequeno círculo de envolvidos na conversa. É como entreouvir o papo de alguns adolescentes desconhecidos na praça de alimentação do shopping.
“A maioria do ‘conteúdo produzido pelo usuário‘ não é ‘conteúdo‘ coisa nenhuma, no sentido de haver sido criado para consumo geral. É como dizer que uma ligação telefônica entre você e um parente é ‘conteúdo produzido pela família‘”
A partir daí surge a distinção entre mídia de comunicação e mídia de difusão. A mídia de difusão, que inclui rádio, TV, jornais e filmes, é como um megafone, facilita a distribuição da mensagem para que todos a recebam. A mídia de comunicação, por outro lado, facilita a conversa de duas vias e tem como exemplos o telegrama, o telefone ou o fax.
A mídia de comunicação sempre foi entre um emissor e um receptor, no padrão um-para-um. Eu falo e você escuta, em seguida você fala e eu escuto. A difusão seguia o padrão de um-para-muitos, e os receptores não tinham como responder.
O padrão que não existia até pouco tempo atrás é o de muitos-para-muitos, e o e-mail foi a primeira ferramenta simples e verdadeiramente global a seguir este padrão.
Conforme a tecnologia evolui, as diferenças entre os padrões evaporam e áreas de transição entre eles surgem. Antes, o meio bastava para se determinar o conteúdo da mensagem. Ler “Eu te amo” em uma carta é bem diferente de ouvir “Eu te amo” na fala de uma personagem na televisão. A carta é o padrão um-para-um e a TV um-para-muitos. Não tem como confundi-los. Mas este limite tão claro acaba ficando nublado na internet.
“Antes da internet se tornar ‘mainstream’, um esforço considerável era necessário para dizer algo que fosse ouvido por um número significativo de pessoas, e por isso consideramos todo material disponível publicamente como material oferecido diretamente para nós. Agora que o custo de colocar coisas em uma mídia global desmoronou, muito do que é postado em um dia qualquer está em público mas não é para o público.”
Por enquanto é isso, mas o livro não acabou ainda. Acho que rende mais um post ou dois para breve.
“I think I’ve been using Python for close to 12 years now, and it’s been my favorite language for much of that time…” “I think the combination of choices offered by Django + TurboGears covers people’s needs better than a single monolithic approach, and Django appears to be the right solution for a large portion of the applications out there.”
“But what makes Django an even greater work of art is that knuckle-dragging, mouth-breathing, not-very-good journalism graduates from small midwestern states (ahem) can learn just enough to build something they can be proud of.”
5. Porque Guido van Rossum, criador do Python, gosta do Django:
“My personal favorite — and I expect that that will remain a personal favorite for a long time — is something named Django. … I highly recommend it.”
6. Porque o Google (onde o Guido trabalha) resolveu apostar pesado em Python+Django com o AppEngine:
“With Google’s employment of Python and Django as a first class citizen in its AppEngine infrastructure [...] this development has the potential of trusting Python into the limelight.”[fonte]
7. Porque Python é uma das linguagens cuja adoção tem crescido constantemente pelo mundo:
Ocupa a 7ª colocação no ranking do índice Tiobe de julho de 2008, com quase 5% do total de linhas de código escritas.
“Because journalism and computer science don’t normally go together, I’ve had some success in this silly little niche of employing Web development in news organizations — ‘journalism via computer programming.’”
“A apresentação é um passo a passo de como a pesquisa de um repórter em tabelas do Word pode se tornar uma aplicação web interativa com mapas e gráficos em apenas dois dias. O James Bennett usa Python e Django pra isso.”
Terminei esses dias de ler Here Comes Everybody, do Clay Shirky, um cara que consegue clarear e dar um sentido bem coerente pra muitos conceitos que pairam por aí neste “mundo conectado”. Faço aqui um resumo das partes que achei mais interessantes. Provavalmente nos próximos dias posto uma continuação.
Duplas sertanejas vêm e vão, mas seus integrantes continuam por aí, se juntando em novos pares e criando novos sucessos. Você já percebeu que Tião do Carro, por exemplo, já fez dupla com Odilon, Santarém, Pagodinho, Jackson Antunes e Mulatinho? E que Carreirinho já gravou músicas com Carreiro, Tião Carreiro, Zita Carreiro, Zé do Carro, Zé Carreiro, Zé Matão e Sulino?
Para expor essa relação interessantíssima, fiz um navegador das parcerias musicais sertanejas e da MPB, que pode ser acessado aqui. Peguei todo o acervo da Rádio Cultura AM, que tem mais de 12 mil músicas brasileiras e separei todos os intérpretes que continham ” e ” no nome. Vieram todas as duplas sertanejas, mas também alguns intrusos como “Chico Science” e “Nação Zumbi”. Acabou ficando engraçado e deixei os metidos por ali também.
Pra quem não sabe, tive acesso a esses dados porque agora trabalho no Radar Cultura. Aí fica fácil fazer essas brincadeiras.
Atualização: Mal coloquei no ar e já recebi um monte de reclamações. Vamos a elas:
“sim, mas cadê bruno e marrone? zezé di camargo?” “milionário e josé rico só permutam entre eles, e eles já fizeram dupla com vários outros”
Tá faltando coisa, eu sei. Mas se não tem ali é porque não tem no acervo da Cultura AM. Se você quiser que eles coloquem na programação é só entrar lá no Radar Cultura e pedir.
Atualização 2: Agora o post também tem uma versão “oficial” no blog do Radar. Melhorei bastante coisa no navegador de lá, vale a pena dar uma olhada.
O pessoal de uma pós-graduação da Cesusc me pediu e fiz uma apresentação rápida pra eles remotamente. Falei pelo Skype e pela webcam vi a sala onde foram exibidos os slides abaixo.
Eles discutiam o texto na internet e como a pirâmide invertida se encaixava nessa história toda. Eu aproveitei pra bater novamente na tecla do jornalista-programador
Não me perguntem o porquê do nome, mas o fato é que julio é esse mapa em Flash que conversa com Javascript. Ainda está em desenvolvimento, mas já uso pra alguns projetos e resolvi liberar todo o código no Google Code pra quem quiser usar.
Também tem uma página de exemplos aqui que é um manual de instruções.
Para ter uma idéia de como o mapa funciona, dê uma clicada pelos estados para experimentar o zoom:
julio
Uma das aplicações do julio pode ser a exibição de gradações de cores no mapa de acordo com alguns valores. Peguei o preço médio do litro de gasolina em cada estado aqui e passei pra variáveis dentro do Javascript. E com isso basta um link para alterar tudo no julio: Clique aqui para ver no mapa. Passe o mouse sobre os estados para ver os valores. Quanto mais escuro, maior o preço da gasolina.
Não esqueça, dá pra brincar bastante com o mapa na página de exemplos.
A idéia principal é trocar experiências sobre técnicas de coleta, processamento e visualização de informações no Brasil.
O termo ‘dados públicos’ é usado aqui de uma maneira bem flexível, abrangendo dados disponíveis na rede em geral.
Veja o theinfo.org para uma iniciativa internacional desse tipo.
COLETA:
Scrapers, robôs de varredura, crawlers, dumps, shapefiles, arquivos xls, csv, txt, pdf(!) .
Ferramentas existentes, troca de scripts, liberação de iniciativas particulares em código aberto
PROCESSAMENTO:
Geoprocessamento, cruzamento, limpeza dos dados, scripts, etc.
VISUALIZAÇÃO:
Gráficos, mapas, tabelas, qual a melhor forma de mostrar tudo isso?
Questões relacionadas
Repositório colaborativo de dados públicos brasileiros. É viável? E uma API de acesso a este repositório?
A transparência/cobrança política pela web passa pelo acesso e cruzamento de dados públicos.
Mobilização social para a abertura a desenvolvedores (APIs e web services) e simplificação da consulta a dados públicos que - por lei - devem estar disponíveis.
Pergunte, sugira e colabore. Qualquer um pode participar.
Muita gente já comentou o lançamento do EveryBlock, um site sensacional feito em Django por um dos criadores do próprio Django. Mas uma coisa que ainda não vi ninguém comentar e que achei interessante foi a ausência do Google Maps nele.
Tenho pensado em trocar o Google Maps por algo mais leve há algum tempo, e com o EveryBlock vi que existe um concorrente a altura, o OpenLayers. Não sei detalhes de como o Holovaty implementou, mas cada imagem que compõe o mapa é servida por um arquivo Python (tilecache.py).
Esse fato é significativo porque demonstra que o Google Maps não é mais unanimidade para a construção de mash-ups geográficos, moda iniciada pelo próprio Holovaty usando Gmaps em 2004 com o chicagocrime.org.
Outra surpresa interessante é que o EveryBlock usa jQuery. Como eu também tenho me dedicado a Django e a jQuery é bom saber que os dois frameworks andam conversando bem por aí.
Sou um jornalista programador que de vez em quando escreve alguma coisa a ver com esses assuntos ou qualquer coisa que interesse no momento. RSS dos posts RSS dos comentários
