Pessoal, está chegando mais uma edição do FMDS, Fórum de Mídias Digitais e Sociais, que acontece em Curitiba. A terceira edição vem cheia de novidades, tanto no formato do evento, quanto na localização que esse ano será na FIEP.

O FMDS acontecerá nos dias 03 e 04 de Dezembro, em Curitiba/PR.

O objetivo principal do FMDS 2010 é promover discussões entre empresas e profissionais
sobre as melhores práticas, técnicas e resultados no uso das diversas ferramentas e estratégias na Internet, sobretudo utilizando as mídias digitais e sociais.

O FMDS é idealizado para atender as expectativas dos seguintes públicos:

• Profissionais gestores dos departamentos de marketing e estratégicos das empresas anunciantes;
• Profissionais que geram conteúdo por meio das mídias digitais e sociais (blogueiros, videomakers, podcasters…);
• Profissionais de planejamento, mídia, criação e atendimento nas agências de comunicação e marketing;
• Profissionais de veículos de mídia off line e on line;
• Professores e estudantes de áreas ligadas ao desenvolvimento das mídias digitais e sociais.

O Fórum de Mídias Digitais e Sociais aproveita o conceito mash-up (segundo a Wikipédia: “… uma aplicação web que usa conteúdo de mais de uma fonte para criar um novo serviço completo.”) para construir seu diferencial.

Trata-se de um evento umbrella, aproveitando e misturando os conceitos de conferência e desconferência, agrupando alguns outros grandes eventos, sendo o BlogCamp, PodCon+, ETC (Twitter) , SeoCamp e BPEcommerce.

Não perca a chance de participar desse mega evento, faça logo sua inscrição

Twitter!

Talvez você já tenha visto a sigla IxD e ficou sem entender do que se trata, pois bem, ela significa Interaction Design, ou Design de Interação (DxI), não gosto da sigla em português, seria o mesmo que utilizar uma sigla EU ou XU (Experiência do Usuário) para definir UX (User Experience), portanto vamos utilizar a sigla correta, IxD.

Mas afinal, o que é IxD? Design de Interação é a mesma coisa que UX? Certamente não.
Ao passo que a UX é a experiência final sentida pelo usuário, o IxD é a matéria que trabalha os melhores aspectos do desenvolvimento de uma boa UX, pois visa entender e compreender o usuário para criar os bons métodos na criação de um produto, no nosso caso, de uma aplicação usável, funcional e satisfatória.

Certamente são muitas as matérias da área de design, mas faço questão de trazer a vocês as mais significativas, as que mais estão agregando valor aos projetos voltados a aplicações, temas que de fato estão no auge e que constroem a melhor UX possível. Temas que foram ignorados a tempos e hoje se está dando o real valor pelas grandes empresas. E um desses temas certamente é IxD.

Como IxD é uma abordagem também conceitual, ainda há divergências sobre sua definição, você encontrará muitas idéias diferentes a respeito do mesmo tema, e se por um lado isso pode ser ruim por outro a discussão é boa, já que começa a definir um pouco mais algo que no meu ponto de vista sequer pode estar engessado, ficou confuso? Você vai entender.
Acredito que IxD estará sempre em mutação, e o motivo é simples, tudo está em mutação, vejamos abaixo o que é IxD.

Design de Interação, o nome praticamente diz tudo, ou não, depende muito do seu repertório. Interação para algumas pessoas pode ser a relação entre uma pessoa e outra, mas também é no caso do nosso tema a relação entre um usuário e um produto.
O que temos de interativo quando pensamos em relação a interfaces?
Games talvez seja a sua primeira opção, e é um dos melhores exemplos, foi lá que essa matéria se desenvolveu bastante, pois era necessário entender a relação entre o usuário e o game, seu grau de satisfação.
Quem é que nunca jogou um game e teve altos graus de felicidade mas também altos graus de fúria…  essa fúria (sentida pelo usuário) foi amplamente estudada e amenizada ao longo dos anos da história dos games, podemos dizer que a cada ano diminui a quantidade de gamers que destroem seus consoles, é fato. Isso porque houve o estudo da interação entre a relação do gamer com o jogo em si, para minizar a sensação de frustração e aumentar a sensação de satisfação.
Até aí simples, mas não é só o game que é interativo, existem diversas aplicações que são interativas e a cada dia mais e mais produtos estão se tornando interativos, em breve sua TV será interativa se já não for, interativa totalmente, com uso de recursos como Google TV ou Apple TV. Mas em breve sua geladeira ora tão pacata será interativa, e quem sabe até mesmo o seu sofá. Portanto, essa não é uma matéria que deve ser ignorada por um designer, e muito menos por alguém que desenvolve aplicações.

Lembra-se que falei que essa é uma matéria mutável? Porque? Porque a cada dia surgem novas mídias ou áreas físicas onde possa existir uma aplicação interativa, portanto a cada dia o IxD ganhará novo estudo conforme o próprio desenvolvimento da humanidade.

Mas o que de fato é interação nesse tema?
Entende-se interação a relação com o usuário, e que deve ser funcional a fim de proporcionar uma boa UX.

Portanto eu entendo (devido a minha experiência como designer) o IxD como principal intermediário entre a idéia (Conceito inicial do projeto) e a UX, ele é praticamente a ferramenta de trabalho que leva o conceito a realidade, fazendo a ponte desde a concepção da idéia do projeto até a sua realização e o contato com o usuário.

