Multiplexado

Volta e meia temos a chance de bater um papo com os amigos que estão em outros cantos da terrinha e também de outros lugares do mundo. A parte boa a que a gente mata a saudade. A parte ruim é a recorrência em todo canto de relatos sobre a dificuldade de relacionamento entre pessoas de disciplinas diferentes.

Rixas entre designers, programadores, analistas, arquitetos, profissionais de projetos, de atendimento e até mesmo em relação aos clientes tornam inúteis boa parte da energia que deveria estar concentrada em benefício dos usuários finais. Esses sim é os que saem mais prejudicados quando não existe sintonia de equipe.

Implantação de modelos de produção do tempo do guaraná de rolha

É muito fácil mergulhar nos preceitos acadêmicos de cada disciplina, seguí-los a risca e exigir que as pessoas de outras áreas se adaptem ao jeito que você aprendeu a trabalhar. Isso foi supimpa no passado. Taylor achava isso legalzão. Ford usou isso pra fazer carros mais baratos na década de 20.

O interessante é que já faz um bom tempo que esse pensamento está superado no resto da indústria. Desde 1940 já se fala em uma abordagem humanística para isso tudo.

Depois do Fordismo, vieram o Toyotismo e uma série de outros movimentos, com suas soluções e seus novos problemas. Muitos deles surgem justamente atacando a especialização desenfreada defendida pela indústria anglo-saxônica.

Segundo o Volvismo, por exemplo, um alto grau de qualificação profissional não quer dizer exatamente a mesma coisa que um alto grau de especialização profissional. A alta qualificação respeita muito mais a inteligência humana e o trabalho em equipe do que você se especializar demasiadamente em fazer uma única função, sem conhecimento do todo.

Para encerrar o assunto do Fordismo, a mesma Detroit que serviu de contraponto para os Japoneses desenvolverem o movimento do Toyotismo, hoje é uma cidade fantasma. Digo isso segundo relatos do meu amigo André Mitchels em visita à sede da Compuware na semana passada. Nem o Robocop quer saber mais de Detroit, muito menos o pessoal da Ford.

No entanto, tem gente que ainda insiste em inserir uma divisão de trabalho arcaica na hora de trabalhar com projetos de novas mídias. Isso constitui um absurdo conceitual que assola boa parte da indústria do software nos dias de hoje.

Falta de conhecimento e de respeito pelas atividades dos outros

Hoje, o mínimo de qualidade que um produto ou serviço deve ter normalmente envolve atividades de inúmeras disciplinas, onde todas as etapas tem a sua importância. Pessoas são pessoas, não importa se de exatas ou humanas, de computação ou de desenho, de economia ou de administração, de marketing ou direito.

Não entender suficientemente o trabalho que o outro faz pode nos levar a besteira de subdimensionar suas atividades. Essa talvez seja a faceta mais cruel do modelo de especialização imposto pelo mercado.

Preconceito patrocinado

E as empresas, por sua vez, pecam a também não conhecerem o valor real de todos os papéis envolvidos nos projetos. Em alguns casos, pude acompanhar a implantação de culturas de privilégios a determinados segmentos de empresas. Esse tratamento desigual acaba afastando todos os bons profissionais que não pertençam as áreas focais do negócio. Justamente os profissionais que são extremamente importantes no processo como um todo, e que só se percebe a falta depois que vão embora das suas posições de trabalho.

Existe uma grande falta de inteligência corporativa, onde o preconceito interno entre as áreas acontece patrocinado pelos níveis estratégicos das empresas. Esse modelo de preconceito é muito comum em Agências que privilegiam demasiadamente as áreas de Criação, ou também em Empresas de Software (Fábricas) que privilegiem somente as áreas técnicas e de processos.

No final das contas, as Agências acabam produzindo projetos bonitinhos e capengas do ponto de vista tecnológico, e as empresas de software acabam por produzir software escalável e parrudo, mas também feio, desengonçado e sem capacidade de uso. É extremamente difícil para os clientes encontrarem fornecedores que produzam simplesmente projetos de qualidade e ponto.

Enquanto não se afinam as bússolas...

Cabe a nós como profissionais buscarmos a reflexão para melhor entender e respeitar o trabalho que os outros executam à nossa volta. Esse respeito oferecido talvez seja o primeiro passo para o respeito recebido, e a consequente valorização do trabalho de todos.

Trata-se de um exercício de empatia, que pode um dia se espalhar como um meme positivo para que as pessoas passem a conviver de uma melhor maneira, deixando de somente competir para colaborar entre si. Talvez esse dia chegue, e os usuários deixem de pagar o pato por conta das disputas dos outros.

Até o próximo!

Ontem recebi do meu amigo Gustavo Burnett uma piada velha, daquelas que circulam por aí em nossas caixas de e-mail. Essa é uma das que sempre acabam voltando.

Tratava-se de um fluxo "Solucionador de Problemas". Esse fluxo descreve técnicas interessantíssimas para que você se livre dos problemas que ocorrem todos os dias no mundo corporativo. Não consegui identificar a autoria do fluxo original, que é muito divertido. Se alguém souber, por favor, comente aqui para que eu possa dividir os créditos.

No intuito de trazer para o contexto do site, resolvi converter o fluxo para o padrão adotado no Vocabulário Visual de James Garrett, já comentado aqui dentro. Penso que pode ser um exemplo bacana porque exercita um bocado a ocorrência de pontos de decisão dentro dos fluxos. E também para mostrar que esse vocabulário fantástico que serve até para ilustrar piada.

