Multiplexado

Fast track para compressão de vídeo para Internet - H.264, FLV e afins

noreply@blogger.com (Fernando Aquino (Nandico)) — Wed, 13 May 2009 19:36:00 +0000

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!

Sobre o Product Definition Statement, a disciplina de Product Management e outras coisas mais

noreply@blogger.com (Fernando Aquino (Nandico)) — Wed, 08 Apr 2009 01:15:00 +0000

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:

PDS - Product Definition Statement - iBeatles Application

Aplicativo desenvolvido para a plataforma Apple iPhone, compativel com iPhone 2.0 ou superior. O objetivo do aplicativo é a apresentação da discografia dos Beatles, com a lista de álbuns oficiais, singles e bootlegs, juntamente com a ficha técnica de gravação das faixas, equipamentos e instrumentos utilizados, músicos convidados, produtores e letras das canções.

Características técnicas

O aplicativo será desenvolvido usando o iPhone SDK for iPhone OS 2.2.1 ou superior, usando a linguagem Objective-C e a API Cocoa, em conformidade com a iPhone Human Interface Guidelines, no estilo "Productivity Application", com organização hierarquizada dos dados para a completude das tarefas previstas no software.

a) Definição
Aplicativo para iPhone que permitirá a entusiastas a consulta de informações de ficha técnica das canções dos Beatles.

b) Inferência de características da audiência

Público acostumado com aplicações na plataforma escolhida.
Público com conhecimento moderado sobre o assunto selecionado (processos de gravação, discografia dos Beatles)
Faixa de idade estimada entre 25-55 anos.
Aplicativo relacionado a informação de entretenimento ou informações técnicas para profissionais de áudio.
Linguagem informal.
Software não-regionalizado, disponível para compra no mundo inteiro. Idioma inglês.
Publico interessado em informações técnicas sobre os álbuns dos Beatles.
Acesso móvel (paradigma mobile).
Modelo de interação "data-driven" (busca por informações)

c) Inferências de expectativas da audiência

Deseja abrir o aplicativo de maneira ágil e ter acesso a conteúdo útil imediatamente (provavelmente ao mesmo tempo que ouve a faixa na função iPod ou através de dispositivo externo como toca-discos ou CD-Player).
Deseja conseguir executar a tarefa em poucos toques na tela.
Deseja a utilização de controles padrão do iPhone os quais está acostumado, especialmente a lista padrão e navegação hierárquica.

d) Atividades principais

Consulta álbuns (oficiais, bootlegs, singles) e versões regionalizadas (lançamentos dos álbuns específicos em países).
Consulta ficha técnica do album.
Consulta lista de canções do album.
Consulta ficha técnica específica de canções.
Consulta ficha técnica de músico, produtor ou técnico envolvido.

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

"Planejamento de Produção" versus "Planejamento de Comunicação" - uma diferenciação necessária e complementar

noreply@blogger.com (Fernando Aquino (Nandico)) — Sat, 04 Apr 2009 14:01:00 +0000

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!

Produção de Software é como um filme, não como um prédio!

noreply@blogger.com (Fernando Aquino (Nandico)) — Wed, 01 Apr 2009 13:24:00 +0000

"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!

User Experience no iPhone - Human Interface Guidelines - Parte 1: Planejamento

noreply@blogger.com (Fernando Aquino (Nandico)) — Sun, 29 Mar 2009 22:50:00 +0000

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:

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).
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.
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! =)

Alguns caminhos de inspiração para programadores em plataformas de conteúdo interativo

noreply@blogger.com (Fernando Aquino (Nandico)) — Mon, 09 Feb 2009 17:12:00 +0000

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...

Trabalho novo no ar - Sandero Stepway

noreply@blogger.com (Fernando Aquino (Nandico)) — Fri, 10 Oct 2008 17:58:00 +0000

Tá no ar o novo site do Sandero Stepway, novo carro da Renault. A Adjetiva teve o prazer de trabalhar com uma galera excelente da Salem Digital, da Mono 3d, da Loud e com Habacuque e músicos do Ludov para o audio do site. Não tenho informações, mas é provável que mais empresas ou pessoas tenham trabalhado nas etapas anteriores a produção - valeu por abrirem as clareiras no terreno que viemos pavimentando (literalmente) nos últimos dias. Conheça a cidade que demos vida, navegue lá no site que você vai entender =).

Enquanto o site novo da Adjetiva não fica pronto, tô usando esse espaço aqui para deixar esse marco e registrar uma coisa do bocado que a Adjetiva vem fazendo em 2008 diretamente aqui do Planalto Central e em ponte aérea e parceiros em São Paulo, Rio e outras capitais.

Abraço especial para a galera da Salem, que conviveu conosco durante muitas horas corridas nos últimos dias.

Agora vamos ver se consigo voltar a postar =). Valeu!

Funções de tecnologia podem ser consideradas de "produção intelectual"?

noreply@blogger.com (Fernando Aquino (Nandico)) — Fri, 04 Jul 2008 14:10:00 +0000

Segue definição que encontrei dentro do Programa de Pós-Graduação em Artes da Unicamp:

"Produção Intelectual são realizações de própria autoria ou em parceria, dadas à publicação, que se materializam em forma bibliográfica (livros, capítulos de livros, artigos em periódicos ou anais...); técnica (apresentação de trabalho, organização de eventos, organizar e/ou ministrar cursos de curta duração, relatório de pesquisa...); artística/cultural (apresentação de obras artísticas, obra de arte visual, arranjo musical)."

Caberia encaixarmos as atividades de tecnologia da informação e seus principais papéis (programador, analista de sistemas, engenheiro de software, etc) como atividades de produção intelectual?

Pegando o conceito acima ao pé-da-letra, talvez não. E levando para o exercício de TI em Fábrica de Software muito menos ainda. Dentro de Fábrica, é certo que se procura a viabilidade de uma maior escala de produção. Isso passa necessariamente pela retirada da inteligência das pessoas e colocação dessa inteligência nos processos. Isso cria uma "casta" de pensadores - normalmente os SEPG's (Software Engineering Process Groups) - e uma Shudra de "fazedores" - as pessoas que, de fato, trabalham nos projetos de Fábrica e seguem os processos desenhados pelos Brâmanes do software.

Partindo desse pressuposto, em ambientes tradicionais de TI, a produção intelectual está concentrada em um pequeno grupo. A maior parte das pessoas dentro do ambiente produtivo apenas executam tarefas pré-programadas. É claro que na execução dessas atividades as pessoas usam suas faculdades intelectuais. O que acredito é que essa hierarquia não favoreça a transferência do conhecimento em todas as direções, prejudicando sim as organizações a longo prazo.

Essa reflexão sobre Brahmin, Shudras ou até mesmo os Párias faz parte de uma crítica pessoal sobre a indústria brasileira de software. Insistimos em copiar o modelo de desenvolvimento de software da Índia, que provavelmente foi desenvolvido sob a luz de uma estratificação característica da sociedade indiana e que mata a criatividade e talento característico brasileiro.

Aliás, na minha experiência de Fábrica de Software, o talento brasileiro não era de todo eliminado. As pessoas normalmente não acreditavam em certas atividades, então usavam o jeitinho brasileiro para burlar e subverter o que consideravam impróprio ou inadequado ao projeto.

Copiamos aqui o modelo indiano, enquanto profissionais dos países líderes se recusam a trabalhar em regimes de produção que desconsiderem o talento individual e prezam apenas pela produção massiva. Já falei sobre isso aqui há dois anos atrás: enquanto a indústria de software dos BRICs tem ênfase Fordista, outros países como Suécia, Finlândia, EUA, Canadá e Japão trabalham em modelos mais evoluídos.

Seriam os Párias das castas indianas os Programadores da casta de software?

Voltando as vacas pretas...