Um bom IxD tem por objetivo conseguir comunicar com eficácia a informação de uma aplicação até seu usuário, definindo o comportamento da aplicação, e claro, as interações que essa tem com o mesmo.

Você se recorda do texto que eu postei sobre a visão de UX de Shane Morris? (Desenvolvimento da UX)?

Vamos concluir a idéia, Morris fala que para se conseguir uma boa UX é necessário seguir 4 etapas:
1. Projeto Conceitual (aquilo que chamei nesse artigo de ‘idéia’)
2. Design de Informação  (não confundir como arquitetura da informação)
3. Design de Interação
4. Apresentação do Design (Criação do projeto em si)

Perceba que essas matérias se misturam um pouco no seu conceito mas são distintas pode acreditar, acontece que a fronteira entre uma e outra se mistura, ou seja, quando você estuda Design de informação perceberá que esse tema é parte de Design de Interação, e quando estuda Design de Interação perceberá que ele é a estrutura de desenvolvimento da UX.

Essa é uma parte que discordo do Morris, as estruturas por ele apresentadas tratam da relação de interação com o usuário, portanto é o próprio IxD.

O IxD estuda muita coisa, desde o ambiente onde a aplicação será apresentada (computador, totem, telão, se é dia, noite, espaço aberto, fechado, etc) até o tipo de usuário que estará utilizando.

Se eu fosse abordar o IxD em todo o seu aspecto seria muito mais que um post, aqui me reservo a tratar do tema naquilo que mais nos interessa, aplicações.

Vou ao melhor exemplo que conheço de IxD, o Agon.

O Agon é  uma rede social corporativa, no qual as pessoas de uma empresa fazem pontos ao compartilhar conhecimento, tal como faço nesse momento ao escrever esse post, portanto o que foi estudado para se chegar na sua criação?

Objetivo:
- Como motivar o compartilhamento de conhecimento

Estudo:
- Relação das pessoas com os games
- Relação do funcionário com a empresa e entre si
- Relação dos usuários com redes sociais
- Interatividade com a aplicação sem alterar a rotina (curva de aprendizado) dos seus participantes

A solução você já conhece, uma rede social corporativa que utiliza a rede social Twitter para alterar sua interface (através de tweets com hashtags específicas), que atingiu o seu objetivo de incentivar as pessoas a compartilhar conhecimento. (Perceba que antes do Agon eu sequer tinha postado nada nesse blog e você talvez nem soubesse o nome do atual designer da DClick).

Então é muito simples, não é somente o estudo típico de transições em uma aplicação (consistência e inconsistência), cores, tipografia, etc, ainda que isso seja parte e é muito significativo, o IxD vê a relação entre pessoa e aplicação, analisa o aspecto humano, social e histórico.

E o que seria isso? Como no caso do Agon foi avaliado a idade do usuário, quais ferramentas ele já utilizava, foi visto o que não deu certo nas corporações para estimular o compartilhamento do conhecimento, e como fazer de uma disputa algo lúdico.
Então a criação de um tipo de game foi algo natural, afinal, estamos todos acostumados a disputar nos games com nossos amigos, parentes etc e nem por isso ao término do mesmo ficamos rancorosos com os adversários virtuais (pelo menos não a maioria de nós). A relação de disputa no bom estilo dos games foi explendidamente bem aplicada no Agon, ainda com pontuações e interatividade via rede social, eu disse interatividade? Pois bem, é essa interação o estudo de IxD, prever como o usuário irá se comportar, procurando com isso atingir uma boa UX.

Então percebemos que para se saber aplicar o IxD é necessário um conhecimento vasto da área de sua atuação, da aplicação em si, o bom designer de interação é aquele que está profundamente alimentado de informações antigas (conhecimento histórico) e novas, dos diversos segmentos possíveis, ou seja, é alguém de fato muito, mas muito bem informado e com poder de comunicação. Sem isso ele não conseguirá facilmente aplicar um IxD.

Ainda que existam IxD mais modestos, ou seja, estudos mais simples, IxD é o estudo amplo e vasto de tudo que envolve a interação com o usuário por parte de uma aplicação.

O IxD acima de tudo se preocupa com o aspecto emocional de uma aplicação, se ela é útil ou inútil isso não diz nada, um game é inútil, mas tem valor emocional muito amplo, portanto Design de Interação visa entender a relação da aplicação (ou produto) na vida do usuário, como isso se reflete e repercute no dia a dia do mesmo.

Se através desse texto você se sentiu atraído a saber mais sobre esse tema pouco explorado ainda no Brasil, resta dizer que existem algumas poucas faculdades voltadas ao assunto, existindo inclusive uma pós-graduação, já no exterior diversas universidades abordam o tema, e existem mestrados inclusive. Porém lhe aconselho a visitar a associação IxDA (Interaction Design Association), da qual sou membro atualmente, uma boa oportunidade para você ficar antenado sobre o assunto.

Eu poderia colocar os passos do que é a profissão de Design de Interação, o que faz ou deixa de fazer, ou como se tornar um designer de interação e quais passos exatos tem essa matéria, existem diversos autores do assunto, mas meu objetivo aqui era passar toda a idéia conceitual  para que você se municie de informação interativa, sim, aquela que se liga a outras áreas do seu cérebro, pois garanto, que tópicos e passos determinados não serão facilmente lembrados, mas um texto que interage com demais informações, ou seja, com seu repertório, ficará enraizado e você se lembrará do que é IxD com facilidade. Portanto espero com isso ter interagido com demais conhecimentos que você possui fazendo que tenha tido uma boa UX ao término da leitura…

