Como Automatizar Testes de aplicações Android – Parte 3

Estamos de volta em mais um post da série de como automatizar testes para aplicações em Android. E agora vamos para a parte que mais interessa à todos que é como automatizar testes para aplicações Android.

No eclipse vamos em File-> New -> Other e dentro da tela de New, selecionamos a opção Android Test Project e clicamos em Next (Passo 1 da imagem). Colocamos um nome no projeto de teste, por recomendação o nome do testes geralmente é o nome do projeto a ser testado concatenado com a palavra “Test”, no nosso caso o projeto a ser testado se chama Calculadora então o nome do projeto de teste será CalculadoraTest (Passo 2 da imagem) , colocando o nome do projeto então clicamos em Next. O nosso terceiro passo para criação do projeto de teste é selecionar o projeto que será testado, no nosso caso será Calculadora (Passo 3 da imagem) e clicamos em Finish. No final o eclipse criou um projeto de teste com boa parte já configurada como podemos observar no ultimo passo da imagem abaixo, onde percebemos que o projeto de teste foi criado com o pacote quase igual ao projeto que vai ser testado, exceto pela adição de um novo pacote chamado test.

 

Clique na imagem para ampliar

Em um projeto de teste para android podemos definir diversos objetivos e criar diversas classes de teste, no post atual a classe que estamos criando tem o objetivo de testar as funcionalidades básicas da calculadora utilizando a interface da mesma. Para isso criamos uma classe de teste que estende de ActivityInstrumentationTestCase2 ficando assim:

package br.edu.cesar.test;
import android.test.ActivityInstrumentationTestCase2;
import br.edu.cesar.CalculatorActivity;
public class CalculatorActivityTest extends ActivityInstrumentationTestCase2<CalculatorActivity> {

public CalculatorActivityTest() {
super(“br.edu.cesar”, CalculatorActivity.class);
}

}

Depois de criarmos a classe de teste, precisamos implementar o construtor desta classe que deve fica como no código acima. A classe de teste deve dizer para o framework de teste do android qual aplicação deve ser testada, passando por parâmetro do super construtor o pacote e o .class da activity a ser testada. Logo após a criação do construtor podemos passar pra alguns métodos “genéricos” que podem ajudar nos testes em si. São eles: setUp() – Este método herda do método setUp() do JUnit, portanto tem a mesma característica de ser usado para preparar o ambiente antes de cada teste ser executado. tearDown – Este método também herda do JUnit e também tem a mesma característica de ser usado para finalizar o ambiente corretamente quando necessário após cada teste executado. Utilizando o método setUp(), primeiramente pegamos a instancia da activity que vai ser testada e inicializamos alguns views da mesma para interegir a aplicação calculadora.  Outra coisa importante que precisamos fazer no teste para que o mesmo possa utilizar aplicação para interagir é desabilitar o modo touch da activity, fazendo isso temos o seguinte código para o método setUp():

@Override protected void setUp() throws Exception {
super.setUp();
setActivityInitialTouchMode(false);
mActivity = getActivity();
mMonitor = mIntrumentation.addMonitor(ResultActivity.class.getName(), null, false);
e1 = (EditText) mActivity.findViewById(br.edu.cesar.R.id.editText1);
e2 = (EditText) mActivity.findViewById(br.edu.cesar.R.id.editText2);
bSomar = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnSomar);
bSubtrair = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnSubtrair);
bMultiplicar = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnMultiplicar);
bDividir = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnDividir);

}

É importante lembrar que no inicio da classe estou declarando todos os objetos que estamos utilizando nos códigos dos métodos, como por exemplo mActivity que é um objeto do tipo activity e a mesma esta declarada no inicio da classe como voces podem ver no código do projeto de teste que esta disponivel neste link.

Para entender melhor de onde estou pegando os editText e os botões, deem uma olhada no código do projeto Calculadora, no qual disponibilizei no post anterior.  Após criar a classe e implementar o metódo setUp() podemos partir para a implementação do teste em si. Para criar um teste que interaja com a aplicação e analise o resultado esperado, basta criar um método que comece com a palavra “test” no inicio do nome do teste que o framework de teste do android reconhece o mesmo como teste para ser executado. No nosso exemplos demos o nome de testCalculadoraSoma001.  Neste teste vamos pegar as instâncias das views carregadas no método setUp() e vamos interagir com a mesma, mas para tal, precisamos criar uma thread especifica de UI para que essa interação ocorra. Pegamos a instancia da activity que temos e chamamos o método runOnUiThread() e dentro do run da nova runnable, a gente interage com as views, como por exemplo pegamos os editText da aplicação e populamos com os valores desejados e depois colocamos o foco no botão somar. O código do teste fica assim:

