Olá a todos!

Para os mais distraídos, há cerca de uma semana coloquei, do lado direito do blog, um logótipo do qual me orgulho muito. É o logótipo que é atribuído a todos os profissionais que possuem o título de Adobe Certified Expert.

Esta certificação deu-se, depois de ter completado, com sucesso, o exame da Pearson Vue sobre Flex 4.

Em termos de partilha de experiência, posso-vos dizer que o exame é difícil e que toca em bastantes pontos do desenvolvimento nesta plataforma.

As questões que nos são colocadas no exame vão desde o simples nome de uma propriedade de um componente, passando por casos de utilização ou não de certos tipos de design patterns, até a questões sobre BlazeDS, Adobe Live Cycle e consequentemente questões sobre model-driven development.

No meu caso, quando achei que estava na hora de obter a certificação, marquei logo o exame e dediquei cerca de dois meses a estudar a plataforma / framework e todos os seus pequenos detalhes. De forma a estar mais confortável no exame, comprei o software Attest 3 que tenta simular o ambiente de exame real e que se revelou essencial para o resultado final.

Esta foi, sem dúvida, a forma ideal de acabar 2010

Qualquer dúvida que tenham e esclarecimento que precisem sobre as certificações de Adobe Certified Expert, coloquem-nas aqui que tentarei responder o melhor que sei!

Bom 2011, Mauro.

Olá a todos!

No meu último post aqui no blog, falei das potencialidades do primeiro tablet da RIM (Blackberry) e a possibilidade de criar aplicações utilizando as ferramentas da Adobe.

Aqui fica um exemplo (há vários na web, no entanto, este parece-me, sem dúvida, dos mais fáceis de seguir) sobre como criar a vossa primeira aplicação para o PlayBook com o FLEX.

Posso-vos dizer que já comecei a trabalhar numa aplicação, e é bastante fácil e intuitivo. O emulador do sistema operativo responde bem, se bem que, no meu portátil (MacBookPro), por vezes, fica lento.

(O vídeo é do Michael Chaize, Adobe Flash Platform Evangelist). Podem aceder ao blog do Michael seguinte este link, ou seguindo-o no Twitter.

Se quiserem mais informação após verem o vídeo, podem seguir o post original aqui.

Novos desafios para minha carreira!

Salve pessoal

Os que me seguem pelo Twitter já sabem, mas aos que não sabem gostaria de informar que estou novamente no mercado de publicidade, mas especificamente na Alta Comunicazione.

Quem me conhece pessoalmente sabe que eu venho falando há muito tempo que o melhor formato de trabalho é o “Home Office” então porque aceitei essa mudança?

Eu acredito na evolução constante do homem, acredito que só fica estagnado quem tem preguiça ou medo do novo, a última agência que trabalhei foi a OWINTERACTIVE, lá eu tive varias experiências que me fizeram evoluir muito como profissional, meu primeiro projeto em AS3 foi o site da Virazom e nesse período aprendi bastante coisa, fiz novos amigos e evolui como profissional.

Passado esse período tive alguns problemas pessoais e decidi que me dedicaria exclusivamente aos “freelas”, foram 2 anos vivendo dessa maneira, nesses 2 anos ganhei muito e perdi muito porém o mais importante foi a experiência de ter que me virar em todas as áreas, gerenciar projetos e equipes e ter experiências de trabalhos internacionais.

Em 2010 eu trabalhei para uma empresa de Portugal com uma equipe de amigos “freelas”. Foi bem legal e difícil gerenciar toda essa quantidade de trabalho e relacionamentos, mas no final tudo aconteceu bem, ainda temos algumas coisas por resolver, mas o saldo da evolução é bom e me deixa satisfeito.

Novos desafios

Agora estou na Alta Comunicazione, novos desafios me esperam, na Alta Comunicazione minha função não é apenas de “Flash Coder” estou fazendo também a parte de direção de criação, atividade essa que desenvolvi também durante o ano de 2010.

A equipe é bem legal, destaque para a galera do 3D que vão com certeza me ajudar a ter um portfólio bem melhor durante o ano de 2011.

Desafios para 2011

Todo homem tem que ter metas as minhas para 2011 são

