Multiplexado

Oi pessoal. Escrevo um fast track para quem se deparou com o processo de decidir sobre compressão para vídeos na internet. Este texto, apesar de conter conceitos genéricos, considera principalmente a plataforma Adobe Flash Player - ambiente líder de mercado para a construção de sites com vídeo altamente interativo.

O texto não é voltado para especialistas. Se você trabalha exclusivamente com compressão de vídeo, já sabe tudo o que está dito aqui. Compilei apenas algumas coisas que profissionais de diversas outras disciplinas as vezes me perguntam. O foco de leitura é para Diretores de Arte, Arquitetos de Informação, Diretores de Criação, Redatores, Profissionais de UX, Produtoras de vídeo off-line, ou geeks que gostem de ler sobre qualquer coisa técnica interessante.

Que formato usar? FLV (VP6), H.264? Garçom.. o cardápio!

Para responder essa pergunta, é necessário considerar aspectos técnicos. Não existe um formato absolutamente melhor do que o outro, e sim o mais adequado. É nisso que esse texto tenta ajudar.

Temos duas grandes possibilidades de compressão na plataforma: o VP6 e o H.264.

O VP6 é o formato mais antigo, desses que a gente conhece por arquivos com extensão FLV (apesar do Flash Player não se orientar pela extensão do arquivo, e sim pela assinatura interna do mesmo).

O H.264 é o novo formato, suportado à partir de Dezembro de 2007 pelo Flash Player Update v3 (9.0.115 em diante). Muita gente coloca o arquivo no ar com outras extensões, mas usualmente é ".MOV" mesmo.

Se quiser saber a compressão real dos vídeos de um site, não vá pela extensão. Baixe o vídeo para sua máquina e use o "Show Movie Inspector" no Quicktime.

Sobre o H.264, uma versão de Flash Player normalmente demora 12 meses para alcançar 90% de penetração no mercado. Tecnicamente, alcançamos esse número em dezembro de 2008. Logo, 2009 é um bom ano para consolidarmos a migração para H.264.

Existe também o formato H.263, também conhecido como Sorenson Spark. Mas esse já tá velho. Vamos tirar o Spark da jogada por ele ser anterior ao Flash 8.

Para não ficar colocando tudo em texto, vou apelar para a tabela mandrake de comparação dos formatos. Preste atenção nos 'prós' e 'contras' de cada uma das opções.

	On2 VP6 (FLV)	H.264
Suporte	A partir do Flash Player 8 (Agosto de 2005).	A partir do Flash Player 9.0.115 (Dezembro de 2007)
Quem mantém?	On2 Technologies	ITU-T Video Coding Express Group (VCEG)
Discurso de venda	Funciona bem em máquinas antigas e tá bem suportado, podendo ainda ser atrativo se houverem restrições técnicas.	Formato fodão capaz de fornecer alta qualidade e bitrate baixo em relação a padrões existentes. Bom suporte a vídeo em baixa e alta resolução.
Melhores softwares de compressão	On2 Flix Pro, ferramenta da própria criadora do Codec - oferece compressão ANIMAL. Suportado também pela maioria dos softwares profissionais (QuickTime Pro, Final Cut, etc). EVITE usar o Adobe Video Encoder, é horroroso.	Compressão bem feita por qualquer software que suporte o Codec H.264. Amplamente suportada por compressores profissionais de vídeo.
Vantagens que só ele tem	Suporte a Alpha Channel (vídeo com transparência). Até o momento da escrita nesse texto, H.264 não oferece essa opção. Suporte a embedded cue points (cue points um pouco mais preciso do que os que você coloca via código). Suportado no Flash Lite 3 da Adobe, para uso em plataforma móvel. Para uso em máquinas mais antigas, apresenta performance de execução melhor (dropa menos frames). H.264 exige mais da máquina.	Menor perda de saturação do que o H.264 - cores mais vívidas. Melhor relação de bitrate/qualidade de reprodução em todos os trocentos mil testes que eu fiz, perdendo por pouco apenas em algumas ocasiões específicas para o VP6. Em máquinas mais modernas (processadores acima de 2GHz), oferece opções para maravilhosa reprodução em alta definição.
Pontos fracos	Tá velho. Se fosse bom, a Adobe não teria substituído, apesar de continuar suportando o formato. Saturação. Dá uma "lavada" característica nas cores. Custo do Flix Pro - Licença da ferramenta de compressão ainda custa caro.	Suportado apenas em quem tem Flash Player 9.0.115 em diante. O Flash Player gasta muito processamento "desencodando" o H.264. Se você faz vídeo interativo e mistura com outras técnicas de alto processamento (ex.: misturar vídeo com Papervision3D) a performance de execução será execrável em algumas máquinas. Não suporta vídeo com transparência (canal alpha), pelo menos até a data de escrita desse texto. Não suporta cue points. Conseguimos implementar isso na mão, deu um pouco de trabalho, mas funcionou bem. Mas é palha a ausência do suporte nativo.

