Twitter!

Chegamos a fase final, organizamos o layerComps e exportamos as imagens para apresentação, agora, em uma nova aula, totalmente separada, será a parte de componentização e preparação do arquivo PSD para o Catalyst, sei que muitos aguardam ansiosos por isso… Mas continuem acessando o Blog da DClick e me seguindo no Twitter @eduardohorvath para saber quando lançarei as mesmas.

.

AULA 23

.
Aula que ensina como organizar seus layers através do layerComps, juntamente com detalhes importantes da ferramenta.
.

.

AULA 24

.
Finalização a organização com layerComps e explicação de como exportar as imagens por demanda.
.

.

AULA 25

.
Criação de um player e interferindo no LayerComps.
.

.

_________________________________________

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 há mais de 15 anos.
@eduardohorvath
.

Twitter!

Aqui estão algumas dicas que podem ser úteis quando você? for desenvolver ícones ou outros detalhes de design para sua aplicação. As dicas supõem que você está usando o Adobe Photoshop ou programa similar de vetor ou tratamento de imagem.

Use convenções de nomenclatura comum para os ícones.

Tente nome de arquivos de modo que os assets (vamos entender assets como qualquer imagem que compõe a skin da sua app) fiquem dentro de um diretório todos ordem alfabética. Em particular, ajuda muito usar um prefixo comum para cada tipo de ícone.

