UC04377

Implementar interfaces interativas

HTML, CSS e JavaScript, princípios de design UX/UI, prototipagem, usabilidade e publicação responsiva

Curso profissional · 25h · Técnico de Produção de Conteúdos Interativos

Plano

  1. Interfaces interativas e a linguagem da web
  2. HTML: estrutura da interface
  3. CSS: estilo e layout
  4. JavaScript: interatividade
  5. Frameworks
  6. Princípios de composição visual
  7. Layout, tipografia e cor
  8. Texto, legibilidade e imagens
  9. Wireframes e mockups
  10. Design UX: utilizador, concorrência e arquitetura de informação
  11. Design responsivo
  12. Montar o protótipo
  13. Testar e ajustar a usabilidade
  14. Publicar para diferentes suportes
  15. Segurança, ambiente e boas práticas

Bloco 1 · Interfaces interativas e a linguagem da web

O que é uma interface interativa

Uma interface interativa é a camada visual e funcional através da qual a pessoa utilizadora comunica com uma aplicação: site, app móvel ou sistema. É o resultado de três linguagens a trabalhar em conjunto: HTML (estrutura), CSS (estilo) e JavaScript (comportamento).

  • Analisar layout e requisitos, montar o protótipo, testar a usabilidade e publicar para diferentes suportes: é o ciclo completo desta UC.
  • Trabalha-se em agências digitais, empresas de desenvolvimento ou como freelancer.
  • O critério que atravessa tudo: resposta rápida aos comandos e navegação eficiente.

O ciclo de trabalho desta UC

O referencial define quatro realizações que estruturam todo o percurso:

  1. Analisar layout e requisitos para a interface.
  2. Montar o protótipo.
  3. Testar e ajustar a usabilidade do protótipo.
  4. Publicar a interface interativa para diferentes suportes.

Este ciclo repete-se em qualquer projeto profissional, do site institucional à app de gestão interna.

Bloco 2 · HTML: estrutura da interface

HTML: a estrutura da página

O HTML (HyperText Markup Language) define a estrutura semântica do conteúdo: títulos, parágrafos, listas, imagens, formulários, botões. Cada elemento é uma tag.

<header><h1>Título do site</h1></header>
<main>
  <p>Conteúdo principal.</p>
  <button>Clicar aqui</button>
</main>
<footer>Rodapé</footer>
  • Tags semânticas (<header>, <nav>, <main>, <footer>) descrevem o significado, não só o aspeto.
  • O HTML é lido de cima para baixo e forma uma árvore de elementos (o DOM).

Formulários e elementos interativos em HTML

Os formulários são a porta de entrada de dados do utilizador para a interface:

  • <form>, <input>, <textarea>, <select>, <button> recolhem texto, escolhas e ações.
  • Atributos como type="email", required, placeholder melhoram a experiência sem uma linha de JavaScript.
  • Elementos com estados (foco, desativado, erro) precisam de feedback visual claro.

Um formulário bem estruturado em HTML já resolve metade da usabilidade antes de qualquer estilo ou script.

Bloco 3 · CSS: estilo e layout

CSS: o que é e como se aplica

O CSS (Cascading Style Sheets) define a aparência: cores, tipografia, espaçamentos, posicionamento. Aplica-se por seletores.

.botao-principal {
  background: #2563eb;
  color: #fff;
  padding: 12px 24px;
  border-radius: 8px;
}
  • Cascata: quando há conflito, ganha a regra mais específica ou a última declarada.
  • Box model: todo o elemento é uma caixa com conteúdo, padding, border e margin.
  • Layouts modernos usam Flexbox (alinhamento em linha/coluna) e Grid (grelhas bidimensionais).

Estados, transições e animações

O CSS não só posiciona, também dá vida à interface:

  • Pseudo-classes: :hover, :focus, :active dão feedback visual a cada interação.
  • Transições: transition: all 0.2s ease suaviza mudanças de estado.
  • Animações com @keyframes para movimento contínuo (loaders, destaques).

Um botão sem :hover parece "morto"; uma transição bem calibrada comunica que a interface respondeu ao clique.

Bloco 4 · JavaScript: interatividade

JavaScript: o comportamento da interface

O JavaScript torna a interface reativa: responde a cliques, valida formulários, atualiza conteúdo sem recarregar a página.