Até a próxima.

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

* Alta disponibilidade
* Segurança abrangente
* Gerenciamento simplificado de TI

 O BPOS é composto dos seguintes serviços online:

Twitter: @atsh2

Twitter!

Diferente dos screencasts anteriores, dessa vez gostaria de compartilhar com vocês uma sugestão para a organização dos diretórios e arquivos de um projeto.

Uma das maiores dificuldades em se trabalhar em diferentes projetos e em diferentes equipes é o processo de busca por um determinado arquivo ou quando o achamos, se ele é realmente a versão final do arquivo…

Essas e outras dúvidas que nos perguntamos toda vez que precisamos de algo feito por nós ou por outros colaboradores pode ser facilmente solucionada com pequenas ações e uma delas é justamente o tema de hoje.

E aproveitando o assunto, que tal modificar a forma com que envia seus e-mails, facilitando a sim a vida de todos…

Dica de como escrever um assunto de e-mail
Para facilitar sua vida e a das pessoas que recebem seus e-mail, aqui vai uma sugestão simples e que não afeta em nada o tempo investido no envio dos e-mails.

A receita é simples, basta utilizar o modelo abaixo:
[<Empresa> - <Projeto>] <Assunto de forma objetiva> – <extras>

Exemplos:
[DClick - Agon] Wireframes do módulo administrativo – v01
[DClick - Agon] Lista de colocados no round 1

Viu só como pode ser muito mais fácil a comunicação…
Agora vamos aos diretórios e nomes de arquivos.

Twitter!

Começamos este post afirmando que você ama UX, que você quer UX na sua vida a todo momento, a menos que… você seja um masoquista, e para atingir a satisfação você goste de experiências diferentes das quais a maioria das pessoas estão interessadas.
Portanto, a experiência que trataremos nesse texto é sobre a boa experiência, e se possível sobre a experiência maravilhosa…
A User Experience (UX) é mais comumente tratada pelo literal do seu nome, experiência do usuário, mas  afinal como essa matéria é de fato aplicada pelos profissionais da área de tecnologia e como é vista realmente.
O objetivo desse post é de maneira resumida (se você pensar em um livro) fazer você entender o que de fato é UX, o que não é UX, e como utilizar a UX em benefício próprio e do seu projeto.

Escrever sobre User Experience em milhares de páginas é fácil, isso tem sido feito a anos e as pessoas até hoje tem idéias diferentes sobre o mesmo tema, e poucos sabem definir com exatidão em poucas palavras do que afinal ele se trata. O difícil mesmo é trazer a informação correta e objetiva em um texto que é acessível a todos, e esse texto também é uma experiência pela qual você (usuário) está passando nesse momento, portanto espero que ele seja o mais agradável possível, e que cumpra sua função.

.

O que não é UX

Acredito firmemente que para explicar UX é necessário antes de tudo mostrar o que não é UX, e vamos por tópicos.

- Usabilidade
Não é UX, e apesar de todos confundirem essa matéria com UX ela não é a experiência do usuário, ela ajuda a melhorar drásticamente a experiência, mas ela em si não é a própria experiência, portanto vamos descartar a Usabilidade do termo UX e vamos inseri-la como parte do processo de UX.
É comum, muito comum por sinal, você ver os profissionais de usabilidade se apoderando do termo UX, certamente porque foram eles sem dúvida que fizeram renascer  essa idéia na área de tecnologia, e vamos entender por tecnologia nesse texto todo o tipo de aplicativo e interface disponível que possui uma interação com o usuário.
Se você é um arquiteto de informação pode estar se perguntando porque eu disse renascer,  já que a idéia a esse respeito é de que o termo foi criado através da Usabilidade e que são esses profissionais unicamente que se preocupam com o bem estar do usuário, mas não é bem assim como veremos mais a frente. Por hora vamos ficar com a firme noção de que usabilidade não é UX.

- Arquitetura de Informação
Sei  que há uma discussão eterna de que Arquitetura de Informação e Usabilidade são as mesmas coisas, não vou entrar no mérito,  para esse texto Arquitetura é a disposição e organização da informação, que gera é óbvio a usabilidade (ou não).
E porque Arquitetura de Informação não é UX? Ela organiza a informação de forma a gerar ao usuário uma melhor experiência, esse é o seu objetivo, mas será que sozinha é capaz desse feito? Quem já não se deparou com sites extremamentes funcionais (usabilidade) e bem organizados (arquitetura) e cujo layout era para lá de ridículo, para não dizer horrível, e por fim apesar de cumprir bem com sua função não gerava uma boa experiência.

- Design
Ah sim, Design… a maioria das pessoas ama essa matéria,  somos todos apaixonados  pelas coisas bonitas e pela estética, no entanto, o estético e o belo também devem ser funcionais, de nada adianta uma boa interface se não funcionar, e de nada adianta funcionar se você não for capaz de chegar onde você quer.
Certamente Design não é UX, e isso parecia óbvio para você, mas óbvio não é saber que tal matéria é importantíssima para a experiência do usuário, visto que, digo novamente, a associação de UX a Usabilidade parece a cada dia mais forte, e infelizmente é isso que está fazendo as pessoas não entenderem do que se trata o termo UX.

.

O que o mundo acha que é UX e porque nós pensamos diferente

