Skip to content

Laboratoria/SAP009-social-network

Repository files navigation

Criando uma Rede Social

Índice


1. Prefácio

Instagram, Snapchat, Twitter, Facebook, Twitch, Linkedin, etc. As redes sociais invadiram nossas vidas. Nós as amamos ou odiamos, e muitas pessoas não conseguem viver sem elas.

adem-ay-Tk9m_HP4rgQ-unsplash

Há redes sociais de todo tipo para todos os tipos de interesse. Por exemplo: em uma rodada de financiamento com investidores, foi apresentada uma rede social para químicos onde os usuários podem publicar artigos a respeito de suas pesquisas, comentar os artigos de seus colegas e filtrar artigos de acordo com determinadas tags ou popularidade, mais recente ou mais comentado.

2. Resumo do projeto

Neste projeto você construirá uma Rede Social sobre o que você e sua equipe decidirem. Pode ser, por exemplo, sobre alimentação saudável, feminismo, educação, saúde, energias renováveis, amantes das Empanadas, de Tacos, de Feijoada, ou do que seja.

Sua Rede Social terá que permitir à qualquer usuário criar uma conta de acesso, logar-se com ela, criar, editar, deletar e dar likes em publicações.

O objetivo principal de aprendizagem deste projeto é construir uma Single-page Application (SPA) responsiva (com mais de uma tela/ página) na qual seja possível ler e escrever dados.

3. Objetivos de aprendizagem

Reflita e depois enumere os objetivos que quer alcançar e aplique no seu projeto. Pense nisso para decidir sua estratégia de trabalho.

HTML

CSS

Web APIs

JavaScript

  • Uso de linter (ESLINT)

  • Uso de identificadores descritivos (Nomenclatura e Semântica)

  • Diferença entre expressões (expressions) e declarações (statements)

  • Callbacks

    Links

Controle de Versões (Git e GitHub)

  • Git: Instalação e configuração

  • Git: Controle de versão com git (init, clone, add, commit, status, push, pull, remote)

  • Git: Integração de mudanças entre ramos (branch, checkout, fetch, merge, reset, rebase, tag)

  • GitHub: Criação de contas e repositórios, configuração de chave SSH

  • GitHub: Implantação com GitHub Pages

    Links

  • GitHub: Colaboração pelo Github (branches | forks | pull requests | code review | tags)

  • GitHub: Organização pelo Github (projects | issues | labels | milestones | releases)

Centrado no usuário

  • Desenhar e desenvolver um produto ou serviço colocando as usuárias no centro

Design de produto

  • Criar protótipos para obter feedback e iterar

  • Aplicar os princípios de desenho visual (contraste, alinhamento, hierarquia)

Pesquisa

  • Planejar e executar testes de usabilidade

Firebase

4. Considerações gerais

  • Este projeto deve ser desenvolvido em trios.

  • O intervalo de tempo estimado para concluir o projeto é de 4 a 5 Sprints.

  • A lógica do projeto deve estar implementada completamente em JavaScript (ES6+), HTML e CSS 😃. Para este projeto não está permitido o uso de frameworks ou bibliotecas de CSS e JS.

  • A divisão e organização do trabalho deve permitir, sem exceção, que cada integrante da equipe pratique a aprendizagem de tudo que está envolvido em cada história. Não dividam o trabalho como em uma fábrica.

  • Está avançando em seus projetos com alguma fluidez e sem grandes problemas? Seja generosa com suas parceiras, deixe-as aprender e praticar sem restrições, mesmo que demore um pouco mais. Aproveite para mentorá-las, para fazer pair programming. Uma das melhores formas de aprender é explicar verbalmente.

  • Está sentindo dificuldade e para você é mais difícil de avançar? Não fique com as partes "fáceis" do projeto. Converse, negocie, busque sua oportunidade de praticar e aprender o que é mais difícil para você.

  • Vocês apenas poderão trabalhar em uma história por vez. Não avancem para a próxima sem completar a anterior. As histórias apenas são concluídas quando se completam todos os critérios de aceitação + toda sua definição de pronto.

