Search buenodc

Nesta página
  1. Contextualização
  2. Cronograma
  3. Antes de começar — Pesquise!
  4. O Problema
  5. Os 3 Pilares do RWD
  6. Fase 1 — Bug Hunt (Diagnóstico)
  7. Fase 2 — Correção
  8. Fase 3 — Melhoria (Desafio)
  9. Fase 4 — Testes
  10. Fase 5 — Apresentação
  11. Critérios de Avaliação
  12. Entrega

Atividade PBL — Web Design Responsivo

Disciplina: Programação Web 2
Professor: Me. Danilo Bueno
Grupos: 4 integrantes
Duração: 4 aulas de 50 minutos (em sala)


Contextualização

Um cliente contratou um desenvolvedor às pressas para criar o TechBlog, um portal de notícias de tecnologia. O desenvolvedor entregou o site quebrado: no celular, praticamente nada funciona.

Sua equipe foi contratada para consertar o projeto.


Cronograma

AulaFocoAtividade
1ª (50min)EntendimentoLeitura das instruções, pesquisa sobre RWD e diagnóstico inicial dos problemas
2ª (50min)DiagnósticoFinalizar a Fase 1 (tabela de bugs) e iniciar as correções da Fase 2
3ª (50min)Correção + MelhoriaConcluir as correções, implementar as melhorias da Fase 3 e testar no DevTools
4ª (50min)Entrega + ApresentaçãoUpload no Moodle e apresentações dos grupos (5 min/grupo)

Antes de começar — Pesquise!

Vocês ainda não viram esse conteúdo em aula. Parte do desafio é pesquisar e aprender para resolver o problema. Use os materiais abaixo como ponto de partida:


O Problema

Baixe o arquivo PRW2-web-design-responsivo-pbl.html disponível nesta tarefa e abra-o no navegador. Em seguida, use o DevTools para testar o site em diferentes tamanhos de tela (pesquise como ativar o modo responsivo no link do DevTools acima).

Navegue pelo site em resolução de celular e observe o que acontece com o layout.

Anote todos os problemas que encontrar antes de começar qualquer correção.


Os 3 Pilares do RWD

O Web Design Responsivo se sustenta em 3 pilares. Todo problema encontrado no site pertence a pelo menos um deles:

PilarO que é
🏗️ Layouts FluídosMedidas que se adaptam ao espaço disponível
🖼️ Mídias FluídasImagens e vídeos que se ajustam ao contêiner
🔎 Media QueriesRegras CSS que mudam conforme o dispositivo

Fase 1 — Bug Hunt (Diagnóstico)

Objetivo: identificar e catalogar todos os problemas do site.

O grupo é livre para conduzir a investigação como preferir — vale dividir tarefas, investigar juntos, usar o DevTools, ler o código-fonte, etc.

Registre cada problema encontrado na tabela abaixo:

#SeçãoPilar afetadoPor quê é um problema?
1
2
3
…

A coluna Seção deve conter o nome do bloco HTML onde o problema está, exatamente como aparece nos comentários do código: NAVEGACAO, HERO, DESTAQUE, POSTS, SIDEBAR, FOOTER ou <head>.

Dica: há pelo menos 3 problemas por pilar!

A tabela preenchida será parte da entrega.


Fase 2 — Correção

Objetivo: corrigir todos os bugs encontrados na Fase 1.

Regras:

  • Não apague o código com problema — comente-o com /* ANTES: ... */
  • Escreva a correção logo abaixo com /* DEPOIS: ... */
  • Use unidades relativas onde cabem (%, rem, vw, vh)
  • Adicione as media queries necessárias para o layout funcionar corretamente em telas menores

Fase 3 — Melhoria (Desafio)

Após corrigir os bugs, o grupo deve implementar pelo menos 1 das melhorias abaixo:

  • 🍔 Menu responsivo: no mobile, esconder os links da nav e mostrar um ícone de menu (pode ser só com CSS)
  • 🌙 Dark Mode: usar @media (prefers-color-scheme: dark) para adaptar as cores do site
  • 📐 Mobile First: reescrever o CSS dos posts usando a estratégia mobile-first (min-width)
  • 🔤 Tipografia responsiva: trocar tamanhos de fonte em px por rem em todo o arquivo
  • 📱 Breakpoint tablet: adicionar um comportamento intermediário para telas entre 568px e 1024px

Fase 4 — Testes

Antes de entregar, teste o site nos seguintes cenários no DevTools:

DispositivoLarguraO que verificar
iPhone SE375pxLayout empilhado, imagens dentro da tela
iPad768pxTransição entre 1 e 2 colunas
Desktop1280pxLayout original mantido
Landscape mobile667pxNada estoura na horizontal

Fase 5 — Apresentação

Cada grupo terá 5 minutos para apresentar na última aula:

  1. Quantos e quais bugs encontraram (mostrar a tabela)
  2. Como corrigiram cada pilar (mostrar no código)
  3. Quais melhorias implementaram e por quê escolheram essas
  4. O que aprenderam — qual pilar foi mais difícil de corrigir?

Critérios de Avaliação

CritérioPeso
Diagnóstico completo (Fase 1)20%
Correção correta dos 3 pilares (Fase 2)40%
Pelo menos 1 melhoria implementada (Fase 3)20%
Testes realizados (Fase 4)10%
Apresentação clara (Fase 5)10%

Entrega

Enviar 2 arquivos nesta tarefa do Moodle até o início da 4ª aula:

  1. techblog-[nomes].html — o código corrigido, com os comentários /* ANTES */ e /* DEPOIS */ preservados para evidenciar cada correção
  2. fase1-bugs-[nomes].pdf (ou .docx) — a tabela de diagnóstico da Fase 1 com todos os bugs encontrados, o pilar afetado e a justificativa

Apenas um integrante por grupo faz o envio.