const botao = document.querySelector(".botao-principal");
botao.addEventListener("click", () => {
  alert("Formulário enviado!");
});
  • DOM: JavaScript lê e altera a árvore de elementos HTML em tempo real.
  • Eventos: click, submit, input, scroll disparam funções.
  • Sem JavaScript, uma interface é apenas estática: bonita, mas surda aos comandos do utilizador.

Validação e correção de bugs

Um dos conhecimentos do referencial é corrigir bugs e problemas de desempenho no código. Práticas essenciais:

  • Usar a consola do browser (DevTools) para ler erros e testar código.
  • Validar formulários no cliente (JavaScript) e sempre confirmar no servidor.
  • Depurar: isolar o problema, testar hipóteses, corrigir uma coisa de cada vez.
  • Problemas de desempenho comuns: scripts pesados a bloquear o carregamento, imagens não otimizadas, eventos repetidos sem necessidade.

Código que funciona "às vezes" não está pronto: interface interativa exige fiabilidade.

Bloco 5 · Frameworks

Tipos de frameworks

Um framework é um conjunto de ferramentas e convenções que aceleram o desenvolvimento, evitando reinventar soluções comuns.

Tipo Função Exemplos
CSS frameworks grelhas, componentes prontos Bootstrap, Tailwind CSS
JS frameworks/bibliotecas interfaces reativas e componentes React, Vue, Angular
Frameworks de prototipagem mobile protótipos navegáveis Figma, Adobe XD
  • Reduzem tempo de desenvolvimento e garantem consistência visual.
  • Trazem uma curva de aprendizagem: exigem seguir as convenções da ferramenta.

Escolher o framework certo

  • Projeto pequeno e estático: HTML/CSS puro, talvez com Bootstrap ou Tailwind para agilizar o estilo.
  • Interface muito interativa (dashboards, apps): React ou Vue, que gerem estado e atualizações do DOM automaticamente.
  • Prototipagem de apps móveis: Figma ou Adobe XD, sem escrever código, para validar o design antes de programar.

A escolha depende dos requisitos do projeto, do prazo e da equipa, não da moda do momento.

Bloco 6 · Princípios de composição visual

Equilíbrio, ritmo e proporção

Uma interface bem desenhada segue princípios de composição visual que orientam o olhar sem que o utilizador se aperceba:

  • Equilíbrio: distribuição do "peso" visual (cor, tamanho, texto) de forma harmoniosa entre os lados.
  • Ritmo: repetição de elementos (espaçamentos, cores, formas) que cria previsibilidade.
  • Proporção: relação de tamanho entre elementos, coerente com a sua importância.

Estes três princípios são a base sobre a qual assentam a hierarquia e o foco visual.

Hierarquia, foco visual e perspetiva

  • Hierarquia visual: usar tamanho, cor e posição para indicar o que é mais importante primeiro.
  • Foco visual: um ponto de entrada claro que guia o olhar (ex.: um botão de destaque, uma imagem principal).
  • Perspetiva: profundidade e camadas (sombras, sobreposição) que ajudam a organizar informação em planos.

Sem hierarquia clara, o utilizador não sabe por onde começar a ler a interface.

Bloco 7 · Layout, tipografia e cor

Layout: estrutura e elementos

O layout organiza os elementos da interface no espaço disponível:

  • Grelha (grid): colunas e linhas que alinham conteúdo de forma consistente.
  • Elementos estruturais: cabeçalho, navegação, conteúdo principal, barra lateral, rodapé.
  • Espaço em branco: não é espaço "desperdiçado", é o que dá respiração e legibilidade à composição.

Um bom layout responde à pergunta: onde é que cada coisa deve estar, e porquê?

Tipografia e cor

Tipografia:

  • Máximo 2-3 famílias tipográficas por interface, com hierarquia clara (títulos, corpo de texto, legendas).
  • Tamanho e altura de linha (line-height) afetam diretamente a legibilidade.

Cor:

  • Uma paleta consistente (cor primária, secundária, neutros) reforça a identidade e a hierarquia.
  • Contraste suficiente entre texto e fundo é uma questão de legibilidade e de acessibilidade.

Bloco 8 · Texto, legibilidade e imagens