Para começar, você precisará criar um fork e clone deste repositório.

5. Critérios de aceitação mínimos do projeto

5.1 Boilerplate

Este projeto não inclui um boilerplate, portanto você terá que definir a estrutura de pastas e escrever seus próprios testes unitários (tests). Para isso, você pode guiar-se por meio de projetos anteriores. Este projeto não inclui um boilerplate completo, apenas alguns arquivos de configuração básica, então você terá que definir a estrutura de pastas e escrever seus próprios testes de unidade (tests). Para isso, você pode ser guiado por projetos anteriores e/ou organizar os arquivos seguindo uma estrutura de Model-View-Controller.

Neste projeto vamos utilizar uma ferramenta chamada Vite para empacotar nossos módulos e iniciar o servidor de desenvolvimento, que disponibiliza nossos arquivos usando a estratégia Hot Module Replacement (HMR), isso significa que quando você faz alterações em arquivos que estão sendo hosteados, o navegador será atualizado automaticamente sem a necessidade de fazê-lo manualmente para recarregar todo o site. Você deve ter um cuidado especial para não ter nenhuma dependência circular em seu código já que pode causar problemas com o HMR. (O eslint-plugin-import tem a regra import/no-cycle que notificará se os tiver.)

5.2 Definição do produto

No README.md, conte-nos brevemente como você mapeou as necessidades dos seus usuários e como você chegou à definição final do seu produto. É importante que detalhe:

  • Quem são os principais usuários do produto.
  • Qual problema o produto resolve/para que ele serve para esses usuários.

5.3 Histórias de usuário

Depois de entender as necessidades de seus usuários, escreva as Histórias de Usuário. Elas representam tudo o que ele precisa fazer/ver na Rede Social. Cada uma de suas histórias de usuário deve possuir:

  • Critérios de aceitação: tudo o que deve acontecer para satisfazer as necessidades do usuário.

  • Definição de pronto: todos os aspectos técnicos que devem ser atendidos para que, como equipe, saibam que essa história está finalizada e pronta para ser publicada. Todas suas histórias de usuário (com exceções), devem incluir esses aspectos em sua definição de pronto (além de tudo o que precisa adicionar):

    • Ser uma SPA.
    • Ser responsivo.
    • Receber code review de pelo menos uma parceira de outra equipe.
    • Fazer tests unitários.
    • Fazer testes manuais buscando erros e imperfeições simples.
    • Fazer testes de usabilidade e incorporar o feedback dos usuários como melhorias.
    • Fazer deploy do aplicativo e marcar a versão (git tag).

5.4 Desenho da Interface de Usuário (protótipo de baixa fidelidade)

Você deve definir qual será o fluxo que o usuário seguirá dentro do seu aplicativo e, com isso, criar a interface do usuário (UI) que siga este fluxo.

5.5 Responsivo

Deve funcionar bem em dispositivos de tela grande (computadores, laptops etc.) e pequena (tablets, telefones celulares etc.). Sugerimos seguir a técnica mobile first (mais detalhes sobre essa técnica ao final).

5.6 Considerações sobre o comportamento da Interface do Usuário (UI)

Essas considerações ajudarão você a escrever as definições de pronto de sua H.U.:

Criação e login de conta de usuário

  • Login com Firebase:
    • Para o login e postagens na timeline, você pode usar o Firebase
    • O usuário deve poder criar uma conta de acesso ou autenticar-se com conta de e-mail e senha e também com uma conta do Google.
  • Validações:
    • Somente usuários com contas válidas têm acesso permitido.
    • Não haver usuários repetidos.
    • O que o usuário digita no campo de senha (input) deve ser secreto.
  • Comportamento:
    • Quando o formulário de registro ou login é enviado, ele deve ser validado.
    • Se houver erros, mensagens descritivas devem ser exibidas para ajudar o usuário.