public void testCalculatorSoma001() {
mActivity.runOnUiThread(new Runnable() {

@Override
public void run() {
e1.setText(“2”);
e2.setText(“8”);
bSomar.requestFocus();
}

});
this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
oActivity = mIntrumentation.waitForMonitor(mMonitor);
assertNotNull(oActivity);
result = (TextView) oActivity.findViewById(br.edu.cesar.R.id.textview_result2);
assertEquals(“10”, result.getText());
this.sendKeys(KeyEvent.KEYCODE_BACK);
}

Após interagirmos com as view apenas enviamos o evento de pressionamento do center key do teclado com com método sendKey, e como o resultado da operação vem numa nova activity, temos que pegar a instancia da nova activity que vai ser exibida  com o método waitForMonitor() passando por parâmetro uma classe que fica monitorando o sistema aguardando que a nova activity que definimos para que o mesmo monitore la no método setUp. Após conseguirmos pegar a instancia da nova activity que vai mostrar o resultado,  pegamos o valor que está no TextView result  e verificamos se o valor é o mesmo do esperado com o método assertEquals que tem a mesma características dos asserts do JUnit. Por fim apenas precisamos executar o projeto, e para isto basta clicarmos com o botao direito em cima da classe de teste, no nosso caso CalculadoraActivityTest e selecionar a opção Run as-> Android JUnit Test. A execução do teste você pode conferir no video abaixo.

No vídeo acima podemos ver que temos dois testes, o primeiro esta relacionado ao código que coloquei acima testCalculatorSoma001() no qual passamos o valores 2 e 8 para os editTexts e esperamos que o resultado seja igual a 10. O segundo teste vamos deixar por sua conta para praticarem. O valores passados para os editText são 2 e 81 respectivamente e o resultado esperado é uma mensagem de erro que esta dentro do arquivo string.xml (dentro de res/values) do projeto da calculadora que passamos o código no post anterior. A mensagem de erro é  a string “Número Inválido”.

Por enquanto é isso pessoal, após utilizar este framework que o android prover eu tirei algumas conclusões, principalmente em algumas situações como por exemplo que dei na qual  a aplicação a ser testada possui mais de uma activity e as mesma utilizam intents entre si e  quando queremos testar aplicações dos quais não temos acesso ao código mas apenas ao .apk . Nesses casos implementar teste utilizando apenas o framework de teste do google se torna muito trabalhoso e complicado. No próximo post eu vou mostrar um exemplo da diferença de um teste implementado da forma que é recomendado pelo google e implementado utilizando uma biblioteca chamada robotium.

Anúncios

#TGIF – Achievement Unlocked

De acordo com a Wikipedia podemos definir “Gamification“, como o uso de técnicas e mecânicas de Game Design para resolver problemas e cativar as pessoas.

O #TGIF de hoje, inspirado no artigo do Papo de Homem, lista alguns exemplos e links interessantes sobre o assunto.

Um dos cases, que podemos citar, é o Nike+, aplicativo para dispositivos apple (iPod, iPhone), onde a definição de metas, recebimento de pontos e interação entre usuários podem ser usados como fator motivacional.

O primeiro vídeo, encontrado no Fun Theory, mostra de maneira simples como é possível motivar as pessoas e educá-las aplicando conceitos simples.

 

No campo educacional diversas são as possibilidades para motivar os alunos, o vídeo abaixo exemplifica.

 

Quer ouvir um pouco mais sobre o assunto, encontrei esse podcast do pessoal da Talk, onde o tema da conversa é justamente “Gamification”. Abordando os conceitos básicos e possibilidades.

Outros links interessantes:

– Gamification é bullshit (brainstorm)

– Gamificação: uma tendência ainda incompreendida

– Portal Gameficação

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais diversificado, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Desafio dos 30 dias

– Consumer Eletronics Show 2012

Como Automatizar Testes de aplicações Android – Parte 2

