Avaliação de Interface - Alice

O que é o Alice?
Alice é um inovador ambiente 3D de programação, desenvolvido pela Sun, cujo objetivo é introduzir conceitos computacionais à pessoas que ainda não possuem conhecimento na área. O objetivo é conduzir de forma menos frustrante o primeiro contato do usuário com o mundo da programação.

Avaliação
Apesar de apresentar um conceito muito interessante, o software Alice, como todos os outros softwares do mercado, possui alguns problemas em sua interface. Esse documento visa analisar tais problemas de forma crítica e construtiva.

Estrutura
Por esse não ser um documento exclusivamente sobre avaliação heurística, resolvemos abordar os pontos encontrados de forma a privilegiar tanto aqueles que possuem conhecimentos em Interfaces, quanto aqueles que não o possuem. Para isso, criamos a seguinte estrutura:
Inicialmente exibimos algumas telas com problemas de interface e anexamos um texto detalhado sobre o problema encontrado. Aqui não identificamos as heurísticas violadas, apenas apresentamos o problema.
Num segundo momento, usamos os conceitos de heurísticas de avaliação para elucidar as faltas encontradas.

Análise:

Seguem alguns pontos que não obedeceram boas práticas que devem ser seguidas a fim de se chegar em uma interface limpa, intuitiva, funcional e agradável ao usuário:

Esta primeira imagem faz referência a um dos tutoriais disponíveis no sistema Alice, para que o usuário aprenda alguns dos conceitos básicos envolvidos no aplicativo. O tutorial esta explicando que, ao fim da animação, o usuário deve clicar no botão "X". Entretanto, a janela está na frente da instrução, de forma a impedir que o usuário possa lê-la. Assim, o usuário deve clicar no botão "X" para que, depois de fechar a janela, leia a instrução que dizia exatamente os passos que ele acabou de fazer. Outro fator dificultante é que, ao clicar na parte amarela da tela (a instrução), está não passa a ser exibida por completo. A tela "World Running..." continua a ser o destaque.

Além disso, não há nenhuma visibilidade do status do sistema, fica-se em dúvida se a animação chegou ao fim ou não.

Neste segundo caso, temos uma questão que pode até passar despercebida por quem usa, mas deveria ser repensada por quem desenvolveu. O propósito do aplicativo é ser uma ferramenta que introduza o usuário à computação. Logo, podemos concluir que grande parte das pessoas que irão usar o sistema não possuem conhecimento prévio sobre o assunto. Nesta tela, podemos ver dialetos característicos da área (principalmente de linguagens orientadas a objetos) como "propriedades", "métodos", "funções", "lógica booleana", "parâmetros", "variáveis"... Isso certamente deixa os usuários confusos e tende a assustá-los.

Aqui temos um exemplo de falta de informação em uma funcionalidade. O ícone marcado em vermelho serve de "Clipboard". O usuário arrasta qualquer objeto para esse ícone, que funcionará como uma área de transferência. Quando necessário, o usuário pode recuperar o que ele havia arrastado anteriormente, para utilizar da forma que desejar. No entanto, não há meios de descobrir o que está nessa "memória". O usuário é obrigado a lembrar qual foi o último elemento que ele arrastou para essa área. Caso não lembre, ele deve arrastar para algum lugar, para descobrir o que era, e depois desfazer a ação, caso necessário.

As funções de desfazer e refazer não funcionam corretamente com o clipboard, ferindo a heurística de controle do usuário.

Ao desenvolver um software, programadores devem sempre ter a preocupação em manter a interface do sistema o mais limpa e intuitiva possível. Interfaces confusas podem acabar com as chances do sistema ser vastamente utilizado. Neste caso, temos uma tela extremamente complexa, até mesmo para programadores experientes. A heurística de estética e design minimalista claramente é rompida.

Aqui uma questão muito recorrente em sistemas: ausência de "help". É bem verdade que os desenvolvedores pensaram em criar tutoriais e exemplos, para que os usuários pudessem entender melhor como funciona o sistema, entretanto, essas ferramentas não excluem a necessidade de um help. Tutoriais servem para ensinar os usuários nos primeiros passos, "help" serve para ajudá-los quando enfrentam algum problema.

Alterar a resolução da tela e tamanho da janela é sempre visto com maus olhos. Pior ainda é que aparentemente nada foi alterado após essa mensagem.