A tabelinha acima pode ser um bom ponto de partida para tomada de decisão. Por favor, considere usar o H.264 sempre que possível: na maioria das vezes, compensa.

A lista de promessas blogais está aumentando...

E no próximo texto, falarei sobre parâmetros de compressão (bit rate, audio settings, etc), de maneira orientada a quem já decidiu que formato usar. Quando o texto ficar pronto, faço o update desse aqui.

Agora deixa eu voltar a trabalhar um pouco. Abraços, e obrigado!

Como prometido, escrevo um pouco para falar sobre o Product Definition Statement (algo como "Declaração de Definições do Produto", em tradução tosca deste que vos fala). A criação de um PDS é uma tarefa sugerida dentro do iPhone Human Interface Guidelines, que estou comentando aqui no blog.

Um pouco sobre Product Management antes de voltarmos ao PDS

Um tempo atrás (2007) eu tive contato com a disciplina de "Product Management" (Gerenciamento de Produtos). Comecei a ver anúncios sobre esse tipo de vaga no exterior, mas especialmente uma vaga da época para Product Manager no Google Brasil (tá, eu confesso: já quis trabalhar no Google).

Há! Então perguntei ao próprio Google o que diabos seria essa coisa e acabei encontrando um texto velho do Jeff Lash que explicava o que era essa disciplina: Transitioning from User Experience to Product Management. No intuito de ajudar quem não quiser ler todo o texto do link, preparei uma manjada tabelinha com o resumo das idéias de Jeff:

Gerenciamento de Projetos	Gerenciamento de Produtos
Muito bem difundido no Brasil.	Somente bem difundido lá fora ou em empresas internacionais com filial por aqui.
Cuida de recursos, prazo, escopo, andamento da execução do planejado, risco, resolução de problemas, etc.	Cuida da estratégia de um produto, com visão de longo prazo. Traduz essa estratégia em um roadmap. Identifica como executar essa estratégia. Olha para o mercado para identificar as necessidades que o produto atende.
Entende que o projeto precisa responder a questões de fiabilidade/custos/lucro (there is no free lunch). Entende que são importantes os processos de gerenciamento e controle da execução para que tudo dê certo no final.	Entende que um produto precisa de um propósito e de um mercado para ser efetivo. Garante que a estratégia esteja sendo seguida, e consequentemente, que o produto esteja tomando um rumo certo.
Pensa no sucesso do projeto pelo ponto de vista de cumprimento das atividades previstas (término e aceite do projeto).	Pensa no sucesso do projeto pelo alcance pleno dos objetivos do produto em seu mercado. Sucesso é o produto bombar de fato, não apenas ficar pronto.
Não cobre atividades de Gerenciamento de Produto.	Não cobre atividades de Gerenciamento de Projetos. É absolutamente complementar, sem sobreposição de atividades. As duas disciplinas deveriam trabalhar juntas para que o projeto fique foda.

Se você vai fazer uma aplicação para iPhone (ou qualquer outra empreitada pessoal), precisa do mínimo de Gerenciamento de Produto para que o seu esforço seja efetivo

Esse é o motivo de eu ter abordado esse tópico. O Product Definition Statement que a Apple sugere nada mais é que um artefato realmente simples que te pode te ajudar com algumas perguntas que te ajudam a fazer o fundamental em Product Management - seja hobista ou profissional, para que você contemple ao menos um basicão de planejamento antes de sair por aí já executando o projeto.

Exemplo de Product Definition Statement

Elaborei um exemplo hipotético de PDS que talvez seja interessante para alguém tomar como ponto de partida. É "brainstórmico", rápido e faceiro.

Idéia basica: É um exercício hipotético imaginando um aplicativo de iPhone que me permita consultar informações sobre a discografia dos Beatles.

Então vamos ao PDS para o aplicativo dos Beatles:


