Nesta semana que passou estive na RubyConf Brasil. Um excelente evento, sinceramente eu não tenho nada a reclamar, só tenho elogios para o Fábio Akita e a Locaweb (na verdade 2 palestras me incomodaram, mas isso não tem relação com a organização).

Apesar do evento ter sido fantástico sempre existem reclamação. E este ano a reclamação ficou em dois pontos, wifi inexistente e projetores.

Reclamando do WIFI

A primeira reclamação eu acho totalmente sem sentido, já que o único motivo para eu ir aos eventos é assistir palestras e conversar com as pessoas. Internet eu tenho no escritório e para urgências o 3G do meu iPhone atende perfeitamente.

Eu não consigo prestar atenção em duas coisas e notebook/ipad durante as palestras me distrai. Por isso já nem levo notebook mais quando não vou palestrar. Então não dou a mínima para internet e sinceramente acho que os eventos já deveriam anunciar que não vai ter internet, assim ninguém reclama.

Reclamando dos Projetores

Os palestrantes reclamarem dos projetos acho que faz um pouco de sentido, mas só um pouco.

Seria muito legal a organização deixar tudo regulado mas qualquer palestrante sabe que organizar um evento é um trabalho colossal e se você quer que sua palestra corra bem não é bom depender de pontas que a organização pode ter deixado passar (isso é totalmente aceitável e esperado).

Mais uma vez: não culpe a organização pelo projetor, culpe a si mesmo. Em um evento o mais importante é ter gente na platéia (quanto mais melhor) e o projetor é uma coisa mínima. Você se propôs a palestrar, então deve ter um plano de contingência para essas situações.

Acho que nos últimos 3 anos acumulei algumas horas de palestras e também umas 300 horas de aula. O legal (ou nem tanto) é que deu tempo para muita coisa dar errado e algumas darem certo.