1. Evoluir mais como programador AS3
2. Lançar o meu curso de AS3
3. Conseguir finalmente colocar meu site no ar (em casa de ferreiro espeto é de pau)
4. Ganhar um FWA
5. Aprender 3D Max
6. Aprender Affter Effects
7. Voltar a escrever nesse blog
8. Ficar rico fazendo o que eu faço rsrs

Bom pessoal é isso, post meio “institucional” mas em breve volto a escrever coisas úteis!

Twitter!

.

Essa notícia é bem interessante, e no sentido real da palavra, de que nos interessa e muito, o Rafael Martinelli trouxe diretamente da MAX essa informação. Fiquei bastante impressionado com o MoleHill, motivo que me fez escrever esse post dando uma introdução sobre o assunto.

Estarei acompanhando com muito interesse o que estiver acontecendo nesse segmento e sempre que possível vou procurar trazer novidades sobre essa engine.

Mas afinal, o que é MoleHill?

“Molehill” é o nome de código para um novo conjunto de baixo nível, com APIs de aceleração GPU  3D  que permitirá avançadas experiências em 3D nas telas através do Adobe ® Flash ® Platform runtimes.

Existem diversas comunidades, frameworks para desenvolvedores poderem ampliar seus horizontes na criação de aplicações 3D, como Alternativa3D, Away3D, Flare3D, Sophie3D ou Yogurt3D.

Durante a AdobeMAX um vídeo muito interessante foi apresentado para os participantes, ele mostra um jogo em 3D com gráficos mais apurados, algo que não deixa nada a desejar a consoles físicos para games, e que, talvez não fosse nada fantástico o vídeo abaixo se o game não estivesse rodando em um FlashPlayer.

Impressionante ver o que a Adobe fez, e contrariando muitos que dizem que o flashplayer requer processamento da máquina, a Adobe fez um game com uma estrutura potente e que requer ZERO, isso mesmo, ZERO de processamento da CPU, utilizando somente a placa aceleradora.

Confira o vídeo antes de continuar o artigo.

.

De acordo com o anúncio feito pela Adobe, no primeiro semestre de 2011, (quando em versão pública beta) a versão do Flash Player irá suportar essas novas APIs, bem como também acontecerá uma atualização do Adobe Flex SDK. Para obter mais informações leia atentamente o Molehill faq:

http://labs.adobe.com/technologies/flash/molehill/#faq

Para a maior parte das suas dúvidas você com certeza encontrará as respostas aí nesse link, portanto vou me fixar a falar das possibilidades de algo assim.

Não será novidade pensar que milhares de desenvolvedores começarão a criar seus games, mas não é só de game que vive o homem, apesar de ser muito bom é claro. Essa engine nos dará possibilidades de experimentar de fato uma nova era da web em 3D. Lembramos que o shockwave não deu certo, não emplacou, mas pelo visto a Adobe aprendeu com o erro e fez uma engine de qualidade, a cada dia mais e mais computadores saem de fábrica com placa aceleradora 3D, ao ponto que isso está se tornando comum, se essa engine é a primeira fase, podemos esperar muito pelo que esta por vir.

Pense nas aplicações 3Ds que poderão ser desenvolvidas, pensem em um showroom virtual, hotsites etc, tudo aquilo que era feito antigamente com as piores gambiarras possíveis, hoje poderá ser realizado com qualidade.

Sou suspeito para tecer elogios a Adobe visto que sou um entusiasta, fiz minha carreira em cima de todos os seus sofwares, e claro, da Macromedia, que hoje é Adobe… portanto fico feliz em saber que ela nunca abandonou o Flash, e mais que isso, se empenhou em criar inclusive um conversor de SWF para HTML5, fazendo com que os desenvolvedores Flash (vulgo flasheiros) não percam seu mercado, afinal, se Flash fará HTML5, certo é dizer que HTML5 nunca fará um SWF e nem chegará perto da qualidade, visto que essa tecnologia com todo respeito ainda está engatinhando.

Mas o assunto é MoleHill, vamos  continuar falando de quem vai se dar bem nessa história toda na minha opinião.

.

.

