Desafio Front End Pessoas de Tech - desafio 2

Nossa incrível agência melhorou seus processos, afinal viu que os desenvolvedores que trabalham para ela são talentosos e querem fazer belos projetos. Os clientes começaram a pagar um pouco mais, e exigiram um projeto de melhor qualidade. Afinal, temos que progredir, certo?

Tanto que tem projeto novo na casa, e você foi convocado! (tá, não é obrigado a fazer o desafio, mas sabe, a gente avalia de verdade, mandamos aquela listinha maravilhosa para você estudar depois de corrigirmos o seu exercício - win win para todo mundo). https://www.figma.com/file/x3RWpqO8blDHp2bSKQwsnH/Desafio-Front-end-2---Pessoas-de-Tech?node-id=0%3A1

Briefing deste segundo projeto

PS: Este é um briefing de mentirinha, nem sempre será assim que você receberá os seus projetos. Porém entre na fantasia e pense num chefe biruta e num designer mega fascinado pelo projeto e faça o seu melhor.

Este segundo cliente tem um olhar mais analítico que o primeiro, e pagou por um layout melhorzinho. Estamos feliz pois aprovou de primeira, e o nosso designer ficou tão feliz com o sucesso que vai acompanhar de perto este projeto, para nada sair de fora do lugar. Ele é chato, mas é bem competente:

  • O menu do site é fixo, e quando scrolla acima de 50px, ele tem a animação de deixar o fundo roxo e a logo em Branco
  • O designer estava sufocado de projetos para fazer, e deixou para você fazer o responsivo. Ah, não pode esconder imagens em telas menores. Ele curtiu como você fez o responsivo do outro projeto, que nem fez esta tela.
  • O botão "Participar" manda para a sessão Nosso compromisso. O cliente precisa saber do nosso compromisso antes de sair botando seus preciosos dados no formulário.
  • O designer deixou BEM EXPRESSO que a bola atrás da moça precisa estar em outra imagem. Ele quer no futuro animar aquela bolinha por trás da moça.
  • Ali na sessão Nosso compromisso tem os ícones. Ele gostaria muito que os ícones fossem estes mesmos, pois demorou 1 dia inteiro de pesquisas para retornar com estes. Melhor agradar a fera.
  • Ali em notícias ele pediu 3. Se der tempo e quiser botar em slider, pode fazer, mas se não, não tem problema.
  • No anotar a agenda ele pediu que se botasse slider, pois tem muito evento, e ele queria deixar tudo ali. Acho que o designer está um pouco neurótico com este projeto.
  • Ele estava tão inseguro com o projeto que fez até as telas de loading e de resultado da requisição. Ele comentou comigo que se algo der errado neste projeto ele pede demissão. Cara, me ajuda ai, por favor.
  • Ah, o cliente solicitou que o campo de email seja um e-mail válido, e o de telefone tenha uma máscara. Ele reclamou que o povo no site antigo mandava endereço do concorrente ao invés de telefone.
  • Bom, ele me falou também que vai testar os hovers, pois teve umas ideias malucas depois que voltou do Taj Mahal.

O cliente está tão satisfeito que pagaria aquele bônus para gente, Logo a gente repassaria algo pra ti. #vemBonus!

FAQ

1) Para quem é indicado este desafio?
Este desafio é indicado para qualquer desenvolvedor que queira ser avaliado com critérios sólidos de frontend. No site Pessoas de tech desafio 1 listamos todos os resultados obtidos, e temos aqui um documento comprovando que a gente realmente avalia todos os projetos que vem para a gente.

2) Tem prazo para entregar este desafio?
Este será um projeto de longa duração, com prazo de encerramento em 1 de julho de 2022. Logo, você tem 6 meses para me entregar.

3) Quem vai avaliar o meu projeto?
Eu, Mateus Ávila Isidoro. Devo chamar mais algumas pessoas para avaliar, e quem foi bem demais no primeiro desafio.

4) Posso botar no github como projeto "pinado" para avaliadores olharem meus códigos?
Apesar da gente entender que é um código feito por você, entendemos que ele não deveria ser usado como destaque na sua conta de github. Ele é um exercício simples. Recomendamos deixar sempre uma solução 100% original com destaque. Mas se você quiser deixar lá, pode. mas dai depois de corrigir, tu troca as fotos e deixa mais original.

5) Posso usar algum framework tipo Boostrap, Sass, Stylus, React, Vue, Svelte, Wordpress, Tailwind, Astro, entre muitos outros?
Sim, fique a vontade. Se você usar algum framework, daremos pontos extras, pois o mercado exige que você saiba alguma coisa além do básico.