Meu amigo Carlos Eduardo da e-Genial sabe como a minha primeira aula de Flex em 2007 foi ridícula, um fiasco total (obrigado por não ter me demitido de imediato .

Então aprendi algumas coisas que tento seguir em meus cursos e palestras. Talvez isso possa ser útil para você também.

Palestras/Aulas Online

Uma palestra presencial é completamente diferente de uma palestra online.

Online você tem mais controle do seu ambiente e não depende de microfone e projetor. Assim você pode usar qualquer cor nos seus slides e tudo vai aparecer perfeito (isso se a ferramenta for boa como o Treinatom).

Por outro lado aprendi quem em eventos online você tem que falar bem mais e com muito menos pausa que eventos presenciais, do contrário as pessoas começam a ficar cansadas (nesse caso, é melhor você ficar cansado do que a platéia).

Não cometa erros online. Um erro online tem uma proporção muito maior e sua credibilidade vai pelo espaço muito mais rápido. Cinco minutos encontrando um bug ao vivo não parece nada, online é uma eternidade.

Palestras Presenciais em Eventos

Ao presencial as coisas são bem diferentes e como não é possível ter controle nenhum do ambiente sempre tomo alguns cuidados.

A primeira coisa é a resolução, raramente encontro projetores com resolução de 1024 ou superior, então sempre uso 800×600 nos slides.

A segunda coisa é a calibragem do monitor. Sempre que plugo meu Mac no projetor vou em System Preferences/Displays/Color escolho o sugerido pelo S.O. (as vezes ajusto manualmente o perfil também).

A terceira coisa é em relação ao contraste dos slides. Como você não tem controle da iluminação é bom criar seus slides com bastante contraste entre o conteúdo e o fundo. Não precisa tirar os efeitos e usar slide branco com texto preto, só cuidar do contraste. Sempre uso dezenas de transições, efeitos e as vezes desenho meu próprios ícones para os slides mas fico atento para que o conteúdo contraste bastante do fundo.

A quarta coisa que sempre tomo cuidado é com a centralização. Nunca espero que o projetor esteja alinhado (nunca está), então coloco tudo centralizado. Se vai ter código coloque-o em um box mais para o centro do slide. A mesma coisa para vídeos, deixe-os centralizados.

Use fontes grandes no seu código, com fundo branco e texto com muito contraste. Eu também uso o Copy as RTF no Textmate para colar código no Keynote.

Outra coisa é que não importa o que aconteça, em um evento grande eu não passo do tempo de forma alguma. Acho uma falta de respeito um palestrante atrasar o evento todo porque não preparou sua palestra direito (a final de contas foi você aceitou o convite ou enviou uma proposta).

Para evitar problemas com tempo eu sempre uso o “Presenter Display” do Keynote do Mac. Nele você vai ver o próximo slide e o tempo gasto (acho isso fundamental).

Caso você plug seu Mac e não apareça “Presenter Display” basta ir em System Preferences/Displays e “des-espelhar” os monitores. Se os monitores ficarem trocados bastar arrastar o menu para o que você deseja que seja o primário (como abaixo).

Live Coding

Live Coding é um caso a parte pois é uma fonte gigante de problemas. Parta do princípio que você vai errar tudo ao vivo, mesmo que seja o criador do Rails você vai errar uma demo com ele!

Nas aulas online eu sempre tenho um guia para seguir. Em aulas presenciais normalmente levo um papel e coloco em cima da mesa, não tem nada de errado em levar um cola. Mas não escreva uma bíblia na cola pois você se “ferrar” da mesma forma, a cola é para você saber a ordem do que fazer e não para aprender as coisas ao vivo.

Abaixo a minha cola para o curso de 6h do Fisl:

Se for uma palestra de 50 minutos então não faça live-coding, prefira um vídeo. Você não vai querer atrasar o resto da sua palestra se demorar de mais em algum ponto do código.

Para gravar os vídeos eu uso o ScreenFlow e gravo com voz. Depois removo a voz e refaço o vídeo algumas vezes, dessa forma vou saber exatamente a ordem das coisas no vídeo.

Caso você não tenha como gravar um vídeo então treine o que será mostrado várias vezes. Não tem nada mais frustrante do que cometer um erro para um auditório que não te conhece.

Palestras são diferentes de aulas e a por padrão a platéia é totalmente cética com você e com o seu tema. Você precisa ser convincente, se passar um bug e não conseguir resolver (rápido), vai pairar aquele pensamento de “hehehe, se F*eu” ou “iiih, isso não é lá grandes coisas”.

Outra coisa que é muito importante em live-coding é o tema do seu editor, como eu já disse anteriormente. Use sempre fundo branco mas caso você tenha feito um vídeo e mesmo com fundo branco e fonte grande não tiver dado certo tente inverter as cores com Ctrl+Option+Command+8.

Síndrome da Faculdade

Em computação não tem nada mais comum do que pessoas tendo se mostrar inteligentes. Ninguém vai assistir uma palestra querendo saber como você é inteligente e “bomzão”. Ninguém quer saber se você sabe 20 linguagens ou sabe “zilhões” de termos técnicos. Você não tem que se mostrar inteligente para um professor.

Não digite “zilhões” de coisas rápido de mais, não faça scroll do código para cima e para baixo, não grite ou fale correndo de mais. Se vai digitar algo ao vivo explique cada coisa que está digitando e com bastante calma, a final de contas você sabe o que está fazendo mas as pessoas não.

As pessoas assistem uma palestra para aprender algo e não estão nem aí para o que você é. Então foque em ensinar alguma coisa.

Nessa última RubyConf a palestra do Norman Clarke me deixou de queixo caído como ele conseguiu explicar um tema complexo como encoding como se fosse um “Hello World”. Parecia que ele tinha conseguido abrir a minha cabeça e colocar as palavras no local correto. Uma aula de como priorizar os ensinamentos.

Você não precisa falar dezenas de termos técnicos difíceis para ser convincente. Assuma que as pessoas sabem muito pouco do que você está falando, assim os que já sabem algo vão entender e o que não sabem também.

O que é mais agradável e convincente?

• Nosso MP3 Player vem com 2gb de RAM e sincroniza com seu computador via USB
• “O mais legal do iPod é que sua playlist inteira cabe em seu bolso.” – Steve Jobs 2001

Treine Antes

Não importa o quanto você domine o tema, pratique antes. Várias vezes, eu normalmente ensaio uma palestra de 50 min umas três vezes. Essa é a única forma de saber quanto tempo você gasta com esses slides e como pode enxugar as coisas para ajustar o tempo, caso seja necessário.

Não me venha com o papo de que treinar não dá certo para você. Se Steve Jobs treina seus Keynotes exaustivamente e Michael Jackson ensaiava suas próprias músicas centenas de vezes não caia no erro de achar que você não precisa ensaiar.

Conclusão

Meu checklist:

• Não confie no projetor
• Não confie na iluminação
• Não confie em mic’s (as vezes vai ter que ser no gogó mesmo)
• Leve sua própria garrafa d’água (as vezes não tem)
• Centralize o conteúdo dos slides
• Use conteúdo bem contrastado do fundo
• Ajuste o perfil do projetor
• Use código com fundo branco e fonte grande
• Prefira vídeos ao invés de live-coding
• Em cursos faça muito live-coding mas tenha um rascunho
• Ensaie antes várias vezes
• Use “Presenter Display” do Keynote
• Explique as coisas com calma e fale devagar se forem coisas técnicas

Eu não sou nenhum expert e nem um Steve Jobs mas essas coisas tem me ajudado a fazer minhas palestras e aulas não serem um completo fiasco. Talvez possam te ajudar.

E da próxima vez não reclame da organização, esteja preparado para tudo dar errado. Se estiver tudo perfeito então melhor ainda.

No meu último Post tinha comentado sobre o framework que começamos a criar durante o curso #flexdp, agora vou falar sobre o seu objetivo, uma demostração e como colaborar com o framework ainda em sua versão alpha.

OBJETIVO

O Nome Cafx vem do merge Café com Flex(seu logo FX), e o objetivo do framework e tentar encontrar situações em que nós #soudev repetimos muito código e tentar diminuir esse processo de repetição desnecessário, ou seja, tudo que você imaginar assim: “poxa, toda aplicação que vou fazer em flex tenho que fazer esse processo outra vez?”. Talvez seja o caso de nos ajudar e adicionar essa lógica nesse framework. o Framework embora tenha sido feito durante um curso é opensource e não tem fins lucrativos(financeiramente, já que o objetivo é ser lucrativo no sentido de tempo). O objetivo mais importante desse framework é sobrar mais tempo para tomar café huahua sério, o framework vai fazer alguns processos chatos e eu vou poder apreciar meu café  com mais tempo

DEMOSTRAÇÂO

Durante o curso imaginamos em criar a primeira facilidade do framework, e pensamos em diminuir o trabalho na criação de Formulários para cruds simples. criamos então nosso CafxForm. Imagine essa entidade(alguns chamam de VO):

PLAIN TEXT

ACTIONSCRIPT:

1. [Bindable]
2.     public class Contato
3.     {         
4.        
5.         public var id:Number;
6.        
7.         public var nome:String;
8.        
9.         public var sobrenome:String;
10.        
11.         public var telefone:String;
12.        
13.         public var celular:String;
14.        
15.         public  var email:String;      
16.        
17.         public var dataNascimento:Date;  
18.        
19.     }

normalmente precisamos de um formulário onde incluimos e/ou alteramos os dados do mesmo, normalmente fica assim:

PLAIN TEXT

XML:

1. <mx:Form>
2.         <mx:FormItem label=“Cód.: “     enabled=“false”>
3.             <s:TextInput text=“{contato.id}”/>
4.         </mx:FormItem>
5.         <mx:FormItem label=“Nome: “>
6.             <s:TextInput text=“@{contato.nome}”/>
7.         </mx:FormItem>
8.         <mx:FormItem label=“Sobrenome: “>
9.             <s:TextInput text=“@{contato.sobrenome}”/>
10.         </mx:FormItem>
11.         <mx:FormItem label=“Telefone: “>
12.             <s:TextInput text=“@{contato.telefone}”/>
13.         </mx:FormItem>
14.         <mx:FormItem label=“Celular: “>
15.             <s:TextInput text=“@{contato.celular}”/>
16.         </mx:FormItem>
17.         <mx:FormItem label=“Email: “>
18.             <s:TextInput text=“@{contato.email}”/>
19.         </mx:FormItem>
20.         <mx:FormItem label=“Data Nasc.: “>
21.             <mx ateField selectedDate=“@{contato.dataNascimento}”/>
22.         </mx:FormItem>
23.         <mx:FormItem>
24.             <s:Button label=“Salvar”  click=“button1_clickHandler(event)”/>
25.         </mx:FormItem>
26.     </mx:Form>

e com o nosso framework precisamos dessa linha:

PLAIN TEXT

XML:

1. <components:CafxForm objectGenerator=“{contato}” formAction=“button1_clickHandler(event)”/>

Perceba que temos um objectGenerator, e é aí que usamos a mágica da reflexão e criamos o formulário.

Usamos algumas Metadatas na nossa entidade para tratar algumas coisas como um label mais agravável para nosso usuário:

PLAIN TEXT

ACTIONSCRIPT:

1. [Bindable]
2.     public class Contato
3.     {   
4.        
5.         [Field(label=“Cód.: “,enabled=false)]
6.         public var id:Number;
7.        
8.         [Field(label=“Nome: “)]
9.         public var nome:String;
10.        
11.         [Field(label=“Sobrenome: “)]
12.         public var sobrenome:String;
13.        
14.         [Field(label=“Telefone: “)]
15.         public var telefone:String;
16.        
17.         [Field(label=“Celular: “)]
18.         public var celular:String;
19.        
20.         [Field(label=“Email: “)]
21.         public  var email:String;      
22.        
23.         [Field(label=“Data Nasc.: “)]
24.         public var dataNascimento:Date;  
25.        
26.     }

Imagina uma entidade com uns 20 campos, estaria apenas com uma linha na declaração do form, bacana né!?

O QUE FALTA?

Como falei estamos começando agora e começamos por esse CafxForm, temos que melhorar e permitir novos componentes e de forma dinâmica, atualmente fizemos o teste com TextField, Combobox e DateField. Precisamos também implementar suporte a skins e validações usando possivelmente metadatas.

Agora é melhorar esse e imaginar outras situações em que é repetitivo no flex e encapsular nesse framework(sugestão é sempre bem vindo ).

o Código fonte se encontra aqui http://github.com/jandersonfc/CafxFramework e assim que estiver em uma versão beta comunico a vocês , quem quiser colaborar pode ficar à vontade para baixar o código no github e se divertir, qualquer dúvida é só entrar em contato, blz!?

Cumps.

Similar Posts:

• TUTORIAL JAVA + FLEX NA PRÁTICA 4/6
• TUTORIAL JAVA + FLEX NA PRÁTICA (9) – Atualizando o Swiz
• TUTORIAL JAVA + FLEX NA PRÁTICA (8) – Datas
• TUTORIAL JAVA + FLEX NA PRÁTICA 5/6
• TUTORIAL JAVA + FLEX NA PRÁTICA 1/6

Hey everyone!

[Para os ouvintes brasileiros/portugueses: a entrevista foi feita em inglês mas o vídeo também foi legendado em português! Aproveite!]

Following on our special series of interviews, Roberto interviewed Paul Betts, a Software Development Engineer in the Windows team and creator of ReactiveXaml. In a video special, he talked about Reactive programming and how to apply it to WPF and Silverlight through RxXaml. An awesome introduction to a new paradigm on WPF/SL development!

If you want to download the video, leave a comment in this post. If there’s enough demand, I’ll upload the video (1.6GB!) to a file share.

Here are the links we talked about in the interview:

Reactive Extensions for .net
http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx

ReactiveXaml
http://github.com/xpaulbettsx/ReactiveXaml

ReactiveXaml Google Group
http://groups.google.com/group/reactivexaml

Paul’s Twitter
http://twitter.com/xpaulbettsx

Paul’s Blog
http://blog.paulbetts.org

Also, don’t miss our previous interview with Arturo Toledo about design and Expression!

Subscribe to receive XAMLCast directly on your MP3 player, phone or RSS reader:

• RSS feed: http://www.xamlcast.net
• iTunes/iPod: pcast://www.xamlcast.net
• Zune/Windows Phone 7: zune://subscribe/?XAMLCast=http://www.xamlcast.net

You can follow XAMLCast on Twitter: @xamlcast

• Hashtag #xamlcast
• Follow the XAMLCasters:
  • @kelps
  • @robertos_br
  • @rodrigokono

Stay tuned for more!

Kelps, Roberto Sonnino and Rodrigo Kono

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

Twitter!

O Axure é um dos programas mais utilizados pelos profissionais de Arquitetura de Informação, pois ele permite de forma fácil e intuitiva a construção de wireframes navegáveis.

Um dos principais diferencias dessa ferramenta é a capacidade de construir componentes e torná-los navegáveis através de comando simples feitos com a ajuda de uma interface e sem a necessidade de conhecimento em programação.

Nesse screencast vamos abordar a interface do programa, confira o vídeo.

Twitter!

Agora que vimos como funciona a interface do Axure,  vamos juntos construir dois elementos muito utilizados quando construímos wireframes.

Hoje iremos construir e programar:
- Abas
- Enquete

Confira no vídeo como fazer esses elementos passo-a-passo:

Twitter!

Nesse primeiro screencast vamos falar sobre um programa para a construção de wireframes bem interessante, o Balsamiq.

Uma das principais características dele é a construção de interfaces com elementos que simulam o desenho feito a mão.

Essa característica, na minha opinião, é muito boa porque tira da mente do cliente / usuário que não teve contato anterior com documentações de wireframe a idéia que o produto apresentado é o visual (layout) da aplicação. Ou seja, o foco da discussão é direcionado exclusivamente para as questões de prioridade de informação, elementos de conteúdo e navegabilidade.

Confira abaixo o screencast e veja as possibilidades:

Twitter!

Continuando o podcast de ontem, falamos de assuntos muito interessantes:

. Performance de Apps Flex
. Tablets Android
. Flash 3D
. Flex para Mobile entre outros

Click to play

Clique aqui para fazer download P02E01

Veja o vídeo que fizemos do Galaxy Tab

Abrindo o produto da DClick Media Manager (futuro Holmes)!

Hoje foi um dia e tanto, começamos o dia com um boato de que ainda esse ano teríamos um sucessor para o finado Google Nexus One da HTC, que desta vez pelas mãos da Samsung…

 

Obs.: a imagem acima é uma montagem feita pelo pessoal do Gizmodo US, que representa uma aproximação de como é o visual do aparelho, segundo os relatos fornecidos por seu informante.

Começamos a tarde com um boato de que a Google + Samsung estavam preparando um golpe para ofuscar o primeiro dia de vendas do Windows Phone 7, agora dia 08/11/2010, lançando a segunda versão do telefone da Google, agora dessa vez pelas mãos da Samsung, onde o Google Nexus Two virá com a próxima versão do Android Gingerbread (Android 3.0), isto foi publicado nesse post do Gizmodo US, por volta das 14 hrs no horário do Brasil de hoje (28/10/2010).

Então, ainda nesse mesmo dia, agora de noite por volta de 20 hrs, saiu outro post do Gizmodo US, agora um Hands on WTF?! Que afirma que o que começou com um boato é real! E ao que tudo indica você não irá se desapontar com este novo aparelho.

Segundo o “informante” do Gizmodo US, visto de longe o aparelho até te faz pensar que seja o Samsung Galaxy S, mas com o aparelho em mãos é um tanto surpreendente este Nexus Two, pelo fato de ser um tanto diferente do Nexus One.

 

Vamos aguardar e ver o que irá aparecer de informação oficial deste aparelho, que até o momento já não é mais um boato, segundo último post do Gizmodo US. Enquanto isso ficamos com um misto de ansiedade e curiosidade hehe.

Veja também:

• [ Adobe AIR ] Package Assistant Pro
• Adobe AIR – Empacotador para iPhone OS + demos
• [Android Game] Angry Birds : acessando níveis travados
• [Adobe Flex] Definindo o foco na aplicação
• Marissa Mayer, a rainha do Google