Simples, né? Temos um exemplo basicão de PDS. Espero que gostem e até a próxima parte dos textos. Valeu!

Ultimamente tenho usado o termo "Planejamento de Produção" ao invés de simplesmente "planejamento" para referenciar as atividades que se relacionam com o arranjo produtivo de um projeto.

O intuito é para diferenciar a parte de produção (que também exige um planejamento interno em grandes projetos) da disciplina de "Planejamento Publicitário/Planejamento de Comunicação", normalmente presente em Agências (deixamos um pouquinho de fora o Planejamento Estratégico, dado que esse blog conversa prioritariamente com o mercado de propaganda).

Planejamento de Estratégia/Comunicação e lidar com inteligência corporativa é uma coisa que todo mundo acha que sabe fazer. Mas eu gosto de trabalhar o lado pedreiro da coisa, sei que não tenho competência o suficiente em inteligência =P e fui cuidar de "Planejamento de Produção", que é o que trabalho de maneira mais proficiente. O Planejamento de Produção é absolutamente complementar ao de Comunicação porque complementa e instrumentaliza o que foi concebido nas etapas estratégicas de um grande projeto.

Planejamento de Comunicação/Publicitário	Planejamento de Produção
Estratégia e inteligência	Arranjo produtivo para execução
Início do projeto	Etapa produtiva do projeto
O que fazer?	Como fazer?
Junto ao cliente	Junto a parceiros de produção
Ênfase em descoberta e desenho de ações	Ênfase em instrumentalização de ações
Melhor executado em Agências	Melhor executado em Produtoras
Posterior acompanhamento	Posterior sustentação e suporte
Posterior análise de métricas e medições	Posterior otimização e evolução

*Concorde, discorde, comente e me ajude a completar essa tabela.

Paradigma contemporâneo de produção de propaganda e conteúdo interativo

Na visão mais atual da produção de interatividade, as agências passam a ser pólos de Planejamento e Criação. Estabelecem enlace por projeto com produtoras para atividades especializadas, de acordo com o tipo do projeto. Nesse "pool", entram produtoras de áudio, vídeo, tecnologia e inovação, 3D/Assets/CGI, pós-produção, etc.

Em tempos mais remotos, a produção interna das agências aguentava o tranco de produção. As entregas básicas seriam "banners" e peças de campanha, hotsites "slideshow" (para aqueles hotsites que mais parecem apresentações em PPT por falta de interatividade), sites e outros produtos simples. O arranjo redator + diretor de arte + interface/montador/animador + cara da tecnologia resolvia 90% dos problemas. E fomos reconhecidos internacionamente por fazer muito bem isso para as idéias da época.

Na realidade globalizada e competitiva, uma grande idéia que não for bem produzida e sustentada perderá força e poderá não alcançar os resultados desejados.

É muito difícil "inchar" a produção das agências para absorver a quantidade de disciplinas necessárias para que se tenha um "repertório" interessante de soluções, principalmente na realidade econômica atual. Só é viável manter internamente o profissional que tiver uma recorrência de trabalhos que justifique o que a empresa investe nele do ponto de vista salarial.

E a produção nas agências, principalmente as digitais, está oprimida pelo raciocínio HORA/HOMEM e pelos insuportáveis timesheets e mecanismos de controle de projetos. Eu já estive nessa realidade de opressão, e produzir com o rabo preso é uma merda.

Em produtoras, os profissionais mais especializados ficam disponíveis para um pool maior de agências, o que resolve um problema econômico com implicações tão intricadas que daria um outro texto e que não vou comentar agora.

Algumas agências como a Gringo possuem investimentos maiores em produção interna e conseguem ótimos resultados técnicos. Mas isso faz parte de uma estratégia de diferenciação que elas possuem, com um alto investimento em excelência técnica e times mais enxutos com muita gente boa e altíssimo grau de comunicação direta. E eles não nóiam com "timesheet" como se fossem fábrica de software.

Não acredito (e espero estar errado) que seja possível implementar isso que a Gringo está fazendo em estruturas maiores sem perder a "pegada". O que eu vejo de mais comum são algumas agências renomadas tentando dar murro em ponta de faca montando grandes equipes para alocação interna, grandes disputas internas por pessoas e recursos, grandes demissões quando a agência perde uma conta, etc.

