O método de trabalho é essencial para obter qualidade e satisfação dos clientes e utilizadores.

1. 5. O Processo do Projecto de Interacção(Aula Teórica 5 – apresentação adaptada do sítio de [Preece et al 2002]) • O método de trabalho é essencial para obter qualidade e satisfação dos clientes e utilizadores. • Engenheiros excelentes podem usar «maus» métodos com bons resultados. • A seguir: 6. Identificar necessidades e definir requisitos; 7. Projecto, protótipos e construção, 8. Projecto centrado nos utilizadores (UCEP - WISDOM); 9. Avaliação.

2. Quatro Actividades Básicas • Há quatro actividades básicas no desenho de sistemas interactivos: 1. Identificar necessidades e Definir requisitos 2. Desenvolver projectos ou modelos alternativos 3. Prototipar ou construir versões interactivas dos modelos 4. Avaliar os projectos.

3. Três Características chave • Três características chave rodeiam as quatro actividades: 1. Focar nos utilizadores o mais cedo possível no projecto e na avaliação dos artefactos. 2. Identificar, documentar e acordar em objectivos de usabilidade e de experiência dos utilizadores. 3. Iteração é inevitável. Os projectistas nunca acertam à primeira. Serious corporate management efforts may require you to produce specific numbers that quantify usability. Usability objectives are target values for things such as speed to perform representative tasks and number of errors allowable. These can be used to motivate designers and support resource allocation decisions. The target values can be selected to beat the competition or to meet the functional needs of well-defined tasks.

4. Aspectos práticos • Quem são os utilizadores ? • O que são necessidades? • Como se identificam alternativas? • Como se escolhe entre alternativas?

5. Quem são os utilizadores? • Não são tão óbvios: • Interagem directamente com o produto ou serviço • Gerem os utilizadores directos • Recebem relatórios ou outros resultados do sistema • Decidem a aquisição • Utilizam os produtos ou serviços concorrentes ??? • Três categorias de utilizadores: • primários: utilizadores frequentes • secundários: ocasionais ou através de terceiros • Terciários: afectados pela sua introdução ou que influenciam a sua aquisição • Outro termo: «stakeholders»

6. O que são «necessidades»? • Os utilizadores raramente sabem o que é possível. • Os utilizadores não são capazes de dizer o que necessitam para atingir os seus objectivos. • Pelo contrário, deve olhar-se para as tarefas que executam: • O seu contexto • Que informação requerem? • Quem colabora para executar a tarefa? • Porque é que a tarefa é executada da forma actual? • Tarefas previstas: • Podem ser construídas a partir de comportamento existente • Podem ser descritas como cenários futuros

7. Requisitos dos Utilizadores A determinada altura do projecto, alguém começará a lamuriar-se acerca da necessidade de determinar os «requisitos» do projecto. Isso implica entrevistar pessoas que não sabem o que querem, mas, curiosamente, sabem com toda a exactidão quando é que precisam dessas coisas. Essas pessoas são chamadas «utilizadores finais» ou, simplesmente, «cabeças de alfinete». A investigação mostrou que não existe nada neste planeta que seja mais estúpido do que um «utilizador final». O estudo apresentado abaixo ordena deste modo a inteligência relativa de alguns artigos domésticos vulgares: Scott Adams: O Princípio de Dilbert, p. 243

8. Requisitos dos Utilizadores A equipa do projecto continuará a reunir requisitos até encontrar satisfeita uma destas duas condições: • Os utilizadores finais esquecem-se de respirar, o que lhes provoca a morte durante o sono. • A equipa do projecto chega à conclusão de que os requisitos não são tão necessários como se pensava. Scott Adams: O Princípio de Dilbert, p. 244

9. User Interface Design For ProgrammersJoel Spolsky 2001 • When you design user interfaces, it's a good idea to keep two principles in mind: • Users don't have the manual, and if they did, they wouldn't read it. • In fact, users can't read anything, and if they could, they wouldn't want to.