Esta mensagem de erro é muito vaga e não explicita qual foi o erro. Além disso, às vezes aparece mesmo quando não há erro.

Tanto "Text Output" quanto "Error Console" levam à mesma funcionalidade.

O console apenas apresenta a mensagem de exceção do Java.

Se a funcionalidade não está implementada, não deveria estar no menu.

É difícil identificar à primeira vista qual a guia ativa.



Abaixo, podemos notar problemas que foram encontrados e as respectivas heurísticas que foram feridas em cada caso.


5ª Heurística: Prevenção de erros

Aqui listamos os problemas encontrados que feriram a heurística de número 5:

5.1 Se o usuário roda um programa no ambiente Alice e este permanece em segundo plano por muito tempo o erro acima é exibido.

Na janela de edição dos objetos, é possível ao usuário manipular o cenário, em objetos muito pequenos fica difícil de manipular os objetos.

Ao se copiar um objeto ao "Clipboard" mantendo a tecla Ctrl pressionada e recopiando o mesmo objeto do Clipboard para a tela de código mantendo ainda pressionada a tecla Ctrl, a seguinte mensagem de erro aparece:



7ª Heurística: Flexibilidade e eficiência de uso

Aqui listamos os problemas encontrados que feriram a heurística de número 7:

Quase tudo é feito pelo mouse e menus flutuantes, não há atalhos pelo teclado para inserir, modificar ou remover objetos e rotinas.

A barra de ferramentas rápida tem poucas opções.

O usuário é obrigado a remover uma rotina/objeto de cada vez.

Não se pode manipular aplicação ao se rodar um projeto. Não é possível ver o "Error Console" antes de encerrar a execução, por exemplo.

Coisas que odeio em interfaces

Durante o curso de interfaces, recebi muitas dicas de coisas a não se fazer. No entanto percebi que existem problemas muito comuns relacionados as interfaces web que poderiam ter sido evitados caso seus desenvolvedores tivessem a oportunidade de ter ouvido essas dicas. Por essa razão, resolvi dedicar este post as coisas que não suporto me deparar em interfaces web:

Surpresas!

O conceito de “Affordance”, ou seja, o que os usuários esperam fazer com um elemento, está passando longe de muitos sites. Banners disfarçados de janelas, textos que parecem links mas não são ou links em lugares inesperados enganam o usuário e atrapalham a navegação.

Como saio daqui? Onde estou?

Pior do que surpresas é o usuário se sentir perdido em uma página. Aprendi que, ao contrário de mim, os usuários “normais” preferem navegar a buscar. Por isso, qualquer coisa que dificulte a navegação do usuário pode fazer com que ele nunca mais volte a visitar o site. Alguns elementos devem estar presentes em toda página:

• o botão “Voltar” é a segunda funcionalidade mais utilizada durante a navegação na Web, perdendo apenas para os links. O botão “Voltar” do navegador só é usado se não for encontrado na página.

• um link para a página inicial é importante para os usuários que chegam através de uma página externa. Agora um link que vai para a própria página dá a sensação de ser um link quebrado ou incorreto.

• Alguma indicação de onde o usuário está, pois nem todos os usuários sabem como pararam ali nem tem boa memória.

• É importante que todo o conteúdo crítico e opções de navegação estejam visíveis no topo da página, evitando o uso do scroll.

Abuso do Flash!

Nada mais irritante do que um site todo feito em flash. É comum encontrar sites que usam flash no menu, flash no banner, flash em todos os lugares! Além de demorar anos para carregar a página (o “carregando...” bonitinho não melhora essa sensação), a usabilidade cai bastante: o CTRL+F não funciona, o botão direito também não e o flash precisa ser instalado (mas nem todos os sites feitos em flash avisam sobre a falta dele). Volte e meia preciso dar assistência a parentes que reclamam de páginas que não funcionam mas, na verdade, faltava o tal plugin Flash ser instalado.

Micro-imagens

Imagens em baixa resolução ou muito pequenas, em que não é possível diferenciar pessoas de manchas, devem no mínimo oferecer uma opção de zoom decente. Pior que isso é esperar a página carregar por anos uma imagenzinha inofensiva e descobrirmos que a pessoa apenas redimensionou a imagem sem reduzir seu tamanho, que passa de Mb! Encontro muito isso em sites de imobiliárias e até no site da comunidade do IC que, se eu colocar uma foto de tamanho gigante no perfil, nunca mais nenhum amigo vai conseguir ver meu rosto.