Depois do fracasso geral da Carreira em Y nos ambientes tradicionais de produção de software, e considerando que o Google não tem emprego para todo mundo, resta aos profissionais de pegada técnica encontrar caminhos para preservarem a condição de agentes de produção intelectual em seus ambientes de trabalho.

Como esse tema vai dar muito pano para manga, encerro esse post por aqui, retomando mais tarde para falar como alguns desses aspectos são absolutamente enterrados no exercício de TI em outros mercados, principalmente os de propaganda, entretenimento, mecatrônica e artes.

O mundo não está perdido! Abraços, valeu!

Gerando arquivos .DAE (Collada) para o Papervision3D usando o Google SketchUp

noreply@blogger.com (Fernando Aquino (Nandico)) — Tue, 01 Jul 2008 20:02:00 +0000

Na minha horinha de hoje do projeto Caffeine da Colmeia não avancei em código. Eu procurei na web uma xícara em 3D, que pudesse usar na minha visualização. Não encontrei nada que fosse o suficientemente simples para o Papervision: um modelo que fosse bom para realtime, com poucos vértices.

O Papervision3D lê um formato chamado Collada. Eu não manjo nada de modelagem 3D, mas googleando, vi que é possível gerar arquivos collada com o Google Sketchup. Se você não conhece o Sketchup, ele faz o desenho 3D ficar tão fácil quanto o desenho 2D com as ferramentas nativas do Flash. Olha a belezura de Xícara que eu fiz com apenas alguns minutos de interação com a ferramenta:

Eu mesmo modelei a tosqueira em apenas alguns minutos, após ver os video-tutorials do site do produto.

Para gerar arquivos Collada para uso no Papervision3D, baixe o Google Sketchup e depois siga os macetes comentados neste link. Veja o avanço da minha visualização do Caffeine com a xícara 3D aplicada:

Cada xícara na tela representa um café bebido no dia de hoje na Colmeia. Para saber mais sobre o Caffeine, veja o post anterior ou acesse direto a página do projeto.

Caffeine - Café, hack de cafeteira e visualizações interativas

noreply@blogger.com (Fernando Aquino (Nandico)) — Thu, 26 Jun 2008 23:20:00 +0000

Meus amigos da Colmeia lançaram dentro do seu Lab um produto muito bacana: o Caffeine.

Trata-se de uma hackeada na cafeteira que fica lá na copa da Colmeia, onde pude filar uns pães com manteiga nuns dias que passei em Sampa com eles. Conheci a cafeteira antes do procedimento aplicado, mas confesso que só tomei café da garrafa térmica - esses cafés de moça da copa - que prefiro em relação ao expresso.

Flávio e Teta nerdizando no Arduino - clique se quiser saber mais sobre o hardware da parada.

A galera botou uma cafeteira na Internet, e cada vez que alguém pede o café, "god kills a kitten" e esses dados ficam disponíveis para que os vejamos na web. Apesar da relevância ZERO da informação, a prova de conceito é sensacional =).

No site tem uma chamada para que outras pessoas construam visualizações do consumo de café dos ursos, e eu já comecei a fazer a minha, sem prazo para terminar, já que estou cheião de coisas pra fazer (ainda bem). Segue a palhinha da minha hora dedicada de hoje - estou tentando um visualizador dos dados de consumo usando Papervision3D na versão GreatWhite. Conforme for avançando, posto por aqui e depois coloco os sources para download.

Olha a micragem aê... (work in progress, depois gasto mais uma hora para dar andamento).. Valeu!

Sobre desenvolvimento de trabalhos altamente interativos e o profissional de front-end

noreply@blogger.com (Fernando Aquino (Nandico)) — Tue, 24 Jun 2008 14:42:00 +0000

Hoje eu tava lendo alguns tópicos do Radinho e escrevi uma mensagem para um cara que eu admiro muito, o Rodrigo Ratan, que é participante ativo da lista e manja muito de Silverlight.

Nessa mensagem eu falava sobre um antigo incômodo, que foi tema de papos com amigos tipo o Marco Gomes na época que trabalhavamos juntos. Fala da subvalorização do profissional de front-end (seja Flash, Silverlight, XHTML+CSS, Javascript ou o que for). Esse pessoal hoje faz a parte mais difícil e tecnicamente avançada do trabalho de produção, e as vezes a sua hora dentro do modelo de cobrança das agências não correspondem a qualificação técnica exigida para o sujeito poder trabalhar bem.

Esse para mim é um pilar que permitirá profissionalizar mais ainda o mercado de produção de propaganda interativa. Então, se você tem perfil técnico, por favor, leia com atenção e me ajude a batalhar para reverter essa leitura do mercado =).

Segue o tópico, endereçado ao Ratan:

Gostaria de revelar uma coisa que me incomoda há muito tempo e não tem relação com Flash ou Silverlight, mas sim com uma visão enraizada no mercado: o fato das atividades de backend (serviços, bancos de dados, etc), serem sobrevalorizadas em relação as de frontend (parte client-side da aplicação).

Caso clássico do game que você colocou: Um bom game em Flash ou Silveright exigirá dos programadores da parte de frontend pelo menos bons conhecimentos de física, noções de gameplay, de fun-factor, boa experiência como jogador, noções de animação e integração de gráficos, noções de 3D, Isometria, aplicação de vídeos, tem que ter noção de Inteligência Artificial, saber cuidar de sound libraries, noções de performance, otimização de código, cuidar de memory leaks no cliente, cuidar de problemas com dispositivos específicos, abstração absurda para lidar com complexidade de código, modularização, controle de carga do game, cuidar do peso em kb do game, efetuar testes em um bom espectro de máquinas e condições de acesso, etc, etc, etc.

E a parte de servidor (banco de dados), o cara põe um serviço num servidorzão, implementa lá a persistência do game e acabou por aí, com uma leve exceção no caso de games multiplayer, que exigem serviços síncronos e que adicionam complexidade tanto no back quanto no frontend. Cá entre nós: tu que curte .NET sabe que o próprio .NET tem recursos que matam toda eventual complexidade desse tipo de trabalho, exigindo apenas que você faça uma boa modelagem (coisa que se aprende em qualquer faculdade de computação tradicional).

Então eu acho que a carência de "programadores de verdade" está muito mais na parte gráfica e interativa, que vai para o browser rodar em qualquer plugin, do que na parte de backend e de persistencia de dados. Assim como quase tudo na TI tradicional, backend é bem commodity. Não concordo quando se sobrevaloriza isso. Deveria se valorizar um bom enlace disso =).

É um problema absolutamente "trans-plataforma" esse: e não se trata de questão de "ego" dos profissionais, mas sim tem relação com possibilidades de carreira e valor de hora-homem do sujeito - essa grande doença que assola as agências interativas, que não sabem cobrar de outro jeito e talvez por isso não consigam bancar bons salários para as pessoas.

De uma forma ou de outra, o teto do salário de quem faz frontend em Flash ou Silverlight vai ser definido pela hora-homem padrão do mercado para essa atividade. O que colocaria no mesmo balaio o "Flasheiro Gateiro" que você citou com uma outra gama de grandes desenvolvedores client-side como o Zeh Fernando (já falado na thread) ou o Malungo, Teta, Cauê e Dias (Colmeia), Debert, Laet e Neto Leal (Gringo). Esses caras tão voando em céu de brigadeiro talvez porque saíram da prisão da hora-homem e podem exercer seu talento dentro de grupos que executam a ponta de todas essas disciplinas.

Ou será que eu tô viajando e não tem nada a ver? Essa é apenas a minha hipótese. =)

E vocês, o que acham? Por favor, comentem. E se concordam, ajudem! =)

Camaleão. Agora esse é um espaço dedicado a produção de propaganda

noreply@blogger.com (Fernando Aquino (Nandico)) — Wed, 18 Jun 2008 02:22:00 +0000