Vamos frizar, vamos bater na tecla novamente, a maior parte das pessoas está pensando que UX é Usabilidade, não é incomum você ver gerentes de projeto, designers, arquitetos, todos substituindo o termo usabilidade unicamente por UX, dizendo equivocadamente “A UX do site está pronta?” tratando o layout, o design por esse termo, ou mesmo os wireframes, e por aí vai. Esse tipo de comentário faz a cada dia as pessoas banalizarem um termo que tem um grau alto de importância em um projeto.
Você cria aplicativos, sites, hotsites, para quem? Primeiramente ao cliente que te pediu, mas obviamente para um usuário que vai utilizar o sistema, esse usuário precisa ter uma boa experiência, ele precisa ter a sua satisfação atingida.
Nós não devemos pensar a User Experience como algo palpável, algo que pode ser visto, porque não pode, UX não é usabilidade, UX não é arquitetura, UX não é wireframes, UX não é o layout, design, etc.

.

Mas afinal, o que é UX?

Se alguém te fizer essa pergunta e você tiver que explicar em uma frase o que você diria? Apesar de parecer complexo, UX não é nada complexo, e se resume sim em uma única frase.

UX É CONCEITO.
Simples, não tem mistério, não tem milhares de terminologias para definir UX, ninguém é dono dessa matéria, e ninguém pode dizer que é seu criador. Isso porque UX por ser conceito é algo muito mais antigo do que os arquitetos de informação atualmente comentam, como algo novo, criado por eles, como disse anteriormente, eles fizeram renascer o termo, mas não o criaram.
E porque UX é conceito?
Você depende de diversas matérias para que a experiência do usuário seja atingida com satisfação,  é necessário uma boa arquitetura da informação, uma boa usabilidade, um bom layout, uma boa estrutura de dados (de nada adianta também uma programação ruim, banco de dados lento) etc, e de tudo o que for importante para que a aplicação funcione e seja agradável, que atinga todos os  objetivos almejados pelo usuário, isso certamente trará a ele uma boa experiência. Ok, mas para que isso aconteça é necessário estudar alguns assuntos, e vamos trazer aqui uma idéia superficial disso, mas o nosso objetivo aqui é fazer você entender de maneira rápida o que de fato é UX e porque as pessoas tem usado esse termo de maneira equivocada.

Com o que foi escrito até agora acredito que você já entendeu boa parte da idéia, percebeu que Usabilidade, Design, e outras matérias trazem algo concreto (que gera a UX), e que UX é algo abstrato, por isso UX é conceito, tais matérias são responsáveis por uma boa UX ou uma UX ruim, claro que, nosso intuito é termos uma boa UX,  mas acredito que a partir de agora você não mais vai chamar um wireframe de UX, ou mesmo uma layout de UX, pois percebeu que a UX é algo experimentado, você pode dizer “Essa interface não me parece trazer uma boa UX…” pois antes mesmo de a mesma ir ao usuário somos capazes de avaliar todo o conjunto da obra, e pensar se o nosso usuário vai de fato ficar satisfeito com a aplicação.
Mas tem algo que você talvez ainda se pergunte, porque estamos insistindo que UX não é algo novo, vamos então ao assunto.

.

História da UX voltando a Ergonomia

Poderiamos voltar na história da Bauhaus (escola de design) para tratar do assunto, mas isso estenderia demais o post, vamos resumir essa passagem.
Bauhaus é uma escola de design que se preocupou com ergonomia, em uma época em que as pessoas se preocupavam com produção, logo após a revolução industrial. As empresas faziam milhares de cadeiras, e quando tinham que pensar nos gostos do usuário apenas variavam a cor, então tinhamos milhares de cadeiras idênticas com cores diferentes, era azul, rosa, violeta e afins para todos os gostos, porém algo não era visto, o consumidor, e quem é ele? Ele é o usuário dessa cadeira, aquele que vai usá-la, então os designers da Bauhaus começaram a pensar na matéria de ergonomia, e a analisar como seria a cadeira ideal para um determinado tipo de usuário, e não só isso, mas para uma determinada tarefa que o usuário precisasse executar, logo a cadeira da sala não era igual a cadeira da cozinha e assim por diante. Estou sendo simplista.

Essa matéria foi criada pela Bauhaus? Não, claro que não, se a gente for voltar no tempo vamos chegar nos gregos e no seu estudo sobre simetria (porque o ser humano gosta do simétrico), e se voltarmos mais ainda vamos chegar na era da pedra… o homem sempre se preocupou com a UX, sempre se preocupou com a experiência do usuário, pois como disse, não somos masoquistas, pelo menos não a maioria de nós.

Assim sendo na web não aconteceu diferente, com a revolução tecnológica, com os milhares de sites surgindo, milhares de aplicativos, o mesmo erro voltou a acontecer, eram sites de todas as cores para todos os gostos, aplicações com botões azuis, rosas, vermelhos, mas poucos se preocupavam com a ergonomia desses sites e aplicações, e o que é a ergonomia na nossa área de tecnologia? Devemos pensar no tempo de exposição do usuário a aplicação, qual a finalidade da aplicação, que tipo de usuário majoritário temos para a aplicação, quais funcionalidades existem e como otimizar a informação ao máximo para que o usuário encontre o que necessita. Esse é apenas um resumo do resumo, a matéria é vasta, mas ergonomia para a nossa área existe, e hoje ela é chamada de UX.
Portanto não há nada novo aí, apenas o mesmo erro foi cometido e a mesma solução foi aplicada, tratar o usuário com o devido grau de importância.
Ok, mas você vai ainda perguntar, “Então como fazer uma boa UX?” com poucas palavras é difícil dizer, mas faremos o possível para que você entenda com um exemplo prático.