Em contrapartida, um outro grupo de empresas também renomadas como AgênciaClick, Almap, Salem, OgilvyInteractive, MatosGrey e Sinc (só para citar algumas e já sendo injusto com outras) estão recorrendo ao apoio de produtoras para o estabelecimento de contextos para a produção de trabalhos divisores de águas para a indústria nacional.

Na minha leitura, a retomada da liderança criativa brasileira passará necessariamente pelo enlace de grandes agências com grandes produtoras, para que possamos dar as nossas grandes idéias um grande contexto de execução e produção. Tem "grande" demais nesse período, ficou horroroso do ponto de vista de redação, mas é que eu preciso dessa ênfase nessas idéias.

Projetos matadores exigem um bom contexto de planejamento de produção

Um fenômeno interessante de observar são as fichas técnicas dos grandes trabalhos da atualidade. Estamos cada vez mais perto de times de cinema na produção interativa. Grandes projetos com abordagem transdisciplinar como o "case" ainda em andamento do Punto T-Jet no BBB 9 (AgênciaClick, Colmeia, TAXILabs, [comente se sabe de outras produtoras envolvidas]).

Estou no aguardo do vídeo de making-of do que talvez tenha sido o maior arranjo produtivo da história da produção digital brasileira UPDATE:Saiu o Making of do T-Racer, veja aqui. Já tive contato com uma prévia desse material no Quarto Almanaque de Criação que rolou aqui em Brasília, com a gravação ao-vivo do podcast 3.8 do enxame.tv. Para mais informações sobre este case, siga o link e aguarde por novidades, porque os caras disseram lá no evento que a ação ainda não acabou. É provável que eu escreva algo específico sobre a parte de produção desse projeto que infelizmente não participei (como diz o Pontual: #invejabranca) =)

Putz...

Mais uma vez pirei na batatinha e escrevi demais. Mas é normal com os assuntos que me apaixonam. Nos próximos dias voltarei com a série sobre planejamento de produção para aplicativos iPhone e mais alguma coisa sobre o tópico desse texto aqui. Muito obrigado pela paciência e pelo retorno que vocês tem dado em relação ao que venho escrevendo aqui. See ya!

"Softwares e filmes seriam expressão de idéias, relacionamentos e comportamentos, numa cadeia de retroação que dissemina expertise, oportunidades e motivação, perpassando a equipe e o ciclo de vida do produto."

Mês passado alguém tuitou, eu li, anotei e perdi quem me passou essa informação - um artigo brilhante da Cooper que quebra a analogia padrão do desenvolvimento de software.

Estou há mais de dez anos ouvindo que a construção de programas de computador seria um processo análogo à construção de uma edificação. E o artigo provoca: Fazer software NÃO é como fazer prédio.

Cooper Journal: Software is a movie, not a building
(Imagem original do artigo)

Aprendemos a sempre pensar em construção civil na hora de compararmos a produção digital em geral. Eu mesmo sempre usava analogias como "o wireframe é como a planta baixa do seu projeto", "o framework é a como a fundação do teu software", "vamos primeiro reformar a fachada do teu site para depois reprojetarmos as funcionalidades internas", etc. É inegável que qualquer cliente, por mais "leigo" que seja, entende melhor quando estabelecemos esse tipo de comparação.

Mas mesmo ao conversar com cliente "pedreiro", o autor do texto desencoraja esse pensamento sobre vários argumentos, entre eles:

• A arquitetura tradicional é linear e sequenciada. Só se entrega a obra uma vez, tal como foi planejada no começo. Já o desenvolvimento de software contemporâneo é iterativo - trabalhamos com diversas entregas intermediárias e permitimos a correção ou mudança de rumo dentro do produto sempre que houver bons motivos para isso.
  
  
• Um operário normalmente não influencia no desenho da obra tradicional, apenas executa tarefas na obra que cumprem um conjunto determinado de especificações. Em times de software em metodologias mais ágeis, o talento individual das pessoas, e a multiplicação desses talentos com a capacidade de trabalho em grupo influencia diretamente o resultado final da obra. Todos os envolvidos, inclusive os programadores, também possuem papel criativo e de produção intelectual no projeto.
  
  
• O autor questiona o modelo obsoleto de métricas da construção civil (material gasto e horas/homem trabalhadas). Pela natureza do trabalho, raciocínio HORA-HOMEM não pode funcionar bem dentro do contexto de produção digital.

Dê uma lida lá no texto. Fico por aqui, senão escrevo mais que o original. Internamente, estou exercitando o raciocínio. Me ajude a espalhar o mantra: "Software is a movie, not a building". Valeu!

Resolvi escrever uma espécie de "resenha" aqui de um documento que estive estudando por esses dias: o iPhone Human Interface Guidelines (pode exigir cadastro no iPhone Dev Center para acesso). Estou comentando sobre a versão atualizada em 4 de Março de 2009, conforme a tabela de revisões do documento. Este documento faz companhia ao iPhone Application Programming Guide como as duas principais fontes de informação para quem está nos primeiros passos nessa plataforma.

Este primeiro texto é focado na parte de planejamento de aplicações para iPhone. O próximo falara especificamente do Product Definition Statement, uma declaração que instrumentaliza bem essa etapa de planejamento e o último destrinchará as questões de desenho de interface de aplicações, na visão da Apple.

Objetivos

O HIG procura te introduzir nos princípios de interface humana e os principais conceitos usados no ambiente iPhone e iPod Touch para que possamos propiciar uma boa experiência aos usuários. Sinaliza claramente os paradigmas que devem ser quebrados em relação a outras plataformas (web, desktop, etc). Em muitos momentos o documento fala que não adianta pegar o que você sabe de web ou de software e tentar colocar dentro do iPhone: as soluções podem ser planejadas e desenhadas da forma mínima que o documento sugere para que os bons princípios da plataforma sejam contemplados.

Imagino que quem já está no mercado de mobile não tenha visto tanta coisa nova no documento. Me lembro de alguns pontos sendo tangenciados em conversas com amigos do INdT (Instituto Nokia de Tecnologia) em período anterior ao iPhone. As pessoas nesses lugares são muito preocupadas com a ergonomia do software que projetam.

Estratégia do documento

Para melhor atingir seus objetivos, o documento se divide em duas partes. A primeira te ensina como planejar seu produto de software para iPhone. A segunda, te ensina como desenhar a interface de usuário da aplicação.

Parte 1. Como planejar software para iPhone

Desaprenda os seus vícios em plataformas anteriores. Não tem mais 1024 x 768 pixels para criar - são apenas 480 x 320 para manter o foco do usuário apenas no que é essencial.

Memória é recurso critico. Se a memoria faltar, sua aplicação vai dar crash. Quem planeja a aplicação deve estar bem informado ou assessorado para não projetar bombas sem viabilidade técnica.

Esqueça o paradigma de janelas. Temos apenas uma tela por vez no iPhone. Quem vem de web talvez não estranhe tanto. Mas quem vem de desenvolvimento desktop muitas vezes está acostumado com o desenho e sobreposição de janelas, 'modais' e outros recursos que não estão disponíveis no aparelho.

Uma aplicação por vez. No geral, quando outra aplicação é aberta, a sua é fechada. É preciso imaginar situações de retorno à aplicação que sejam bacanas para quem está usando.

Sem help para os usuários. Faça direito que o usuário não precisará de ajuda. Use também os controles padrão da plataforma da maneira correta.

São três os estilos básicos de aplicação. E o que você vai planejar estará em um desses estilos:

1. Aplicativos de produtividade - tarefas de organização e manipulação de informação, como o Mail e o iPhoto. Tendem a organizar as informações hierarquicamente em múltiplas views, com interfaces simples e uso de controles padrão do iPhone (a tarefa precisa ser feita de maneira ágil, sem firulas).
2. Aplicativos utilitários - executa tarefas simples com o mínimo de input - quase sempre somente vemos essa aplicação. Exemplos são o Weather e tudo o que parece muito mais um widget do que uma aplicação do primeiro tipo.
3. Aplicativos imersivos - precisou de full-screen, interface e conteúdo rico, esse é o estilo. Aqui se enquadram coisas como games e aplicativos especiais que geralmente escondem a interface padrão do iPhone no intuito de que o usuário passe a entrar mais no mundo da aplicação. O conteúdo pode ser volumoso, mas não é hierarquizado. É apresentado em um contexto de game-play, história ou experiência mais imersiva.

Escolha um dos estilos acima, e pense na melhor forma de apresentar as informações de acordo com o foco da tarefa principal de sua aplicação. Na dúvida, projete do jeito mais simples.

Os princípios de planejamento

Faça um bom uso de metáforas do mundo real. Assim, usuários novos podem entender rapidamente como sua aplicação vai funcionar.

Ofereça algo tangível para as pessoas manipularem, elas gostam. Aproveite a característica do Multi-Touch do iPhone, onde a pessoa virtualmente "mexe" no objeto na tela, e não apenas "aponta" para ele, como no caso do mouse em um computador. É muito mais intuitivo manipular diretamente do que apontar, então vamos explorar bem isso.

Use a forma de listas sempre que possível para facilitar a escolha das pessoas - aquela forma campeã que aproveita bastante o multi-touch também.

Retroação - para cada ação do usuário, gere uma resposta imediata que responde ao que a pessoa fez.

Dê o controle ao usuário. Ele é que deve iniciar controles e ações, e não sua aplicação. Dê a oportunidade da pessoa cancelar operações, e peça confirmação antes de dar a opção dela fazer algo potencialmente destrutivo.

Forneça integridade estética - não é questão somente de ser bonito, mas de oferecer estética consistente ao longo do uso da aplicação.

O Product Definition Statement

Nessa primeira parte do documento, é apresentada uma proposta de criação de um Product Definition Statement. Algo como uma "Declaração de Definições do Produto", com uma estrutura pré-sugerida. Resolvi comentar o PDS em um novo texto (em separado) por ter gostado muito da proposta concisa. Adotei esse "artefato" no meu repertório de soluções não só para iPhone, mas também de outras plataformas. Por favor, aguardem que logo publico isso UPDATE: Escrevi o texto: leia em "Sobre o Product Definition Statement, a disciplina de Product Management e outras coisas mais".

No mais, fico por aqui mandando abraços a todos, valeu! =)