Texto: composição, tratamento e ritmos de leitura

O texto de uma interface não é só conteúdo, é também design:

  • Composição: parágrafos curtos, títulos claros, listas em vez de blocos densos.
  • Tratamento: negrito para destacar palavras-chave, sem exagerar.
  • Ritmos de leitura: o olho lê em padrões (ex.: em "F" ou em "Z" em páginas web); organizar o conteúdo mais importante nesses percursos.
  • Legibilidade: tamanho de letra, contraste e espaçamento adequados ao suporte (ecrã vs papel).

Imagens na interface

  • Escolher imagens de bancos de imagem, sons e vídeos com licença adequada ao uso.
  • Otimizar o peso do ficheiro sem perder qualidade percetível: imagens pesadas atrasam a resposta da interface.
  • Texto alternativo (alt) em toda a imagem com significado: acessibilidade e SEO.
  • Escolher o formato certo: JPEG para fotografia, PNG para transparência, SVG para ícones e logótipos.

Uma imagem mal escolhida ou mal otimizada compromete tanto a estética como o desempenho.

Bloco 9 · Wireframes e mockups

Wireframes: o esboço funcional

Um wireframe é um esboço de baixa fidelidade do layout, sem cor nem conteúdo final, focado apenas na estrutura e disposição dos elementos.

  • Serve para validar a organização da informação antes de investir em design visual.
  • Pode ser feito em papel, em ferramentas digitais (Figma, Adobe XD, Balsamiq) ou em software dedicado.
  • Responde à pergunta: onde fica cada bloco de conteúdo, e em que ordem?

Mudar um wireframe custa minutos; mudar uma interface já construída custa horas.

Mockups e ferramentas de prototipagem

O mockup é uma representação de alta fidelidade: já tem cor, tipografia, imagens reais, mas ainda não é clicável (ou é só parcialmente).

  • Ferramentas de design: Figma, Adobe XD, Sketch, Canva.
  • Permitem criar componentes reutilizáveis (botões, cartões) que mantêm consistência em todo o projeto.
  • A partir do mockup constrói-se o protótipo interativo, com ligações entre ecrãs.

Wireframe → mockup → protótipo é o percurso natural de qualquer interface profissional.

Bloco 10 · Design UX: utilizador, concorrência e arquitetura de informação

Conhecer o utilizador

O Design UX (user experience) começa por conhecer quem vai usar a interface:

  • Necessidades: que problema o utilizador quer resolver?
  • Comportamentos: como navega, em que dispositivo, em que contexto?
  • Preferências: que expectativas traz de outras interfaces que já usa?

Um bom design nasce de decisões baseadas no utilizador, não de gosto pessoal de quem desenha.

Análise da concorrência e arquitetura de informação

  • Análise da concorrência: estudar interfaces semelhantes já existentes, identificar boas práticas e falhas a evitar.
  • Arquitetura de informação: organizar o conteúdo em categorias lógicas e hierarquizadas.
  • Mapas de site: diagrama da hierarquia de páginas.
  • Fluxos de navegação: o caminho que o utilizador percorre para completar uma tarefa.
  • Esquemas de taxonomia: sistemas de categorias e etiquetas coerentes.

Bloco 11 · Design responsivo

Princípios do design responsivo

O design responsivo garante que a interface se adapta a diferentes tamanhos e contextos de uso: computador, telemóvel, tablet, ecrãs de alta resolução.

  • Grelhas flexíveis e unidades relativas (%, rem, vw) em vez de valores fixos em píxeis.
  • Media queries em CSS aplicam estilos diferentes consoante a largura do ecrã.
  • Mobile-first: desenhar primeiro para o ecrã pequeno, depois expandir para ecrãs maiores.

Testar em diferentes suportes

  • Breakpoints comuns: telemóvel (até ~480px), tablet (até ~768px), desktop (a partir de ~1024px).
  • Testar sempre em dispositivos reais e nas ferramentas de desenvolvimento do browser (modo responsivo).
  • Elementos que precisam de atenção especial: menus (transformam-se em "hambúrguer"), tabelas largas, imagens.
  • Toque vs rato: em ecrãs táteis, os alvos de toque devem ser maiores (mínimo recomendado ~44px).

Bloco 12 · Montar o protótipo

