10 – Protótipo Funcional – 2ª Funcionalidade
1. Objetivos
Implementar a segunda funcionalidade do protótipo.
2. Preparação da Aula
Continuar a implementação do protótipo funcional, depurando questões de organização geral e terminando a implementação da segunda funcionalidade. Deve permitir ao utilizador realizar várias tarefas, apresentando a flexibilidade necessária para tal. Relembra-se, mais uma vez, que uma funcionalidade completa envolve dar ao utilizador liberdade de escolha (ex.: “encontrar amigos” não é apenas “encontrar o João”). Recorda-se ainda que não é necessária nem desejável a implementação de nenhum backend ou servidor. Devem manter o estado (por exemplo, se o utilizador escolher o João, no ecrã com as indicações para o encontrar deve aparecer essa pessoa e não outra), mas isso deve ser simulado usando uma de várias formas disponíveis para isso em HTML (Client-Side Storage, cookies ou até mesmo variáveis globais em JavaScript).
Não só a parte funcional do protótipo deve ser tida em conta como também o aspeto: devem ser seguidos os princípios básicos de desenho de ecrãs (layout, estrutura, alinhamentos, tipos de letra, proximidade, legibilidade, etc.). Dito isto, é legítimo que o aspeto final (imagens, cores, etc.) possa ser alterado em versões subsequentes do protótipo (por motivos de consistência com as restantes funcionalidades, por exemplo).
Relembramos que esta é a segunda funcionalidade de um produto consistente, completo e coeso, e portanto não deve aparecer completamente desgarrada do que já antes existia. Tanto em termos de aspeto como funcional deve haver consistência e, onde relevante, devem ser exploradas sinergias entre as funcionalidades.
O protótipo tem que estar disponível online no site do grupo. Será demonstrado a partir desse site.
3. Tarefas na Aula
Demonstração do protótipo funcional.
4. Tarefas depois da Aula
Assim, e como habitual, a nota desta aula poderá subir até dois valores se na próxima versão do protótipo apresentarem correções efetuadas de acordo com as sugestões do docente.
5. Critérios de Avaliação
Layout
Boa Utilização do Espaço (inclui boa utilização do espaço em branco. Sem atafulhar de coisas…)
Ecrãs Consistentes (é uma interface coesa, e não um “copy&paste” de estilos diferentes)
Widgets Consistentes (no seguimento do anterior, em particular para os widgets usados)
Agrupamentos lógicos (coisas relacionadas estão perto e separadas do resto)
Adequado ao Dispositivo (não estão a tentar encaixar uma interface de telemóvel, ou web, no pulso dos utilizadores…)
Texto
Consistência
Sem serifas
Tamanhos aceitáveis e legíveis
Cores
Consistência
Significados corretos
Bom contraste (no geral, e facilitando a legibilidade do texto)
Ícones/Imagens
Consistência (estilos, etc. cuidado com ir buscar imagens a fontes diferentes)
Percetíveis (sabemos o que representam)
Funcionalidade 2
Complexidade Aceitável (não é um “caminho de ferro”, nem deixa fazer apenas tarefas trivialmente simples
Completa (conseguem fazer-se tarefas do princípio ao fim)
Utilizador controla e exerce o livre arbítrio
Integração
Fala a Linguagem do Utilizador
Estado do sistema visível
Demonstram-se situações limite (“e se quiser ser avisado de 12 concertos, e não apenas de 1”?)
Mantém Estado (“encontrar o João” tem que se lembrar que é o João nos vários passos (e quando sair dos ecrãs da tarefa e enquanto não o encontrar), etc.)
Evitam-se Erros
Look&Feel Coeso (parece um produto só, e não duas funcionalidades diferentes “coladas”)
Funcionalidade Coesa (as tarefas estão interligadas onde faz sentido, há sinergias entre elas, e não são dois “caminhos de ferro” estanques, o que tipicamente pode acontecer se pessoas diferentes tiverem trabalhado em cada uma delas e depois ter sido só juntar as partes…)