Olá pessoal.  Estou de volta para dar continuidade a meu último post sobre automação de testes para aplicações Android e neste post vou detalhar como implementei a nossa calculadora fajuta do Bdb para que possamos entender os conceitos básicos de Android e depois conseguirmos automatizar o testes para esta plataforma.

Primeiramente, como falei no post anterior temos que alinhar o ambiente de desenvolvimento que estamos usando. No meu caso eu uso o Eclipse Classic 3.6.2  instalei o plugin ADT. Para mais detalhes de como configurar seu ambiente, veja aqui.

Como todo começo de projeto, vamos no menu principal do eclipse: File->New->Other… e la na janela wizard temos a opção Android Project que nos leva a seguinte tela que devemos colocar o nome do projeto (Calculadora). Depois de colocar o nome do projeto e clicarmos em Next, vamos para a tela que devemos selecionar o Build Target. Como todos devem saber o Android já evoluiu bastante desde do seu surgimento no mercado  com a versão 1.5 mais conhecida como Cupcake até o mais recente e famosa versão 4.o ou Ice Cream Sandwich que promete integrar todo o ecosistema entre smartphones e tablets, mas isso não vem ao caso aqui. No caso da nossa calculadora, ela foi implementada para a versão 2.3.1 (API Level 9)  e é o que eu recomendo para que todos usem no momento para que possamos ter um alinhamento das atividades aqui no post.

Depois que escolhermos o Build Target, vamos para a seguinte tela na qual definimos o nome do pacote no qual nossa activity principal ficará disponível  e também já vamos ter uma sugestão do nome da activity principal que é o nome do projeto + a palavra Activity no final. Nesta última tela você verá também a opção de criar um projeto de teste para este projeto que você esta criando no momento, mas vamos deixar esta opção desmarcada e no próximo post vou mostrar como criamos um projeto de teste para esta aplicação.

Assim que o  nome do projeto, o Build Target, nome do pacote e o nome da activity principal são definidos, o projeto Calculadora vai ser criado com a seguinte estrutura:

Nosso primeiro passo vai ser no arquivo main.xml dentro de res/layout que é o arquivo responsável pela interface visual da activity que vamos implementar. No Android a estrutura da aplicação é dividida em algumas camadas e a camada de interface com o usuário é mais comumente definida no xml. O primeiro passo é selecionar o layout que vamos trabalhar na nossa aplicação, no nosso projeto a layout definido não vai fazer muita diferença, portando fica de livre escolha de vocês qual usar, no nosso código, definimos o relative layout. Para mais detalhe de cada layout suportando no Android, leiam aqui. No nosso projeto de calculadora vamos trabalhar com duas activities e dois xml de layout o primeiro xml (main.xml) temos um TextView (Nome da aplicação),  dois editText (Campos para usuario digitar os operandos) e 4 buttons (um botão para cada operador básico). O segundo xml (result.xml) de layout temos apenas um textView que é para exibir o resultado da operação selecionada pelo usuário na tela anterior.Obviamente poderíamos exibir o resultado na mesma tela mas fizemos dessa forma com um próposito que veremos no próximo post quando formos falar das 2 maneiras de automatizar os testes dessa calculadora.

Para ver como ficou os arquivos xml  e também os arquivos .java que vou explicar nos parágrafos seguintes, baixe o código da nossa aplicação neste link .

Depois de definido o layout vamos para a implementação em si. Primeiramente, vamos ao básico e criamos uma classe chamada Operators.java com todos os métodos de cada operação básica da nossa calculadora, esta classe será instanciada pela activity principal e seus métodos serão chamados de acordo com os eventos que a nossa activity principal tratar.

Na primeira activity, que é a nossa activity principal (CalculadoraActivity.java) definimos qual layout vamos usar (main.xml) e definimos também alguns atributos que vamos utilizar para pegar as instancias dos Views (componentes visuais, Ex: Buttons) que definimos no main.xml e no qual vamos tratar os eventos que serão gerados pelos usuários ao interagir com estes views,  como por exemplo o clique no botão (OnClick). A nossa segunda activity (ResultActivity.java) é a tela que simplesmente pega o resultado “empacotado” pela primeira activity e exibe no textview que esta definida pelo layout result.xml.