Tô aproveitando o fechamento do período de Cannes para dar uma arrumada na casa. Estive praticamente quatro meses imerso em um grande volume de trabalho e abstinência social. Período esse que se fechou há pouco, com o término do julgamento dos leões.

No segundo semestre de 2007 (tá fazendo um ano), embarquei numa nova jornada. A jornada onde regressei ao mercado de produção de propaganda.

Deixei de trabalhar com atividades de user experience em fábrica de software, assunto largamente comentado nesse site, para voltar ao mercado de comunicação lidando com todo tipo de tecnologia que propicie experiências interativas.

Como bom humanista que aprendi a ser, estou trabalhando com tecnologias da mídia numa pegada de propaganda, sem a burocracia e engessamento da TI tradicional quando tenta produzir para publicidade. Estou absolutamente convencido que não dá para atender o mercado de propaganda emulando o comportamento de empresas de TI dentro das agências, modelo mais usado hoje.

Voltei para o mundo da publicidade na condução de minha própria produtora, a Adjetiva. Essa empresa possui programadores malucos que desejam ser caras de propaganda, e não de TI. Tem gente de criação que cria junto com programador. E todo mundo cria junto ou alinhado com o diretor de criação das agências que a gente atende. A gente conversa com gente, com video, com audio, com 3D, com ilustração ou o que mais se faça necessário na produção dos trabalhos. Todas as pessoas se envolvem com os projetos e constroem coisas de maneira transdisciplinar. A gente acredita que isso faça toda a diferença.

Essa produtora, nascida em setembro de 2007, conseguiu na sua tenra idade produzir um dos shortlists de Cannes conquistados em 2008 pela AgênciaClick, em um ano tão difícil para o nosso país nesse festival. Pelo menos para mim, esse shortlist tem peso de ouro principalmente por ser um indicativo que o nosso jeito de pensar está dando certo.

Daqui eu encerro essa coisa de falar da empresa pelo fato desse espaço ser pessoal. Aqui não falarei muito de campanhas, como muitos blogs excelentes por aí. Vou tentar colocar linhas de raciocínio e estabelecer um viés de análise de produção técnica, território praticamente virgem no campo das blogagens de propaganda. Estou todos os dias buscando qualificação técnica para ser um cara de comunicação que entenda bastante de TI (ou vice-versa). Essa vem sendo a minha vida profissional, e quero dividir isso com vocês por aqui.

Quero conversar com a nerdaiada que tá fazendo a revolução. A nova ordem da produção interativa. O programador criativo, o diretor de arte que manja muito do meio, o diretor de criação que quiser entender como funciona uma tecnologia aqui comentada e quiser usar isso de input criativo, redatores e pessoas que gostem de propaganda interativa.

Começou, e tem muito pano pra manga! Abraços...

Equilibração - o processo!

noreply@blogger.com (Fernando Aquino (Nandico)) — Thu, 17 Apr 2008 13:19:00 +0000

Enquanto estou inevitavelmente esperando um processo aqui no trabalho ser concluído, aproveito pra escrever um pouco pra vocês.

Tempo desses, tomei uma corrigida indevida quando usei o termo equilibração, que tinha visto na época da faculdade e revi durante a temporada de estudos de UX. Equilibração existe, sendo diferente de equilíbrio. Enquanto equilíbrio é um estado, a equilibração é um processo pelo qual se persegue esse estado de equilíbrio. É claro que esse termo fica bem mais denso na teoria de Piaget. O que a gente tá falando aqui é de algo mais simples e pragmático: equilibração para você, no cotidiano.

Para mim, equilibração se consegue normalmente conciliando premissas conflitantes. Por exemplo, agora eu tenho que equilibrar meu papel de família (pai e marido) com o meu papel no trabalho (diretor da minha empresa). Dois papeis que exigem tempo disponível e grande dedicação.

Não existe a alternativa de deixar uma coisa ou outra desandar. Família e trabalho são muito importantes. Antes que me acusem de ser desumano, família é bem mais importante para mim, viu? É importante contextualizar também que o bem-estar da minha família depende que eu tenha um bom desempenho no trabalho. Eis uma parte signficativa do enlace da vida, que explica o motivo do equilíbrio ser importante. Tem que cuidar bem das duas coisas.

Para mim, uma parte importante da equilibração é tentar tomar as microdecisões adequadas na sua vida. Tipo "Vou almoçar com a família hoje e não posso abandonar esse compromisso.". Ou coisas como: "Preciso adiantar a parte alfa desse trabalho para poder passar o sábado com meu filho.". Bah, não vou explicar mais, vocês entenderam. Uma microdecisão errada em relação a família ou trabalho pode ter efeito cascata que pode fazer você não ir bem em nenhum desses planos.

Ricardo Saldanha, sujeito que eu admiro muito, costuma sempre dizer em suas incursões on-line o que os antigos já diziam: Virtus in medium est, ou algo como "A virtude está no meio". Eu acho que o caminho é por aí. Sigamos equilibrando! Me aperfeiçoar nisso é a coisa que eu mais desejo aprender nos dias de hoje. Torçam por mim! Abraços...

Não me arranquem dos seus feeds... =)

noreply@blogger.com (Fernando Aquino (Nandico)) — Thu, 13 Mar 2008 20:21:00 +0000

Tá decidido.

Após um período de mudanças comentadas no post anterior, este blog permanece.

Ainda tenho uma pá de coisas para falar sobre esse assunto. E agora eu tenho um pouco mais de liberdade para desovar alguns temas mais delicados de UX: não tô mais tão confinado na questão corporativa. Me sinto o "milico reformado" que já pode abrir o bico =). E tem muita coisa querendo sair, agora, em múltiplos canais:

Blog longo (UX) - Quando for pra falar de Experiência do Usuário, o endereço vai ser esse aqui mesmo. E continua a linha de posts mais densos nesse espaço, nada de textinho rápido.

Blog médio (Produção) - Quando for falar de assuntos mais ágeis, rápidos e relacionados muito mais à produção interativa do que UX, jogarei no http://nandico.tumblr.com. Esse não tem nem comments, pois é pedra lançada e não vou ficar voltando lá pra discutir assuntos. Tem também pitadas de coisas pessoais e é menos careta. Acho que os AIs não vão gostar desse, então nem assinem. ;)

Microblog (Tudo) - Para cobertura diária (e madrugária) dos pensamentos em formato curtíssimo, é no http://www.twitter.com/nandico.

Daí fechou o ciclo: consigo me fazer mais presente na web sem ter que esperar uma janela de jobs para poder escrever. Mais tarde, integrarei esses canais dentro desse domínio e de um mesmo feed para quem tiver a fim.

Valeu demais pelos feedbacks positivos que recebi, pessoal. De coração! =) A nova Jornada começou, e será coberta por aqui.

Mensagem postada na ux-recife - Seria uma despedida?

noreply@blogger.com (Fernando Aquino (Nandico)) — Thu, 21 Feb 2008 15:20:00 +0000

Reproduzo aqui para vocês uma mensagem que mandei para a UX-Recife, lista onde tenho amigos virtuais (eita coisa nerd) e que fala sobre Experiência do Usuário. Gosto muito do pessoal de lá, então resolvi falar com eles primeiro das mudanças que vêm acontecendo em minha vida profissional de um ano para cá. Esse deve ser um dos primeiros posts indicativos de fim dessa Jornada que foi muito bacana na minha vida. Por favor, vocês que tiveram aqui por tanto tempo, acompanhem com carinho =).

Segue a mensagem na íntegra:

Queria dizer pra vocês, amigos de Recife, que eu debandei para o lado negro da força.

Depois de 2 anos trabalhado 100% com UX, eu voltei a fazer produção. O tempo que eu passava pesquisando essas coisas de metodologias e processos de UX foi pro brejo. No ano passado, entrei como sócio de uma Agência, saí dessa Agência e depois montei uma produtora e graças a "Djah" tá tendo tanto job que não dá tempo da gente fazer o próprio site (muito menos de atualizar o meu site antigo).