1. Curva de Aprendizado.
2. Curva de Satisfação.
3. Atender uma necessidade do usuário que ele desconhece.

Essas são as três chaves mestras para se ter uma boa UX, acredito que a primeira você já ouviu falar por todos os cantos mas a segunda talvez seja novidade, a terceira então… bom, vamos a explicação.

.

Curva de aprendizado

A curva de aprendizado como sabemos é o período que o usuário leva para entender um site ou uma aplicação, esse período deve ser curto, o mais curto possível, porém existem exceções, e explicaremos logo mais.
Primeiro vamos a um exemplo prático, vamos utilizar o Twitter para ser avaliado.
Não é incomum a frase “Ninguém pode explicar o sucesso do Twitter…”

Escreverei minha visão particular, como autor do post, eu de fato ouvi essa frase por diversas vezes e por milhares de pessoas, mas será mesmo que não podemos explicar rapidamente o sucesso dessa ferramenta fantástica?
Sim podemos.
Ela possui elementos já conhecidos do usuário, vamos a eles:
- SMS
- Blog
- Rede Social
- ScrapBook (tão conhecido no Orkut)

Você vai concordar que quando se acessa o Twitter pela primeira vez leva-se algum tempo até entender o que está acontecendo, mas esse tempo de aprendizado é curto, pois nele há elementos que você já conhece, tal como os mencionados acima, e rapidamente você já está utilizando a ferramenta.

Então chegamos a uma conclusão, o tempo de aprendizagem do Twitter é curto, e portanto ele oferece uma boa experiência nesse quesito.
Mas é necessário que sempre a curva de aprendizado seja curta? Em regra sim, mas como disse há exceções, elas acontecem quando por exemplo você cria uma aplicação para uma empresa utilizar internamente, ela poderá ter situações diferentes que o usuário desconheça, pois a empresa poderá oferecer treinamento a seus usuários, mas reforço, essa é a exceção, pois quanto menor for esse treinamento melhor também será a aceitação dessa ferramenta, e se não houve necessidade então de treinamento …

.

Nível de Satisfação

Hum, talvez você deva estar pensando em comida, ou talvez nem isso…  mas é fato, o ser humano precisa se satisfazer, e quando usamos uma aplicação não é diferente, é necessário um grau de satisfação para que voltemos a utlizá-la.
Quando lidamos com clientes eu digo que esse é o tema mais importante  e deve ser observado com cuidado.
Todo cliente necessita ter seu grau de satisfação atingido, ele tem uma expectativa em relação a aplicação que você está desenvolvendo, geralmente ele até já imaginou como é a interface dessa aplicação, então você tem duas soluções, ou mostra algo que ele vai olhar e dizer “ah, não era bem isso mas está bonito.” ou ele vai dizer “Fantástico, ficou melhor do que eu pensei”.
Acredite, não há meio termo, não vai existir a frase “Foi exatamente isso que pensei”, não mesmo, ou você supera as expectativas ou fica abaixo da média, quando você supera as expectativas ótimo, mas quando fica abaixo da média é que surgem os problemas.
Por conta do nosso primeiro usuário (o cliente) não ter atingido seu grau máximo de satisfação ele logo vai começar com frases bem conhecidas “não sei, talvez a gente possa mudar essa cor aqui.. “ ou “acho que precisa de mais texto”, ou ainda… “Vamos inserir alguns campos nesse formulário, estou achando meio pobre”, entre outros clássicos.
A culpa é dele? Não, o que aconteceu é que ele não atingiu seu nível máximo de satisfação e como todo ser humano ele vai tentar preencher  isso com alguma coisa, como não estamos tratando de comida, não basta só tomar um cafezinho e comer um chocolate…

Ok, mas não estávamos usando o Twitter como exemplo? Pois bem, voltemos a ele.
O nível de satisfação do Twitter é alto, é bem elevado, isso porque o usuário está usando uma aplicação que atendeu as suas necessidades, porém, resolvendo problemas de comunicação que ele desconhecia existir, vamos ao tema.

.

Atender uma necessidade do usuário que ele deconhece

O que é isso? Como atender uma necessidade que o próprio usuário desconhece? Ninguém sabia que era necessário criar a roda até que ela existisse, foi criada a partir de uma necessidade, mas desconhecida pela maioria.
Assim foi com o Twitter, ele sanou um problema de comunicação que a maioria das pessoas sofria na internet, a falta de informação objetiva, poder seguir pessoas sem qualquer vínculo ou comprimisso. Claro que, se você quer uma informação um pouco mais aprofundada vai procurar um post como esse, e se ele não te sanar todas as dúvidas é provável que você compre um livro ou faça novas pesquisas, mas é certo que o Twitter é muitas vezes o início de tudo (você pode inclusive ter chegado aqui através dele), filtrando milhares de informações e otimizando a informação de algo que corre na velocidade da luz, a internet.

Por isso, e pelos motivos acima descritos ele é um sucesso, os seus criadores Jack Dorsey, Biz Stone e Evan Williams fizeram o Twitter para atender suas próprias necessidades (a idéia mesmo foi do Dorsey), e quando isso acontece o resultado geralmente é atender a necessidade de outros tantos semelhantes.

Existem milhares e exemplos que podem ser usados como uma boa UX, tal como o Google, mas creio que você já tem como fazer suas próprias análises.

E para quem pensa que UX é Design (tópico para designers)…

.

Arte que se explica não é arte, é artifício