Um último detalhe e não menos importante é o arquivo strings.xml que fica dentro da pasta res/values. Nesse arquivo definimos algumas “variáveis” no qual podemos ter acesso de várias parte do cógido, como nos arquivos de layout, no código das activities, etc…
No nosso caso definimos o o valores para todos os views utilizados pela aplicação, como por exemplo o nome na aplicação que é definido no arquivo mais.xml para o TextView esta setado no arquivo strings.xml como app_name e seu respectivo valor é Calculadora.

Após todo esse trabalho a nossa calculadora fajuta do Bdb vai ficar com essa cara como na imagem aqui abaixo:

Bem, por enquanto já temos o suficiente para nos divertimos um pouco durante a semana e no nosso próximo post eu vou finalmente revelar como podemos fazer alguns testes automáticos para esta nossa calculadora fajuta. Aproveitem o restante da semana para por em prática os conceitos básicos  passados aqui e brinquem de alterar o código para entender um pouco mais como a coisa toda funciona. Uma ótima semana para todos e até o próximo post.

Guia Android Design para Ice Cream Sandwich

Recentemente, numa sexta-feira 13 (sim, bem pertinente), a google lançou mais uma novidade para o seu sistema operacional, o Android Ice Cream Sandwich (4.0). Dessa vez, entretanto, a surpresa fica por conta de um guia de estilos para promover novas interações e o novo “look and feel” da versão nova.

A ideia geral por trás desse guia de estilos é tentar unificar a plataforma no que se diz respeito à interface. Além disso, existe uma preocupação por parte do google de tentar criar padrões visuais mais fortes e consistentes. Isso, entretanto não é novidade para, por exemplo, a Apple que sempre teve guias de design bem atrelados à plataforma.

Design Elements
Guia pretende consolidar padrões de interface

Uma coisa bem interessante sobre o guia é que ele tentou focar não somente nos desenvolvedores da plataforma mas também nos usuários, com dicas, padrões e e documentos que vão auxiliar em todo o processo, da criação à implementação. A primeira versão do portal pode ser encontrada em Android Design e já contém algumas coisas bem interessantes.

O guía é dividido em seções como Estilo, onde encontramos linhas gerais sobre interface como detalhes sobre cores, feedback, ícones e até tipografia e padrão de escrita. Já em Padrões, conseguimos identificar toda a parte de interação da plataforma, como estrutura da aplicação, gestos, compatibilidade e conceitos de interação. Por fim, temos os Blocos, onde podemos identificar os componentes e seus tipos e sub-tipos.

A consulta ao site é uma coisa bem válida para todos que estão começando a desenvolver, bem como para aqueles que já têm experiência com a plataforma. Lembrando que a ideia é que esse guia seja atualizado com novidades da plataforma. É, parece que agora, ninguém mais tem desculpa para desenvolver aplicações feias.

#TGIF – Afinal, o que danado é SOPA?? e PIPA??

Essa semana foi um dos ápices do movimento contra o projeto chamado SOPA, e se você não sabe do que se trata exatamente está no lugar certo! No #TGIF de hoje o Bytes Don’t Bite tenta explicar o que siginifca SOPA e também PIPA.

O que é isso??

SOPA é um acrônimo para “Stop Online Piracy Act”, que  é um projeto de lei americano cujo objetivo seria combater a pirataria online (downloads e compartilhamentos de músicas, filmes, imagens, textos ferindo direitos autorais e outras formas de proteção ao conteúdo). O problema é que juntamente com isso, vem alguns efeitos colaterais, e a internet da forma que conhecemos hoje pode mudar radicalmente. Além do SOPA, outro projeto de lei americano é o PIPA, que é um acrônimo para “Protect IP Act” e simplesmente esse projeto de lei dá poder ao governo americano para fazer provedores de internet bloquearem o acesso a sites aonde exista compartilhamento e também dá direito para processarem os sites que apontem para esses conteúdos (como blogs, fóruns e até os sites de busca como o google) e exigirem a remoção de links para sites considerados infratores.

Quem está por trás disso??

É muito claro que o maior interessado é a indústria de entretenimento, grandes produtoras de filmes, grandes gravadoras de música e etc. O grande objetivo dessas empresas é diminuir a quantidade de conteúdo ilegal sendo compartilhado na internet. O problema é que essa tentativa de diminuir a pirataria vai também CENSURAR a internet de uma forma que nunca vimos até agora.