Essa produtora tem conceitos de UX, mas é focada no mercado de propaganda interativa mesmo. Isso significa dar muitos tiros no pé, muitos Flashs, Papervisions, Video pra caramba e coisas do tipo: Por isso que comentei a questão do "lado negro" da força =). Nada mais de Wireframes, Garretts e outros artefatos de UX: simplesmente não dá tempo. Quando preciso de UX mais apurada e os prazos deixam, tô contratando os brothers e vivendo as agrurras de ser Mico-Empresário.

Motivos? Sei lá. Um deles é esse negócio da área de UX ter amadurecido e ter muita gente boa que além de ser boa, estuda formalmente (o que não é o meu caso, só graduação mesmo já tá bom pra mim). Eu acho que a galera tem mais é que estudar mesmo, nada contra. Acho que quem for continuar na área de UX, deve trilhar esse caminho (mestrado, doutorado, etc), pra não ficar de fora depois. Como eu gosto de estudar por conta própria e não me dou muito bem com os trilhos da educação formal, previ uma sinuca de bico que ia estourar daqui a 2 anos. Tomei uma reação preventiva: a de ficar fora do mercado que ajudei a criar quando todos vocês terminarem seus mestrados e doutorados que já estão fazendo.

Outro motivo foi retomar uma carreira que eu já tinha antes e que tinha me dado bons frutos, e também trilhar essa idéia de montar um negócio, já que pra mim é difícil pra caramba trabalhar em Brasília como assalariado (sou pai de família, hahaha). Esse mercado de produção que eu voltei é sofrido, mas paga mais e te avalia pelo que você sabe fazer, e não pelos títulos que você tem.

Então é isso, vou continuar por aqui de butuca pra não esquecer as coisas que aprendi com vocês durante esse período.

Abraços...

Nandico

Uma experiência de auto-avaliação continuada

noreply@blogger.com (Fernando Aquino (Nandico)) — Thu, 13 Dec 2007 10:20:00 +0000

Este texto sai um pouco do viés de User Experience para falar de uma coisa mais genérica: a busca do aprimoramento pessoal. Passei alguns anos com foco em desenvolvimento técnico, até que percebi que precisava melhorar várias coisas em outros aspectos.

Remexendo ontem meu material antigo de trabalho, encontrei uma lista que norteou as minhas atividades nos anos de 2005 e 2006. Na época da elaboração, tava vindo de uma experiência de cuidar de picos de 15 pessoas alocadas em prédios diferentes na AgenciaClick.

Da vivência de erros e acertos, e do feedback de antigos gestores como Ricardo Figueira e Willian Rocha, elaborei uma lista que levei comigo e usei intensamente durante esses dois anos, em esquema de auto-avaliação mensal: disciplinada, reflexiva e auto-motivada. Não era papo furado de RH de empresa grande, e sim um processo pessoal que gerava mudança de atitude já no momento seguinte à reflexão. Não precisava mais esperar um ano pra saber que precisava melhorar nisso ou naquilo.

É um material feito sob medida, que me serviu diante de um novo desafio e da perspectiva de não repetir erros anteriores. Das coisas que já vivi, a problemática de conduzir pessoas só perde em complexidade para a incrível arte de produzir salários, que é o meu desafio atual. Em sua íntegra, duvido que essa lista sirva para mais alguém. Só que uma coisa ou outra pode servir para mais gente. Fica então registrada no digimundo para que eu possa mandar os papéis para a reciclagem... =)

Segue a lista:

Levantar e monitorar a existência de riscos em todos os projetos da casa, estabelecendo uma visão estruturada sobre os mesmos.
Negociar e contingenciar os riscos identificados para sua eliminação ou direcionamento para as equipes ou pessoas responsáveis de fato.
Ser pontual nas entregas parciais e finais, garantindo o cumprimento de cronogramas.
Dominar técnicas, ferramentas e tecnologias de gestão de projetos.
Mapear e conhecer as habilidades de cada membro da equipe, bem como avaliar os seus resultados individualmente.
Alocar corretamente e eficientemente os membros da equipe nos projetos.
Estabelecer iniciativas inovadoras para a melhoria de processos.
Estabelecer comunicação de maneira clara e objetiva.
Ser pontual em relação ao horário de trabalho, reuniões e demais compromissos.
Estabelecer instrumentos de gerenciamento do tempo em todas as atividades executadas.

O resumo da ópera é que essa auto-avaliação foi boa para mim. Em breve sairá a minha lista própria de 2008, abarcando as competências que eu quero desenvolver. Se for criar a sua lista, me avise. =)

Desgastaram o "foco no usuário"... Mas não propuseram nada para o lugar.

noreply@blogger.com (Fernando Aquino (Nandico)) — Mon, 19 Nov 2007 07:33:00 +0000

Senhoras e senhores, venho aproveitar que passei a noite em claro trabalhando e agora aguardo o dia amanhecer para ir trabalhar mais ainda. Faço assim porque se dormir essa hora, não acordo mais. Venho falar sobre um assunto que tenho acompanhado em algumas listas de discussão: uma crescente rejeição ao lugar comum da expressão "foco no usuário".

Acho que se fizer uma pesquisa aqui nesses dois anos de blog sobre esse termo e suas variações, elas estarão presentes em todas as páginas. Fiquei pensando sobre a possibilidade de estar sendo apenas mais um "chavãozeiro", principalmente depois de ler alguns argumentos bêm consistentes contra o meu até então inabalável edifício mental do pensamento user-centered.

Na contramão da nova tendência, decidi que esse mantra permanecerá na minha cabeça com apenas uma adaptação: é foco na pessoa, pois fica um pouquinho mais humanizado.

Depois de uma temporada trabalhando para fábricas de software, essa adaptação me ajudava a resolver um problema de entendimento no contexto de TI, onde usuário pode significar tanto usuário final, quanto cliente, quanto quase todo tipo de stakeholder que você converse. As vezes eu emendava um "pessoa utilizadora" na tentativa de deixar as coisas mais claras. Essa é uma mera adaptação é de uso pessoal, sem pretensão de nada, mas que coube na época.

As mini-decisões de projeto - é disso que eles são feitos.

Não sei como o mercado lida com isso, mas o "mantra" absorvido pela mente me ajuda em todas as mini-decisões que preciso tomar durante o exercício do nosso trabalho. Eu acho que é dessas mini-decisões que os produtos são feitos. Não lidamos com materia prima física, e sim com produção intelectual. Em todas as pequenas encruzilhadas, podemos avaliar entre os caminhos disponíveis como primeiro critério o caminho que intuirmos que seja melhor para as pessoas utilizadoras do produto, mesmo que esse caminho não seja o mais fácil (e quase sempre não é).

Nesse processo granular, quanto mais conseguimos acertar, maior a nossa chance de termos ou mantermos um bom produto. Penso que a maioria dos projetos notáveis são um somatório de pequenas virtudes, frutos de pequenas decisões, criações e construções centradas em gente que usa.

Se o "mantra" do foco no usuário me ajuda a alcançar isso, só irei desconstruí-lo quando aparecer alguma idéia que me ajude mais. Isso aqui não é uma defesa do termo. É uma demonstração de utilidade pessoal para uma idéia aparentemente desgastada. Ninguém levou em conta que esse desgaste pode ser muito mais problema de uso fanfarrão do que com a idéia propriamente dita.

O mantra é um lembrete constante para meu exercício continuado de empatia. Então, na minha cabeça (pelo menos, por enquanto) ele segue soberano.

Abraços a todos!

A morte desejada do Especialista em Usabilidade.

noreply@blogger.com (Fernando Aquino (Nandico)) — Wed, 07 Nov 2007 12:53:00 +0000