A arte deve ser sentida, a arte deve ser experimentada, cada qual terá sua própria experiência através do Design, mas seja ela boa ou ruim, varia de pessoa para pessoa, de público para público.
Portanto primeira passo, para quem é o design, quem é o nosso usuário, e quem é nosso público final.
Temos evidentemente dois tipos de usuários em algumas situações. Quando possuímos um projeto que nos é solicitado por um cliente então algo deve ser muito bem avaliado, seu primeiro usuário será esse cliente, ele quem utilizará a aplicação pela primeira vez, e então depois dele será o cliente do cliente, o segundo usuário e este é o mais importante, tanto para você quanto para o seu cliente.
Porém é necessário que você agrade gregos e troianos, é imprescindível que você atinja todas as necessidades do cliente, e quando possível demonstre que entende e conhece o cliente dele, que você se preocupa com o usuário final e por isso tais coisas devem ou não serem implementadas. Acredite, se você agradar unicamente seu cliente, e não o cliente dele, o seu cliente pode dizer hoje “fico maravilhoso”, e amanhã dizer “aquela aplicação que você fez não é boa, ninguém gostou… ninguém acessa.”

O Design não precisa ser explicado, o que precisa ser explicado é a disposição da informação, as cores, mas não o seu conjunto, não adianta ficar inventando coisas do tipo “isso causa uma sensação de fluidez” quando isso não é sentido nem por você e nem pelo usuário, é diferente dizer, “essa sensação causada por essa transição chamamos de fluidez e os usuários gostam disso”.
É óbvio que existem milhares de matérias que  o designer deve conhecer para fazer uma interface, desde semiótica a teoria das cores, mas não adianta ser acadêmico, é a experiência, o dia a dia que vai fazer você criar uma boa interface, não esquecendo que você também é um usuário, pense como tal ao ver sua própria “arte”.

Esse post é o resumo de uma palestra ministrada aqui na DClick, muito poderia ser comentado mas a objetividade em textos é muito mais complexa que na fala, pois aqui estamos consumindo o seu precioso tempo.

Assim sendo, vou finalizar com alguns mitos a respeito de UX, que se precisar de algum comentário pode postar sua dúvida que estarei a disposição para responder.

.

10 piores mitos a respeito de UX

- Mitos entre os Desenvolvedores

#1  O cliente não repara se o campo está  1px para a direita ou se está muito amarelo, o cliente quer saber se o aplicativo funciona.

#2 Não faz diferença se o canto é arredondado ou se não é, ninguém vai reparar nisto.

#3 A aplicação está lenta mas está funcionando, é isso que importa.

- Mitos entre os Designers

#4 O Cliente deve ser ouvido

#5 O Cliente é quem define as cores

#6 O usuário deve ser ouvido

#7 O layout é que faz vender o produto

- Mitos entre os Arquitetos de Informação

#8 Site acessível tem que ser “feio”

#9 Todas as páginas devem ser acessíveis em 3 Cliques

#10 Seu usuário é como você

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

Web RunTime é uma das possibilidades que a Nokiaoferece para criação de aplicativos para seus dispositivos movéis. Se você já é um desenvolvedor web, você não precisa de quase mais nada para começar a desenvolver para os dispositivos Nokia usando o WRT. Ele permite a criação de widgets para plataforma S60 sendo uma extensão do navegador Webkit permintindo que as instâncias do browser sejam executadas como se fossem aplicativos separados. E você ainda pode criar aplicativos mais ricos com o uso do Flash.

Ferramentas de desenvolvimento.
A Nokia oferece algumas ferramentas para facilitar o desenvolvimento para WRT:

• Nokia Web Developer Environment Standalone.
• Plugin para o Aptana Studio.
• Extensão para o Adobe Dreamweaver.
• Plugin para o Microsoft Visual Studio.

Também oferece UI Framework e Library como:

• Guarana WRT UI library – Uma library baseada em JQuery para o Nokia WRT feita pelo pessoal do INdT(Instituto Nokia de Tecnologia) com sede em Manaus.
• Nokia Mobile Web Templates – Um conjunto de templates otimizados para mobile e para você customizar como quiser.

E tem algumas API’s para se trabalhar com os recursos dos dispositivos movéis.

• Platform Service 2.0 – Uma API em JavaScript e ActionScript 2.0 para acessar recursos dos dispositivos movéis como acelerometro, geolocalização etc.
• API Bridge – é um componente para aparelhos Nokia com Symbian, que permite widgets WRT, conteúdo Adobe Flash Lite e aplicações Java possam acessar recursos do dispositivo através de uma arquitetura plug-in. Os desenvolvedores podem estender o componente APIBridge com os seus próprios plug-ins.

Como funciona os widgets feitos com Web RunTime? esse widgets são arquivos com extensão .wgz que nada mais é que um arquivo compactado com os arquivos de seu site. Os arquivos que não podem faltar são:

• Info.plist – arquivo responsavel pelas informações de seu widget como versão, pagina inicial, nome etc
• index.html – na verdade, pode ser qualquer nome desde que esteja setado no Info.plist como MainHTML.

Criar widgets com WRT e Flash Lite
Como você usa html para criar seus widgets com WRT, nada impede de usar o Adobe Flash na mesma maneira de como você usa normalmente atraves do html. Vamos ver um exemplo usando JavaScript para fazer a comunicação com o Flash atraves da classe ExternalInterface. Nesse exemplo utilizarei o Nokia Web Developer Environment Standalone.

• Crie um novo projeto do tipo Symbian web apps->Basic web app project. Dê um nome para seu projeto e clique em next. São gerados os arquivos basicos para seu projeto.

