/dev-hall-front-end-1

Desafio para Frontend iniciantes para o Dev Hall

Challenge Front end - desafio 1

Vamos corrigir o desafio, mas não pertencemos mais ao canal do discord Dev Hall. Seremos uma iniciativa autônoma e independente.

Nós, do servidor do discord Dev Hall, criamos este desafio para você testar suas habilidades como desenvolvedor Front End. Este é o nosso primeiro desafio, onde vamos pedir para vocês montarem o projeto Figma que geramos aqui: https://www.figma.com/file/oAzrbFOra5NuygvnsLZBcv/Desafio-Front-end?node-id=0%3A1

Lembrando que este desafio não é seleção. Mas se você for bem para caramba, vamos criar textão com o teu nome no linkedin. Por que não????

Briefing deste projeto (é de mentirinha, beleza!)

O cliente, que é um tremendo mão de vaca, solicitou um website simples que mostra que você sabe fazer um site. Para tanto, pediu para ter algumas questões importantes:

  • A foto de fundo precisa ocupar toda a dobra da página
  • O formulário precisa ter estes dois campos, de nome e whatsapp
  • O cliente exigiu que o site fosse responsivo, mas não pagou o designer para fazer as telas responsivas. E teu chefe tá pedindo pra tu se virar.
  • Não definiu nenhum hover, e nenhuma animação. Mas é o site que tu precisa fazer para ganhar aquele bônus no final do ano.

O cliente vai pagar algum desenvolvedor back end para fazer o formulário final, mas vai que você se empolga e entrega isto para o teu cliente. #vemBonus!

FAQ

1) Para quem é indicado este desafio?
Este desafio é indicado para qualquer desenvolvedor que está iniciando com html, css e javascript.

2) Tem prazo para entregar este desafio?
Não há prazo para término desta tarefa, entretanto recomendamos que, quando você iniciar este projeto, entregue em até 20 dias.

3) Quem vai avaliar o meu projeto?
Temos uma equipe de avaliadores que será convocada para avaliar o seu código, junto com o criador do 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.

5) Posso usar algum framework tipo Boostrap, Sass, Stylus, React, Vue, Svelte, Wordpress?
Sim. Fique a vontade.

6) O formulário precisa estar funcionando?
Não é obrigado ele estar funcionando, mas ganha pontos extras se ele estiver funcionando, nem que seja uma requisição de mentirinha.

7) Pode usar alguma imagem diferente?
Não. Gostaríamos de que você usasse a mesma imagem, para maior fidelidade.

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.

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.

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

11) Se eu quiser passar um orçamento de mentira, do tempo que eu iria fazer, e valores, posso? Pode sim. Para quem quiser treinar mandar orçamento para freelances, me manda que eu avalio com muito prazer.

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. Legibilidade do código: se o código possui clareza na leitura.
  2. Consistência nas nomenclaturas: se o código é consistente, isto é, usando sempre o mesmo padrão de nomes. Se ele usa camelCase, snake_case ou kebab-case.
  3. Concisão de código: se o código não é verboso demais sem necessidade, isto é, importar código demais sem necessidade.
  4. Se é fiel a proposta estabelecida: se o projeto atende as regras do briefing proposto.
  5. Projeto perfeitamente responsivo: se ele tem suporte de qualidade para celulares e tablets.
  6. Se é rápido o suficiente: se o site consegue responder em até 4 segundos a requisição inicial.
  7. Se os links externos das redes sociais estão apontando para uma nova aba: insira os links das redes sociais de qualquer site, mas precisa que eles estejam apontados para outras abas.
  8. Se o botão laranja da dobra faz o movimento de scroll para o formulário: Este é um comportamento obrigatório, para que o usuário tome a ação de preencher os campos.
  9. Aplicou hovers: os botões precisam ter algum hover. Seja criativo.
  10. Se as imagens estão nas extensões corretas e recomendadas: se usou svg para logos de redes sociais e png/jpg para as outras imagens.
  11. Se utilizou as fontes corretas, nos tamanhos e cores recomendadas pelo designer: Esperamos bastante fidelidade ao design proposto.

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. Se a máscara no input de telefone foi correta, impedindo a inclusão de letras e formatando um número.: Não é necessário mascarar o campo de telefone, mas se o fizer, que ele siga o padrão (99) 99999 9999.
  3. Se a requisição para o servidor apontar para o Método Post: Não é obrigatório fazer o formulário funcionar, mas vamos validar se ele faz a requisição para o método correto.
  4. Se o formulário funcionar, se o usuário terá os feedbacks necessários: Vamos validar se o formulário tem mensagens que mostrem que há erros de preenchimento de campos inválidos e vazios, e se no processamento da requisição o usuário receberá alguma informação que a requisição estará processando.
  5. Se o HTML está semântico: se as tags utilizadas neste projeto estão bem semânticas, e boas para SEO. HTML bonito ganha muitos pontos
  6. Se a área da dobra for uma imagem e uma div por cima: Se o desenvolvedor entendeu o uso de z-index.
  7. Se o hover utilizado tem transition de css: para que transitar rápido demais se pode ser elegante e feito com carinho.
  8. Se as imagens possuem os atributos corretos: se elas possuem largura, altura, loading e o texto alternativo.

Realmente impressionar o patrão (#vemBonus!)

Bom, texto grande, mas se você quiser realmente me impressionar, eu costumo adorar desenvolvedores que:

  1. Usam CSS puro ou pré-processador.
  2. Usam formatos de imagem como avif e webp.
  3. Tiram nota acima de 90 no lighthouse
  4. Animações feitas usando CSS animation
  5. Se usar algum framework em JS, usar muitas arrow functions e desestruturação de objetos
  6. Se criou em css puro, criou variáveis internas. Se usou algum pré-processador, criou variáveis e mixins.
  7. Se o layout dá suporte para telas acima de 300 pixels de largura (para iphones velhos).
  8. Se valida o campo de nome considerando sobrenome
  9. Se valida o campo de telefone considerando o tamanho recomendado
  10. Se após a requisição mostrar algum feedback bonitão.
  11. Se teve boas ideias de reutilização de código.
  12. Se o texto alternativo das imagens respeitar as pessoas com deficiência visual como pessoas empoderadas, não dando descrições vagas ou com julgamento de valor.
  13. Se usou Vite.js. Sério, Vite é sensacional! <3
  14. Dark Mode? Why not?
  15. Fez versão em inglês? Go on!
  16. Se usou css clip-path na sessão Nossa iniciativa
  17. O SEO tem as tags bem certinhas, inclusive com imagens para compartlihamento? Caramba
  18. PWA! UAU

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