Tá bom, eu não sou bom "mancheteiro", muito menos sei como criar boas polêmicas. Vou externar uma vontade futura aqui, e depois explicar o motivo: desejo a morte do papel de especialista em usabilidade, do especialista em design da interação, do especialista em experiência do usuário e assim por diante.

Acredito que essa seja uma visão centrada na pessoa utilizadora, e não uma visão umbigocêntrica. Enquanto a responsabilidade sobre a usabilidade de um produto pairar sobre um papel periférico nas empresas que adotam esse tipo de postura, um produto final dificilmente irá persistir as características de usabilidade que forem boladas pela cabeça desse papel.

Enquanto não houver...

Atendimentos ou áreas comerciais que entendam e respeitem usabilidade;
Gerentes de projeto que entendam e respeitem usabilidade;
Analistas, engenheiros, programadores, testadores que entendam e respeitem usabilidade;
Diretores de Criação, de Arte, Designers e Arquitetos da informação que entendam e respeitem usabilidade;

...não haverá usabilidade de fato, a não ser em pequenas empresas, pequenos projetos ou pequenas equipes.

Resumindo mais ainda: Basta um dedo marrom de algum membro da equipe depois que o trabalho do "usability guy" terminou para arruinar a experiência de uso de um projeto. As vezes é o cliente que pede pra cortar um artefato e alguém lá de cima que deixa. As vezes é um programador que reutilizou um componente tosco sei lá do que, e acochambra ele na interface. Os riscos de sair algo diferente do planejado no final são enormes.

Atenção: o parágrafo a seguir contém um trocadilho infame.

Em empresas com esse tipo de abordagem, a responsabilidade sobre a usabilidade deve ser de todos. Tem gente que acha que tá isento de se preocupar com isso só porque tem um Arquiteto da Informação, por exemplo. Eu acho que o caminho não é bem por AI.

Daqui pra frente, não tem mais trocadilho.

Outras abordagens (outros já perceberam que o "cara da usabilidade" não funciona bem)...

Algumas empresas gringas estão adotando o conceito de gerenciamento de produto (product management). Trocando em miúdos, é um sujeito geralmente proveniente da área de user experience que ganha mais poderes para poder cuidar do produto - de verdade -, de maneira semelhante a que um gerente de projetos possui a responsabilidade de cuidar do projeto. Tem um texto já até meio velho do Jeff Lash que fala sobre isso.

O gerente de projeto cuida de prazos, recursos e equipe (me recuso a colocar equipe como recurso, se alguém achar que tô sendo redundante). O gerente de produto cuida da estratégia do produto, e da persistência dessa estratégia do início ao fim do projeto. Tá com um olho na user experience/usuário final, e o outro olho no mercado e no possível de ser feito (aquela história de um olho no peixe, outro no gato).

O gerente de projeto tem poderes para tirar da equipe um cara que chega atrasado ou que não cumpre prazos, certo? O gerente de produto consegue agir sobre um cara que avacalhe a qualidade do produto. Qualidade no sentido do senso comum - produto bacana - e não qualidade no sentido "industrial" - produto aderente à especificação técnica (blergh).

O engraçado é que, na época que eu estava flertando com o PMBOK, o Torá do gerenciamento de projetos, lembro que no início do livro existe uma separação do que é gerenciamento de projeto e produto. O livro fala sobre as atividades de product management estarem fora do escopo dos GP's. Pena que o mercado brasileiro ignorou esse parágrafo do documento.

Tem até uma vaga anunciada faz tempo para trabalhar no Google, em Belo Horizonte, de Product Management.

Não tô dizendo que essa história de gerenciamento de produto seja o "ovo de colombo", mas para mim é um indicativo de mercado que a história do "usability guy" pode estar com os dias contados. Cada empresa sabe onde seu sapato aperta, então é preciso ler coisas como esse próprio texto aqui de maneira cuidadosa para tirar o que serve para você.

É besteira tentar aplicar "na íntegra" as soluções dos outros. Cada empresa tem um ecossistema próprio. Tentar pegar metodologias dos outros ou achar que a sua metodologia serve para os outros é tecnicismo e miopia. E quem trabalha com User Experience não se pode dar a preguiça de ser tecnicista.

Finalizando...

Um abraço a todos, tava com saudades de vocês. Agora podem mandar as pedradas via comments. Ultimamente tenho tomado tanta que a carapaça tá ficando cada vez mais forte. ;)

Algo sobre a mecânica dos frilas e a vida do freelancer de UX

noreply@blogger.com (Fernando Aquino (Nandico)) — Thu, 20 Sep 2007 18:19:00 +0000

Peço licença aos leitores para discorrer sobre algumas coisas a respeito de uma das formas que somos contratados para executar nossas atividades profissionais: o famoso frila.

Apenas vou anotar aqui alguns aspectos que tenho conversado com amigos sobre as decisões conscientes ou inconscientes que devem ser tomadas no "start" de um frila. Mais uma vez esse espaço está propondo apenas uma reflexão sobre o assunto, com muita carga de opinião e sem nenhuma pretensão de definir nada.

Sem estatísticas inventadas

Não tenho números para dizer nada, mas acredito que a frilação responde por uma fatia não-desprezível do volume de serviços do nosso mercado. Tentarei construir um raciocínio que leva em consideração a "Frilosfera" e os seus principais agentes: Clientes, Contratantes, Parceiros e o Freela propriamente dito.

Glossário interno

Freela (leia-se frêêla): Sujeito que faz o frila (freelancer).
Frila (leia-se frííla): O trampo ou serviço executado pelo Freela.

Vamos começar falando um pouco sobre o tal do GIRO: a mola mestra da frilação - a gênese de todo trampo de frila que pipoca no mundo.

Aspectos de negócio - O Giro

Tem uma coisa na atividade empresarial que a gente chama de "giro". Ele engloba os valores necessários para a manutenção da empresa a cada mês. No setor de serviços, podemos considerar bem a grosso modo o giro sendo a quantidade de grana que precisa ser faturada para pagar as contas, salários das pessoas e quitar os impostos da empresa.

As pessoas costumam dizer que precisam de tantos mil reais para girar a empresa tal. Isso quer dizer, que todos os meses ou na média de um período, deve-se faturar pelo menos esse tanto a cada mês para a empresa não entrar no vermelho. O que você fatura além do giro é o seu lucro líquido, ou seu azul.

Que diabos isso tem a ver com os freelas?

Estou falando sobre essas coisas porque acredito que lidar com o giro é um dos fatores fundamentais que levam as empresas a frilarem trabalhos. Alguns segmentos de negócio que demandam atividades de Experiência do Usuário podem não conseguir "girar" a quantidade de colocações fixas versus volume de trabalhos tempestivos que precisam ser feitos nos projetos.

Tentando pincelar com exemplos, se você necessita de ilustrações profissionais de vez em quando, pode ser viável frilar um ilustrador pontualmente, quando esse contexto ocorrer. Talvez não seja muito inteligente manter pessoas em postos de trabalho à espera demandas trasitórias.

O giro é um dos problemas mais sérios da operação de empresas do nosso segmento. A nossa atividade depende muito de capital intelectual para conclusão dos trabalhos, com exigência de gente qualificada. Mesmo empresas de porte pequeno possuem folhas de pagamento relativamente salgadas. Se você não paga um salário competitivo, não consegue manter um bom profissional na estrutura por muito tempo.

Mais exemplos: Não custa barato manter uma vaga fixa de "Arquiteto da Informação Pleno", que é a vaga média do nosso mercado. As despesas com esse Arquiteto serão fixas para a empresa: todo mês o sujeito receberá salário e benefícios, e todo ano férias e décimo terceiro.

Já a receita que a empresa recebe em decorrência do trabalho do Arquiteto é absolutamente variável, dependendo de fatores internos e externos que eu não conseguiria enumerar. Mesmo assim, numa visão de "microcosmo" vou arriscar dizer alguns fatores para manutenção dessa vaga:

a) O Arquiteto ter uma boa visada produtiva (não ficar "sem job").
b) O Arquiteto trabalhar uma quantidade de horas próximas das horas vendidas para o Cliente. Ele absolutamente não pode trabalhar mais do que foi vendido. Se isso acontecer, o lucro do projeto vai pro saco.

Para dar sequência a esse raciocínio, vou colocar três modelos de trabalho até chegar no modelo de freela:

a) Modelo tradicional - Cliente => Contratante => Colaborador

Nesse modelo, o Contratante possui funcionários (Colaboradores) que executam um determinado serviço vendido a um Cliente. No modelo tradicional, a parte mais pesada do "giro" fica com o Contratante.

Normalmente o Cliente paga por um serviço a ser executado em um prazo estabelecido. Se o Contratante executa no prazo combinado, tudo beleza. Mas se ele começa a atrasar, a margem de lucro do Contratante vai reduzindo até que o projeto entre em prejuízo.

O Contratante nesse modelo vive em conflito de gerenciar uma receita variável (pagamento do Cliente) com uma despesa fixa (pagamento de salário ao Colaborador).

Para que esse modelo funcione, o Contratante deve operar redondinho para conseguir fazer os projetos terem uma boa margem de lucro. Apesar dos esforços de todos, essa situação de prejuízo é muito comum no mercado.

b) Modelo de parceria (Subcontratação ou Quarterização) - Cliente => Contratante => Parceiro

Isso aí é uma forma do Contratante transferir para um Parceiro (empresa contratada por ele) o ônus do giro de equipe. Ele só paga o Parceiro quando receber do Cliente.

O Parceiro, por sua vez, para não ficar no "prejú" vai tentar se proteger e cumprir o escopo o mais rápido possível, caso contrário, sua margem de lucro vai para o buraco rápido. Vai ter gente no Parceiro pra "tensionar" o Contratante tão logo as atividades estejam concluídas para pegar o aceite do projeto e solicitar recebimento da remuneração combinada.

Algumas empresas do mercado estão adotando esse tipo de abordagem para trabalhos de especialização notória. Produtoras e alguns estúdios trabalham assim.

Vamos supor que dentro do Contratante alguém decida que seja legal produzir um "game" dentro de uma campanha. Se o contratante não possuir gente especializada nisso, pode ir atrás de um Parceiro qualificado pra desenvolver essa parte do projeto.

O Parceiro precisa ter um fluxo de caixa excepcional para conseguir girar os projetos. Um Parceiro descapitalizado sobrevive muito menos do que o Contratante na mesma condição. O Parceiro está num "nível trófico" com menos "energia" disponível, então precisa se desenvolver muito para conseguir sobreviver com saúde.

c) Modelo frilado - Cliente=> Contratante => Freela

Demos uma volta infernal para finalmente chegar no ponto. Muita gente não observa isso, mas é nesse viés que as desventuras do giro são transferidas para o profissional de freela.

O dinheiro do frila passa a ser receita variável para o executante, por mais que digam o contrário. Tem gente maluca que faz planejamento com dinheiro de frila antes de receber: eu acho que isso é muito complicado. Depende entre outras coisas da construção de um relacionamento de cumplicidade entre os Freelas e Contratantes, coisa que não acontece da noite para o dia.

Esse relacionamento entre Contratantes e Freelas é essencial para as duas partes. O Contratante se livra do giro mas assume alguns riscos ao adotar a abordagem de frilar um job. Sempre existe o risco do Freela "dar um perdido" (evaporar), atrasar entregas ou simplesmente ser incompetente pra fazer o que foi combinado. Como acordar prazos com Clientes se a pessoa que está fazendo com você não for absolutamente confiável?

Conheço casos de freelas que "dão sumiço" sem entregar nada, e também de contratantes que recebem produtos e dão calotes nos freelas. Tenho certeza que você também já acompanhou esse tipo de coisa.

Depois dos modelos, algumas visões.

Um bom freelancer não precisa somente das competências técnicas inerentes ao seu serviço. Tem que ficar antenado para desenvolver habilidades financeiras, para que sua atividade seja rentável e a grana arrecadada nesse esforço recompense o volume de labuta e as eventuais dores de cabeça. Nunca se deve equiparar o valor de hora tranquila que receba em um trampo convencional com o valor de hora mais conturbado do Freela.

O freela precisa ter também um mínimo de noções sobre gerenciamento de projetos para saber delimitar o seu escopo e definir junto ao Contratante EXATAMENTE qual será o objeto de suas entregas, os respectivos prazos e as datas da grana cair na conta.

Na perspectiva do Contratante, demorar para entregar um projeto pode ser apenas adiamento de receita, que é uma coisa menos grave e diferente de prejuízo. Prejú mesmo só toma quem arca com o giro, que nesse caso é o Freela que vai levar, trabalhando além da conta.

Transferência de calote: Isso é correto?

Tenho outra visão pessoal de que a relação combinada e estabelecida é entre o Frila e o Contratante. Se o Cliente não pagar o projeto e isso não for culpa do Freela (é importante frisar), o Contratante não deverá repassar o calote. O Freela fecha negócio é com o Contratante, e esse deve arcar com as responsabilidades inerentes a demandar serviços para terceiros (ou quartos e quintos dependendo do caso).

Muita gente não combina isso no início dos projetos. Todas as vezes que eu ia fazer freelas, amarrava com meu Contratante que a condição de pagamento era o serviço concluído e aceito. Se o produto está homologado, é problema de quem contrata se o Cliente resolver não pagar.

A mensagem que eu passava é de "Quando eu alcançar o escopo, receberei o dinheiro. Organize o seu caixa pra isso." Se o Contratante não topava o modelo eu declinava. Se a intenção do Contratante é de "dividir riscos", esse intuito não deve ficar velado. Assumir risco desse tipo é como transar sem camisinha. A camisinha, nesse caso, é um contrato assinado em duas vias amarrando a situação (ambos podem ser protegidos por esse tipo de instrumento).

Fechando a ladainha...

Os Freelas podem ser uma boa maneira de melhorar as suas contas. Mas para que não virem um pesadelo, é bom estar de olho nas coisas faladas aqui e em algumas mais que eu não lembrei ou que não dá para colocar aqui porque o texto já está grande.

Pode ser melhor passar mais tempo com a família do que pegar um "projeto seqüestro" para comer a sua vida a troco de pouco ou de nada. Se formos fazer, que combinemos direitinho antes. O frila deve ser bom para todas as partes envolvidas.

Discordou? Comente =). Até logo!

Faça uma boa ação: Adote uma persona abandonada

noreply@blogger.com (Fernando Aquino (Nandico)) — Mon, 23 Jul 2007 13:27:00 +0000

Todo mundo que trabalha com Experiência do Usuário já deve ter ouvido falar ou até mesmo utilizado uma técnica chamada Personas. É chover no molhado ficar aqui desenvolvendo o assunto do ponto de vista técnico. É uma prática sedutora, com um potencial danado para bons resultados. A primeira vez que ouvi falar de Personas foi quando o Ricardo Figueira chegou dos EUA mais ou menos em 2002 com essa novidade na manga. Logo ela foi colocada em prática lá nos meus saudosos tempos de descobertas quando trabalhava na AgênciaClick.

O que venho tentar chamar atenção é para um problema social da quantidade de personas que são criadas e abandonadas todos os dias.

Na pressão de estarem em dia com as novidades do mercado (que não são nem tão novidade assim), profissionais de experiência do usuário estão brincando de deus ao criarem personalidades e histórias de vida, soprando alma em adolescentes, vovozinhas, executivos, universitárias e donas de casa.

Se você é uma pessoa responsável pelas personas que cria, tudo bem. Vá em frente e continue criando. Você é do bem.

Mas se você usa suas personas somente no início dos projetos, por pura vaidade, e depois deixa esses pobres seres jogados em arquivos PowerPoint ou documentos do Word, você é do mal.