Daremos a opção do usuario escolher dois videos para tocar. Começaremos com o html contendo as opções de video.

E o html que carregará o swf responsavél por tocar o video:

Editaremos o arquivo basic.js para adicionar o método que mandará para o swf o video que deverá ser tocado.

No Flash, criamos um arquivo do tipo Flash Lite 3.0 ou 3.1. No painel da library, clique em na opção “new Video”. Dê o nome de instancia de “vd”. Em type deixe selecionando “Video (ActionScript-controlled) e adicione no stage. Adicionaremos o seguinte codigo para que o Flash execute o video via stream a partir do Flash Media Server:

Usamos a classe estatica ExternalInterface para que nosso método dentro do Flash possa ser chamado a partir do JavaScript. Executando o emulador do Nokia Web Developer, devemos ter algo parecido com isso:

Emulador Nokia Web Developer

Para gerar o arquivo .wgz, bastar clicar com o botão direito no projeto e pedir “Package Web app” e seu aplicativo está pronto para rodar no celular. Testei no Nokia 5230

Para saber mais:
http://www.forum.nokia.com/Develop/Web/Tools/
http://wiki.forum.nokia.com/index.php/Category:Web_Runtime_%28WRT%29
JQuery Mobile
Adobe Flash Lite

Enquanto alguns se questionam, se a plataforma Flash irá sobreviver frente ao HTML5 e ao mimimi do Steve Jobs (Apple) que é totalmente anti-Flash, o pessoal da Adobe mostra que não está para brincadeira…

 

Temos ai mais um excelente exemplo, no qual podemos ver o poderio avassalador da plataforma Flash.

Aonde trabalho essa semana passada (18~22/10/2010), surgiram questionamento sobre a possibilidade de criar aplicações onde o usuário possa ter mais liberdades de fazer basicamente o que quiser na interface. Bom esta aplicação que veremos neste post, responde com um belo SIM! Porém é importante lembrar que aplicações desse gênero custam $$$ e levam um tempo considerável para ser implementadas.

 

Mas chega de enrolação, vamos falar do que interessa aqui.

Apresentando um preview público do projeto ROME, o qual é uma ferramenta de criação e publicação de conteúdo para virtualmente qualquer um.

 

É muito mais do que você sonharia de poder de mídia digital para expressar suas ideias. Caso você queira criar e interagir com um relatório, onde neste tenha vídeo, música, dividir suas apresentações com animações e interatividade, elaborar um ofício visual com gráficos feitos por você mesmo para enviar por e-mail, ou quem sabe projetar e publicar seu primeiro website para todo mundo ver. Mas não sabe por onde começar.

Hoje, a Adobe lhe apresenta uma prévia sobre o projeto ROME, o qual é uma ferramenta tudo em uma só, para criar e publicar conteúdo, utilizando-a de casa, trabalho ou na escola. Esta ferramenta é direcionada a qualquer um que queira adicionar o poder do vídeo, áudio, fotos, gráficos texto ou animações em qualquer tipo de projeto que tenha que criar em seu dia a dia – para materiais que serão impressos e apresentações para arquivos e websites. Você pode começar e finalizar tudo em um ambiente simples e criativo e você também poderá trabalhar com seus arquivos de basicamente qualquer lugar, pois o projeto ROME, possui tanto versão web, quanto uma versão instalável desktop.

O objetivo da Adobe em construir o projeto ROME, tão intuitivo e interativo, na qual a tecnologia não será um impe cílio e dor de cabeça para que você possa expressar suas ideias, com vídeo, áudio, fotos, gráficos, texto, ou animações. A interface é bem limpa e simples, ainda sim ela é bem poderosa. Por trás desse projeto está a tecnologia padrão da Adobe (plataforma Flash), a qual foi projetada e planejada para que você possa rapidamente e facilmente começar a utilizá-la. O projeto ROME é destinado para aqueles que diferente de nós, não são profissionais da área (ex.: designers), porém desejam e querem expressar suas ideias através de um meio mais poderoso, utilizando conteúdo digital.

Para uso no trabalho, tente criar um relatório multimídia, ou então uma apresentação para expor sua ideia causando impacto. Ou então, que tal criar seu primeiro website familiar, usando gráficos, fotos, som, vídeo e animação? Ou então, colaborar e compartilhar seus projetos com seus colegas, clientes, amigos e familiares, através do Adobe Acrobat.com, ou Google Apps, ou através das redes sociais como por exemplo, Twitter ou Facebook.