6) O formulário precisa estar funcionando?
Sim. Diferente da versão 1, a gente desta vez quer ver se você envia os dados certinho. Você pode enviar o seu objeto json para um console.log e fazer com que o formulário funcione de mentirinha. Desde que ele tenha uma tela de loading e do resultado como o designer projetou, tudo certo. Se você for fullstack, pode criar uma rota em qualquer framework que você conhece.

7) Pode usar alguma imagem diferente?
Apenas na sessão de notícias que o designer liberou a utilização de imagens diferentes. Nas outras, seja fiel ao design proposto.

8) Eu preciso subir este site numa URL pública?
Sim. Há serviços que podem ajudar nisto, como github pages, surge.sh, heroku. E há hospedagens apache bem baratinhas que podem ajudar você a entregar valor. Lembrando que sem este link, o seu projeto não será corrigido.

9) Eu preciso subir num repositório público?
Sim. Pode ser em qualquer serviço git, como github, gitlab ou bitbucket. Só que o repositório precisa ser público. Lembrando que sem este repositório, o seu projeto não será corrigido.

10) Preciso ter branches além da master (main)?
Não é necessário. Mas se criar branches, avise no seu README.md.

11) Pode fazer com algum colega, pra estudarmos juntos?
Sim. Fiquem a vontade. A avaliação será feita da mesma forma.

O que vamos avaliar?

Para facilitar o seu trabalho, vamos listar o que vamos avaliar neste projeto, de coisas que consideramos necessárias e opcionais que irão agregar valor. Lembre-se, quanto mais coisas o projeto tiver, mais atento iremos avaliar o seu projeto. Temos descritores obrigatórios e descritores opcionais, se eles serão ou não atendidos pelo código:

  1. Qualidade Geral do código: se o código possui clareza na leitura, utiliza nomenclaturas consistentes e é conciso.
  2. Se é fiel a proposta estabelecida: se o projeto atende as regras do briefing proposto acima.
  3. Projeto perfeitamente responsivo: se ele tem suporte de qualidade para celulares e tablets.
  4. Se é rápido o suficiente: se o site consegue responder em até 4 segundos a requisição inicial.
  5. Links aplicados da maneira correta: Se os links abrem em outra abra, e de maneira segura.
  6. As imagens estão nas extensões corretas, recomendadas e com a implementação otimizada: Se o desenvolvedor tomou cuidado com as imagens no projeto.
  7. Se o formulário está funcional: isto é, se atende as determinações que o designer projetou.
  8. Se o HTML está semântico: se fez bom uso das tags do HTML 5, evitou usar múltiplos H1s no projeto, entre outros.

Abaixo listamos os descritores opcionais, que agregarão valor ao projeto. Aqui é a parte que pode começar a impressionar o patrão:

  1. Se há animações, e elas são agradáveis ao olhar. Não é obrigatório ter animações, mas se houver, vamos validar se elas estão adequadas, se são performáticas e se elas fazem sentido ao projeto.
  2. Usou CSS Clip para criar polígonos ou Rotate de CSS em uma div
  3. Se usou CSS Grid para fazer a sessão Nosso compromisso
  4. Se deixou as fontes perfeitamente responsivas
  5. Se o menu no topo faz uma transição elegante quando fica ativo

Realmente impressionar o patrão (#vemBonus!)

Se você quer deixar o patrão feliz, faça algo a mais. Dicas de como impressionar o cara que assina o teu cheque:

  1. Usou fotos reais e notícias de verdade
  2. Fez a sessão de notícias virar um slider
  3. O README do seu projeto ser bem escrito
  4. Utilizou variáveis ou mixins de CSS ou de algum pré-processador
  5. Fez boa componentização do projeto
  6. Utilizou algum builder como Vite, Parcel, Gulp, Webpack
  7. Configurou algum framework como Nextjs, Nuxtjs, Gridsome, Gatsby, Svelte Kit
  8. Dark Mode
  9. Versão em inglês
  10. SEO e SEM, inclusive com imagem de compartilhamento para facebook
  11. Fez bom uso do git, como criando branches, commitando com mensagens que descrevem bem a tarefa que subiu
  12. Usou parallax no banner
  13. PWA
  14. Usou alguma técnica de cache
  15. Adicionou o bloco de uso de cookies (LGPD)
  16. O link de eventos for para eventos reais ou mandar para o calendly
  17. Criou uma API para o projeto
  18. Usou AVIF nas fotos

Bem, aqui é só para quem quer motivação para estudar um pouco mais.