Timeline/linha do tempo

  • Validações:
    • Ao publicar, deve ser validado se há conteúdo no input.
  • Comportamento:
    • Ao recarregar o aplicativo, é necessário verificar se o usuário está logado antes de exibir o conteúdo,
    • Conseguir publicar um post.
    • Poder dar e remover likes em uma publicação. Máximo de um por usuário.
    • Visualizar contagem de likes.
    • Poder excluir uma postagem específica.
    • Solicitar confirmação antes de excluir um post.
    • Ao clicar em editar um post, você deve alterar o texto para um input que permite editar o texto e salvar as alterações.
    • Ao salvar as alterações, você deve voltar ao texto normal, mas com a informação editada.
    • Ao recarregar a página, poder ver os textos editados.

5.7 Considerações técnicas sobre front-end

  • Separar a manipulação do DOM da lógica (separação de responsabilidades).
  • Ter várias telas. Para isso, seu aplicativo deve ser um Single Page Application (SPA)
  • Alterar e persistir dados. Os dados que você adiciona ou modifica devem persistir por todo o aplicativo. Recomendamos que você use o Firebase para isso também.

Testes unitários

  • Lembre-se de que não há setup de testes definido, isso dependerá da estrutura do seu projeto. Você não deve esquecer de pensar sobre os testes. Eles podem ajudar a definir a estrutura e sua lógica.

  • Os testes de unidade devem cobrir no mínimo 70% de statements, functions, lines e branches.

5.8 Considerações técnicas UX

  • Faça pelo menos 2 entrevistas com os usuários.
  • Faça um protótipo de baixa e alta fidelidade.
  • Verifique se a implementação do código segue as diretrizes do protótipo.
  • Faça sessões de teste de usabilidade com o produto em HTML.

6. Hacker Edition

As seções chamadas Hacker Edition são opcionais. Se você terminou e cumpriu todos os requisitos acima e sobrou tempo, tente concluí-las. Dessa forma, você pode aprofundar e/ou exercitar mais os objetivos de aprendizagem do projeto.

  • Criar posts com imagens.
  • Procurar usuários, adicionar e excluir "amigos".
  • Definir a privacidade de posts (público ou apenas para amigos).
  • Permitir ver na linha do tempo de usuários "não amigos" apenas os posts públicos.
  • Permitir comentar ou responder a uma postagem.
  • Editar perfil.

7. Entrega

O projeto será entregue subindo seu código no GitHub (commit /push) e a interface será exibida usando páginas do GitHub ou outro serviço de hospedagem (Firebase, Netlify, Vercel, etc) que você pode ter encontrado pelo caminho. Verifica a Documentação Vite para orientá-lo sobre isso.


8. Guias, dicas e leituras complementares

Mobile first

O conceito de mobile first faz referência a um processo de desenho e desenvolvimento que parte de como se vê e como funciona uma aplicação primeiro em um dispositivo móvel e mais adiante se analisa como adaptar a aplicação à telas progressivamente maiores. Esta é uma contraposição ao modelo tradicional, no qual primeiro se desenha os websites (ou webapps) para desktops e depois os adaptam para telas menores.

A motivação aqui é se assegurar que desde o começo sejam desenhadas telas responsivas. Dessa forma, começamos com a aparência e o comportamento do aplicativo em uma tela e ambiente móvel.

Múltiplas telas

Em projetos anteriores, nossas aplicações eram compostas de apenas uma tela principal (uma só página). Neste projeto, precisaremos dividir nossa interface em várias views ou pages e oferecer uma maneira de navegar entre essas telas. Esse problema pode ser resolvido de várias maneiras: com arquivos HTML independentes (cada um com seu próprio URL) e links tradicionais; mantendo na memória e renderizando condicionalmente (sem atualizar a página); manipulando o histórico do navegador com window.history. Neste projeto, convidamos você a explorar opções e decidir sobre uma opção de implementação.

Gravação de dados

Nos projetos anteriores, consumimos dados, mas ainda não tínhamos escrito dados (salvar alterações, criar dados, excluir, etc). Neste projeto, você precisará criar (salvar) novos dados, além de ler, atualizar e modificar os dados existentes. Esses dados podem ser salvos remotamente usando o Firebase.

Para usar o Firebase, você deve criar um projeto no console do Firebase e instale a dependência firebase usando npm. Leia instruções passo a passo aqui.

Outras:

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published