Evidente, ela já se deu bem, e depois e todo o alvoroço e discussão sobre o Flash rodar ou não no Iphone fica aí um susto que a Adobe está dando a Apple, ou não, pois talvez a mesma já previa tal situação e portanto procurou evitar os games em Flash para poder alavancar a AppStore, sem entrar muito no tema, nem são os games 3Ds os mais vendidos na mesma (portanto nem sei porque da preocupação do Steve, talvez parcerias , enfim) mas…  certamente essa é uma tecnologia fantástica que faz a Adobe novamente ficar a frente dos demais, como sempre esteve. Afinal, uma plataforma para desenvolvimento de games mais sérios, com suporte a joysticks, volantes etc, (nada pronunciado a respeito mas isso vemos nos vídeos, o volante do XBox sendo utilizado), combinado com um Flash Media Server, um ambiente de multiusuário, online,  pode ser realmente devastador (no bom sentido) para o mercado como um todo.

Então não poderíamos deixar de falar quem é que mais ganha com isso.

.

Android

.

O Android tem sido um parceiro do Flash simplesmente porque a Apple não quis ser no seu iOS, e a Adobe já se pronunciou a respeito dizendo que haverá acesso as APis 3D também para as plataformas móveis…  fantástico, não só para games, mas como falei, para outros recursos de aplicativos.

A web sempre procurou introduzir o 3D, é uma tendência natural, também sou suspeito para falar do assunto pois sempre apostei no 3D e sou um 3Ddesigner também e obviamente amo o assunto e sempre acreditei que a experiência 3D é muito poderosa, pois ela trata quase todas as sensações visuais que o cérebro pode comportar, dando é claro maior realismo ainda que não haja muitos detalhes gráficos.

Posso dizer que consigo passar horas desenvolvendo algo em 3D sem me cansar, pois me sinto imerso no ambiente, mas não é a mesma coisa para desenvolver algo em 2D.

Enfim, o Android de fato vai se dar bem nessa história, vai abocanhar todo um mercado de 3D para mobile, com milhares de desenvolvedores famintos para migrar diversas aplicações e games prontos para essa engine, para rodar em Flash.

.

Portanto quem também ganha com isso?

Os diversos frameworks que já citei.

.

Dentre eles eu aposto mais no AlternativaPlatform, me pareceu mais robusto, mais acabado inclusive, a maioria dos vídeos que trago aqui são desse framework, no mais, outras como Frare3D e Away3D também me parecem boas, mas como ainda não botei a mão em nenhuma delas fica suspeito comentar, em um futuro próximo farei alguns testes (como designer) e darei a minha visão. Mesmo assim, tanto designer como desenvolvedor terá uma gama de possibilidades bastando ver as suas necessidades, e ter várias opções nesse caso é muito bom.

Vou dar um foco maior a AlternativaPlatform, portanto veja o anúncio feito no blog da própria empresa sobre a Adobe Max.

http://blog.alternativaplatform.com/en/2010/10/16/alternativa-3d-is-free-see-you-at-adobe-max

Confira a qualidade do site:
http://alternativaplatform.com/en/

Uma breve introdução visual:

.

Vamos agora a imersão, vamos aos vídeos:

.

Confira outro vídeo, agora de uma visão externa mostrando o “jogador” do MaxRacer :

.

.

Outro vídeo da Alternativa3D:

.

.