Do mockup ao protótipo interativo

Montar o protótipo é a segunda realização do referencial: transformar o design estático em algo navegável.

  1. Definir os ecrãs (telas) necessários a partir do mapa do site.
  2. Ligar os ecrãs com interações (clicar em X leva a Y).
  3. Adicionar microinterações: estados de hover, transições entre ecrãs.
  4. Rever a consistência visual: mesmas cores, tipografia e espaçamentos em toda a interface.

Um protótipo bem montado já dá a sensação de usar o produto final.

Ferramentas e boas práticas de prototipagem

  • Figma, Adobe XD: prototipagem com ligações clicáveis entre ecrãs, direto no mesmo ficheiro de design.
  • Usar componentes reutilizáveis para manter consistência sem retrabalho.
  • Documentar decisões: porque é que este botão está aqui e não ali?
  • Recolher feedback cedo, antes de avançar para código de produção.

O objetivo do protótipo é falhar barato: descobrir problemas agora, não depois de publicado.

Bloco 13 · Testar e ajustar a usabilidade

Testes de usabilidade

Testar e ajustar é a terceira realização da UC. A usabilidade mede quão fácil e eficiente é usar a interface.

  • Testes com utilizadores reais: observar alguém a tentar completar uma tarefa, sem ajuda.
  • Testes extensivos: percorrer todos os fluxos, em todos os suportes, antes de publicar.
  • Perguntas-chave: o utilizador encontrou o que procurava? Em quantos cliques? Sentiu-se confuso em algum ponto?

Um problema descoberto no teste custa muito menos que o mesmo problema descoberto por um cliente real.

Ajustar a interface: iteração e correção

  • Corrigir bugs encontrados nos testes: erros de layout, ligações partidas, comportamento inesperado.
  • Resolver problemas de desempenho: elementos que demoram a responder, animações que engasgam.
  • Ajustar a navegação: simplificar caminhos confusos, reduzir cliques desnecessários, evitar redundâncias e excessos.
  • Repetir o ciclo: testar → ajustar → testar de novo, até a interface responder de forma consistente e eficiente.

Bloco 14 · Publicar para diferentes suportes

Publicar a interface interativa

Publicar é a quarta e última realização: tornar a interface acessível ao público, em diferentes suportes.

  • Web: alojamento (hosting), domínio próprio, certificado HTTPS.
  • Dispositivos móveis: publicação como app (loja de aplicações) ou como site responsivo/PWA.
  • Ecrãs de alta resolução: garantir que imagens e ícones não perdem qualidade (assets otimizados para retina/HiDPI).

Publicar não é só "carregar ficheiros", é confirmar que a interface funciona em todos os contextos previstos.

Checklist antes de publicar

  • [ ] A interface foi testada em desktop, tablet e telemóvel.
  • [ ] Todas as imagens estão otimizadas e com texto alternativo.
  • [ ] Não há erros na consola do browser.
  • [ ] Formulários validam corretamente e dão feedback ao utilizador.
  • [ ] Navegação consistente em todos os ecrãs, sem redundâncias.
  • [ ] Tempo de resposta aos comandos é rápido e percetível.

Uma checklist simples evita que problemas óbvios cheguem ao utilizador final.

Bloco 15 · Segurança, ambiente e boas práticas

Segurança e saúde no trabalho

O referencial inclui normas transversais a qualquer profissão técnica:

  • Ergonomia: postura correta, altura do ecrã, pausas regulares no trabalho ao computador.
  • Segurança da informação: nunca expor palavras-passe ou dados sensíveis no código publicado.
  • Saúde visual: pausas para os olhos, iluminação adequada, contraste do ecrã.

Trabalhar em interfaces é trabalho sentado e de ecrã: cuidar do corpo faz parte do profissionalismo.

Proteção ambiental e fecho

  • Proteção ambiental: preferir alojamento com energia renovável quando possível, otimizar código e imagens para reduzir consumo de dados e energia dos servidores.
  • Interfaces mais leves consomem menos dados e menos bateria nos dispositivos dos utilizadores.
  • As atitudes desta UC: responsabilidade, autonomia, empenho, flexibilidade, sentido crítico e criativo, organização, cooperação.