Ontem o @rafabarros postou em seu Twitter a seguinte questão:

"Aonde você vê interações diferentes, além do FWA, qual suas referências?"

O Rafa fez a pergunta para todos os seus followers. Achei a questão pertinente e fiz uma lista de algumas fontes de inspiração que utilizo.

Esse post leva uma carga pessoal muito grande, por favor, estou dividindo visões que talvez possam ser pertinentes para alguém. Fique a vontade para contestar se for o caso. =)

Vamos aos itens de inspiração:

1. Gosto de FWA, mas vejo somente quando alguem indica pontualmente

O FWA todo dia retorna um site bom. Isso gera um problema para mim: Analisar decentemente um site bom todo dia custa muito caro.

Para evitar esse trabalho, confio em uma rede de pessoas composta de contatos e amigos que me mandam links com os sites imperdíveis do FWA para que eu possa "decupar" os que interessam com calma, sem dispersar energia.

Um certo cuidado que também tomo com sites como o FWA é que é uma referência que já vem muito processada. Olhar um site do FWA é meio como usar um retrovisor: de certa forma aquilo já passou. Eu entendo e compartilho da inquietude do Rafa Barros pela busca de outras referências.

2. TV e Cinema

Boa parte do tempo que eu passo vendo TV a Cabo, fico observando soluções gráficas que os grandes canais usam para apresentar informações. Um exemplo recente de exploração dessa linha foi a cobertura das eleições americanas. Sei que a parte política é importante. Mas eu tava absolutamente vidrado nos múltiplos planos de informação que a TV usou (barras on-screen, projeções nos cenários, superfícies interativas e até hologramas).