Agora da Frima Studio (http://www.frimastudio.com/), que utilizou a engine usada para PSP do jogo Zombie Tycoon (http://www.zombietycoon.com/EN/index.htm) migrando para Molehill (sim fantático, não o jogo mas a possibilidade) :

.

.

Away3D :

.

.

Vamos a uns vídeos mais instrutivos:

O primeiro é a sessão de Sebastian (engenheiro-chefe na Molehill):

.

.

O segundo vídeo é da equipe Flare3D, apresentando o Molehill e suas vantagens:

.

.

Away3D e Alternativa3D teams (equipes), ainda sobre seus respectivos frameworks e vantagens:

.

.

E então a Pixel Bender 3D:

.

.

Bom galera, espero que esse post tenha sido uma boa introdução para conhecer o assunto, fiz uma pesquisa vasta para trazer as melhores informações sobre o tema e espero que tenham gostado.
Assim que tiver novas informações interessantes estarei postando, até lá se você também tiver algo a acrescentar não deixe de comentar aqui nesse post.

E que venha o mundo 3D na web.

_________________________________________

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!

Tudo o que você sempre quis saber para começar a criar sua skin.

Esse post é para você designer, que atualmente está sonhando em criar uma skin para app de Iphone ou Ipad e simplesmente não sabe como fazê-lo, ou porque não sabe inglês, ou porque não encontrou material a respeito.

Lá fora (na gringa) há muito material a respeito, mas infelizmente nem todos são objetivos e respondem as perguntas mais básicas.

Vamos supor que você já sabe alguma coisa sobre Iphone, afinal deve possuir um, sabe como desenhar uma skin, afinal entende de Fireworks, Photoshop, Ilustrator ou outro software gráfico (sem ser Adobe não recomendo…).

Então você chegou nas seguintes dúvidas:

Qual o tamanho da tela? Iphone 3G ou 4G tela de retina? Qual o procedimento certo para criar o design, já para Iphone 4 ou para 3? Entre outras muito comuns.
Em pesquisa para criar interfaces para esses gadgets aqui na DClick me deparei com essas questões, e como já as solucionei estou aqui para contribuir com esse material muito valioso.
Esse é o primeiro de muitos posts do mesmo tema. Em breve estarei ensinando também aos novatos na área de Design de Interface como criar uma bela skin para esses portáteis, e vou indicar material sobre o assunto.

Bem, chega de blá blá blá e vamos ao post.

Tamanho padronizado da tela e dos ícones

.

É possível que você já tenha lido a documentação da Apple sobre Iphone e Ipad Guidelines, são os padrões para a criação das skins. Caso não tenho lido aconselho a faze-lo, é o primeiro passo para entender como funciona esse mundo, no entanto, o conteúdo está em inglês,  se tiver dificuldades peça ajuda ao concorrente da Apple e utilize nosso amigo Google Translator, não será a melhor tradução do mundo mas com esforço você chega lá.

Iphone Guidelines

Ipad Guidelines

É possível ler este artigo sem ter o conhecimento acima?  Sim é, mas será melhor com a leitura dos padrões da Apple.

Quando comprei meu Iphone 4 no dia do seu lançamento (não peguei fila acredite) eu fiquei surpreso com a resolução da sua tela, mas logo veio algo a mente… como isso afetaria os aplicativos,  e não demorou até eu ver aplicativos com a resolução perfeita, e aplicativos com os famosos pixelados, sim, com um visual podre, literalmente falando. São os aplicativos que foram criados para a resolução 320 x 480px, todos os modelos anteriores a quarta geração de Iphone.  Claro que não eram totalmente ruins, porém muito da qualidade se perdia, e logo não demorou para  que a maioria deles fossem atualizados para a nova resolução de 640 x 960px.

Essa é a vantagem de quem desenvolveu em vetor, bastaram redimensionar suas skins para o novo tamanho e aplicá-las na app e então enviar o pedido de atualização ao usuário.

Quando você exporta os arquivos para Iphone ou Ipad geralmente é PNG. O Xcode (leia tópico a respeito), não considera o valor PPI (não confunda com DPI) quando você salva a imagem, portanto, para matar a charada siga as configurações abaixo:

Agora, um comentário importante sobre isso,  qual software utilizar? Eu particularmente gosto do Fireworks para a criação de Interfaces, esse software é fantástico e prático, mas se realmente quer ter facilidade com skins para Iphone e Ipad volte ao Photoshop, caso não seja usuário do mesmo, crie suas skins bases no Fireworks e salve com PSD, e depois aplique os efeitos e detalhes no Photoshop, ele é realmente uma máquina de guerra para esse assunto.
Nos futuros posts estarei falando melhor disso.

Supondo portanto que estamos falando do Photoshop, vejamos então algumas padronizações de configurações:

.

.

E quanto ao Itunes Store segue:
Ícone: 512 x 512 px (tif, jpg ou png, 72 dpi, RGB…)
Imagens iPhone: 320 x 480 px ou 640 x 860 px (tif, jpg ou png, 72 dpi, RGB…)
Imagens IPAD: 1024 x 768 px (tif, jpg ou png, 72 dpi, RGB…)

Agora a grande questão, criar uma Interface pensando na resolução do 3G (terceira geração) ou 4G (quarta geração)?

Apesar da sua resposta parecer óbvia, e ela até é, você certamente disse a si mesmo “criar skin para a quarta geração, evidente… não precisa ser guru para saber isso.” Ela não é a resposta correta acredite.

Antes de mais nada a pergunta, você já possui um Iphone4? Se sua resposta é não, relaxe, mas será necessário você entender através desse link as nossas preocupações:

Comparações entre tela 3G e 4G (Retina)

Como pode ver, as resoluções são drasticamente diferentes, o Iphone 4 tem uma resolução superior ao olho humano (segundo a própria Apple) e de fato é uma resolução impecável, a tela de retina .Utilize o mouse e percorra a rosa mostrada no Iphone nesse link que te apresentei…

Assim você vai pensar, “Então como não fazer para a melhor resolução?”

Simples, muito simples, porque quando você cria interfaces com resoluções maiores você tende a ser mais detalhista, e interfaces detalhadas quando forem redimensionadas a tamanhos menores vão dar problema, não será uma boa interface, não ficará com um belo padrão de visualização. Os pixels podem se confundir, criando até mesmo embaçamentos.

Portanto a melhor técnica é criar, obviamente tudo em vetor, na resolução de 320 x 480px, ver se está tudo harmonico, e então só depois redimensionar para o dobro, 640 x 960px. Confie, ficará muito melhor que desenhar diretamente para 640 x 960px, já tive algumas experiências ruins criando diretamente nessa resolução. Deixe para aplicar texturas caso queira faze-lo na resolução de 640, já as bases tem que ser vetorial.

E claro, agora sim não precisa ser guru para saber que se fizer em 320 x 480px sem ser vetor e redimensionar (que é o acontece com as aplicações sem suas interfaces atualizadas) ficará pixelado e granulado, tal com vemos nos exemplos abaixo.
.

.

Padrão de imagem na exportação

.

Como bom brasileiro sei que para tudo há um jeitinho, mas no caso de interfaces para iOS o jeitinho pode ser uma não aprovação na Apple Store, ou mesmo uma interface ruim.

Portanto não custa nada enfatizar, o padrão que você deve usar na exportação das imagens dos seus elementos é o PNG, na teoria o iOS pode exibir outros formatos, mas… na prática não ficará bom, o motivo é que o PNG é otimizado automaticamente no pelo SDK do iOS. Assim sendo, como estamos nosso software gráfico utilizado é o Photoshop vamos exportar em PNG 24 e com transparência.

.

Padrão de botões

.

Você já se deparou com aplicações cujos botões eram pequenos demais? Aquelas aplicações que para poder inserir um determinado evento o designer implementou um botão pequenininho que coubesse na interface a fim de executar a função desejada mas… que por vezes não era sensível ao toque?

Pois bem, seja bem vindo ao maravilhoso mundo daqueles que acreditam que pesquisa não serve para nada, a Apple padronizou os botões em 44 x 44px, apesar do rigor que a mesma tem na aprovação dos aplicativos muitos dos mesmos passam com botões inferiores a isso, e espero que você não seja um destes, afinal, você estará estragando toda a UX (leia artigo) da sua aplicação caso se meta a achar que um botão menor é melhor para o seu usuário, sendo que a Apple fez inúmeras pesquisas para definir o melhor tamanho, sendo esse, 44 x 44px o tamanho MÍNIMO recomendado.

.

O Mistério, como preparar os arquivos para o seu desenvolvedor

.

Sim, sua obrigação, e talvez a leitura desse texto inteiro seja por conta dessa preciosa informação, afinal você pensa “Fazer interface eu sei, design eu sei, conceito eu sei, mas como afinal eu devo exportar tudo isso para o desenvolvedor?”.

Eis a fórmula mágica, volte a ler os Padrões de imagem para a exportação. Sim isso mesmo, você apenas tem que fatiar os arquivos e enviá-los de forma organizada ao seu desenvolvedor, ele tratará de incluir isso através do XCode, caso você tenha interesse em agilizar esse processo e trabalhar em parceria com seu desenvolvedor de forma mais dinâmica, então terá que estudar o XCode, um bom primeiro passo para isso é o post que indiquei no começo do artigo do nosso colaborador Artur Fabri (@arturfabri), que explica como implementar uma skin em uma tabbar, incluindo formas de testar nas versões 3G, 4G e Ipad, é imperdível o Screencast dele, se você assim como eu é um pouco mais que um designer e gosta de fuçar em como as aplicações se comportam vai gostar muito da explicação dele.

Espero com esse artigo ter elucidado os primeiros passos para que você venha a criar interfaces para Iphone, Ipad , futuramente estarei falando aqui no Blog de Android também, bem como compartilhando métodos de criação de skins e as próprias skins (Guidelines) para download.

Espero que tenham gostado do artigo.

_________________________________________

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!

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

“A maré passou mas ainda há tempo para um cafezinho.”

Venha participar do primeiro Café Ágil em Belo Horizonte!

1. Programação

Cafe da manha: 8:30am – 9am
Palestra 1: 9am – 10am
Palestra 2: 10am – 11am
Palestra 3: 11am – 12pm
Coding Dojo : 12pm – 1pm

2. Palestras

Leia mais no post original aqui

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 curso de pós graduação em Engenharia de Software Centrada em Métodos Ágeis ganhou um novo blog. Um espaço aberto, transparente, onde todos poderão expressar sua opinião, elogios e criticas. Vamos aproveitar para reunir material do curso, apresentações de trabalhos, fotos, eventos, etc. Compartilharemos práticas, conhecimentos e assuntos pertinentes ao curso, com foco na transparência e sobretudo na agilidade.

Panorama Geral do Curso:

Teremos bastante desenvolvimento no curso. Trabalharemos com Java, Ruby on Rail e Adobe Flex. O objetivo é que, no final, o aluno saia apto a integrar, liderar e implantar processos ágeis em equipes de desenvolvimento de softwares. Nas disciplinas de programação tentaremos introduzir Coding Dojo. Uma forma de interação muito maior, guiado por TDD. Um Coding Dojo é um encontro onde um grupo de programadores se reúne para trabalhar em conjunto em um desafio de programação. Eles estão lá para se divertir, e, através de uma metodologia pragmática, melhorar suas habilidades de programação e de trabalho em grupo. Nesse primeiro semestre tentaremos introduzir o Dojo nas disciplinas de Programação Orientada a Objetos e Padrões de Projeto.

O coding dojo surgiu da motivação que os programadores não treinam. Tipicamente eles estão preocupados apenas em resolver problemas de produção em projetos reais. O objetivo de coding dojo é criar um ambiente de treinamento, um ambiente de contínuo aprendizado e compartilhamento de experiências, independente do nível de habilidade dos participantes com o intuito de aplicar o aprendizado obtido nas reuniões para aplicar em situações reais de desenvolvimento.
A primeira disciplina “Métodos ágeis de desenvolvimento de software”, gosto de dizer que é uma disciplina de evangelização. Nela o aluno irá compreender os princípios e valores de equipes ágeis que pregam: auto-gerenciamento, multidiciplinaridade, TDD, programação em par, software funcionando, interação entre indivíduos, colaboração com cliente, resposta rápida a mudanças etc. Ou seja, essa será uma disciplinas para “quebrar” conceitos.

No decorrer do curo, o aluno irá ter contato com várias outras disciplinas que entrarão com mais cuidado em itens abordados na referida “evangelização”.
A última disciplina: “Laboratório de Engenharia de Software Ágil”, na verdade não será a última, ela ocorrerá em paralelo durante todo o segundo semestre do curso. Será nessa disciplina que o aluno terá a oportunidade de montar uma equipes agil, gerenciada com Scrum, aplicando técnicas de XP para construir um software (do início ao fim) utilizando as técnicas, processos e ferramentas estudadas durante o curso. No final, o aluno terá tido a sua primeira experiência em construir um software do zero seguindo metodologias ágeis.

Veja grade completa do curso aqui ou a grade oficial no site da UNA