Está piorando um problema virtuo-social de ordem muito maior do que a derrocada do ICQ, a morte dos e-mails grátis ou qualquer outro fenômeno interneto-social - como os avatares errantes abandonados no SecondLife.

As personas são muito mas úteis: elas querem te ajudar no andamento do projeto, não só no início. Querem validar as entregas de cada etapa. Querem ser lembradas quando algum programador tentar mudar alguma coisa por conta de um framework tosco. Querem ser lembradas quando o cliente tentar estuprar alguma funcionalidade que foi criada pensando nelas. Esse é o seu papel. Não servem só para ficarem bonitas no projetor. Persona criada não é formiga de fazenda.

E não acaba por aí...

Quando o projeto terminar, as personas querem avaliadas na contribuição que ofereceram. Ajudar a avaliar as diferenças entre o planejado e o executado. E depois do projeto, não querem morrer: Elas desejam persistir para nortear a evolução consistente do projeto em seus próximos passos, servindo como parâmetros para a manutenção, evolução e sustentação do projeto, em um modelo coerente com a forma como as coisas foram criadas e modeladas para elas.

É por isso que lanço a campanha: ADOTE uma persona abandonada!

Se você conhece alguma persona que foi esquecida ou anda sub-utilizada, use o recurso de comentários desse blog para poder anotar as informações sobre elas. Vamos cuidar para que todas sejam adotadas, resgatando-as do LIMBO para que elas revivam em novos projetos. Por favor, divulgue essa campanha em seu blog para que todas as personas possam ter condições de ter uma vida melhor.

Selinhos da campanha:

Saiu o vídeo completo - Acessibilidade Web: Custo ou Benefício?

noreply@blogger.com (Fernando Aquino (Nandico)) — Fri, 25 May 2007 14:39:00 +0000

Saiu a versão completa do vídeo "Acessibilidade Web: Custo ou Benefício", criado pelo grupo Acesso Digital, mantido pelo companheiro Horácio Soares juntamente com o querido MAQ (Marco Antônio Queiroz) e a Lêda Lucia Spelta, que acabei de conhecer.

O grupo conta também com apoio do Fred Van Amstel e do Bruno Torres. Esse bocado de links que eu coloquei acima é uma tentativa de atestar um pouco a seriedade do trabalho e a competência das pessoas envolvidas para quem ainda não teve contato com elas.

O vídeo fantástico traz exemplos práticos da vivência de pessoas com deficiência na hora de acessarem grandes sites como Americanas.com, Jornal O Globo e Banco do Brasil. Foram trabalhados principalmente exemplos de larga visitação. Projetos em escala de acesso onde qualquer percentual por mais baixo que seja, significa muita gente deixando de ter acesso as coisas.

Acredito que o vídeo deve servir para sensibilizar não só o pessoal de codificação, mas toda a cadeia de pessoas que tomam decisões ao longo de projetos para internet, principalmente os clientes, diretores e gestores. Na pressão, as vezes essas pessoas priorizam demais as questões de fiabilidade em detrimento de fatores essenciais como a Acessibilidade dos projetos.

É por isso que faço um apelo maior para o pessoal de disciplinas correlatas que as vezes caem nesse site (meus amigos designers, pessoal de motion, redatores, diretores de arte, programadores, analistas ou que trabalham em outras áreas): vejam o vídeo.

Como diz o pessoal do Acesso Digital: Acessibilidade não é altruísmo, e tá na hora desse pensamento sair do mundo técnico do XHTML e do CSS e e começar a cair na cabeça de todas as pessoas que influenciam a qualidade das coisas produzidas para a internet.

Acessibilidade, civilidade e projetos que induzem a erros

noreply@blogger.com (Fernando Aquino (Nandico)) — Tue, 08 May 2007 15:45:00 +0000

Durante todo o primeiro e segundo graus (hoje nível médio), estudei em uma escola que tinha amplas áreas verdes conjugadas com muitos espaços de grama verdinha e muito bem cuidada. Aprendi muito cedo que não devíamos pisar na grama.

No começo, era porque não podia e pronto. Mas na 5^a Série, o professor de Práticas Agrícolas explicou que não se devia fazer isso devido ao peso do nosso corpo pode compactar o solo, dificultando a fixação das raízes da planta. Isso explicava a criação de "caminhos" ou "trilhas" na parte do gramado onde as pessoas passam com frequência. As trilhas eram o solo compactado, que precisava de ser revolvido, tratado e replantado para a reversão do problema.

Essas coisas ensinadas tão cedo me geraram um enorme compromisso de não pisar na grama. A essa sensação, alguns dão o nome de civilidade - segundo a wikipédia, nada mais é do que o respeito pelas normas de convívio entre os membros duma sociedade.

Qual a relação disso com a acessibilidade?

Hoje cedo fui levar meu filho Mateus no pediatra e me deparei com um prédio em condições deploráveis de acesso. E meu filho, enquanto criança de colo, nos coloca em uma condição legítima de Acessibilidade e prioridade de tratamento, inclusive prevista no Decreto 5.296, de 2/12/2004.

O projeto do prédio começa com o estacionamento muito distante da entrada sem algum motivo aparente. Passa por uma calçada maluca que praticamente dobra o trajeto que você precisa fazer. E ainda abriga em seus andares um grande número de clínicas médicas e laboratórios especializados que atendem todo tipo de público, inclusive as pessoas com mobilidade reduzida.

E qual a relação disso com a civilidade?

Me senti no direito legítimo de pisar na grama hoje. Me deparei com a trilha alternativa, compactada e presente no local. Ela que denunciava que aquele era um caminho de fato utilizado pela maioria das pessoas. Pode parecer um fato sem importância, mas quebrei um tabú pessoal de décadas. Tomei uma decisão baseada em muitos princípios de responsabilidade de projeto que a gente usa no trabalho, no raciocínio da Experiência do Usuário.

Não foram poucos os autores que me influenciaram a pensar que os projetistas devem assumir as consequências de seus erros de projeto que induzam as pessoas a agirem de maneira errada. A cada passo dado em cima da grama, pensava estar pisando nas costas da mão do arquiteto que priorizou a estética de uma fachada imponente em detrimento de uma boa acessibilidade. Sentia que estava ali perdendo um pouquinho da minha civilidade, com um leve requinte de crueldade, por causa desse arquiteto que eu nem conheço.

Nesse senso de responsabilidade, cabe um questionamento interno se os nossos usuários não estão fazendo coisas erradas nos sites e softwares que projetamos por nossa culpa, vaidade ou omissão. =) Um abraço e até breve!

UXrecife esquentando o relacionamento das pessoas no mercado

noreply@blogger.com (Fernando Aquino (Nandico)) — Fri, 20 Apr 2007 13:59:00 +0000

Já fazem alguns dias que eu tive contato com o blog do UXrecife, via Sinistras do Caparica. Fiquei muito feliz pela organização desse grupo, que muito mais do que uma lista de discussão, é uma "rede de happy hour", que promove encontros físicos, organiza eventos e aproxima as pessoas.

Foi aí que o meu irmão Paulo Foerster, lá da "terrinha", como ele gosta de dizer, me fez o convite para participar da lista, me contando uma pá de coisas legais que acontecem por lá, entre apoio de instituições fantásticas como o CESAR, muita gente legal que eu precisava conhecer, o entusiasmo e as impressões dele sobre os encontros.

Maracatu Rural, de Haidee Lima, ilustrando a página de entrada do UXrecife

Quanto ao lado pessoal desse projeto, nem preciso me pronunciar muito. Deve ser fantástico para esquentar o relacionamento entre os profissionais da área. Isso facilita a comunicação para troca de idéias, descoberta de afinidades, divulgação de oportunidades de trabalho/freelas e a associação futura com grupos de outros lugares para a troca de informações.