Saindo um pouco do data-visualization, outra coisa que presto muita atenção é no uso de transições pela TV. Em qualquer ambiente gráfico profissional, nenhum elemento simplesmente aparece na tela. Tudo se constrói ou vem de algum lugar por algum motivo. A TV já trabalha isso há mais tempo que a internet. Falando nisso, como tempo é muito importante na TV, as transições de interface dos bons canais conseguem ser bonitas e ao mesmo tempo ágeis, enriquecendo a mensagem que precisa ser transmitida naquela ocasião. Não adianta o mestre Zeh Fernando nos dar um puta Tweener e a gente não ter condições de usá-lo por falta de "olho" treinado.

A parte do Cinema tem sido algo bastante novo para mim: Com a ocorrência cada vez maior de vídeo profissional em nossos trabalhos, estou começando a treinar a percepção de enquadramentos, planos e outras coisas técnicas que passavam batidas aos meus olhos. Isso tem me ajudado principalmente nos exercícios de 3D realtime sobre vídeo que experimentamos nos dois últimos jobs da casa.

Esse flerte com o cinema tradicional é importante e inspirado por algumas coisas lidas sobre estúdios como a Pixar, que usa a prática de simulação de câmeras e aparatos reais de um set de cinema nos ambientes virtuais de seus filmes - a expressão de uma linguagem - não o posicionamento arbitrário de cameras impossíveis que um ambiente digital permitiria. Em 2009 quero exercitar esse olhar para ter melhores condições técnicas de incorporar esses elementos em interfaces mais modernas.