Quem serão os mais afetados??

Todos nós seremos afetados, independente se você consome conteúdo pirata ou não, pois os sites que você tanto gostava de acessar e que traziam tantas coisas úteis vão simplesmente pouco a pouco serem fechados e perderem seu valor. Sites como Wikipedia, Google, Youtube, Soundcloud, Flickr, servicos de upload como megaupload, rapidshare e quaisquer outros sites que as pessoas  usam pra divulgar ideias e trabalhos seriam pouco a pouco “capados” até que perdessem seu valor total.

Mas se este projeto de lei é para os EUA, porquê eu deveria me preocupar??

Uma vez esse projeto de lei aprovado nos EUA, seria somente uma questão de tempo até que os outros países começassem a adotar posturas semelhantes até o momento em que a nossa internet mundial estaria nas mãos dos governos dos países, acabando com a liberdade que temos atualmente.

E será que essa lei vai ser aprovada mesmo??

Esperamos que não, e tudo indica que não! Grandes sites estao fazendo a parte deles no que diz respeito a protestar contra esses novos projetos de lei, e quarta-feira passada retiraram os sites do ar em protesto. Sites como wikipedia (em inglês) saiu do ar toda a quarta-feira.

Para mais informacoes, assita o vídeo abaixo que tem 4 minutos.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais divertido, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– As 3 coisas que descobri quando meu avião caiu

– Desafio dos 30 dias

Como Automatizar Testes de aplicações Android – Parte 1 (O desafio)

Olá pessoal,  este ano vou começar com uma pequena série de posts e um pouco DIFERENTE dos posts habituais para falar mais uma vez de teste na prática. Obviamente para ser diferente eu vou deixar este primeiro post um desafio para todos assim como eu tive um desafio no final do ano passado para  preparar e ministrar uma disciplina de teste de software para uma turma de desenvolvedores que estava participando de um curso de desenvolvimento para Android. Preocupado em deixar as aulas de teste mais interessantes,  eu arrisquei adaptar meu material para algo que fosse bastante prático e relevante para essa turma e por isso dei uma estudada no Android e como desenvolver aplicações e criar testes automáticos para o mesmo e acabei descobrindo algumas coisas que o SDK disponibiliza que gostaria de compartilhar com vocês.

Antes de começarmos a desenvolver testes para o Android, preciso passar  algumas informações relevantes para que todos possam conseguir ter um entendimento completo de como automatizar alguns testes para aplicações em Android e também consigam completar o desafio que deixarei neste post.

Para podermos automatizar testes para aplicações Android, precisamos entender alguns de seus componentes básicos, que são: Activities, Services, Content Providers e Broadcast Receivers.

Activities – Uma activity é um dos componentes do Android mais usados nas aplicações pois ele é que  fornece uma tela com a qual os usuários podem interagir. Por exemplo dicar um número de telefone, escrever uma sms, ou visualizar um mapa. Para cada activity é dada uma “janela” na qual “desenhamos” uma  interface de usuário. As “janelas” normalmente preenche toda a tela, mas também podem ser menores do que a tela e flutuar em cima de outras “janelas”.

Services – São componentes de aplicação que podem executar operações de longa duração em segundo plano, portanto não fornecem uma interface de usuário. Um serviço pode ser iniciado por uma aplicação e ele continuará a ser executado em segundo plano, mesmo se o usuário trocar para outra aplicação.

Content Providers – Como o nome já explica, Content Providers é componente responsável por armazenar e recuperar os dados e torna-los acessível para todas as aplicações, ou seja são os provedores de conteúdo. A única forma de compartilhar dados entre aplicações no Android é através de content providers, pois não existe área de armazenamento comum que todos os pacotes Android podem acessar.

Broadcast Receivers – É um componente que responde a anúncios de todo o sistema de broadcast. Muitos brodcast provenientes do sistema, como um broadcast anunciando que a bateria está fraca ou uma sms foi recebida. As aplicações também podem iniciar os broadcast, por exemplo, para permitir que outras aplicações saibam que alguns dados foram disponibilizados para eles usarem. Os broadcast receivers também não possuem interface de usuário, mas eles podem criar uma notificação de barra de status para alertar o usuário quando um evento de broadcast ocorreu.