Do primeiro esboço à publicação, a interface interativa é sempre um trabalho de equipa, rigor e melhoria contínua.

Recapitulando

  • HTML estrutura, CSS estiliza, JavaScript dá interatividade: a base de qualquer interface.
  • Composição visual, layout, tipografia, cor e imagens constroem a linguagem visual da interface.
  • Wireframes → mockups → protótipos: do esboço à simulação navegável.
  • Design UX conhece o utilizador; design responsivo adapta a qualquer ecrã.
  • O ciclo da UC: analisar → montar → testar e ajustar → publicar, sempre com segurança e sustentabilidade em mente.

Próximo: fichas e projeto, analisar, montar e publicar uma interface de raiz.

NOTAS DO PROFESSOR - Enfatizar: uma interface interativa não é só "bonita", tem de responder a comandos e navegar-se com fluidez. Estética e função andam juntas. - Erro comum: alunos tratam HTML/CSS/JS como disciplinas isoladas. Mostrar desde já que uma interface real usa as três ao mesmo tempo. - Analogia: HTML é o esqueleto, CSS é a roupa, JavaScript são os músculos que fazem mexer.

NOTAS DO PROFESSOR - Enfatizar: este é o "mapa" da UC. Voltar a ele no início de cada bloco novo, situando o que se está a aprender. - Erro comum: saltar direto para código sem analisar requisitos primeiro. A análise poupa retrabalho. - Analogia: como construir uma casa, primeiro a planta (análise), depois a estrutura (montar), depois a inspeção (testar), só então a entrega de chaves (publicar).

NOTAS DO PROFESSOR - Enfatizar: HTML descreve significado ("isto é um título"), não aparência ("isto é grande e a negrito"). O aspeto é trabalho do CSS. - Erro comum: usar `<div>` para tudo em vez de tags semânticas. Prejudica acessibilidade e SEO. - Analogia: o HTML é como o índice e os capítulos de um livro, organiza o conteúdo antes de o decorar.

NOTAS DO PROFESSOR - Enfatizar: validação nativa do HTML (`required`, `type="email"`) é grátis e deve ser a primeira linha de defesa. - Erro comum: esquecer o `<label>` associado a cada `<input>`, o que quebra acessibilidade e usabilidade em ecrãs táteis. - Exemplo: mostrar um formulário de contacto simples e identificar cada tag e o seu papel.

NOTAS DO PROFESSOR - Enfatizar: o box model explica 90% dos "porque é que este espaçamento não bate certo". Desenhar a caixa no quadro. - Erro comum: usar `margin` quando o problema é `padding`, ou empilhar `!important` para "resolver" conflitos de cascata. - Analogia: Flexbox é uma fila de pessoas numa linha; Grid é um tabuleiro de xadrez com linhas e colunas.

NOTAS DO PROFESSOR - Enfatizar: ligar isto diretamente ao critério "resposta rápida e eficiente aos comandos do utilizador": o feedback visual É parte da resposta. - Erro comum: transições longas de mais (acima de 300-400 ms) fazem a interface parecer lenta, mesmo sendo tecnicamente rápida. - Exemplo: mostrar o mesmo botão com e sem transição e pedir à turma para descrever a diferença de sensação.

NOTAS DO PROFESSOR - Enfatizar: JavaScript é o único dos três que "ouve" o utilizador em tempo real. HTML e CSS são estáticos por natureza. - Erro comum: manipular o DOM antes de a página terminar de carregar. Explicar `DOMContentLoaded` ou colocar o script no fim do `<body>`. - Analogia: se HTML é o esqueleto e CSS a roupa, JavaScript é o sistema nervoso que reage a estímulos.

NOTAS DO PROFESSOR - Enfatizar: abrir a consola do DevTools é o primeiro reflexo perante qualquer comportamento estranho, não o último recurso. - Erro comum: corrigir um bug "por tentativa e erro" sem perceber a causa. Ensinar a ler a mensagem de erro com atenção (ficheiro, linha, tipo de erro). - Exercício rápido: mostrar um erro de consola real (ex.: `undefined is not a function`) e a turma diagnostica a causa.