Olha no que deu: (espero que gostem!)


(Clique na imagem para abrir com mais detalhe)

Versão original

(Clique na imagem para abrir com mais detalhe - Atenção: A versão original contém palavras que podem ser consideradas ofensivas por algumas pessoas)

Outras versões

• Arquivo no formato PDF, para imprimir
• Arquivo no formato Visio, para alterar e criar novas versões

Este é o terceiro texto da série onde eu falo sobre Wireframes do ponto de vista prático. Se você não leu os textos anteriores, recomendo consulta ao índice.

Como já disse anteriormente, vale ressaltar que o caráter desses textos leva uma carga pessoal muito grande. Estou aqui apenas para aprender e dividir - sinta-se à vontade para concordar, discordar ou apresentar outros pontos de vista. Novamente, vamos lá:

Parte 3 de 6 - Discrepâncias no aproveitamento de espaço da tela - fator de "acochambramento"

(Soluções contra a síndrome do "Coração de Mãe" - Nem sempre cabe mais alguma coisa no Wireframe)

a) Trapaça de uso inadequado para caber mais informação na tela

A divisão de tarefas no projeto de interfaces é uma coisa muito proveitosa. Mas como qualquer coisa na vida, isso não deve ser levado ao extremo. Quando o profissional se isola em sua disciplina, muitas vezes acaba superestimando o seu papel e prejudicando toda a sequência de etapas posteriores do projeto.

Um caso que ilustra a situação acima é quando o projetista tenta distribuir os elementos no Wireframe de maneira não-realista. Colocar quantidades excessivas de elementos e contêineres muitas vezes atende o anseio de clientes, mas cria problemas sérios para equipes de design.

É sedutor reduzir as fontes ou redimensionar controles para tudo ficar bonito no Wireframe. Mas isso não resolve o problema do volume de informações. Apenas empurra a agonia para a próxima fase do projeto.

Um bom artefato de design, entre outras coisas, deve aproveitar razoavelmente as potencialidades do meio. Além disso, deve contornar bravamente as limitações tecnológicas que cada tipo de meio normalmente oferece.

Não é justo esperar o milagre de que o designer faça o mundo caber em retangulinhos de resoluções variáveis. Não esqueçamos as necessidades atuais de acessibilidade para dispositivos. O nosso horizonte não mede mais 800 x 600 pixels. Ele pode ser muito menor ou muito maior do que isso.

Para o alcance da qualidade, é fundamental que o designer não receba como artefato de entrada wireframes entulhados de informações "acochambradas", reduzidas, espremidas, adaptadas.

Para a solução desse problema, o projetista precisa estar atento que algumas condições de volume informacional podem ser resolvidas com alternativas melhores de navegação e de distribuição de informações entre níveis.

O cliente também precisa entender que a priorização de algumas áreas resulta em encolhimento natural de outras. Todo mundo quer aparecer com a mesma relevância, mas nem sempre isso será possível.

Em alguns tipos de projeto, a própria plataforma de implementação pode oferecer recursos de tratamento desse problema, como vemos no caso do Ajax, só para citar um exemplo. Pode ser favorável ao usuário refinar as informações sob demanda, como acontece com as mensagens do Gmail - exemplo clássico.

Só precisamos de cuidado para que esses recursos possuam alternativas acessíveis para todas as pessoas. Alguém aí já tentou acessar o Gmail via software ledor de tela? Eu já tentei. É praticamente impossível de navegar e ler mensagens. Inclusive na versão "Somente HTML" do mesmo. Presteza zero da interface. Essa coisa do mito do Gmail como o case perfeito do Ajax é pano para manga para um texto exclusivo, que devo escrever em breve. Como pode o maior "case" de Ajax do mundo não implementar o conceito de graceful degradation?.

O projetista também precisa quebrar a barreira do isolamento e entrar em contato com designers e programadores, com a finalidade de checar a viabilidade técnica dos seus projetos. Não é feio perguntar, pedir opiniões. Esse tipo de integração pode evitar retrabalho para todos. Em caráter multidisciplinar e com respeito mútuo entre as equipes, quem ganha é o usuário final do que está sendo produzido.

b) Trapaça na colocação de recursos de scrolling e de previsão de rolagem de conteúdo

A possibilidade do controle de rolagem de conteúdo (scrolling) foi um recurso muito explorado um tempinho atrás. Todo projeto "moderno" tinha que ter uma barrinha de scroll customizada. Todos os problemas de redação de conteúdo agora tinham uma solução idiota: Muito melhor do que corrigir um texto ruim era colocá-lo espremido dentro de um scrollzinho.

As atuais premissas de acessibilidade desmontam um bocado a cultura do scroll customizado. Nem sempre um recurso despadronizado e caseiro conseguirá implementar todas as características de acessibilidade incorporadas por um controle padronizado, que funciona de maneira mais integrada com os sistemas operacionais e browsers disponíveis. Essa simplicidade é que garante o melhor entendimento da interface por softwares assistivos, suportando um maior número de condições adversas de uso.

Sempre que possível, o projetista deve evitar cair nesse tipo de solução clichê para tratar volume de conteúdo. É um outro caso de aculturamento de clientes. O aumento da qualidade dos textos, com a busca da linguagem e objetividade corretas, pode ser uma solução bem mais inteligente para esse tipo de problema.

Novamente, até o próximo e obrigado por estarem acompanhando a série!