Bem , depois desta uma breve introdução, vamos por a mão na massa e desenvolver uma calculadora bem simples para que depois possamos automatizar alguns testes para essa aplicação. Quem quiser se aprofundar um pouco mais sobre como desenvolver aplicações para Android pode dar uma olhada neste site para desenvolvedor da Google.
Essa calculadora que desenvolvi possui algumas restrições para cada uma das operações básicas (somar, subtrair, multiplicar e dividir) com o objetivo de exemplificar o uso de algumas técnicas de criação de teste para os alunos da turma e essas técnicas de criação de testes não vem ao caso neste post nem nos seguintes que virão, o nosso objetivo aqui é explicar como desenvolver e automatizar testes para aplicações Android. Outro fator relevante que devo deixar claro é que eu utilizei o eclipse com o plugin ADT para desenvolver meu projeto em Android. Para saber como configurar seu ambiente, veja aqui.
Após configurar o ambiente vamos ao nosso desafio:
Vou deixar alguns requisitos básicos da nossa calculadora para que você possam tentar desenvolver e no próximos post  disponibilizarei o nosso código e explicarei passo a passo como o desenvolvi.  Logo abaixo segue os requisitos da aplicação que vamos automatizar os testes mais na frente:

Nome: Aplicativo Calculadora Fajuta 

[REQ001] Tela principal deve possuir dois campos (EditTexts) para inserir valores e um botão (Button) de cada  funcionalidade da calculadora, que são:
– SOMAR
– SUBTRAIR
– MULTIPLICAR
– DIVIDIR

[REQ002] A operação SOMAR  só efetua soma de números entre 0 e 10, pois a calculadora é fajuta. O resultado deve ser mostrado em um texto (TextView) no canto inferior da tela.

[REQ003] A operação SUBTRAIR é um pouco mais evoluída e consegue efetuar a subtração de números entre 0 e 50. O resultado deve ser mostrado em um texto no canto inferior da tela e caso seja um resultado negativo, o mesmo deve estar na cor vermelha.

[REQ004]  A operação MULTIPLICAR  deve multiplicar  apenas números pares.

[REQ005] A operação DIVIDIR, da mesma forma da operação Somar, só efetua a divisão de números entre 0 e 10.

E claro que qualquer dúvida por mais simples que seja, podem comentar aqui neste post e terei o prazer de responder o mais rápido possível. Para os mais tímidos, podem me mandar um email que tem no meu perfil aqui do Bdb.  Boa sorte a todos !!! 🙂

Usabilidade: O que é? Mitos e verdades

Olá pessoal, a partir de hoje estarei com vocês aqui no BdB pra falar um pouco sobre usabilidade e outros tópicos relacionados com design. Como primeiro tópico, resolvi abordar minha percepção do que é usabilidade.

Hoje, mais do que nunca, usabilidade é uma palavra recorrente em vários dicionários. Para todos nós que estamos diariamente no universo de TI é ainda mais evidente notar o quanto o crescente uso dessa palavra causa, por muitas vezes, mais confusão do que benefícios. Mas afinal, o que é usabilidade?

Por definição da própria Wikipédia, podemos definir usabilidade, entre outras coisas, como a facilidade de uso de “algo” por um ser humano. Normalmente associamos esse “algo” a um objeto, ferramenta ou, no nosso caso, um software. Mas, engana-se quem pensa que usabilidade – seu estudo e também sua melhoria – se restringe a esses itens. De fato, usabilidade também pode ser aplicada em elementos como um manual técnico ou objetos mecânicos portas, carros e muitos outros.

Além disso, um conceito que normalmente fica mal-entendido é que usabilidade faz parte de um conceito mais amplo dentro do design, que é o conceito de experiência do usuário. UX (de User eXperience) é um conceito um pouco mais amplo do que a própria usabilidade. Enquanto o primeiro se concentra apenas em aspectos técnicos como legibilidade, facilidade de uso e muitas coisas, o segundo – a experiência do usuário – tende a ser mais subjetiva, englobando diversas disciplinas como cognição, acessibilidade, arquitetura da informação e a própria usabilidade.

UX

Bom, a partir dos próximos posts vamos começar a entrar um pouco em cada uma das áreas que formam a UX e descobrir o quanto e como elas podem afetar nossos produtos. Até breve!