3. Games

Essa referência é a mais óbvia. Hoje eu tenho um Nintendo DS e um Nintendo Wii e gasto um bom tempo analisando menus e soluções de interatividade antes de começar a jogatina. Comecei a prestar mais atenção nisso depois de um texto do Ted Nelson que li em 2006, onde ele observava o fato das interfaces de software serem horríveis e as de games legais. Segundo Nelson, "Os caras que criam videogames gostam de jogar videogames". Isso explicaria o fato das interfaces serem ágeis, rápidas e vivas. Não vou me alongar porque a inspiração pelos games é meio óbvia =).

4. APIs, experimentos, libraries brutas

Gosto do exercício de ver material bruto produzido por programadores (bibliotecas, componentes, APIs) e tentar aplicar o "olho de thundera" que possa viabilizar a implementação de alguma nova idéia.

Normalmente trabalhamos em viés humanizado, onde buscamos soluções técnicas que nos ajudem a implementar idéias que alguém da equipe já teve (redatores, diretores de arte, diretor de criação). Mas as vezes é bom quebrar isso e analisar a possibilidade de podemos descobrir avanços técnicos inéditos acessando material bruto.

Dividimos isso com as pessoas de criação para tentarmos conceber algo totalmente novo abrindo novas portas técnicas. A maioria dos novos recursos de plataforma passa um tempo sem que as pessoas achem soluções de uso criativas para eles. Quem desenvolve essas soluções primeiro, sai na frente e obtem bons resultados. Por isso talvez seja legal estarmos sempre por dentro de novos features nas plataformas em que trabalhamos (de preferência antes que alguém ganhe FWA, Cannes ou algo parecido explorando essa pegada).

Dessa forma, a gente consegue participar ativamente do tão falado throughput criativo, alimentando a galera de criação com novas possibilidades técnicas.

5. Impressos, arte

Venho pegando gosto em fuçar em anuários, material de tipografia, livros de referência de direção de arte e material impresso. O movimento me atrai. E em bons trabalhos impressos é possível perceber movimento mesmo com o papel a zero FPS.

Pois bem: seria mais fácil de me achar na Bienal do que no Campus Party ou algo parecido. Longe de mim querer bancar o entendido - sou um ignorante em termos artísticos. A única linguagem que eu conheço um pouco mais é a música, pelo fato de ser músico amador já faz um tempo. Mas até a Bienal que eu saí reclamando me ensinou alguma coisa. O importante é prestar atenção e tentar olhar as coisas de um jeito que seu cérebro consiga trabalhar para transformar aquele estímulo em uma referência no futuro.

E o mais importante: Vida, relacionamentos, pessoas

No plano pessoal, tento achar elementos físicos com as mesmas virtudes que procuramos no mundo virtual. Ao entrar numa concessionária e sentar num carro mais moderno, o simples exercício de pensar e comparar a disposição dos controles pode ser bom para sua cabeça. É um processo de análise e síntese que te ajuda no seu trabalho. Quem tem dificuldades com modelagem e abstração, pode também decompor o carro funcionalmente. E daí por diante.

Passamos o tempo todo consumindo informação desde o painel de vôos do aeroporto, o fliperama do shopping e o telefone celular. Ter tempo para sair do trabalho e viver normalmente ajuda bastante. Se conseguirmos prestar atenção nessas coisas sem que isso atrapalhe a nossa vida, que beleza! Eu fico 'nerdizando' até em placa de estrada e graças a Deus nunca bati o carro (por causa disso, já bati por outras coisas). No dia que começar a atrapalhar, eu tento parar (prometo).

E tem pessoas que são uma lição a cada encontro. Aprendo todos os dias com amigos, minha equipe e meus clientes. Interagir é ótimo! Quando não é possível, eu observo - gente pequena, gente grande, gente nerd ou old-school. Essas pessoas é que consomem as coisas que a gente programa.

Será que conta como referência podermos observar o comportamento delas?

Rafa, valeu pela inspiração do post! Abraços...