NOTAS DO PROFESSOR - Enfatizar: framework não substitui saber HTML/CSS/JS, constrói-se em cima desse conhecimento base. - Erro comum: usar um framework pesado (React) para uma página simples de 3 secções. Escolher a ferramenta ao tamanho do projeto. - Analogia: um framework é como um kit de móveis por montar, poupa tempo mas segue as instruções do fabricante.

NOTAS DO PROFESSOR - Enfatizar: ligar esta escolha à primeira realização da UC, "analisar layout e requisitos", a ferramenta certa nasce da análise. - Erro comum: escolher uma tecnologia porque "é a mais falada", sem avaliar se serve o projeto concreto. - Pergunta à turma: que framework escolheriam para o site de um restaurante local? E para uma app de gestão de stock?

NOTAS DO PROFESSOR - Enfatizar: são princípios de design gráfico clássico, aplicáveis a qualquer interface, digital ou impressa. - Erro comum: encher a página de elementos "porque cabem", sem pensar no equilíbrio geral da composição. - Analogia: equilíbrio visual é como uma balança, elementos grandes ou fortes de um lado pedem contrapeso do outro.

NOTAS DO PROFESSOR - Enfatizar: perguntar sempre "o que quero que o olho veja primeiro?" antes de desenhar qualquer ecrã. - Erro comum: dar o mesmo peso visual (tamanho, cor, negrito) a tudo, o que anula a hierarquia por completo. - Exercício: mostrar duas versões da mesma página, uma sem hierarquia e outra com, e pedir à turma para comparar a rapidez de leitura.

NOTAS DO PROFESSOR - Enfatizar: espaço em branco é uma decisão de design, não uma falha. Interfaces "cheias" cansam o olho. - Erro comum: alinhar elementos "a olho" em vez de usar uma grelha consistente. Mostrar como a grelha resolve isto. - Analogia: o layout é a planta de uma casa, define onde ficam a sala, a cozinha e os quartos antes da decoração.

NOTAS DO PROFESSOR - Enfatizar: tipografia e cor não são "decoração final", são ferramentas de hierarquia visual, tal como o tamanho e a posição. - Erro comum: misturar 5 ou 6 tipos de letra diferentes, ou usar cor sem verificar o contraste com o fundo. - Exercício: mostrar um par de cores com mau contraste e pedir à turma para propor uma alternativa mais legível.

NOTAS DO PROFESSOR - Enfatizar: o padrão de leitura em "F" explica porque o conteúdo mais importante deve estar no topo e à esquerda em muitos layouts ocidentais. - Erro comum: parágrafos longos sem quebra, que o utilizador simplesmente não lê num ecrã. - Analogia: escrever para a web é como escrever uma manchete de jornal, direto ao ponto, com destaque para o essencial.

NOTAS DO PROFESSOR - Enfatizar: ligar diretamente ao critério "resposta rápida e eficiente": imagens pesadas são a causa mais comum de lentidão numa interface. - Erro comum: usar uma imagem de 5 MB direta da câmara sem qualquer compressão. - Exercício: comparar visualmente uma imagem otimizada e uma não otimizada ao mesmo tamanho de ecrã.

NOTAS DO PROFESSOR - Enfatizar: quanto mais cedo se testam ideias, mais barato é corrigir. O wireframe é a etapa mais barata de todo o processo. - Erro comum: saltar direto para o design visual (cores, imagens) sem validar primeiro a estrutura em wireframe. - Analogia: o wireframe é a planta arquitetónica, o mockup é a maquete pintada, o protótipo é a casa com as portas a abrir.

NOTAS DO PROFESSOR - Enfatizar: mockup não é ainda o produto final, é uma simulação visual fiel para validar decisões de design com o cliente. - Erro comum: confundir mockup com protótipo. O mockup normalmente não é clicável; o protótipo simula a navegação. - Exercício: mostrar o mesmo ecrã em wireframe e em mockup, lado a lado, e identificar o que mudou.

NOTAS DO PROFESSOR - Enfatizar: UX não é "fazer bonito", é resolver um problema real de alguém real. Situar isto logo no arranque do bloco. - Erro comum: desenhar a interface a pensar em "eu gosto disto" em vez de "o utilizador precisa disto". - Exercício: pedir à turma para descrever, em 3 frases, quem usaria a app que estão a desenhar no projeto final.