A Adobe está oferecendo um beta público do projeto ROME e está nos convidando para testar e saber o que achamos desse projeto. [http://rome.adobe.com]

 

Além dessa versão poderosa descrita acima, a Adobe também pensou e disponibilizou uma versão especial focada para educação: Projeto ROME Education.

 

Para professores, o pessoal da Adobe criou uma versão especial. No intuito de auxiliar e melhorara a experiência de aprendizado, criando um novo meio de ensino, para melhorar a comunicação, expressão das ideias e informações, através de meios mais engajados.

Você e seus estudantes pode utilizar o projeto ROME Education individualmente ou em um ambiente colaborativo, compartilhando arquivos entre os serviços integrados, como Google Apps ou Moodle, um sistema de gerenciamento de aprendizado, dentro ou fora de sala de aula.

 

Obs.:

- um último lembrete, o projeto ROME não foi criado em apenas 1 dia. O pessoal da Adobe pede a sua ajuda para melhorar ainda mais a ferramenta.

- Realizei um teste na ferramenta, ela solicita login e senha da Adobe, o qual é o mesmo que você usa quando precisa acessar algum serviço no site da Adobe.

 

A seguir um vídeo sobre a ferramenta:

Via: @leofranca5 – blogs.adobe.com

Veja também:

• #soudev agora social
• [ Java desktop ] Calculadora Léxica
• [ Adobe AIR ] Local File Explorer
• [Adobe AIR 2 : NativeProcess + Java] SimpleAirJava
• [Adobe AIR 2 : NativeProcess] projeto de exemplo : Windows Console

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

O Zend AMF é uma implementação feita em PHPpara se trabalhar com o protocolo de comunicação binário AMF(Action Message Format) fazendo parte do ZendFramework. Precisei implementar um sistema de upload de arquivos que fosse um pouco diferente do que normalmente é usado no Adobe Flash, sendo que essa funcionalidade precisava ser integrada no Zend AMF.

Pesquisando um pouco na net, achei a solução que foi mais simples do que eu imaginava baseada nesse artigo com algumas poucas adaptações.

Começaremos pelo nosso gateway que será usado como endpoint no Adobe Flex.

Agora o nosso VO com propriedades com nome do arquivo e os binarios.

Agora nossa classe PHP que ser responsavél por efetudar o upload.

Agora vamos a camada de visão usando o Adobe Flex, começamos com nosso VO.

Agora nosso mxml que carregará os bytes do arquivo para enviar para o Zend AMF.

DOWNLOAD SOURCE

Twitter!

Antes de iniciar o artigo é importante que tenhamos em mente que a disciplina denominada “Arquitetura de Informação” não é algo novo, não está relacionada exclusivamente ao universo digital e principalmente não é apenas a geração de wireframes.

Com base nessa afirmação, vamos abordar de forma prática o papel dos Arquitetos de Informação dentro dos ambientes corporativos. Isso porque é muito comum vermos nas organizações profissionais híbridos, ou seja, aqueles que atuam em mais de uma disciplina ao mesmo tempo.

Tendo em vista que no Brasil o cargo de Arquiteto de Informação é algo relativamente novo (aproximadamente 8 anos) e que os cursos de formação de profissionais ainda estão testando as metodologias e disciplinas que farão parte da grade curricular. Isso porque essa é uma profissão que é formada pelas mais diferentes especialidades, como por exemplo, designers e bibliotecários. E estamos em um processo de análise dos benefícios da presença dessa etapa no desenvolvimento das soluções, bem como tentando demonstrar aos clientes que ao se planejar e testar com aquele que será o usuário final o resultado final é mais seguro no ponto de vista das expectativas.

As vantagens de adotar os processos de Arquitetura de Informação podem ser sentidas durante todo o ciclo de desenvolvimento de uma solução. Isso porque além de entender realmente o que o cliente deseja e poder propor melhores soluções para uma determinada necessidade, todos os envolvidos (arquitetos, designer, desenvolvedores, gerentes de projeto, clientes e usuários) conseguem ter a visão do todo.

Ao ter a visão completa do projeto, fica muito mais fácil e seguro levantar o escopo do projeto, o esforço de cada uma das disciplinas, fazendo com que tanto o cliente quanto o fornecedor tenham uma visão clara da solução.

Claro que isso não significa que o projeto está “engessado”, afinal ao longo do desenvolvimento podem ser levantadas novas necessidades, surgimento de questões técnicas e reavaliação por parte dos envolvidos com a finalidade de melhorar a experiência do usuário (UX – User Experience).

Um dos principais equívocos por parte das organizações está em atrelar o trabalho do Arquiteto de Informação apenas a entrega dos wireframes (protótipos estáticos ou navegáveis), afinal esse tipo de documentação é apenas uma representação física que servirá de apoio para que os conceitos construídos sejam transformados em algo mais tangível e permita um melhor entendimento de todos os envolvidos.

O papel do Arquiteto de Informação é principalmente entender e garantir que as funcionalidades principais não sejam prejudicadas por fatores externos. Ou seja, é importante termos em mente que principalmente em produtos virtuais, onde o custo de produção é completamente diferente de um item físico e as possibilidades de mudanças e implementação de novos recursos são vistos como algo extremamente simples e sem impactos, manter o foco naquilo que é importante para o usuário é fundamental.

Sabemos que é complicado manter um profissional alocado tempo integral em um projeto, contudo devemos lembrar que a melhor forma de garantir a manutenção da estratégia que foi concebida é permitindo que a comunicação entre os membros da equipe e o Arquiteto de Informação possibilitando uma visão filtrada das necessidades apresentadas pelo cliente e permitindo uma comunicação fluída.

Outra estratégia que algumas empresas adotam é de colocar um profissional que faz a “ponte” entre o cliente e o Arquiteto de Informação. Isso pode gerar algum ruído na comunicação e posteriormente problemas no entendimento das reais necessidades do cliente e principalmente daqueles que serão os reais usuários da solução. Por isso recomendamos que haja um processo de imersão do Arquiteto dentro do cliente para que ele possa vivenciar a cultura daquela organização e assim entender os problemas e os tipos de recursos que são de conhecimento geral dos usuários.

Ao conhecer a cultura da organização e o perfil dos usuários, o processo de construção do conceito que será adotado se torna mais ágil e assertivo.

Agora que conhecemos um pouco do papel do Arquiteto de Informação trataremos nos próximos posts sobre os dois programas de prototipagem mais utilizados na atualidade .