Por exemplo (Vou deixar os nomes em inglês dos tipos de ícones para não causar muita confusão para? a Guideline:

Lembre–se que você não é obrigado a usar um prefixo, isso é apenas para auxiliar a organização.

Crie uma área de trabalho para organizar os arquivos de múltiplas resoluções.

Dê suporte a várias densidades (resoluções)

Apoiar várias densidades tela significa que você deve criar várias versões domesmo ícone.

Ou seja, dar suporte a vários tipos de devices significa que você precisa ter várias cópias para várias resoluções

E para isso, nossa sugestão é que você crie diretórios específicos para cada tipo de resolução, de forma a organizar o seu trabalho.

Tal como no exemplo abaixo que não está traduzido a fim de não confundir demais a explicação:

Você também pode ter arquivos com o mesmo nome, porém em diretórios distintos com resoluções diferentes. Ou seja, é o mesmo arquivo, o mesmo ícone por exemplo, porém com resoluções diferentes, que dependendo da situação é requisitado de um diretório específico.

Veja exemplo abaixo:

USE VETOR

Sempre que possível recomendamos que você utilize softwares como Photoshop, mas que crie seus ícones e assets em vetor, a fim de poder redimensionar sempre que necessário para outros tamanhos, otimizando o seu projeto.

COMECE PELO MAIOR TAMANHO

Sempre que você tiver que criar uma iconografia ou um asset, verifique qual é a maior resolução desse elemento, de acordo com a Tabela 1, então comece criando pelo maior tamanho, com isso, basta exportar um único PNG com este tamanho e então redimesioná-los para os demais gerando novos PNGs, em vez de ficar aumentando o seu Vetor.

BITMAP

Cuidado, se você gerou ícones ou outro elemento em bitmap em resoluções como Mdpi (resolução média), e quer aumentar para Hdpi (resolução Alta), então não poderá fazê-lo apenas redimensionando, terá que redesenhar esse elemento, por isso ficar atento a dica sobre o tamanho dos elementos.

METADADOS

Imagens PNG carregam muito mais informações do que você imagina, se você for salvar a imagem unicamente como PNG sem fazer isso visando uma interface mobile, provavelmente estará salvando essa imagem com metadados, aumentando assim o seu tamanho, são informações importantes para que a imagem seja encontrada em buscadores por exemplo, mas não para ser usada em uma interface de sistema. Portanto ao salvar um PNG salve através do Photoshop em Save for Web & Devices. E habilite para PNG24.

Twitter!

Generics em Java = Type Parameters em Scala

A motivação para o uso de generics em Java é bem conhecida, e Scala resolve o mesmo problema, dando um nome diferente para a solução: Type Parameters. Podemos chamar também de Generic Types, o significado é o mesmo.

Criando uma lista de tipo específico

Vamos implementar uma lista ligada para valores String. Tente fazer você mesmo, implementando um classe para ser a célula da lista, e uma para ser a lista em si. A lista deve também conter métodos para adicionar, remover e buscar um elemento específico dado o índice.

Em um paradigma mais funcional por assim dizer, você pode acabar em uma implementação para a célula, parecida com a minha:

Implementação diferente do usual, né?
Repare que criei dois tipos de célula: uma célula que está sempre vazia, e uma célula que contém de fato o valor a ser guardado. Fiz isso pois em Scala não existe (ou a idéia é não utilizar) null, assim a checagem é feita por células vazias e não por null. Como Scala utiliza código Java, é possível passar e receber valores nulos. Código puramente em Scala estão praticamente livres de NullPointerException, justamente por essa restrição com valores nulos. Vamos ver logo mais um caso em que é possível obter tal erro.
Em Scala uma das alternativas para execução de funções que devolvem null como resultado para certas circunstâncias, é o Option. Option, como o próprio nome sugere, se trata de um opção por devolver, ou não um valor. No caso de se devolver algum valor, deve-se devolver um Some contendo o valor. No caso de não se devolver o valor, deve-se devolver um None. Ambos são Case Classes, portanto não necessitam da palavra new, e possuem todas a propriedades que vimos em um post anterior.

Pensando em todas essas características da linguagem, cheguei nesta implementação para a lista, e usei uma abordagem recursiva. Vou mostrar o resultado:

Outra implementação não muito convencional… mas mesmo assim não deixa de ser clara. Mesmo não send o foco do post, vou dar uma breve explicação: na lista guardo o último elemento, assim sei onde devo adicionar o novo elemento; na função add verifico se o início da lista está vazio para adicionar, ou se devo adicionar no final; na função remove se a célula passada estiver vazia devolvo uma nova célula vazia, se o índice atual for zero, ou seja, queremos remover o atual, devolvo o próximo, e como caso padrão seto o próximo item como sendo o resto da lista com o item correto removido (Repare que não funciona para remover o primeiro item, mas não é esse o intuito mesmo :p); na função get verificao se a célula está vazia, logo não devolvo nada, e itero no resto dos itens de maneira recursiva no caso padrão.

Para termos certeza que nossa lista está funcionando corretamente, criei o seguinte teste unitário usando JUnit4, que para utilizá-lo é muito fácil, como foi visto no post anterior.

Rode o teste para ter certeza de que está tudo rodando.

Generalizando nossa Lista

Agora imagine que queremos fazer uma lista de inteiros ao invés de Strings. O problema é o mesmo que temos em Java. Se generalizarmos nossa lista para guardar AnyRef do Scala ao invés de Strings (em Java faríamos o mesmo com Object), teremos o problema de ter que fazer cast do resultado em toda chamada para nossa lista. Para isso que existem os Generic Types.

Se você reparou como utilizamos Option, tivemos que passar um tipo de parâmetro para ele, que no nosso caso foi String, dessa forma quem utiliza o resultado do método, sabe que está lidando com Strings e portanto não precisa fazer o cast do resultado. Vamos implementar a mesma funcionalidade em nossa lista. Para isso temos que modificar nossas células e nossa lista, de maneira que recebam o tipo como parâmetro. Segue o código da lista modificada:

Note que a implementação é praticamente a mesma, a única coisa diferente é o tipo do valor passado para guardar na lista. Repare que para quem usa a lista, basta adicionar um tipo no momento de criação da mesma, por isso em nosso teste mude apenas a linha que instancia uma nova lista, e rode o teste.

Crie um outro teste com um tipo de valor diferente e veja que funciona da mesma maneira que no Java.

Restrições de Tipos Genéricos

Nosso tipo T pode ser qualquer coisa. Existe em Scala uma sintaxe própria inclusive para inicializar uma varável de um tipo genérico, basta utilizar um ‘_‘. Dessa forma você está explicitando que sua variável pode ou não ter um valor do tipo genérico, afinal não tem como saber se o tipo será um primitivo ou não. Este é o caso em que estamos sujeito ao NullPointerException que citei no começo do post: para definir uma variável em Scala é necessário iniciá-la, e no caso de tipos genéricos, como não possível iniciá-los, as variáveis possuem valor nulo (‘_‘), logo geram código que pode lançar NullPointerException.

Com nosso tipo genérico podendo ser qualquer coisa, não conseguiríamos, por exemplo, ordenar nossa lista, afinal nem tudo é ordenável. A solução em Java é a mesma, mas a sintaxe em Scala me parece bem mais amigável. O que é necessário fazer, é dizer que o seu tipo obrigatoriamente extende de alguma classe determinada. No caso de querermos uma lista ordenada, basta obrigarmos o tipo passado extender de Comparable (no Java), ou Ordered (em Scala). Ordered extende Comparable, sobrescrevendo os operadores de comparação básico (>, <, >=, <=) e utilizando o método de comparação disponível em Comparable (compareTo).

Vamos mudar o parâmetro de nossa lista para obter tal comportamento. Para isto, basta mudar a assinatura da classe com seguinte código:

Estou usando Comparable, pois não teremos erros de compilação usando String como parâmetro. Porém em Scala é possível dizer que um parâmetro poder ser convertido para o tipo definido na restrição. Esse tipo de restrição é chamado de View Bound e Scala já implementa a conversão implícita para os tipos primitivos e String, portanto se mudarmos nossa classe para:

nosso código ainda compila, e nossos testes funcionam, o que é o mais importante .

Invariância e Covariância

Pensando em termos de orientação a objetos, se definirmos um lista TypeList[String], esta lista deve ser subtipo de TypeList[AnyRef]? Parece uma pergunta simples de se responder, mas as respostas tem suas implicações. Se a resposta é não, então estamos dizendo que quando criarmos uma lista de Strings, só faremos referência a essa lista sabendo que é do tipo String, e que portanto só adicionamos valores String na lista. Se a resposta é não, então estamos dizendo que ao criarmos um lista de Strings, podemos referenciá-la como uma lista de AnyRef e portanto conseguimos adicionar qualquer valor em nossa lista. O primeiro caso é dito invariante, e o segundo caso é dito Covariante.

Em Scala os tipos são por padrão sempre invariantes. Diferente do Java que é covariante.

Quando os tipos são covariantes, temos o problema de lidar com tipos diferentes dos esperados. Java resolve esse problema fazendo a verificação em tempo de execução, no momento da atribuição de um tipo. Em Scala o problema é resolvido de maneira estática impedindo o código de compilar. Ainda assim é possível estabelecer tipo covariantes em Scala. Para nossa lista, basta mudar a assinatura, com o operador +:

Fazendo isso, seremos obrigados a mudar em todas as classes que usem T, por exemplo, nossas células.

Mas com isso surge um problema: como que o compilador irá saber tratar o tipo T de maneira que este possa ser de algum supertipo do mesmo? Para isso podemos definir nosso tipo T, como um limitante inferior. Basta usarmos a sintaxe simétrica a de restrições de limitantes superiores:

Assim estamos dizendo que A é supertipo de T, e portanto podemos usá-lo em nossas funções sem que o compilador reclame.

Também podemos definir um range para nossas restrições combinando os operadores, por exemplo:

Objects

Scala não permite que usemos parâmetros em objects, por isso mesmo nossa célula vazia teve que definir um tipo para o parâmetro.

Para definirmos um object como super classe de uma classe que necessite de parâmetros, precisamos que a classe pai seja cocariante, e em nosso object, basta extendermos tal classe com o tipo Nothing. O tipo Nothing é subclasse de todos os tipos em Scala, portanto é o menor limitante inferior. Com isso conseguimos definir um object que extende uma classe que precisa de parâmetros.

Antes de falarmos de listas em Scala, ainda falta falarmos de tuplas e Functions. Veremos isso em um screencast que será divulgado em breve.

Espero que a série tenha andado bem até aqui, e que as informações que estou publicando sejam úteis a muitas pessoas. Lembrando que todos os tipos de comentários são bem vindos: críticas, dúvidas e sugestôes.

Por @Gust4v0_H4xx0r

Twitter!

Vimos que Scala na verdade é uma linguagem puramente orientada a objetos, com conceitos de classe, instância, heirarquia e polimorfismo como Java por exemplo. Mas Scala traz também alguns conceitos próprios muito interessantes, que é o caso de Case Classes.

Case Classes são um caso de classes com regras pré-definidas em tempo de compilação, de maneira que se permita executar algumas outras operações sobre tais classes facilitando algumas modelagens, e ajudando na aplicação de algumas boas práticas. Vamos estudar mais a fundo o conceito de Case Classes nesse post. Usei como referência o Scala By Example do Martin Odresky, o qual citei em posts anteriores.

Para acompanhar o post, é muito recomendado alguma IDE de desenvolvimento de scala. Estou usando o scala-ide plugin para o Eclipse, que pode ser encontrado em http://www.scala-ide.org/.

Motivação para Case Classes

Eu gostei bastante do exemplo disponível no livro, por isso vou seguir a mesma idéia nesse post só que com as minhas palavras do que eu consegui aprender sobre assunto pesquisando um pouco mais na internet, e citando também as dificuldades que enfrentei.

Imagine que queremos modelar um interpretador de expressões matemáticas que são descritas em objetos do nosso domínio. Por exemplo, queremos interpretar o resultado de 1 + (3 + 7), e representando em nosso modelo, queremos obter algo como:

Uma maneira orientada a objetos de se implemetar tal domínio poderia ser algo como:

A implementação é bastante limpa e nosso interpretador seria mais simples ainda:

Se você assistiu o screencast sobre integração com Java, e JUnit rodando testes de Scala, você pode fazer um teste para verificar que nosso interpretador está funcionando corretamente:

Para essa modelagem, quando quisermos adicionar uma nova operação que pode ser interpretada, basta criar uma nova classe que extends Expr e pronto! Nada mais precisa ser alterado em nosso código, e nosso interpretador continuará funcionando.
Agora imagine que antes de executar a expressão, queremos imprimir no console de um jeito amigável a expressão matemática que está sendo executada. Nesse caso, de acordo com nossa modelagem, teríamos que definir em nosso Expr uma função print, para que todas as suas implementações definam o comportamento de tal função. Para isso temos que alterar o código em todas as classes que já existem, o que pode ser ruim dependendo do nosso sistema.

Aplicando Case Classes

Em Scala existe a definição de Case Class. Para criar uma Case Class basta adicionar o modificador case antes da definição da classe. Em nosso exemplo faça as seguintes mudanças:

Case classes seguem as seguintes regras:

1 – Possuem um construtor definido exatamente com o mesmo nome definido na classe. Em nosso exemplo:

Dessa forma é possível escrever nossa expressão 1 + (3 + 7) da seguinte forma:

Substitua no teste para ter certeza do funcionamento.

2 – Os métodos toString, equals e hashCode já estão implementados seguindo a definição da classe com seus atributos. Para nosso exemplo com Number, esses métodos já levam em consideração o atributo n, deixando de comparar os objetos por endereço de memória. Os operadores == e != também já estão definidos em função do equals.

3 – Todos os atributos passados no construtor possuem os métodos de acesso público já definidos. Em nosso exemplo, Number e Sum já possuem os seguintes métodos:

Fato importante é que tais classes se tornam imutáveis, ou seja, não existe um método para alterar o valor dos atributos, e nem é possível definí-los.

4 – Case Classes podem ser usadas para pattern matching, que é uma operação disponível em Scala e que veremos agora.

Match, não Switch

Vimos que a classe base do Scala é o Any, e que todos objetos podem ser tratados como tal. Any define uma função que permite verificar o tipo de classe que está sendo tratado e tomar a atitude correspondente. Vamos ao exemplo que explica melhor o comportamento. Em nosso object Inter, mude a função inter para o seguinte:

Rode nosso teste novamente e verifique que está tudo correto.
Para entender o que está acontecendo: estamos dizendo que um dos casos esperados é o caso em que e é do tipo Number, que recebe um parâmetro que chamamos de n. Note que não precisamos definir o tipo de n, pois o compilador consegue inferir baseado na definição do construtor de Number. Feito isso, n está disponível no contexto do case atual. Para nosso caso com Number, precisamos apenas devolver o valor de n.
No segundo caso, estamos esperando uma Expr do tipo Sum, que recebe dois parâmetros e que baseado no construtor definido na classe, sabemos que é do tipo Expr. Nesse caso devolvemos o inter de a somado ao inter de b.
Simples não?

Nessa nossa nova modelagem fica fácil adicionar uma nova funcionalidade ao comportamento das expressões, como por exemplo imprimir de maneira legível. Basta adicionar mais um método ao nosso interpretador. Claro que agora temos o problema adicionar um novo caso quando criarmos uma nova operação, mas a quantidade de código a ser implementada é consideravelmente menor.

Match é definida como uma função como qualquer outra em Scala, portanto pode ser atribuída a variáveis, ser devolvida como resultado e ser passada como parâmetro para outras funções. Pode-se também criar um bloco como o seguinte:

e usá-lo como uma função anônima. Dessa forma será criado uma função match para tratar com seus casos definidos no bloco.

Exceptions

Veremos Exceptions mais para frente, mas perceba como funciona o bloco try/catch em Scala, e veja se há alguma semelhança com o que acamos de ver:

Pois bem, catch possui o mesmo comportamento de match para execeções.

Exercício

Vou me basear no exercício disponível no livro do Martin.

Considere que queremos implementar uma árvore binária ordenada de inteiros. E tome a seguinte implementação como base:

Agora complete a seguinte implementação dentro de IntTree:

Lembre-se que Node é imutável, e que é obrigatório usar Case Classes. Boa sorte !

A reposta está no screencast a seguir, junto com a explicação:

Vídeo em alta resolução.

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

Introdução
Neste tutorial será mostrado como gravar um arquivo com extensão em *.txt  dentro do servidor usando o Silverlight usando a linguagem C# e o Visual Studio 2010. Como ponto de partida, é necessário conhecer as classes WebClient e StreamWriter, e o template Generic Handler.

A classe WebClient  fornece métodos comuns para enviar dados ou receber dados a partir de qualquer local, intranet ou Internet recurso identificado por um URI. Nesta explicação será utilizado o método OpenWriteAsync.

leia mais…

abraços

Flávia

Há certo tempo estava pensando em deixar de utilizar o Mate Framework devido a uma falta de suporte mais robusta ao desenvolvimento de aplicações em Adobe AIR, então durante o FlexMania 2010, um uma palestra que abordava o tema Flex 4 – Desenvolvendo com Portabilidade(Web, Desktop e Mobile), pude ver um uso prático e fácil do Swiz Framework que me motivou a iniciar meus estudos e uso deste framework para as futuras aplicações que serão desenvolvidas. Neste post irei compartilhar o que até aqui ajuntei de informações…

Swiz Framework: Site | @SwizFramework | Wiki

Segundo a definição do Wiki temos:

O Swiz é um framework para Adobe Flex, Flash e AIR para fornecer um completo suporte ao desenvolvimento de soluções RIA. O Swiz te proporciona:

• Inversão de Controle
• Injeção de Dependência
• Tratamento de eventos e mediação
• Um cliclo de vida simples para métodos remotos assíncronos
• Um framework desaclopado do código da sua aplicação

Indo na contramão da maioria dos frameworks para Flex, o Swiz:

• Não impõem o uso de nenhum padrão JEE no código da sua aplicação
• Não repete estrutura de pastas
• Não te força utilizar nenhuma estrutura de código predefinida
• Não te obriga a estender nenhuma classe específica do framework

O Swiz representa o melhor das práticas aprendidas dos melhores desenvolvedores de RIA de algumas das melhoras empresas de consultoria da indústria, possibilitando assim que o Swiz seja, simples, leve e extremamente produtivo.

De início um ponto que me chamou a atenção e me agradou muito no Swiz, a documentação de como utilizar o Swiz disponível na Wiki é simples, fácil e clara, a qual recomendo a leitura. Após uma leitura, veja este exemplo de uso do Swiz [CafeTownsend-Flex4].

Links antigos que auxiliam na compreensão do Swiz Framework:

Adobe TV – Introducing Swiz [19/08/2008]

Possui uma explicação ampla sobre o framework.

Christophe Coenraets – uma aplicação simples usando o Swiz Framework e BlazeDS

Exemplo bem interessante, onde um ponto a ser observado foi como foi definido o acesso ao RemoteObject através do Swiz.

Using Swiz Part 1: Initial Setup

Conjunto de post sobre o uso do Swiz, atentar aos links relacionados do post.

Swiz in 20 minutes

Neste vídeo podemos te uma visão clara do poder e facilidade de uso do Swiz Framework e observar um detalhe que para mim é extremamente importante, nenhum código extra além da lógica da nossa aplicação, com isto o Swiz consegue ser fiel ao que se propõem…

Links recentes sobre Swiz Framework:

Jandersonfc

#flexmania 2010 – Flex 4 – Desenvolvendo com Portabilidade(Web, Desktop e Mobile)

Esta foi a palestra a qual me referi no início do post.

#flexmania 2010 – disponibilizando código fonte

Material da Palestra.

Swiz Framework

Publicações no blog abordando o assunto.

Flex & RIA  - Swiz Prototype

Swiz in Actionscript Projects (including Flash IDE projects)

Para quem tiver interesse em utilizar o Swiz Framework sem ser em um projeto Flex ou AIR é interessante a leitura desse post.

Veja também:

• [Flex & AIR] Swiz Framework + Presentation Model : Exemplo de Projeto
• Java Magazine 68 : Artigo sobre Adobe Flex e AIR
• FlexMania 2010 – Adobe Flex + Oracle WebLogic 10.x
• O que é o Adobe Flex?
• Facebook : Aplicação desktop

Esta semana eu estava dando uma olhada na grade do curso de Frontend da Egenial que vai começar neste sábado. Lendo sobre o curso veio novamente aquela lembrança de como o mercado, principalmente brasileiro, é fraco em produtos agradáveis de serem usados.

Por exemplo, eu não conheço nada semelhante ao Shopify em português, muito menos algo como o Basecamp. Que existem concorrentes brasileiros existem, mas por que todos são extremamente inferiores e conseguem até gerar ódio dos usuários?

Não entendo e nem quero entender nada de design

Muitos desenvolvedores criam seus projetos, abrem empresas, montam startups ou entregam produtos para clientes sem ter a consciência que talvez o seu código suado não tenha valor nenhum.

Alegando o contrário, você vai dizer que fez a analise do que era necessário, possui testes, empregou as melhores tecnologias, conversou com o cliente em todas as etapas e agora está tudo exatamente como combinado.

Porém existe uma coisa que a grande maioria das pessoas da área de TI não se preocupa. A interface, ou seja, como será usado seu sistema.

Amor a primeira vista

Em um produto material (não virtual) várias coisas contam, por exemplo a textura, como as coisas funcionam, a matéria prima empregada, como foi empregada, os encaixes e etc. O contato com o produto é físico e apenas por tocar um produto você consegue dizer se ele é uma porcaria ou não e se tem utilidade ou não.

No caso de produtos virtuais esse contato não existe e o mais próximo que temos da situação acima é contato com a interface do sistema.

Agora imagine o seu código lindo e maravilhoso embrulhado em telas cinzas e com 50 campos de formulário sem nenhuma lógica ou explicação?

Qual reação o usuário terá? Com um único olhar ele vai entender isso tudo como uma grande porcaria que é obrigado a usar pois faz parte do seu cotidiano. Quantas vezes você não vê pessoas reclamando que é uma falha no sistema? A grande maioria das vezes são apenas dificuldades que esta pessoa está tendo para entender como as coisas devem fluir naquele emaranhado de botões e campos.

Pensar como as telas vão ser desenvolvidas, quais são os passos lógicos que o usuário deve tomar, quais telas devem existir e quais não devem é sim parte do trabalho do desenvolvedor.

Para entregar um produto de real qualidade para quem vai usar seu sistema todos os dias é necessário que todas as pessoas da equipe entendam que a interface e o design são no mínimo 50% do produto e que o usuário deve abrir seu sistema e se sentir confortável. É assim que você se sente ao ligar seu Macbook ou seu iPhone. Você também não usa seu Gmail com medo de fazer uma bobeira por não saber onde está clicando. No seu produto não deve ser muito diferente.

Você não precisa se tornar um exímio desenhista e criar logos e ícones mas você precisa ter o censo crítico para identificar que seu produto é uma porcaria ou uma maravilha. Também deve ser capaz de conversar com os designers da sua equipe de igual para igual se aquela barreia que existe na maioria das empresas.

Design de UI NÃO É ARTE!

Design de software é quase nada de trabalho artístico e muito, mas muito, trabalho racional. Se ainda está relutante se deve entender algo sobre design ou não eu recomendo fortemente este vídeo para você entender porque um negrito em local é mais importante que um itálico:

<object height=”360″ width=”540″><param /><param /><param /><embed src=”http://vimeo.com/moogaloop.swf?clip_id=6702766&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=b30000&amp;fullscreen=1″ height=”360″ width=”540″></embed></object>

Por onde começo?

Com tudo isto em mente, se tornar um “Devgner” (como costuma dizer Lee Brimelow) é extremamente complexos (se ainda não viu o vídeo acima veja logo).

Voltando ao começo deste post, este curso de Frontend é algo que venho sugerindo ao pessoal da Egenial e conversando com eles a bastante tempo por todos estes motivos acima. Recomendo que você comece fazendo os seus softwares melhores através deste primeiro passo com o curso.