A importância dos testes de softwares.
Todo bom software antes de passar para a fase de lançamento oficial, passa por uma fase de testes. Estes podem ser de vários tipos, neste artigo o maior enfoque estará virado para os testes baseados na critica – Avaliação Heurística. Na maioria dos casos, realizam-se testes para assegurar que todos os requisitos necessários para o pleno funcionamento de um software encontram-se em condições adequadas para que o utilizador final possa desfrutar dos serviços proporcionados pelo mesmo sem complicações.
Fora a Avaliação Heurística, existem outras formas de fazer testes em softwares. Estes podem ser por via de testes empíricos, testes formais ou testes automatizados.Testes Empíricos – estes são feitos com utilizadores reais, que testam o software e dão feedbacks baseados nas suas experiências e observações. Os testes empíricos são na base na tentativa e do erro, cada utilizador compreende o software a sua maneira.
Testes Formais – neste tipo de testes, são construídos modelos e fórmulas para calcular/medir a reposta ou comportamento do utilizador. Dependendo do ambiente em que este é colocado.Testes Automatizados – no modelo de testes automatizados, são construídos ou utilizados outros softwares para testes dos softwares em desenvolvimento. Este modelo é facilmente aplicado em projectos de pequena envergadura e de difícil implantação para projectos de grande envergadura.
Nos testes acima citados, só em 2 ( testes empíricos e formais) é que precisamos de utilizadores reais. Embora o processo de implementação seja diferente. Enquanto que no teste empírico o processo é mais livre e a mais recolha de dados qualitativos nos testes formais acontece o inverso. O ambiente é mais controlado e respostas estão sempre dentro de um parâmetro.
O testes automatizados por sua vez, vem de certa forma complementar a componente humana, dando mais respostas quantitativas, trazendo sempre, respostas relacionadas a performance a outras componentes técnicas do software.
Ainda no mesmo espectro de testes, encontramos outro tipo de testes que de certa forma é apoiado pelos utilizadores, mas mais especializados, são estes chamados testes baseados na crítica ou avaliação heurística, como o título do artigo sugere. Os testes baseados na crítica são normalmente feitos por experts na área. Nestes, pode-se ter/conseguir feedbacks de alto valor. Avaliação Heurística é um método de teste/avaliação de interfaces de softwares baseado em princípios de usabilidade.
Os princípios são chamados de heurísticas pois são desenvolvidos a partir de uma série de experiências prévias, sintetizando pontos recorrentes. Este termo foi cunhado inicialmente por Jakob Nielsen e Rolf Molich em 1990. Por ser o elo entre o homem e o computador, as interfaces dos softwares, pautadas nas heurísticas, é necessário considerar os elementos relacionados à sua adequada estruturação: Arquitetura da Informação, Arquitetura de Design, Navegabilidade, Conteúdo e Interatividade, que relacionados entre si, definem a usabilidade de um de uma interface.
No processo de avaliação a interface é submetida para diferentes avaliadores. Estes darão seu parecer baseando-se em 10 princípios, as chamadas heurísticas (este tópico será tema principal do próximo artigo). Umas das maiores vantagens do feedbacks baseado na crítica é proporcionar a possibilidade deste ser feito em qualquer fase do projecto, sendo que poupa os utilizadores, para testes de outra natureza em fases mais avançadas, onde o feedback baseado no uso do software dentro de um contexto é indispensável.Na avaliação heurística é importante dar destaque ao perfil do avaliador, o expert.
Para que o teste tenha efectivo valor este tem de ser um profissional com experiência. Se este for da área de Engenharia de Software ou Design será melhor. Mas com mais enfoque em análise de interfaces interactivas em aspectos concernentes a usabilidade.
Como já havia prometido acima, no próximo artigo irei abordar a avaliação heurísticas e os princípios de usabilidade com mais profundidade. Bem, por hoje é tudo.
Até a próxima!
Referências
Para além de observar as pessoas de forma participativa como expliquei no artigo anterior, podemos também conseguir feedback valiosodos utilizadores entrevistado-os, isto é, perguntando directamente sobre as suas experiências. Entrevista é a técnica de coleta de dados na qual as perguntas são formuladas e respondidas oralmente.
Trata-se, portanto, de uma conversação metódica, que proporciona ao entrevistador as informações solicitadas. Como técnica de pesquisa, a entrevista é utilizada para obter informações sobre o que as pessoas sabem, crêem, esperam, sentem, desejam, pretendem fazer, fazem ou fizeram e também sobre o que motiva ou motivou tudo o que acabamos de mencionamos.
Neste processo, o passo mais importante é decidir quem serão as pessoas entrevistadas. É importante que as pessoas entrevistadas representem o público alvo do produto que vamos desenvolver. Para encontrar estas pessoas ideais, o método mais comum é definir personas, ou seja, descrever, detalhadamente e com antecedência, o nosso utilizador ideal.
A persona é baseada em dados reais sobre comportamentos e características demográficas dos utilizadores, assim como na definição das suas histórias pessoais, motivações, objetivos, desafios e preocupações. Os entrevistados podem ser utilizadores de sistemas parecidos com o que estamos a desenvolver mas também podem ser não-utilizadores. Desde que eles se encaixem no perfil do utilizador ideal, será suficiente. Depois de defini-los, vamos à busca.
O que é uma boa pergunta numa entrevista?
Uma boa pergunta não é aquela que nos dará necessariamente uma resposta concreta, mas sim aquela que levará o entrevistado a contar-nos uma história a partir da qual perceberemos com mais clareza quais são as suas motivações, aspirações, pressupostos, etc. Como já havíamos dito na semana passada, as pessoas não são muito boas em saber o que querem, logo, perguntando-lhes directamente, poderemos obter respostas ideiais na teoria mas que não expressam os seus reais desejos. Por exemplo, se perguntarmos a alguém: “A atualização diária em softwares é importante pra si?” a maioria dos utilizadores diria “Sim”.
Esta resposta pode parecer ideal mas, se colocarmos a pergunta de outra forma, poderemos ter um resultado mais elucidante. Por exemplo: “Vejo no seu registro que nunca usou a atualização diária. Há algum motivo específico para isso?”.
Aí, o utilizador é capaz de mencionar problemas com a actualização diária dos quais não tinhamos noção, uma resposta mais valiosa que se simplesmente perguntarmos se o utilizador acha as actualizações diárias importantes. Quanto mais abertas forem suas perguntas, mais interessantes serão as respostas.
Da mesma forma que certos tipos de perguntas dão respostas mais interessantes, há também questões que devemos evitar numa entrevista:
Uma boa entrevista é aquela que nos elucida sobre coisas que de outra forma não teríamos como saber e, por isso, é importante tomar sempre atenção em escolher o público alvo que melhor representa o grupo de utilizadores finais e prestar atenção na formulação das perguntas para que, em conjunto com os outros métodos descritos nas publicações anteriores, possamos perceber melhor o utilizador final do nosso produto e, com isto, desenvolver a melhor solução possível para o seu problema.Por hoje é tudo. Daremos seguimento às nossas conversas em breve.
Até já.
Referências
Quando projectamos novas tecnologias, é importante identificar claramente um problema ou necessidade. Mas, depois de encontrá-lo, de nada vale correr para solucionar o problema sem antes perceber como é que a pessoa que vai usar a solução que vamos desenvolver pensa e age. Observar de forma participativa situações correntes, situações do dia-a-dia, ajuda-nos a construir empatia, a pensar no ponto de vista do utilizador e a entender melhor os seus hábitos, metas e valores.
A IDEO, uma das mais conceituadas agências de design do mundo, utiliza a etnografia, ou seja, uma inerção directa e prolongada com o utilizador final dos seus produtos, durante a pesquisa de campo, período inicial no desenvolvimento de produtos e/ou serviços. Isto é a essência da observação participativa: a documentação dos ambientes naturais onde pessoas trabalham e residem e a elaboração de entrevistas um pouco mais detalhadas, com o intuito de desenvolver empatia e identificar padrões de comportamentos e necessidades reais das pessoas para as quais estamos a desenvolver serviços e/ou produtos.
Na observação participativa, há alguns pontos importantes a destacar:
1. Quando vamos desenvolver um produto, é comum que as pessoas já usem uma metodologia especifica para alcançar os objectivos que o nosso produto pretende melhorar. Uma pergunta importante a fazer no início da pesquisa é: Que processos ou procedimentos as pessoas já usam para resolver este problema? Qual é a linha de base que se vai usar para avançar com a pesquisa?
2. Na maioria dos casos, vamos construir tecnologias que se alinhem com o que as pessoas se importam e esperam conseguir. Contudo, isso não significa que temos de construir o que as pessoas pedem, como é o caso da Walmart (que já veremos a seguir), mas sim projectar tecnologias e soluções que se entrelaçam na vida cotidiana das pessoas. Muitas vezes, as pessoas não sabem o que querem, especialmente quando se trata de tecnologias disruptivas então, aqui, o importante é perceber: Quais são os objectivos e valores das pessoas?
3. Para desenvolver soluções efectivas, é importante perceber o contexto maior onde essa solução se encaixa. Como é que as actividades particulares dos utentes estão inseridas numa ecologia maior de comportamentos? Como é que as actividades se integram do dia-a-dia dos utilizadores? Em que momento ou situação é que as pessoas realizam uma determinada tarefa?4. Nem todas as pessoas reagem da mesma forma a diferentes situações, por isso, é importante ter em conta as variáveis comportamentais.
Quais são as semelhanças e diferenças que se podem encontrar nas pessoas?Um dos exemplos usados pelo professor Klemmer foi a Walmart. Em 2009 Walmart fez uma pesquisa com seus clientes, onde perguntou se eles gostariam que os corredores fossem menos confusos e a resposta, sem muita surpresa, foi “Sim!”. Então, muito diligentemente, a Walmart começou a tornar os seus corredores menos confusos. Gastaram centenas de dólares no processo, removendo o stock, limpando as coisas e o que aconteceu? Eles perderam USD1.85 bilhões em vendas.
Parece surpreendente porque eles fizeram exatamente o que as pessoas pediram, certo? Mas a Walmart cometeu dois erros: o primeiro é que eles prestaram atenção ao que as pessoas disseram, em vez do que elas fizeram; o segundo é que a pesquisa deles fez uma pergunta principal: “Vocês gostariam que os corredores fossem menos confusos?”, ou seja, criaram uma solução e depois pediram para que os clientes concordassem com eles.
Juntos, estes dois erros induziram-lhes a tomar uma direção exatamente oposta àquela que deviam ter tomado: fizeram o que os clientes disseram que queriam (tornar os corredores menos confusos) em vez de observá-los e fazer o que eles realmente queriam (uma variedade de produtos a preços baixos).
E daí a importância da verdadeira observação, da prática, como já havíamos falado antes. De nada vale seguirmos cegamente os nossos planos sem realmente conhecer as necessidades de quem vai usar o produto final e sem receber feedback a cada passo. Um pouco mais de observação pode previnir erros monumentais.Vou terminar o artigo de hoje citando Yogi Berra: “We can observe a lot just by watching” que em tradução literal significa: “Nós podemos observar muito, só olhando”.
Até já.
Referências
O ciclo desenhar-testar-feedback é um loop contínuo quando se fala de bom design. Não se para de obter feedback; continua-se a criar versões cada vez mais avançadas do produto para obter um feedback cada vez melhor e mais detalhado. Os protótipos são justamente isso, modelos mais detalhados e interactivos do produto final, que nos permitem obter feedback muito mais rápido e preciso.A prototipagem é uma actividade vital em inovações estruturadas, colaboração e criatividade no Design.
Ela é uma estratégia eficiente para lidar com as coisas e situações que são difíceis de prever. Ao testar as coisas e aprender a partir desta exploração, podemos melhorar o projecto. Passamos a ter ideias, que de outra forma não conseguiríamos ter.
O principal objectivo da prototipagem, não é obter uma forma “final” do objecto ou producto em desenvolvimento, mas sim receber o feedback.Como componente do Design Thinking, uma metodologia de projecto que fornece uma abordagem baseada na solução para resolver problemas, a prototipagem é extremamente útil para lidar com problemas complexos, mal definidos ou desconhecidos, compreendendo as necessidades humanas envolvidas e re-estruturando a abordagem ao problema para que seja centrada no ser humano.
Para que servem os protótipos?Os protótipos respondem às seguintes perguntas:
1. Sentimento: Com o que é que isso se parece?
2. Implementação: Como pode funcionar?
3. Função: Como será a experiência na utilização do produto?
Técnicas de Prototipagem
Nem todos os protótipos são de igual impacto. Existem protótipos de alta e baixa fidelidade e estes se resumem em: sketches, wireframes e protótipos detalhados.Sketches – Os sketckes permitem verificar se o conceito e os requisitos foram percebidos, sem que seja necessário aplicar muito esforço. Esta é a técnica de prototipagem de menor fidelidade.
É ideal para a fase inicial do projecto por ser é fácil de criar e entregar mas, à medida em que se avança no projecto, os sketches tornam-se menos úteis. É difícil testar funcionalidades com sketches quando o produto se torna complexo.Wireframes – Os wireframes tornam fácil testar ideias e saber se elas funcionam na prática.
Estes são mais complexos que os sketches e se forem criados em softwaresespecializados é fácil adicionar o elemento “interação”. O aspecto de “produto finalizado” não é importante nos wireframes mas, é importante que tenha informações detalhadas para se avaliar como o utilizador irá reagir ao produto.
Protótipos – Estes são modelos funcionais do produto acabado. Eles são desenhados para emular as funcionalidades e bem como o aspecto do produto (look and feel). O protótipo é apresentado quando estão acertados e concordados todos os detalhes do produto e se avança para a fase de desenvolvimento.
Os protótipos, por sua natureza, levam mais tempo necessitam de mais custos para produzir.Uma das técnicas de prototipagem mais interessantes, citada pelo professor Klemer, chama-se o Mágico de Oz (nome inspirado pelo personagem de mesmo nome dos contos do escritor americano L. Frank Baum).
Esta era uma técnica usada em testes de produtos para economizar recursos de produção. Em vez de esperar que o protótipo esteja funcional para realizar testes, um operador humano funciona como computador (o Mágico de Oz), processando os resultados e posicionando as telas para o utilizador.
Um exemplo clássico de uso desta técnica é o Mechanical Turk, uma máquina de jogar xadrez do século XVIII que chegou a enganar famosos como Napoleão Bonaparte e outros. Dentro da caixa estava escondido um jogador de xadrez especialista e através de mecanismos especiais ele conseguia ler o jogo e mover as peças no tabuleiro.
Não interessa a forma específica de criar os protótipos, o que importa é o processo, é manter o ciclo desenhar-testar-feedback vivo e em movimento e chegar cada vez mais perto a uma versão ideal, compreensível e simples de usar, do nosso produto. Como já diz o professor Klemmer:
“Os protótipos são como perguntas, faça muitas.”
Até breve.
Referências
Para garantir “bom design”, a avaliação não é opcional mas sim crucial.A história que partilhei convosco na minha primeira publicação voltou a ser relevante quando aprendi que, mesmo mantendo o utilizador final em mente, o mais eficaz é pôr a interface em frente do utilizador e ouvir dele mesmo o relato da experiência de usar o sistema.
Muitos dos comportamentos do utilizador podem ser previstos na teoria, mas só testanto é que se garante que a interface traduz, da forma mais simples e intuitiva possível, tudo aquilo que foi conceituado. Os benefícios que podemos ter com estas avaliações não terminam por aí, mas também incluem desde insights que nos podem ajudar a gerar novas ideias ou alterações que podem melhorar a usabilidade do sistema de formas que não tinham sido pensadas antes e até à correção de bugs.
Como é que os utilizadores vão usar o sistema? Como reagem durante o usam? Riem-se? Reclamam? De que forma é que um design é diferente do outro? E se alterarmos a interface, como é que isso afecta o comportamento dos utilizadores? Que práticas novas podem surgir da avaliação? Como é que a forma de utilização da interface muda ao longo do tempo?
Estas são algumas das perguntas mais frequentes sobre as interfaces do utilizador, e as respostas para cada uma delas vêm de métodos de avaliação diferentes, o que significa que nenhum método é melhor ou pior que o outro e que a escolha de qual método usar depende principalmente do que é que se quer avaliar.
Alguns dos métodos mais usados são:
1. Estudos de Usabilidade: Um das formas de aprender sobre Experiência do Utilizador, é levar os utilizadores para um local de teste (geralmente um laboratório ou escritório) que pode ser equipado com um espelho sem reflexo que divide a sala, e a equipe de observação e os utilizadores ficam de lados opostos. Isto permite que a equipe de observação veja em tempo real como os utilizadores interagem com a interface e as suas reações.
2. Formulários: Uma forma diferente recolher feedback dos utilizadores é usando formulários. Estes ajudam a recolher informação de múltiplos utilizadores em menos tempo e é relativamente fácil comparar múltiplas alternativas. Para este caso não é necessário que a interface esteja completa e já em uso, podemos usar mockups ou screnshots.
3. Grupos Focais: Usar grupos focais significa reunir um pequeno grupo de pessoas para discutir sobre o sistema. Por um lado, conseguimos descobrir informações novas, dificuldades partilhadas, etc.; por outro lado, o cenário de “grupo” às vezes dá lugar para que as pessoas com personalidades mais fortes dominem a conversa e as pessoas com personalidades menos dominantes não se expressem ou não respondam de forma honesta, com o intuíto de agradar o grupo.
4. Feedback de Experts: Um feedback deste nível é chamado de Avaliação Heurística é um método de avaliação de interfaces baseado em princípios de usabilidade. Os princípios são chamados de heurísticas pois são desenvolvidos a partir de uma série de experiências prévias, sintetizando pontos recorrentes. A interface é submetida para diferentes avaliadores que darão seu parecer baseando-se nos mesmos princípios, as chamadas heurísticas.
5. Observação Participativa: Neste modelo de avaliação, o observador acompanha o utilizador no seu dia-a-dia, fazendo notas sobre como ele desempenha determinadas actividades e como estas podem causar alterações ao sistema no seu todo.
6. Modelos Formais – Simulação: Se houver uma teoria matemática formal, podemos fazer previsões e comparar interfaces, sem necessariamente ter de reunir os utilizadores numa sala de pesquisa. A simulação é um técnica de entrada muito usada porque o desempenho motor dos utilizadores é o mais quantificado em IHC.
Existem ainda outros métodos como: generalização, realismo e comparação, nos quais não vamos entrar em detalhe no post de hoje. Não existe um método certo ou errado. Cada tipo de pesquisa ou por outra, cada fase do desenvolvimento da interface requer que avaliemos diferentes factores e é a definição do que se pretende avaliar que vai determinar qual é o método mais apropriado de se usar naquele momento.
Por isso, a questão que se deve manter sempre em mente é: O que é que pretendemos avaliar?Para terminar o resumo de hoje, vou deixar-vos com uma pequena reflexão que de certeza algum grande pensador já alguma vez disse (ou talvez não, mas fica a reflexão na mesma): quem não avalia, mau design cria.
Até breve.
Referências
É importante estudar o passado para entender o presente e projectar o futuro.Muitas vezes, quando uma coisa se torna tão “parte” das nossas vidas, é difícil imaginar que algum dia elas não foram como são hoje. Ficamos com aquela impressão de que ela deve simplesmente ter sido criada tal e qual a conhecemos hoje e, de certa forma, minimizamos o valor de todo o trabalho que foi feito para que tal coisa saísse da imaginação, de uma simples idéia, à realidade da sua forma actual.
Entender que o processo de criação é exactamente isso – um processo – não só nos lembra de dar valor ao esforço e trabalho de todos que contribuíram para que estivéssemos onde estamos hoje, também lembra-nos que o processo criativo, o processo de materializar algo que está nas nossas cabeças, é árduo, trabalhoso e nem sempre acontece de imediato; pode levar dias, semanas, meses ou até mesmo anos.
A história da IHC – Interação Humano Computador iniciou em Julho de 1945, quando Vannevar Bush escreveu um artigo para a edição de Julho de 1945 da revista Atlantic Monthly, um magazine centrado, na altura, em comentário literário e cultural.
O artigo foi mais tarde reimpresso no Life Magazine, na edição de Setembro de 1945, com o título “As We May Think”. O objectivo do artigo, escrito nos últimos meses da Segunda Guerra Mundial, era de perguntar “o que é que os cientistas financiados pelo governo poderiam fazer para criar um mundo melhor em tempos de paz?”.
A visão de Bush era fortemente centrada no ser humano e contemplava a idéia de uma mesa interativa futurista, à qual chamou “MEMEX”.No centro da idéia do MEMEX, estavam interfaces do utilizador efectivas para armazenamento e recuperação de informações. Mais impressionante ainda, é que a visão que Bush tinha para o MEMEX foi responsável pelas idéias que deram origem à invenção do hipertexto.
Grace Hopper, que em 1944 foi uma das primeiras programadoras do Harvard Mark I e inventou o primeiro compilador para uma linguagem de programação, teve a idéia, no início da década de 1950, de trazer um interface amigável para os computadores. Ela pensou em como ferramentas melhoradas poderiam fornecer acesso à computação a uma audiência muito mais ampla.
Nos anos que se seguiram, o surgimento de cada vez melhores ambientes de programação para desktop e web permitiram que legiões de desenvolvedores criassem conteúdo que ajudasse a colocar um PC (Personal Computer) em cada mesa.Isto é o que acontece quando vamos construindo uma idéia por cima de outra, o que faz com que todo o aglomerado de inspiração, idéias criativas, e vontade de servir a humanidade com coisas que tornam o dia-a-dia cada vez mais simples, sirvam de fundação para os maiores avanços tecnológicos dos nossos tempos.
Do desejo de ter um mundo melhor após a guerra, à necessidade de melhor armazenar e recuperar informações, até à vontade de dar acesso à computação a um público mais abrangente, deu-se espaço à criação de interfaces do utilizador cada vez mais sofisticados e, consequentemente, ao desenvolvimento das tecnologias cada vez mais mais intuitivas que temos hoje.Existem três momentos principais que deram espaço à materialização da interface do utilizador tal como a conhecemos hoje:1)
As sementes da manipulação directa, ou seja, da forma intuitiva como movemos objectos num interface (como se fossem objectos físicos) em vez da manipulação usando linhas de comando (linhas de código, como eram usadas nos sistemas operativos antigos), foram plantadas nos MIT Lincoln Labs por Ivan Sutherland.
A principal inovação da interface gráfica do utilizador foi que a entrada (input de comandos) era realizada directamente, ou seja, quase que em simultâneo com a saída (output de resultados) no sistema. Essa operação directa de entrada-saída tornou a interface muito mais fácil de entender e muito mais intuitiva; a entrada (input) era feita com uma caneta leve (em semelhança das canetas Stylus que são usadas nos tablets hoje em dia), e a saída (output) era um gráfico oscilatório (em semelhança a um osciloscópio).2)
O segundo grande marco foi trazido por Doug Engelbart, técnico de radar da marinha americana, estacionado nas Ilhas Filipinas em 1945. Na biblioteca da marinha, ele encontrou uma cópia da revista Life que continha o artigo de Bush. Inspirou-se nele e teve uma visão que deu espaço à criação do mouse e do hipertexto, que foram as bases fundamentais para o desenvolvimento da web.
Levou tempo, mas ele conseguiu financiamento e começou a trabalhar no mouse. Engelbart mostrou ao mundo os resultados da sua pesquisa na sua famosa demo de 1968 (também entitulada “A ‘Mãe’ de Todos os Demos“).3) Após a demo inicial, Engelbart fez uma tournée/digressão apresentando-a a universidades e centros dedicados à pesquisa e desenvolvimento de tecnologias, tendo numa das suas apresentações parado na Universidade de Utah, onde Sutherland acabava de se juntar ao corpo docente.
Na audiência, estava Alan Kay, um aluno de doutoramento de Sutherland, que também sonhava com o computador pessoal. Depois de terminar o doutorado, Kay muda-se para o Stanford AI Lab e, mais tarde, para a Xerox PARC, onde ele expande sua visão: um Dynabook – o computador pessoal para crianças.
Com esta visão na mão, Kay e seus colegas na Xerox PARC começam a construir a fundação da interface do utilizador e anos depois, deram espaço à criação do Star (sistema de computação criado na Xerox), o primeiro sistema comercial a incorporar várias tecnologias que desde então se tornaram padrão em todos os PCs (display com bitmap, interface gráfica à base de janelas, ícones, ficheiros, mouse com dois botões, etc.).
Esta sequência de acontecimentos, embora no momento pudessem aparentar desconectadas, em retrospectiva têm um ar de intencionalidade. Da descoberta “ao acaso” de um artigo num magazine por um técnico da marinha americana nas Filipinas, ao encontro, anos mais tarde, do técnico com o autor do artigo que o inspirou e este último inspirando também a um aluno do técnico de marinha, agora professor universitário, faz-nos pensar nas várias formas em que variações destas coincidências podem estar a acontecer nas nossas próprias vidas, a todo momento.
O Star foi lançado aproximadamente 40 anos após a visão de Vannever Bush, 30 anos depois da invenção do compilador de Grace Hopper, 20 anos depois do primeiro sistema de Doug Engelbart entrar em funcionamento e 10 anos depois de Alan Kay começar a trabalhar no seu Dynabook.Isto é um exemplo daquilo a que Bill Buxton chama “O longo nariz da Invenção”.
Ele afirma que as primeiras idéias por detrás de novos paradigmas de tecnologias são “plantados” décadas antes da sua adopção comercial. E isto acontece não só com as tecnologias mas em todas as áreas, incluindo as nossas vidas: tudo o que cada um de nós é hoje, é resultado dos actos e idéias que plantamos, nutrimos, e ultimamente, colhemos a cada dia que passa.Mas chega de história por hoje. Na próxima publicação, abordararei assuntos mais práticos.Até já.
Referências
Fazem já mais de 4 anos desde a primeira vez que notei que faltava algo (UX Design) numa aplicação em que eu e uns amigos estávamos a trabalhar. Desenhamos o projecto desde o primeiro rabisco até à notificação de “operação efectuada com sucesso”. A aplicação funcionava bem. Estávamos muito orgulhosos de nós mesmos.
Só tinha um porém: nós éramos os únicosque conseguiamutilizar o aplicativo do início ao fim sem complicações. Sim, é isso que estás a imaginar: “viciámos a aplicação”. Projectamos uma má experiência para o utilizador final.Para não repetir o erro, pus-me a pesquisar. Lí artigos e assisti vídeos na internet. Mesmo tendo aprendido muito, esta procura ao aleatório tem sempre as suas limitações.
Então, decidi aprender de uma forma mais formal. Inscrevi-me no Coursera, uma plataforma de cursos online. Inscrevi-me para uma especialização em IHC – Interação Humano-Computador. A mesma lecionada por Scott Klemmer, professor de Ciências Cognitivas, Engenharia e Ciências da Computação na UC San Diego.
E para fazer jus ao dito popular “partilhando é que se aprende”, decidi criar um espaço onde passarei a partilhar algumas das lições mais valiosas destas aulas e de pesquisas paralelas que irei fazendo.Agora, vamos ao prato principal de hoje: O que é Interação Humano-Computador (IHC)?IHC (ou HCI do Inglês Human Computer Interations) não é de fácil percepção logo de primeira. O conceito é simples: é o processo de concepção, implementação e avaliação de interfaces do utilizador.
Neste processo, o ser humano é a peça mais importante de todo o sistema. Depois vem o computador que é a máquina que executa o sistema. No final vem a interface, que traduz o sistema de forma simplificada para o utilizador (o ser humano). Ou por outra, é uma matéria interdisciplinar que relaciona a ciência da computação, artes, design, ergonomia, psicologia, sociologia, semiótica, linguística e áreas afins para proporcionar a melhor experiência ao utilizador.
IHC é chamado de muitas outras formas tais como: UCD (User Centered Design), MMI (Man-Machine Interface), HMI (Human-Machine Interface), OMI (Operator-Machine Interface), UID (User Interface Design) e HF (Human Factors).A área de IHC como é conhecida hoje começou com Donald Norman, psicólogo cognitivo, que trabalhou o conceito de usabilidade.
Em IHC significa simplesmente projectar sistemas fáceis de aprender e usar. Para projectar sistemas com boa usabilidade, os profissionais da área precisam de entender os factores psicológicos, ergonómicos, organizacionais, sociais entre outros, que determinam como as pessoas operam e fazem uso dos computadores efectivamente.
Depois traduzir este entendimento no desenvolvimento de ferramentas e técnicas que ajudem o utilizador a interagir com o sistema com eficiência, efectividade e segurança.Pondo de outra forma, quanto menos “clicks” forem necessários para chegar à informação que a pessoa precisa, mais chances há dela voltar a usar o aplicativo. Quanto menos conhecimento técnico a pessoa tiver que ter pra usar o produto, ou por outra, quanto menos “massada”, quanto mais intuitivo for um objecto de se usar, melhor ele é.
Simples não é? Então por que é tão difícil chegar ao “simples”?Muitas vezes, nós como programadores, ficamos tão envolvidos nas nossas formas “particulares” e “técnicas” de fazer as coisas que esquecemos que no fim do dia, quem vai usar as coisas que produzimos, simplesmente quer sair de A para B da forma mais fácil e rápida possível e devemos ter sempre a sensibilidade de que nem todo mundo é programador e o que é fácil e rápido pra nós, nem sempre é fácil e rápido para o utilizador comum.
É aqui onde está a chave: as interações devem ser simples e isto é a base do bom design.Durante a aula de Introdução o professor Klemmer sublinha que bom design. Em interfaces do utilizador, traz alegria às pessoas. A ajuda-lhes a fazer o que lhes interessa, a conectar com as pessoas que elas gostam.
A conhecer as tarefas, os objectivos e valores que as guiam. Já mau design custa tempo, dinheiro e em alguns casos até vidas, quando se refere aos aparelhos usados pelos médicos, acidentes causados por pilotos de avião e até desastres nucleares.
Felizmente estes problemas podem ser evitados seguindo procedimentos simples de consistência e feedback aprendidos em IHC.Nas próximas publicações partilharei como implementar o “bom design” em nossos projectos.
Até breve.
Referências
1. Interação Humano-Computador, Wikipédia
2.Usabilidade e Interação Humano-Computador, Certificação Digital Nº 0610421/CA3.Curso: Human-Computer Interaction, Coursera