Buscas mal feitas

Vimos nas aulas que usuários experientes estão sempre usando atalhos para acessar diretamente o que lhes interessa. Mas e quando a busca do site é mal feita?

Por exemplo, alguns sites ainda fazem a busca exatamente pelo valor digitado. Recentemente queria encontrar uma notícia e acabei encontrando esse problema... E agora, escrevo com a nova ou com a velha gramática? Coloco hífen, espaços, acentos?

Outro problema são as buscas que precisam de milhares de filtros, como as de sites de imobiliárias de Barão Geraldo e que, ao final, não retornam nenhum resultado. Uma interface melhor construída pouparia o usuário de perder seu tempo com algo que não o leva para lugar nenhum.

Banners

Não condeno quem quer ganhar um dinheiro com a Web, mas todos temos alergia/pavor/medo de banners: estão sempre mal posicionados, aglomerados e inconvenientes. Existem aqueles banners que funcionam em apenas um navegador e em outro lugar adquirem a forma de monstros intrusivos, em cima do conteúdo e desalinhados, como os banners deformados do portal Terra. No orkut, por exemplo, após uma recente mudança, o box de amigos foi substituído por um box de propaganda: isso deixou os amigos, objetivo de um site de relacionamentos, em segundo plano. ;(

Incompatibilidades

Não é novidade que o Internet Explorer vem perdendo espaço para outros navegadores como Firefox, Chrome, Opera e tantos outros. Mesmo assim ainda encontro sites compatíveis apenas com IE, excluindo uma parte significativa de visitantes (como eu =/) . Por exemplo, odeio as notícias que o site do Terra oferece apenas no formato de vídeo. Não existe uma opção de texto para as pessoas que não querem esperar o vídeo ser carregado ou que não gostam de ser obrigadas a assistir a publicidade que aparece antes do vídeo ou que não tem uma caixa de som do lado (nem legendados os vídeos são). Além disso não é possível ver os vídeos quando uso Linux, pois é um SO incompatível, apesar de muito usado.

Gostos duvidosos

Ao contrário do que muitos pensam, testes indicam que o velho contraste preto-e-branco prende a atenção por menos tempo do que um contraste com cores. Mas ao escolher as cores que formarão o contraste, alguns sites não preocupam-se se estas são vistas por todos, nem qual tipo de mensagem que estas cores estão passando. O mesmo acontece com ícones, que podem ter várias interpretações. Um problema que ocorre nos sites é que muitos são feitos usando somente cores ou ícones para o reconhecimento, mas deve sempre haver uma parte textual como alternativa.

Espero que as dicas ajudem e apenas recapitulando:

1) Grande parte das usuários ainda não tem internet banda larga (nem paciência)

2) Algumas pessoas não usam Windows, muito menos IE (teste seu site em outros navegadores)

3) Nem todos veem/pensam de modo igual (torne seu site o mais acessível possível)

4) Usuários normais navegam, não buscam (lembre-se dos botões básicos)

Design de Interfaces Mobile

Introdução:

Este post tem como objetivo fazer um overview sobre design de interfaces mobile.
Aproveitando o pouco de expenriencia que tenho na área e me embasando nos conceitos aprendidos em aula, cito um pouco das peculiaridades desse ramo da área de IHC.
Começo exemplificando as dificuldades em se desenvolver uma interface mobile, sigo com um guideline que intui relacionar a teoria da materia com o universo mobile e concluo com alguns links exemplificando os modelos propostos.


Desafio:

O design de interfaces para dispositvos moveis esbarra nestas 5 pricipais difculdades:
- Um vasto numero de dispositivos;
- Limites de entrada/saida de informação;
- Falta de orientação e recursos;
- Falta de padronização;

Este conjunto de caracterísitcas figura o universo de se criar uma interface mobile. Exemplificando um pouco o problema, nos temos aqui duas interfaces distintas de dispositovs mobile:


