1_TCUID v24r10a p69 (1).pdf

03/10/2024 Task-Centered User Interface Design A Practical Introduction Clayton Lewis, John Rieman © 1993, 1994 by Clayton Lewis and John Rieman. Slides PPTX realizados por Prof...

03/10/2024 Task-Centered User Interface Design A Practical Introduction Clayton Lewis, John Rieman © 1993, 1994 by Clayton Lewis and John Rieman. Slides PPTX realizados por Prof Pedro Faria Lopes Prof Pedro Figueiredo Santana Aviso Nenhuma parte das aulas desta UC pode ser gravada, nem em sala de aula nem à distância, em nenhum formato ou suporte. 1 Tópicos Task-Centered User Interface Design - A Practical Introduction Ch1, Chapter 1. Task-Centered Design Ch2, Chapter 2. Getting to Know Users and Their Tasks Ch3, Chapter 3. Creating the Initial Design Ch4, Chapter 4. Evaluating the Design Without Users Ch5, Chapter 5. Testing the Design With Users Ch6, Chapter 6. User Interface Management and Prototyping Systems Ch7, Chapter 7. The Extended Interface Índice actualizado ao longo das aulas Observações: para reduzir perturbação na percepção, pede-se que dúvidas e questões sejam anotadas para colocar no fim da exposição. Esta abordagem permite também responder de forma agregada a questões que, pela sua natureza, sejam semelhantes na forma e no conteúdo. Nenhuma parte das aulas pode ser gravada 2 2 1  03/10/2024 Task-Centered User Interface Design A Practical Introduction Chapter 1. Task-Centered Design Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 3 Introdução, resumo do livro Aborda o problema de como desenhar sistemas focados na tarefa e no utilizador Descobrir quem vai utilizar o sistema e para fazer o quê análise do utilizador e da tarefa O sistema tem de se integrar no mundo em que o utilizador trabalha hardware, software, processos computacionais e humanos normalmente estas necessidades não são consideradas nas análises de requisitos tradicionais Conhecer o background dos utilizadores a que tipo de interfaces estão habituados no seu local de trabalho A equipa de desenho e os utilizadores devem estar em contacto algo normalmente difícil mas que deve ser procurado Nenhuma parte das aulas pode ser gravada 4 4 2  03/10/2024 tarefas representativas Escolher tarefas representativas da utilização do sistema: Tarefas reais, capazes de cobrir todas as funcionalidades a implementar Devem-se obter os materiais reais utilizados para análise detalhada Tarefas simples úteis para uma fase inicial do desenho Tarefas complexas para garantir que cobrimos interações extensas com o sistema: interações reais! Nenhuma parte das aulas pode ser gravada 5 5 intelligent borrowing Tentar utilizar conceitos/ferramenta existentes: Conceitos para paradigmas de interação completos e para os próprios controlos de baixo nível (até para os manuais) Reinventar a roda tem um elevado risco vamos cometer erros já resolvidos, aumenta os custos sem necessidade Ao reutilizar os utilizadores sentem-se confortáveis com a familiaridade que sentem com o equipamento/software (e.g., spreasheets) Pode até ser preferível garantir familiaridade Em vez de inventar interfaces eventualmente mais eficientes ver o problema como um todo reduzir custos e riscos Nenhuma parte das aulas pode ser gravada 6 6 3  03/10/2024 análise inicial Desenhar um esboço da interface em papel (fácil, barato e rápido): low fidelity Evitar a programação para não haver um compromisso que nos impede de alterar o design: o custo de programar é grande, e alterar depois majora custo Novas features? Verifique sobre que funcionalidade requerida para o sistema resolve; se não houver, então o melhor é não adicionar essa feature A nossa interface vai funcionar? Avaliar: Evitar ir já para testes com utilizadores: pode ser caro e lento Primeiro remover erros grosseiros antes de chegar aos testers Métodos como o GOMS (Goals, Operators, Methods, Selection) permitem prever tempo de execução das tarefas com base nos keystrokes, movimentos do rato e decisões; assim identificamos tarefas problemáticas O cognitive walkthrough permite, imaginado o utilizador a interagir com o sistema, detetar potenciais dificuldades que este sentirá a executar as tarefas Nenhuma parte das aulas pode ser gravada 7 7 protótipo Depois de eliminar erros grosseiros pode então finalmente criar um mockup ou um protótipo do sistema, por exemplo com cartões Focar nos aspetos essenciais para as tarefas, não é possível prototipar tudo em tempo útil; certos detalhes são isso mesmo, detalhes Usar o wizard of oz para simular respostas do sistema (Facilitator / Computer) temos feedback a muito baixo custo A seguir testar com testers / utilizadores gravar e solicitar que façam think aloud No think aloud (espontâneo) temos grande densidade de feedback útil para melhorar a interface Nenhuma parte das aulas pode ser gravada 8 8 4  03/10/2024 após o teste Iterar (alterar, avaliar, testar, várias vezes, vários ciclos) até resultados de usabilidade serem atingidos ou custos/tempo definidos para o projeto tenham sido atingidos O objetivo dos testes é melhorar e não provar que o sistema funciona Queremos é que funcione o melhor possível, funcionar +/- ou mal é garantido Cada iteração melhora o sistema, logo quantas mais melhor Depois construir a interface, que deve estar preparada para a mudança (modularização / abstração) Os utilizadores e as tarefas mudam Manter o contacto com os utilizadores após o sistema ser deployed Assim pode-se alterar quando necessário, oportunidades de melhorias Nenhuma parte das aulas pode ser gravada 9 9 Task-Centered User Interface Design A Practical Introduction Chapter 2. Getting to Know Users and Their Tasks Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 10 5  03/10/2024 Parte 1 – introdução Como conhecer o utilizador e as tarefas reais e a sua relevância para o desenho de sistemas foco em análises de requisitos com pessoas concretas e tarefas concretas em vez de tarefas e atores genéricos (tradicional) porque … … pemite encontrar o que realmente é importante … … fornecer ao utilizador na ferramenta que estamos a desenvolver evitar features espetaculares esperando que venham a ser úteis ser médio, focar no aqui e agora, no outro ferramentas que se tornaram úteis de forma inesperada começaram por ser úteis de alguma forma esperada (e.g., folhas de cálculo) Nenhuma parte das aulas pode ser gravada 11 11 recorrer a utilizadores reais começar por procurar potenciais utilizadores reais (pessoas concretas) se não encontrarmos utilizadores então temos um problema pois provavelmente ninguém irá usar o nosso sistema... … “isto não é um problema porque o sistema é para ser usado por toda a gente” acaba em desastre porque: tipicamente, algo bom para todos acaba por não ser bom para ninguém (e.g., linguagem do utilizador, diálogo natural, clutter visual) temos demasiado background sobre a ferramenta, logo não somos bons representantes de utilizadores reais mesmo que cliente/utilizador indique apenas requisitos gerais devemos procurar mais a fundo porque … … temos interesse em que o sistema seja de facto utilizado Nenhuma parte das aulas pode ser gravada 12 12 6  03/10/2024 analisar tarefas reais Tendo os utilizadores, temos de pensar exemplos de tarefas reais que os utilizadores pretendam realizar com a ferramenta Tarefas devem ser muito específicas para nos obrigar a pensar nos detalhes certos: “O Silva soma as várias entradas do orçamento da empresa mar azul e...) Exemplo: lista de ficheiros com número de caracteres muito pequeno para nomes dos ficheiros, não permite pesquisa por parte do utilizador … … falha causada pelo designer que nunca testou com nomes de ficheiros concretos/reais. Tarefas descritas desacopladas dos detalhes da interface (menu vs botões) para podermos comparar várias possibilidades. Nenhuma parte das aulas pode ser gravada 13 13 análise de requisitos Uma tarefa deve ser um trabalho completo para pensarmos como é que os vários elementos da interface têm de trabalhar em conjunto / em sequência exemplo: “ir ao menu, escolher vídeos, seleccionar o vídeo, voltar ao menu, escolher músicas, seleccionar música” vs “estar a ver um vídeo e depois ouvir uma música” Necessidade de descrever trabalhos completos difere do tradicional, onde se procura descobrir elementos atómicos, o que é insuficiente pois apenas garante que o sistema funciona por partes incrementalmente! ponderar sempre a sua percepção do problema com a do utilizador estabelecer diálogo “calçar os sapatos do utilizador” Nenhuma parte das aulas pode ser gravada 14 14 7  03/10/2024 Parte 2 – participatory design slides anteriores assumem uma distinção entre users e designers vamos agora analisar uma alternativa denominada de participatory design: design com os utilizadores em vez de para os utilizadores Desta forma prentede-se criar sistemas realmente úteis para o utilizador Surge na Europa em consequência dos trabalhadores terem mais a dizer na tomada de decisão do que nos EUA Há três atributos principais no participatory design: O objetivo da atividade é melhorar a vida dos trabalhadores A atividade é colaborativa com objetivos e decisões negociadas A atividade é iterativa ao testar as ideias na prática e melhorar a partir daí Nenhuma parte das aulas pode ser gravada 15 15 participatory design: desafios aplicação prática complicada mesmo em projetos in-house pois existem lugares demarcados e o designer normalmente é um expert contratado Mais complicado no caso comercial porque até que ponto o designer terá interesse em melhorar a vida de um empregado de outra empresa? Se os utilizadores participarem no design, o designer também ganha, pois aumenta probabilidade de aceitação do produto que está a desenvolver Uma forma de convencer os utilizadores a participarem é dando-lhes a possibilidade de se envolverem / influenciarem o design... Nenhuma parte das aulas pode ser gravada 16 16 8  03/10/2024 Como utilizar tarefas no design (1) Primeiro prepara-se a descrição das tarefas e circula-se pelos utilizadores: esta descrição deve ser não específica a um design Incorporam-se correções, clarificações e sugestões nas descrições escritas das tarefas Desenha-se um esboço da interface e produzem-se cenários de execução da tarefa com a interface desenhada Cenários podem ser representados com storyboards (sequências de esboços a mostrar como o ecrã vai mudando ao longo da interação e quais a ações escolhidas pelo utilizador na tarefa) Estes storyboards são apresentados ao utilizador permitindo que este veja o sistema no contexto de tarefas reais em vez de simples listas de botões Nenhuma parte das aulas pode ser gravada 17 17 Como utilizar tarefas no design (2) Cenários têm de fazer sentido como um todo evita perder-se tempo em argumentações abstratas os cenários ajudam a definir os contextos, mas não nos podemos limitar a responder aos exemplos todos de tarefas … … temos de analisar e tentar generalizar; mas pelo menos já sabemos que o sistema vai pelo menos funcionar para um conjunto significativo de tarefas Nenhuma parte das aulas pode ser gravada 18 18 9  03/10/2024 Como utilizar tarefas no design Design centrado na tarefa deve ser integrado nos métodos tradicionais de engenharia de software, como o modelo waterfall: análise de requisitos -> especificação -> design -> implementação -> integração -> manutenção O waterfall original assume que cada passo precede o seguinte e há apenas uma direção, não permite a necessidade de iterar em face de feedback do utilizador Hoje aceita-se que se pode repetir passos anteriores Ir atrás é essencial no design centrado nas tarefas porque se baseia muito em esquiços e protótipos que têm de ser validados e corrigidos iterativamente Análise de requisitos pode incluir o task-centred design recorrendo a tarefas completas, reais e detalhadas, em vez de descrições abstratas e parciais Especificações podem incluir descrições das tarefas pois isso vai ajudar os clientes a compreenderem o que nós pretendemos implementar e forçar que as especificações tenham em conta tarefas completas e não apenas isoladas Nenhuma parte das aulas pode ser gravada 19 19 Task-Centered User Interface Design A Practical Introduction Chapter 3. Creating the Initial Design Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 20 10  03/10/2024 Intelligent borrowing (1) Basear-se no trabalho de outros porque: As nossas ideias provavelmente são piores do que já existe em termos de interfaces (resultado de muitas iterações anteriores) Ao usarmos algo que existe é provável que o utilizador se sinta mais familiarizado (menor curva de aprendizagem) Poupa-nos tempo e custos de implementação, desenho e manutenção (poupamos várias iterações) Exemplo: uso de guidelines do Windows / Mac (e.g., estilo de scroll bars familiares, implementados e testados, basta utilizar) Analisar se não estamos a infringir leis de copyright Nenhuma parte das aulas pode ser gravada 21 21 Intelligent borrowing (2) Para além de toolkits, devem-se aproveitar aplicações existentes. Exemplo, o uso de spreadsheets (e.g., Excel) para realização de simulações numéricas: Já trazem várias funcionalidades que teriam ser ser implementadas; Têm funções que vão para além do necessário (e.g., gráficos); Já integram com outros software, por exemplo para importar dados; Apresentam uma interface já conhecida para os utilizadores; Preparadas para múltiplas plataformas (e.g., drivers para impressoras). Nenhuma parte das aulas pode ser gravada 22 22 11  03/10/2024 Intelligent borrowing (3) Se achamos que fizemos toda a cópia possível devemos: Tentar copiar novamente (falando com outras pessoas); Garantir que o que falta implementar é de facto importante … … pois a inovação é cara, lenta e arriscada; Aplicar o task-oriented design para as novas features. Se existem restrições no uso de toolkits existentes (e.g., hardware específico): deve-se procurar uma alternativa pois … … pode não compensar o esforço/custo de se criar um “one-of-a-kind”; caso contrário, deve-se garantir prever os custos extras (potencialmente elevados). Nenhuma parte das aulas pode ser gravada 23 23 Intelligent borrowing (4) Copiar técnicas de interação de sistemas existentes Obriga a conhecer-se bem as aplicações de topo procurar, usar e analisar Comparar o que pretendemos com o que já existe Obriga também a perceber o PORQUÊ de uma técnica escolhida em vez de outra Saber o PORQUÊ permite-nos saber quando aplicar como generalizar Exemplos páginas seguintes Nenhuma parte das aulas pode ser gravada 24 24 12  03/10/2024 Tipos de “PORQUÊ” (1) Geométricos e de movimento: acertar em objetos pequenos é mais difícil; movimentos de rato longos são mais lentos; usar mais teclas é mais lento; trocar de rato para teclado é lento. Memória: mais fácil reconhecer do que lembrar; apresentar informação essencial / principal (pode minimizar user memory load); agregar elementos de informação que estejam relacionados. Clustering, agrupamento lógico / coerente Nenhuma parte das aulas pode ser gravada 25 25 Tipos de “PORQUÊ” (2) Resolução de problemas: utilizar linguagem do utilizador; dizer quando a tarefa está concluída; permitir voltar atrás quando se engana. Atenção: alterações grandes no ecrã atraem a atenção; informação junto onde o user está olhar é mais provável ser lida; sinais áudio não são tão fáceis de ignorar. Nenhuma parte das aulas pode ser gravada 26 26 13  03/10/2024 Tipos de “PORQUÊ” (3) Convenção: seguir convenções que passaram o teste do tempo para facilitar a vida do utilizador; ideias novas podem apresentar problemas difíceis de antecipar, e por isso podem ser caros de resolver, em tempo e financeiramente. Diversidade: acessibilidade varia de utilizador para utilizador; devemos fornecer mais do que uma forma de aceder a uma função, exemplos dos shortcuts. Nenhuma parte das aulas pode ser gravada 27 27 Princípios de design gráfico (1) Clustering: elementos semelhantes agrupados e separados dos outros grupos pois … … facilita a pesquisa e ajuda o user a aprender a estrutura. Visibility reflects usefulness: tornar visível o que é mais frequente usar; deixar mais escondido o acesso a comandos utilizados menos frequentemente. Intelligent Consistency: utilizar ecrãs semelhantes para funções semelhantes pois … … assim que o user aprende com um, pode aplicar noutro: menor esforço; funções diferentes devem refletir-se em ecrãs diferentes. Cluster: “to stand or be positioned close together in a group”; agrupar coerentemente Nenhuma parte das aulas pode ser gravada 28 28 14  03/10/2024 Princípios de design gráfico (2) Color as a suplement: não codificar informação com cor pois … … 7% dos adultos é daltónico e … … a cor tem significados diferentes nas várias culturas (caso do vermelho); desenhar com cinzentos e adicionar cor apenas de forma minimalista. Reduced clutter: não colocar demasiada informação no ecrã; apenas basta um ou dois tipos de fonte / tamanho … … pois os utilizadores não vão perceber as diferenças, apenas vão ver clutter. Clutter: “a collection of things lying about in an untidy state”; desarrumação Nenhuma parte das aulas pode ser gravada 29 29 Princípios de design gráfico (3) Essencial perceber os PORQUÊ para resolver conflitos entre os princípios Nenhuma parte das aulas pode ser gravada 30 30 15  03/10/2024 Task-Centered User Interface Design A Practical Introduction Chapter 4. Evaluating the Design Without Users Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 31 avaliação vs testes Avaliar antes de testar com pessoas permite detectar erros óbvios, evita desperdiçar testers e perder reputação Por outro lado, avaliar o sistema permite detectar problemas não detectáveis com testers pois: por muitos que sejam os testers são sempre insuficientes e apenas testam a utilização pela 1ª vez, logo o ideal é ter avaliação e ter testes Técnicas para avaliação: Cognitive walkthrough (imaginar a utilização) Action analysis (analisar formalmente a utilização) Heuristic evaluation (verificar no conjunto que regras são violadas) Nenhuma parte das aulas pode ser gravada 32 32 16  03/10/2024 cognitive walkthrough (1) Baseia-se em imaginar os pensamentos e ações do utilizador quando usa a interface pela 1ª vez, sem treino Permite questionar assunções sobre o que os utilizadores pensam, se os controlos estão visíveis e óbvios e se é fornecido o feedback adequado; Pretende ajudar a refinar as especificações, assumindo que temos: Uma descrição do protótipo da interface Uma descrição das tarefas representativas Uma lista completa das ações necessárias para executar tarefas com a interface A caracterização/experiência dos utilizadores da ferramenta Melhor realizado por quem trabalhou perto dos utilizadores de forma a criar uma imagem mental dos utilizadores Nenhuma parte das aulas pode ser gravada 33 33 cognitive walkthrough (2) Para cada ação de cada tarefa tentamos contar uma história a explicar o porquê do utilizador selecionar essa ação … Procura-se criticar a plausibilidade dessa história, perguntando-nos: Será que o utilizador irá tentar produzir o resultado resultante da ação? Será que o utilizador verá o controlo da ação (e.g., botão)? Ao ter encontrado o controlo, será que o vai reconhecer como aquele que produz o resultado desejado? Após a ação ser executada, será que o utilizador compreende o feedback para passar para a próxima ação? Após a análise da ação assumimos que quaisquer problemas foram resolvidos e passamos para a próxima ação Nenhuma parte das aulas pode ser gravada 34 34 17  03/10/2024 cognitive walkthrough (3) História da interação “fazer uma fotocópia”: Tarefa: “O utilizador quer fazer uma fotocópia.” Acção: “Começa por carregar no botão de power.” Justificação: “Porque sabe que a máquina tem de ser ligada.” Crítica da plausibilidade da história: Normalmente assumimos que a fotocopiadora já está ligada Logo, não é mais plausível que o utilizador não tente pressionar o botão de power? Mesmo que saiba que tem de ligar, será que encontra o botão que está nas costas da máquina? ou lado/frente mas pouco visível! Existe algum led a indicar se está on ou off para ele verificar? Nenhuma parte das aulas pode ser gravada 35 35 cognitive walkthrough (4) A crítica do exemplo anterior mostra que a interação não decorrerá como pretendemos, logo a interface terá de ser corrigida: ➡Melhorar os controlos, fornecer mais feedback, … Se detectarmos que o utilizador não verá qualquer razão para executar uma dada tarefa, então ➡Podemos tentar automatizá-la ou ➡Podemos reordenar as ações de forma a que as menos óbvias se tornem pelo contexto (spell check -> load dictionary) Walkthrough é para desenvolver o sistema, não para o validar! temos de estar à espera de encontrar elementos para melhorar! Erros típicos na execução do walkthrough: (1) testers não sabem a lista de ações corretas; (2) o walkthrough de facto não testa utilizadores reais. Nenhuma parte das aulas pode ser gravada 36 36 18  03/10/2024 análise formal (1) Permite estimar tempo que um utilizador experiente levará a completar uma tarefa Cada tarefa é dividida em sub-tarefas recursivamente até se atingir passos listados numa tabela pré-preenchida Soma-se os tempos que se espera serem gastos em cada passo da tarefa, sejam ele físico ou mental Tempos (tipicamente frações de segundo) estimados as partir da observação de centenas de pessoas em: ➡movimentos físicos (keystroke =.28 sec.) ➡percepção visual (recognize a 6 letter word =.34 sec.) ➡ações mentais (retrieve from long-term memory = 1.2 sec.) Nenhuma parte das aulas pode ser gravada 37 37 análise formal (2) Este método pode ser muito moroso, mesmo nas tarefas mais simples Exemplo: uma tarefa que exija manipular um excel por 10’, o que leva a uma análise de ~1000 ações (cada ação leva menos de 1’’) Infelizmente, os resultados podem diferir dependendo de como a tarefa é decomposta e que ações prevemos que o utilizador irá realizar Dadas estas dificuldades, análise formal é apenas vantajosa em circunstâncias especiais (quando a recompensa compensa o custo) ➡exemplo: pressionar de teclas a mais numa tarefa repetitiva por muitos operadores telefónicos (muito tempo acumulado perdido) ➡exemplo: segmentos da interface utilizados repetidamente (e.g., escolher em menus, selecionar e mover objetos gráficos) Nenhuma parte das aulas pode ser gravada 38 38 19  03/10/2024 análise formal (3) Para se obter uma análise mais rápida podemos realizar uma análise do tipo back-of-the-envelope, ou seja, … Em vez de decompormos a tarefa apenas listamos as ações de forma natural; assim não nos perdemos nos detalhes, focando-nos no utilizador e no ambiente em seu redor Com a lista de ações podemos perguntar-nos sobre: ➡A tarefa pode ser realizada com uma sequência simples de ações? ➡As tarefas frequentes podem ser feitas rapidamente? ➡Quantos passos tem o utilizador de aprender? Pode-se assumir que cada ação leva cerca de 2’’ ou 3’’ para determinar-se o tempo que a tarefa como um todo demorará. Nenhuma parte das aulas pode ser gravada 39 39 análise heurística (1) Limitações dos testes orientados à tarefa: ➡não há tempo para avaliar todas as tarefas possíveis e não deteta problemas que podem surgir na interação entre tarefas Análise heurística ajuda a complementar essas análises: ➡regras utilizadas para guiar as nossas decisões de design, regras essas que são independentes da tarefa Processo proposto por Nielsen e Molich: 1. vários avaliadores identificam problemas na interface aplicando um conjunto de heurísticas analisando um protótipo ou em papel; 2. cada avaliador faz esse trabalho isoladamente; 3. depois combinam-se as várias avaliações numa única lista. Nenhuma parte das aulas pode ser gravada 40 40 20  03/10/2024 análise heurística (2) Heurísticas: simple & natural dialog, speak the user’s language, minimize user memory load, be consistente, provide feedback, provide clearly marked exits, provide shortcuts, good error messages, prevent errors. 3-5 peritos em interfaces detectam 75% dos problemas detectáveis com heurísticas 2-3 peritos conseguem o mesmo efeito se forem especialistas no domínio da interface (e.g., voice) 15 conseguem o mesmo efeito se não tiverem treino ou experiência em interfaces 5 sem treino e experiência conseguem cerca de 50% dos problemas Nenhuma parte das aulas pode ser gravada 41 41 Complementaridade Estes métodos complementam-se e no fim temos sempre de testar com pessoas Nenhuma parte das aulas pode ser gravada 42 42 21  03/10/2024 Task-Centered User Interface Design A Practical Introduction Chapter 5. Testing the Design With Users Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 43 Testes com utilizadores Temos de testar a nossa interface quando o design estiver maduro mas antes de passarmos à implementação Apenas quando testamos com utilizadores reais é que podemos dizer se uma interface é boa ou não Os melhores testers são aqueles representativos das pessoas que vão realmente utilizar o sistema (e.g., médicos) Se for difícil encontrar testers “reais”, podemos procurar uma aproximação dos testers reais (e.g., estudantes de medicina) “Testers aproximados” permitem detectar os erros mais grosseiros, mas não nos podemos esquecer que não serão os users finais! Evitar usar amigos, colegas (particularmente subordinados) e familiares (será que são imparciais?) Nenhuma parte das aulas pode ser gravada 44 44 22  03/10/2024 Estamos a falar de pessoas … Quando testamos com pessoas não nos podemos esquecer que ser tester provoca stress por receio de embaraço se algo “corre mal” Para reduzir stress devemos: Deixar claro que é o sistema que está a ser avaliado não o tester Evitar coletar informação que possa ser usada para identificar alguém (sem caras nos vídeos) Garantir que testers são voluntários com consentimento informado Quando o teste “corre mal” podemos: Alegar falha de equipamento se tivermos de parar o teste devido a níveis de stress muito elevados (sem perguntar a razão) Nenhuma parte das aulas pode ser gravada 45 45 Como Conduzir um Teste Ajustar tarefas ao teste (e.g. simplificar para não demorar muito tempo ou se testers não tiverem background suficiente) Preparam-se ecrãs para a execução correta e depois ponderam-se “caminhos alternativos” para explorar com o utilizador Se faltar algum ecrã escreve-se o que o user pretendia realizar, o que era suposto ele ver e tentar que prossiga no teste ou tome outra opção Se tivermos elementos de escolha livre? Pode-se fazer: “aqui chamou XPTO mas vamos imaginar que era ABC”... Para reduzir custos pode-se testar com mockups (mais barato e low-fi do que protótipo) do sistema, em papel e cartão por exemplo Wizard of Oz (e.g. reconhecimento de voz) e Protótipos (e.g., funcionalidades de desenho) podem ser usados se necessário Protótipos são caros de implementar -> pensar em reutilizar no final Nenhuma parte das aulas pode ser gravada 46 46 23  03/10/2024 Observador Quando executamos um teste devemos registar tudo o que for possível para análise posterior: filmar, gravar e tirar notas! Esse é o papel do(s) observador(es)! Tipos de dados que podemos gravar: Process data: observações do que o utilizador faz e pensa para dar o WHY do que está a acontecer Bottom-line data: o WHAT: quanto tempo levou, se foi bem sucedido, número de erros Bottom-line data importante mas pouco nos ajuda a saber como mudar o que falhou, pois para isso precisamos do WHY (process- data) Nenhuma parte das aulas pode ser gravada 47 47 Facilitador O facilitador deve procurar estimular o think aloud para permitir obter process data (“pode dizer-me o que está a pensar?”): Obter o que estão a pensar / as questões que têm Perceber que elementos da interface estão a analizar Cuidado que “porque é que fez isso?” pode fazer sentir-se avaliado Não fazer perguntas diretas porque: Ganha-se mais com os comentários espontâneos do utilizador do que se intervirmos a perguntar coisas que nos interessam Perguntas específicas forçam as pessoas a dar uma resposta, mesmo que errada; não aceitar os comentários de forma acrítica! Estar calado não funciona! Ajudar apenas se ao fazê-lo obtemos mais informação do que se não o fizéssemos porque o teste pára ou a tarefa não avança Nenhuma parte das aulas pode ser gravada 48 48 24  03/10/2024 Avaliar os resultados Os resultados dos testes vão dizer-nos se os utilizadores utilizam o sistema como esperávamos Se não, atualizamos a análise das tarefas e depois repensamos o design para melhor suportar o utilizador Para cada dificuldade encontrada temos de avaliar a sua importância e a dificuldade de a corrigir Importância deve ser função do custo do problema para o utilizador em tempo, irritabilidade e outros, assim como a proporção de utilizadores que esperamos que venham a sentir esses problemas A dificuldade na correção depende dos detalhes de implementação e o impacto (estrutura da interface vs um menu) Nenhuma parte das aulas pode ser gravada 49 49 Processamento de dados Process data diz-nos o WHY e por isso é geralmente mais interessante do que o bottom-line data Contudo, o bottom-line data pode ser importante para comparar dois designs alternativos em termos de tempos/erros de execução Process data e bottom-line deverão ser obtidos em separado: think aloud pode atrasar/acelerar o tester, enviesando os seus tempos Quando temos números temos de lhes aplicar uma análise estatística para ver se são significativos Exemplo: {20’, 15’, 40’, 90’, 10’, 5’} com média 30’ Será que podemos confiar que a média seria a mesma se tivéssemos por exemplo 100 testers, i.e., se representa o tempo “típico” da população? Não porque existe uma elevada variabilidade dos dados da amostra Nenhuma parte das aulas pode ser gravada 50 50 25  03/10/2024 Análise de resultados Permite avaliar credibilidade dos resultados tendo em conta o tamanho da amostra (maior melhor) e a variabilidade dos dados (menor melhor). Custos de se envolver mais utilizadores nos testes têm de ser ponderados face aos custos de não se melhorar a credibilidade dos resultados Inquéritos de satisfação (1 a 10) são normalmente pouco confiáveis, contudo: muitas boas notas é bom e muitas más notas é mau! Quando queremos comparar designs alternativos podemos usar experiências: Between-groups: um grupo usa a versão A e o outro grupo a versão B solução mais robusta mas precisa de mais utilizadores de teste Within-groups: os dois grupos testam A e B: funciona bem para testar técnicas de interação de baixo nível (onde aprendizagem não influencia resultados): aprendizagem ao testar A influencia teste na B as tarefas dadas a testar em A e B devem ser diferentes; ordem A->B / B->A influencia devemos trocar essa ordem entre testers; Nenhuma parte das aulas pode ser gravada 51 51 Considerações finais Devemos ser parcimoniosos nas nossas conclusões por causa da variabilidade e das assunções (e.g., dist. Normal) Tarefas mais simples primeiro e depois mais complexas (assim treina-se nas mais fáceis) Os testers devem ou não ser treinados antes dependendo do que os users reais vão encontrar na realidade Antes dos testes a sério devem-se fazer testes piloto dentro do projecto e depois com amostras de alguns testers Para reduzir variabilidade podemos recrutar testers mais homogéneos (background semelhante) e/ou dar um briefing para arrancarem todos do mesmo nível; garantir que feedback durante testes é igual para todos No debriefing fazemos perguntas mas não podemos esperar muito, ou forçar, porque as pessoas esquecem-se ou lembram-se de forma selectiva Nenhuma parte das aulas pode ser gravada 52 52 26  03/10/2024 Task-Centered User Interface Design A Practical Introduction Chapter 6. User Interface Management and Prototyping Systems Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 53 Toolkits / UIMS Aborda alguns tópicos relacionados com a utilização de ferramentas para criação de protótipos e sistemas finais O uso de ferramentas é essencial para chegar rápido ao mercado e com qualidade competitiva e menores problemas legais Toolkits: biblioteca para criar botões, menus, widgets; poupam tempo e melhoram consistência e fornecem interfaces já conhecidas ao utilizador; mas ainda assim deixam muito trabalho para o programador User Interface Management Systems (UIMS): Toolkit + Ambiente de Programação Ambiente gráfico para construção das interface (drag-and-drop) ao invés de termos de programar à mão tudo o que um Toolkit exige (posições e tamanhos dos botões, …); poupa- se muito tempo! Estes sistemas permitem criar um protótipo e ir iterando até se chegar ao sistema final Nenhuma parte das aulas pode ser gravada 54 54 27  03/10/2024 Estrutura de programação de um UIMS o OOP Object-oriented programming ; Objetos associados aos widgets, que enviam mensagens para os Handlers que incluem o código / lógica de resposta aos botões (as ações que realmente queremos realizar) o Este é um método de programação orientado a eventos, ou seja, o código é despoletado pelas mensagens, em vez de termos um código sequencial que captura o input, processo e envia o output, requerendo a noção de “modo”; com eventos torna-se mais fácil gerir a diversidade de possíveis interações. o Os nomes do menus e botões são guardados como resources em ficheiros (e.g., de texto) à parte que podem ser alterados por exemplo permitindo adaptar a diferentes línguas; não requer re-compilação. o Interapplication communication para facilitar reuso (e.g., comunicar com o excel para evitar reprogramar conceitos já existentes) Nenhuma parte das aulas pode ser gravada 55 55 E se tivermos um hardware específico Investe num UIMS simples para criar um protótipo para validar o design, o que não vai permitir descobrir todos os problemas (não é o UIMS final...) Desenvolve em “estilo UIMS” para o hardware em questão, ou seja, tendo em conta: programação event-driven, código modular e resources em lookup-tables. Não exagerar e tentar criar um UIMS completo! Nenhuma parte das aulas pode ser gravada 56 56 28  03/10/2024 Historial, X-Windows, Motif X-Windows é um sistema onde temos um servidor que fornece acesso ao teclado e display e clientes (e.g., um browser) que acedem a essas interfaces através do servidor; os clientes podem estar remotos Motif como um exemplo de um event-driven ToolKit utilizado para criar interfaces gráficas para o X-Windows, desenvolvido pela Open Source Foundation Em Motif, os elementos gráficos chamam-se widgets, que são colocados com o rato, numa hierarquia orientada a objetos (um botão é uma instância de uma subclasse de labels), alimentados por resource files Motif User Interface Language para permitir ao programador definir a hieararquia de widgets Nenhuma parte das aulas pode ser gravada 57 57 Windows Windows today provides a sophisticated event-oriented user interface, memory management, the ability to run several programs at the same time, and various ways for those programs to communicate. Dynamic Link Libraries (DLL): toolbox routines to draw controls, or to take procedural actions like sorting data Dynamic Data Exchange (DDE): It allows your program to send data to another application Object Linking and Embedding (OLE) : embedding different applications in your program Robustness in the Shared-Code Approach Can the user accidentally edit files? Can the user set options in a server application that will affect your program's behavior? Can the user clearly distinguish between bugs in your program and bugs in one of the server programs? If one of the server applications is upgraded, will it still run the macros you've written? VisualBasic já surgiu capaz de fornecer todas as funcionalidades espectáveis para um UIMS Nenhuma parte das aulas pode ser gravada 58 58 29  03/10/2024 O que procurar num UIMS Capacidade de logging das ações realizadas pelo utilizador (para depois avaliarmos) Permitir todas aquelas capacidade de programação desejáveis: modularidade, múltiplos ficheiros, versões Capacidade de expansão do conjunto de controlos e widgets que depois sejam fáceis de programar Capacidade de suportar interações expectáveis com o sistema operativo (e.g., clipboard, instalador) Capacidade de ir do protótipo à produção final Capacidade de verificar e “enforce” um dado style guide (e.g., “cada diálogo deve ter um OK”) Construir a GUI visualmente com drag-and-drop e impor restrições (e.g., “botões têm largura de 50 px”) Capacidade de comunicar com outras aplicações (e.g., “com documentos Excel”) Nenhuma parte das aulas pode ser gravada 59 59 Task-Centered User Interface Design A Practical Introduction Chapter 7. The Extended Interface Clayton Lewis, John Rieman tópicos de apoio à leitura do texto os tópicos apresentados não são exaustivos e não substituem a leitura do texto original 60 30  03/10/2024 Interface estendida (1) tudo para além do sistema para facilitar a usabilidade: manuais, treino e telefone/help-desks Será necessário? Testes mostram que desde secretárias a programadores, todos acedem a fontes externas de informação em busca de ajuda Para sistema de utilização rápida (e.g., ATM) a interface em si tem de ser suficiente, contudo, software profissional precisa de fontes externas para a primeira utilização e para utilizações de funcionalidades menos frequentes A produção dos materiais externos deve seguir o desenho centrado na tarefa (como tudo o resto) Avaliação sem utilizadores e testes com utilizadores devem ser usados para compreender os cenários onde a ajuda será necessária Nenhuma parte das aulas pode ser gravada 61 61 Interface estendida (2) Contudo, não se fiem no apoio externo para compensar uma má interface! Ir à documentação é algo pouco eficiente; o sistema não deve precisar de ajuda externa nas funcionalidades base; a ajuda deve ser mais para quem sai do percurso normal ou para utilizadores mais avançados (para além das funcionalidades base) A equipa que desenha as fontes de informação externa deve estar integrada na do desenho da interface! Um bom manual é a extensão à interface mais importante Um manual pode ser avaliado com um cognitive walkthrough para detectar problemas: o user pode estar à procura de algo que não está no manual; pode até estar, mas o user não encontrar; ou não reconhecer e compreender a info Nenhuma parte das aulas pode ser gravada 62 62 31  03/10/2024 Dicas para escrever um bom manual Ser breve: focar no relevante para facilitar a pesquisa e reduzir ambiguidades sem filosofias, história, detalhes técnicos dos mecanismos internos, a não ser que sejam necessários Apresentar um resumo e uma sequência de passos para cada tarefa real, identificada com users reais Usar a linguagem do utilizador não estamos a fazer um manual para outros programadores Encontrar um Editor “light” (limpar o texto mas mantendo a nossa linguagem, que reflete o conhecimento que temos dos users) e um Editor que também seja um user (organizar e clarificar o texto através dos olhos dos utilizadores) aqui um Editor não é software!, é alguém que trata o texto e decide o que manter ou alterar Utilizar style guides “gerais” e “internas” para garantir coerência nos vários documentos produzidos Utilizar gráficos simples e de forma profissional usar um profissional para garantir gráficos simples e claros Usar “emprestado” um design visual atrativo e funcional usado em manuais utilizados pelos utilizadores Nenhuma parte das aulas pode ser gravada 63 63 Referências Referência com as descrições para cada comando Mais útil para utilizadores experientes, que requerem fazer algo que vai para além das tarefas planeadas No fundo este documento fornece uma visão técnica centrada no sistema e não na tarefa A organização pode ser alfabética (para comandos) ou seguir a hierarquia dos menus no caso gráfico O Super Índex permite que os utilizadores possam encontrar como fazer algo que não encontraram na documentação O “Vocabulary Problem” diz-nos que qualquer que seja o nome que demos a um comando, 80% dos utilizadores esperariam que o comando tivesse outro nome! A utilização de elementos gráficos (RECOGNITION VS RECALL) reduzem este problema... Adicionar termos como “See” e “See also” para associar termos que os users poderão estar à procura os termos podem-se obter analisando outros pacotes no mercado e entrevistando utilizadores (e.g. “dê- me seis sinónimos para cada uma das operações que vai executar”) Nenhuma parte das aulas pode ser gravada 64 64 32  03/10/2024 Ontem versus hoje O capítulo diferencia os documentos “em papel” dos “on-line” ou seja, na própria aplicação, dizendo que os em papel por vezes são melhores Contudo, isto pode não fazer sentido: on-line para nós agora é na Net e os documentos podem ser em papel ou não local ou remoto A procura por Find em digital é muito mais rápida Seja local ou web online “as pessoas já estão habituadas aos computadores!” Todas as pessoas já estão habituadas? Que faixas etárias? Nenhuma parte das aulas pode ser gravada 65 65 Treino Inclui aulas tradicionais e o uso de tutoriais realizados pelo próprio utilizador O treino tem de ser estruturado para envolver o user ativamente com o sistema Ao contrário dos manuais Isto pode ser feito recorrendo ao “manual mínimo” colocar de forma judiciosa falta de detalhes para que o utilizador tenha de os procurar explorando a interface isto é melhor do que treino “completo” Treino incremental Nenhuma parte das aulas pode ser gravada 66 66 33  03/10/2024 Treino Factos sobre a aprendizagem que devem ser tidos em conta quando se prepara um treino: As pessoas aprendem melhor os factos se tiverem de trabalhar com eles, ou seja, temos de apresentar os factos e depois de alguma forma colocar as pessoas a trabalharem-nos As nossas capacidades melhoram com a prática A aprendizagem requer feedback (imediato) para ser efetiva Esforço próprio, envolvimento próprio, repetição e análise Aprendizagem espaçada é mais efetiva, ou seja, é preferível aprender uma coisa, depois aprender outras coisas e só depois voltamos a exigir que os conhecimentos aprendidos primeiro/antes sejam relembrados As pessoas apenas conseguem aprender algumas coisas ao mesmo tempo, o que leva que tenhamos que evitar colocar elementos irrelevantes que possam distrair As pessoas não conseguem correr antes de andar, o que significa que mais vale ensinar skills básicas, mandar as pessoas praticar por uma semana para o trabalho e depois voltarem para as skills mais avançadas. Nenhuma parte das aulas pode ser gravada 67 67 help-desks São caros e portanto devem ser uma motivação para se desenharem boas interfaces Uma boa interface reduz o número de chamadas e por isso reduzem-se os custos Uma boa prática é enviar a equipa de desenvolvimento para atender telefonemas A informação recolhida nos telefonemas é essencial para identificar problemas a resolver usar a experiência no tipo de problemas encontrados noutros produtos anteriores A forma como as chamadas devem ser atendidas pode ser treinada com “cognitive walkthrough”, imaginando potenciais perguntas... Como utilizar o “cliente mistério”? Nenhuma parte das aulas pode ser gravada 68 68 34  03/10/2024 Fim desta parte Bibliografia Task-Centered User Interface Design, A Practical Introduction Clayton Lewis, John Rieman © 1993, 1994 by Clayton Lewis and John Rieman Nenhuma parte das aulas pode ser gravada 69 69 35