10. Modelos de Processo de Engenharia • Mostram como as actividades estão relacionadas • Modelos de ciclo de vida são: • Ferramentas de gestão • Versões simplificadas da realidade • Há muitos modelos de processo de ciclo de vida, por exemplo: • Da Engenharia de Software: Cascata, Espiral, JAD/RAD, Microsoft (Activity Based Planning – Mike Conte) • De HCI: Star, Engenharia da usabilidade • Modelo Simples

11. Processo Cascata «The waterfall model has proven to be a poor approach to software that has an important user interface component» Clayton Lewis and John Rieman

12. Processo Espiral Desenho Desenvolvimento Piloto 1ª Iteração Análise Teste Âmbito 2ªIteração Implementação Revisão

13. Processo RAD (Rapid Applications Development) Project set-up JAD workshops Iterative design and build Engineer and test final prototype Implementation review

14. Wisdom • Modelo de desenvolvimento: • Envolvimento produtores-clientes-universidade. • Centrado nos utilizadores: casos de uso essencial • Prototipagem, evolução (instabilidade) • OMT  UML (estabilidade), modelo de interacção e modelo de informação (classes), … • Cavalo de Tróia amigável • Análise de tarefas dos utilizadores

15. Task-centered User Interface Design • Clayton Lewis and John Riemanftp://ftp.cs.colorado.edu/ • Foreword • Chapter 1. Task-Centered Design • Chapter 2. Getting to Know Users and Their Tasks • Chapter 3. Creating the Initial Design • Chapter 4. Evaluating the Design Without Users • Chapter 5. Testing the Design With Users • Chapter 6. User Interface Management and Prototyping Systems • Chapter 7. The Extended Interface • Appendix L. What Can You Borrow? • Appendix M. Managing User Interface Development • Exercises

16. Activity Based PlanningJoel Spolsky 2001 Designing good software takes about six steps: • Invent some users • Figure out the important activities • Figure out the user model -- how the user will expect to accomplish those activities • Sketch out the first draft of the design • Iterate over your design again and again, making it easier and easier until it's well within the capabilities of your imaginary users • Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn't matching the user model.

17. Imaginary Users Patricia is an English professor who has written several well-received books of poetry. She has been using computers for word processing since 1980, although the only two programs she ever used are Nota Bene (an ancient academic word processor) and Microsoft Word. She doesn't want to spend time learning the theory of how the computer works, and she tends to store all her documents in whatever directory they would go in if you didn't know about directories. "Frank" who refuses to touch Windows, which he only refers to as an "operating system" in quotation marks, uses his own personally modified version of tcsh, and runs X11 with four tiled xterms all day long. And about 11 xperfs.) Pete is an accountant for a technical publisher who has used Windows for six years at the office and a bit at home. He is fairly competent and technical. He installs his own software; he reads PC Magazine, and he has even programmed some simple Word macros to help the secretaries in his office send invoices. He's getting a cable modem at home. Pete has never used a Macintosh. "They're too expensive," he'll tell you. "You can get a 700 Mhz PC with 128 Meg RAM for the price of..." OK, Pete. We get it. Mike, a 16 year old who runs Linux at home, talks on IRC for hours, and uses no "Micro$oft" software.

18. Modelo simplificado ID-APP(QD - «Quick and Dirty») Ideia Identificar necessidades / Definir requisitos (Re)Projectar«(Re)Design» Avaliar Prototipar ou construir uma versão interactiva Produto Final

19. O que ficou na cabeça • No final deste capítulo os alunos devem saber: • A forma como se organiza o projecto de um sistema interactivo, em comparação com o processo ou modelo tradicional (modelo de processo – «workflow» – «tasks»). • Vantagens e inconvenientes dos vários modelos. • As possibilidades de variação no modelo. Referências: • Capítulo 6 [Preece et al 2002] • ver também POET e OVID: Dave Roberts, D. Berry, S. Isensee, J. Mullaly: Designing for the User with OVID: Bridging User Interface Design and Software Engineering, Macmillan, 1998 www.ibm.com/easy. • Mark van Harmelen (Ed.) 2001: Object Modeling and User Interface Design, Addison-Wesley, Object Technology Series.