Naturalmente que ambos os aparelhos tem recursos, controles e características diferentes. E mesmo sendo tão diferentes, estes aparelhos podem utilizar de sua aplicação. O grande desafio no design de interfaces mobile é permitir que diferentes tipos de usuarios, desde o expert até o usuario mais novo, tenham acesso de maneira clara e objetiva as funcionalidades de sua aplicação.


Guideline:

Baseado na minha experiência na área - Mobile Developer - e nos conceitos vistos em aula, tento sumarizar alguns pontos de IHC com um foco maior no universo mobile, espero que gostem:

Primeiramente, vou falar dos conceitos que são, em sua essência, os mesmos tanto para desktops quanto para dispositivos mobile

Habilitar atalhos para usuarios frequentes:
Conforme a frequência de uso aumenta o usuario deseja reduzir o numero de interações com a interface. Por isso, reduzir o numero de operações para a tarefas frequentes é muito importante para aumentar a usabilidade do usuário.

Oferecer resposta do sistema(feedback):
Para toda ação do usuario, deve existir algum sistema de feedback, seja ele um beep ao pressionar uma tecla ou uma mensagem de erro a uma entrada invalida. Esta resposta deve ser compreensível ao usuario. Por exemplo, a mensagem "The page can not be found" é muito mais amigável a maiorria dos usuarios que "HTTP 404 Error".

Desenvolver dialogos de interação finitos:
Sequências de ações devem ser organizadas em grupos com começo, meio e fim. Usuarios devem ter a satisfação do cumprimento e conlusão da tarefa.

A interface deve obedecer ao usuario:
Usuarios querem estar acima da aplicação e ter respostas para suas ações, em vez de sentirem que o sistema os está controlando. Aplicações devem ser desenvolvidas de tal maneira que o usuario inicie uma ação e o sistema reponda a esta.

Agora destaco alguns conceitos que de alguma forma são diferentes e/ou tem peculiaridades importantes ao qual deve-se atentar ao se desenvolver uma interface mobile:

Consistência:
A consistência tem dimensões maiores em aplicações mobile: a consistência deve estar presnte entre multiplas plataformas e dispositivos para uma mesma aplicação. O usuario pode querer transferir documentos de seu Desktop para seu PDA, nesta situação a aplicação deve manter a consistência entre as plataformas.

Reversão de Ações:
Permitir que usuarios revertam suas ações é extremamente difícil para aplicações mobile devido a pouca memoria e poder de processamento dos dispositivos. Mesmo se os estados dos eventos são carregados em estações fixas mais poderosas, a perda de conectividade torna este recurso extremamente complexo.

Prevenção de erros:
É o mesmo conceito aplicado a desktops, no entanto deve ser levado em conta o design físico do dispositivo. Como o ritmo de interação é mais rapido em dispositivos móveis, a proximidade dos botões e o tamanho do aparelho podem provocar muitos problemas em potencial.

Reduzir as informações a serem memorizadas pelo usuario:
Aplicações devem ser desenvolvidas exigindo pouca memorização por parte do usuário. Neste cenário o usuario está presente a maiores distrações do que em um desktop. Pode ser também que a aplicação mobile nãa seja o foco pricipal do usuario e este não deseje parar sua tarefa pricipal para se concentrar no dispositivo. Alarmes e controles sonoros podem auxiliar esta tarefa.

Por ultimo discorro alguns conceitos que, na minha opinião, tem maior enfase no design de interfaces mobile do que no design de interfaces normais:

Desenvolver para multiplos contextos:
Diferentemente de desktops, em que sem tem um cenário de uso relativamente constante, mobile devices podem ser usados em diferentes tipos de situações vivenciadas pelo usuario. O desenvolvendor deve estar atento a isto. Por exemplo, um determinado som poder ser incoveniente em uma biblioteca. Ou determinada fonte pode ser legível no escritório, mas não no metro quando o mesmo usuario está voltando do trabalho. A aplicação deve ser desenvolvida levando em conta a dinamicidade do dispositivos.

Desenvolver para dispositivos pequenos:
A tecnologia continua a avançar e cada vez mais existe a miniaturização dos dispositivos, desde celulares até braceletes, anéis e chaves. Inovar e modificar a maneira como o usuario interage com esses dispositivos se faz necessário para contornar as limitações físicas dos aparelhos. Comamdos de voz e touch-screen são exmplos de possíveis soluções para esse problema.