NOTAS DO PROFESSOR - Enfatizar: a análise da concorrência não é copiar, é aprender com o que já foi testado por outros no mercado. - Erro comum: desenhar a arquitetura de informação a partir da estrutura interna da empresa, em vez da lógica do utilizador. - Analogia: o mapa do site é como o índice de um livro; o fluxo de navegação é o percurso que o leitor faz capítulo a capítulo.

NOTAS DO PROFESSOR - Enfatizar: ligar diretamente ao critério de desempenho "ajustando adequadamente a diferentes tamanhos de ecrã". - Erro comum: desenhar só para desktop e "espremer" depois para mobile. O caminho mobile-first evita este retrabalho. - Analogia: uma interface responsiva é como água, adapta-se ao recipiente (ecrã) sem perder a sua natureza.

NOTAS DO PROFESSOR - Enfatizar: testar não é opcional, é parte do critério de qualidade. Uma interface "responsiva" só na teoria não vale nada. - Erro comum: esquecer o teste em ecrãs táteis reais, onde o cursor de rato não existe e os alvos pequenos falham. - Exercício: abrir o projeto da turma no modo responsivo do browser e identificar um problema em cada breakpoint.

NOTAS DO PROFESSOR - Enfatizar: o protótipo é a "prova de conceito" antes de qualquer linha de código de produção ser escrita. - Erro comum: montar ecrãs isolados e esquecer de os ligar entre si, o que impede o teste de fluxo completo. - Analogia: se o mockup é a fotografia de um carro, o protótipo é o simulador de condução, já se pode "conduzir" pela interface.

NOTAS DO PROFESSOR - Enfatizar: consistência visual é um critério de desempenho explícito da UC ("mantendo os elementos visuais consistentes"). - Erro comum: cada ecrã do protótipo com um estilo ligeiramente diferente, por falta de componentes reutilizáveis. - Exercício: na turma, criar um único botão "componente" no Figma e reutilizá-lo em três ecrãs diferentes.

NOTAS DO PROFESSOR - Enfatizar: usabilidade mede-se com pessoas, não só com opinião própria. Mesmo um teste informal com 3-5 colegas revela problemas. - Erro comum: só testar "o caminho feliz" (tudo a correr bem) e nunca o que acontece quando o utilizador erra. - Analogia: testar usabilidade é como um ensaio geral antes da estreia, revela os erros que ninguém viu a ensaiar sozinho.

NOTAS DO PROFESSOR - Enfatizar: "evitar redundâncias e excessos" é um critério de desempenho explícito, ligar sempre a exemplos concretos (menus repetidos, botões a mais). - Erro comum: corrigir um problema e não voltar a testar, assumindo que ficou resolvido. - Exercício: dar à turma uma interface com 3 problemas de usabilidade propositados e pedir para os identificar e propor correção.

NOTAS DO PROFESSOR - Enfatizar: publicar é o momento em que todo o trabalho de análise, montagem e teste é validado pelo utilizador real. - Erro comum: publicar sem testar novamente após qualquer alteração de última hora. - Analogia: publicar é como a inauguração de uma loja, tudo tem de estar a funcionar quando as portas abrem.

NOTAS DO PROFESSOR - Enfatizar: esta checklist resume os critérios de desempenho da UC inteira, vale a pena afixá-la na sala. - Erro comum: publicar "de véspera" sem tempo para percorrer a checklist com calma. - Exercício: aplicar esta checklist ao protótipo da turma e contar quantos itens já estão cumpridos.

NOTAS DO PROFESSOR - Enfatizar: normas de segurança e saúde no trabalho não são "letra pequena", fazem parte do referencial e da avaliação de atitudes. - Erro comum: ignorar pausas e postura por estar "a meio de uma tarefa". Sublinhar a importância de intervalos regulares. - Exemplo: mostrar a regra 20-20-20 (a cada 20 minutos, olhar 20 segundos para algo a 20 pés de distância).

NOTAS DO PROFESSOR - Enfatizar: sustentabilidade digital é um tema cada vez mais presente, ligar à otimização de imagens e código já ensinada. - Erro comum: pensar que "proteção ambiental" não se aplica a trabalho digital. Mostrar dados reais de consumo energético de data centers. - Analogia: um site pesado é como um carro a gastar combustível a mais, a otimização é a condução eficiente do mundo digital.