Já do lado técnico, o que eu mais admiro é aquela coisa do "contexto" da Experiência do Usuário dentro de cada mercado, com pessoas conversando em realidades mais próximas e respeitando as particularidades locais. Tem coisas que podem até ser universais no raciocínio centrado no usuário, mas uma parte do tempero de uma boa experiência, num pensamento rápido e improvisado aqui, deve ter relação com os aspectos culturais de cada região. O que mais cansei de ver em listas é fulano "soltando regras" que funcionam em apenas em seu mercado e que não necessariamente se aplicavam a minha realidade e a dos meus usuários.

Tudo isso também fora o fato do conhecimento que temos de um montão de profissionais excelentes que não mantém blogs nem participam de listas talvez porque tudo seja muito frio. A impossibilidade de encontros físicos em listas de alcance nacional pode intimidar os que não tenham muita capacidade de se fazerem simpáticos, polidos, controversos ou interessantes no digimundo e na blogosfera. Esse é um problema que talvez possa ser resolvido no tete-à-tete, dentro de projetos como o UXrecife.

Enfim, são só teorias sem embasamento essa parte aí das elocubrações pessoais dos últimos dois parágrafos. Voltando ao foco do post, espero que as pessoas em outros mercados mirem-se no exemplo de Recife e se organizem. Aqui em Brasília, já estamos dando os primeiros passos =).

Ainda sobre o nossos papéis, técnicas e métodos

noreply@blogger.com (Fernando Aquino (Nandico)) — Tue, 10 Apr 2007 14:33:00 +0000

Depois da viajada no texto anterior, acabei tendo contato com algumas visões interessantes - convergentes ou divergentes - sobre nosso trabalho em Experiência do Usuário. Enumerarei algumas delas aqui:

1) Visão do GAEL/IST

Meu estimado colega de Portugal, Gustavo Pimenta, comentou sobre a visão do Gabinete de Apoio à Produção de Conteúdos Multimédia e eLearning, no Instituto Superior Técnico da Universidade Técnica de Lisboa. Essa exposição aconteceu na lista de discussão portuguesa REPUX, que tem como tema principal a Experiência do Usuário e conta também com alguns colegas brasileiros. Segundo contou Gustavo:

"No GAEL/IST entendemos o user research como sendo algo necessariamente plural e não ortodoxo. Plural porque reduzir o user research a uma única técnica aplicável a qualquer tipo de problema conduz invariavelmente a uma sobrevalorização da técnica em relação ao problema. Não ortodoxo porque defendemos que as técnicas metodológicas não devem ser herméticas, mas sim ser aplicadas de
forma crítica e criativa."

O que mais me chocou na passagem acima foi que o pessoal do GAEL/IST resumiu em um parágrafo o que eu levei um texto inteiro para tentar dizer. Talvez um dia eu consiga ser um pouco mais objetivo, até porque isso é muito mais user friendly do que ficar escrevendo nesse meu estilo Pero Vaz de Caminha.

2) Visão de Dan Saffer onde Pesquisa é Método, e não Metodologia

Meu brother Moisés Ribeiro mandou esse presente para mim via del.icio.us. Nesse excelente texto, Saffer dá um tapa em alguns pontos da minha visão: Para ele, nem sempre é conveniente fazer design baseado em pesquisa. Muitas vezes, profissionais experientes podem resolver o problema. É possível fazer projetos que os usuários gostem sem necessariamente fazer pesquisa. Então ele oferece sete razões onde você deve usar o chamado User Research, como dizem os gringos.

De alguma forma, Saffer acaba combatendo essa coisa de cristalização da usabilidade e transformação de tudo em metodologia, processos e técnicas em caixinha, o que vai de encontro a minha visão e também com a visão do pessoal do GAEL/IST. No final das contas, tá todo mundo indo pelo viés humanista, e isso ao meu ver é uma coisa muito positiva.

Fico por aqui hoje de maneira mais simples, sugerindo inscrição na REPUX e a leitura da visão do Saffer. Abraços e até breve!

O que talvez não seja a usabilidade – mera leitura pessoal

noreply@blogger.com (Fernando Aquino (Nandico)) — Tue, 27 Mar 2007 19:29:00 +0000

Posso estar enganado, mas acho que é preciso ter a envergadura de um Nielsen ou até mesmo de um Nizan para dizer “o que é”, assim, na bucha. Escrever a regra do jogo, criar patamares e definir mercados é com eles. No meu exercício de blogueiro, o máximo que posso fazer é pegar um atalho e tentar dizer "o que não é". Nesse post, vou arriscar falar sobre usabilidade, que é o tema primordial dos meus vizinhos de blogroll.

Na reverberação de uma confusão de conceitos e leituras ao conversar com gestores, clientes, parceiros, amigos e colegas de outras áreas, colocarei algumas coisas aqui no meu blog sobre o que eu acho que usabilidade talvez NÃO seja:

Usabilidade não é teste.
Não é cenário.
Não é heurística.
Não é persona.
Não é cenário de tarefa.
Não é método.
Não é o jeito que empresa "x" trabalha.
Não é a metodologia "y".
Não é padrão.
Não é técnica.

Explicando a verborréia (antes que as tijoladas venham, talvez seja possível evitá-las)

É complicado voltar de férias e soltar uma sequência dessas aí. Mas é que reduzir a usabilidade a qualquer uma dessas coisas é correr o risco de fazer uma simplificação "tecnicista" de uma coisa que deveria ser totalmente humana, baseada em indivíduos e contextos.

Tenho comigo que a melhor técnica (ou conjunto) depende diretamente do que aparenta (ou pode) ser melhor para as pessoas que vão usar o que se está projetando ou consertando.

É aquele velho “depende” que algumas pessoas não gostam de ouvir: sentem-se enroladas. Às vezes preferem dar ouvido a fanfarrões e gurus vomitando verdades universais, sendo que boa parte dos problemas de usabilidade é de escopo local. Pelo menos na vivência que tenho, a maioria dos fatos influenciadores do comportamento dos usuários são de natureza estocástica. Esse comportamento está sujeito a um efeito borboleta danado, e essa teia de eventos não se pega somente em avaliação heurística ou testes de usabilidade, por exemplo. Pega é com imersão, pesquisa e instrumental adequado para cada situação.

É “do usuário”, não podemos esquecer

Pelo menos nas minhocas da minha cabeça, a ênfase nas pessoas é o pino mestre do guindaste que ergue a filosofia da experiência do usuário. Senão deixa de ser “do usuário” e passa a ser “experiência da tecnologia” ou “experiência do prazo apertado” ou ainda a “experiência do magáiver”. Ainda acredito no ideal que as coisas têm que ser necessariamente centradas nas pessoas. Sou contra as decisões de projeto serem unicamente baseadas em portifólio de técnicas, métodos ou ferramentas que empresas e pessoas dominem, só porque isso é mais “repetível”, como se diz na Engenharia de Processos.

O mínimo que a gente pode fazer para selecionar técnicas seriamente, sem colocá-las como “consultoria em caixinha na prateleira” é conhecer basicamente o público, os contextos de uso, ter condições de construir hipóteses, validar essas hipóteses e propor linhas de ação que usem o que for mais adequado das escolas de usabilidade, IHC, UCD, Experiência do Usuário, Design da Interação e o que mais houver. Conteúdo e teorias não faltam.

Já ta acabando...

Falando em conteúdo e já estourando a cota do “achismo”, creio que seguir só um autor ou tendência também é bobagem. Na era do mashup e do remix, até eu que sou retrógrado em muitas coisas fui buscar um pouco de diversidade. Vamos então fazer um boogie-woggie de pandeiro e violão nas teorias e até o próximo texto.

Se Jah quiser, este site será atualizado agora com uma periodicidade decente, visto que as férias (dessa vez físicas) foram excelentes. O último “acho” é que os meus problemas de atualização do blog eram falta de oceano atlântico na vida. =)