Minimizar a atenção necessária do usuario:
Como já dito aqui anteriormente, a aplicação móvel pode não ser o foco principal do usuario. Neste cenário deve ser possível que o usuario utilize sua aplicação com a menos atenção possível. Avisos sonoros ou táteis podem ser mais viáeis que mensgens no display para alguém está usando seu PDA em uma apresentção, por exemplo.

Otimizar o tempo e a recuperação de dados:
Devido ao contexto em que mobile devices são usados, não é interessante ao usuario esperar muito tempo na inicialização de uma aplicação. Mais que isso, quando o tempo é crítico é muito importante que o usuario possa salvar seus dados em pouco tempo e sem perda da informação.

Desenvolver interações "Top Down"
Mobile devices dispõe de pequenos displays para apresentar a informação. Utilizar do "scroll" para listar uma lista muito grande de ppções pode ser uma tarefa extremamente penosa para o usuario. Portanto deve se planejar a aplicação de forma a hierarquizar a informação. O menu do Ipod é um bom exemplo desse conceito.

Perimitir personalização:
Enquanto desktops podem ser utilizados por varios usuarios, dispositivos móveis são, por natureza, mais pessoais. É importante que o usuario possa modificar a aplicação a seu gosto. Seja modificando padrões, modos de exibição ou sonoridade, o usuario deve ter a liberdade de personalizar a aplicação a "sua cara".

O design estético deve ser levado em conta:
Além da funcionalidade e da usabilidade, existem outros fatores importantes no sucesso de uma interface mobile. Dentre estes destaco a estética. A estética pode trazer respostas interessantes por parte da experiência do usuario. Quando a usabilidade e a funcionalidade de dois dispositovs concorrentes são iguais, a estética se sobresai e dita qual interface terá mais sucesso.


Links:

• Best Practices - Pagina da W3C destinada ao desenvolvimento mobile web.
• 6 Tips for Designing Mobile Interfaces - 6 dicas interessantes sobre o design de interfaces mobile
• Challenges of Interface Design for Mobile Devices - Um post que fala sobre o desafio de desnvolver interfaces mobile.
• Mobilize, Don’t Miniaturize - Um conceito importante sobre adaptação de interfaces web para dispositivos móveis.
• Looking for good examples of Mobile Interfaces - Alguns exemplos de mobile interfaces.
• Para não pronlogar ainda mais este post, coloco este link onde você pode encontrar muitos exemplos de páginas criadas para mobile devices.

Claro que o foco aqui foi dado além das paginas web, mas esses links são bons exemplos do universo mobile e é o que nos cabe vislumbrar via browser - visto que as aplicações em si não podem ser visualizadas de forma equivalente via desktop. No entanto, pode-se notar muito dos conceitos aqui citados nestas páginas Wap. A hierarquização da informação é um bom exemplo disso.



É isso, obrigado e até mais.

Conceitos de IHC na prática!

Vou contar aqui um depoimento muito positivo sobre uma aplicação prática que a disciplina propiciou em meu estágio.

Há alguns meses fizemos a entrega de um software. Tratava-se de um sistema cuja fase de desenvolvimento foi bastante tortuosa, pois passou por muitas pessoas e ficou um tempo parado. Restaram muitas telas e códigos legados, e, obviamente, a interface foi um dos pontos afetados por esses fatores.

A questão era que o público alvo do sistema tratava-se de pessoas com pouco (ou nenhum) conhecimento de informática. Com isso, começamos a receber alguns e-mails, ora pedindo por ajuda, ora sugerindo algumas modificações a fim de que a experiência deles com o software fosse mais agradável.

Foi aí que decidimos dar uma maior atenção à interface do programa.
Juntamos todas as sugestões, fizemos algumas reuniões de avaliação heurística e submetemos alguns protótipos aos próprios usuários, para que pudéssemos ouvir algumas avaliações mais informais.

A experiência se demonstrou muito válida! Poucas semanas depois da entrega da nova versão, recebemos alguns e-mails dos usuários (inclusive usuários que sequer haviam mandado e-mail com pedidos de ajuda ou sugestões de alteração), dizendo que o sistema estava muito mais fácil e agradável.

Fica aí a experiência. Focamos um pouco mais no usuário e o retorno foi realmente interessante.


Valeu a pena!