- 1. Prefácio
- 2. Students 2 Students
- 3. Histórias de Usuário
- 4. Protótipo de Baixa Fidelidade
- 5. Protótipo de Alta Fidelidade
- 6. Resposividade
- 7. Teste de Usabilidade
- 8. Testes Unitários
- 9. Considerações Técnicas
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.
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.
Neste projeto construímos uma Rede Social voltada para estudantes da Língua Inglesa interessados em praticar o idioma com outros estudantes, postando informações os mais variados assuntos, desde regras gramaticais à interesses pessoais.
Chegamos à definição final do produto através de pesquisa com usuários reais, que demonstraram interesse em um espaço de compartilhamento de conhecimentos e prática. Identificamos que a maioria dos interessados (40%) se encontravam na faixa etária dos 31 à 40 anos de idade, e com isso conseguimos definir a identidade visual da Students 2 Students - cores que representam tranquilidade e comunicação. Também definimos o inglês como idioma padrão de toda a aplicação (com exceção da página inicial, que explica o produto para visitantes), visto que aproximadamente 50% dos usuários possuem nível de Inglês Intermediário.
Eu, como estudante de inglês, gostaria de me cadastrar e fazer login em uma rede social para trocar experiências com outros estudantes do idioma.
Para atender ao primeiro usuário, definimos os seguintes critérios de aceitação:
- Página inicial explicativa.
- Header com direcionamento para a tela de login e de cadastro.
- Campos de preenchimento de dados.
- Mensagens de erro descritivas.
- Link para recuperação de senha.
Eu, como estudante de inglês, gostaria de logar na rede social Students 2 Students utilizando minha conta do Google, para me conectar com mais facilidade.
Para o segundo usuário, os seguintes critérios de aceitação foram estabelecidos:
- Botão para login com google.
- Pop-up onde o usuário pode selecionar a conta do google que deseja utilizar.
Eu, como cadastrado no app s2s, gostaria de compartilhar textos em inglês com outras pessoas que também estão aprendendo o idioma para praticar a minha escrita.
Os critérios de aceitação para a terceira história de usuário foram os seguintes:
- Tela da timeline.
- Campo para digitação de texto.
- Botão para compartilhar.
Eu, como cadastrado no app s2s, gostaria de visualizar postagens de outros usuários e curtir e descurti-las quando desejar para expressar o que é interessante para mim.
O quarto usuário teve os seguintes critérios de aceitação atendidos:
- Timeline com posts de diversos usuários.
- Botão de curtir e descurtir.
Eu, como cadastrado no app s2s, gostaria de editar e excluir textos que eu postei para atualizá-los.
Os seguintes critérios de aceitação foram atendidos para o quinto usuário:
- Botão para editar postagem.
- Caixa de texto editável.
- Botão para salvar edição.
- Botão para cancelar a edição.
- Botão para excluir postagem.
- Confirmação de exclusão.
Nos primeiros rascunhos, o Students 2 Students foi surgindo já bem parecido com o produto final. Prototipamos uma tela inicial com explicações sobre o objetivo do produto, tela de login e de cadastro com os campos necessários para o preenchimento das informações pessoais dos usuários.
Já a timeline não ficou tão bem definida inicialmente. Pensamos em criar comunidades, onde os usuários poderiam criar postagens sobre temas específicos. Porém, devido ao tempo estimado para a entrega do projeto, decidimos criar apenas uma timeline principal, que fica melhor definida com os protótipos de alta fidelidade.
Com o protótipo de alta fidelidade, a identidade visual da Students 2 Students se tornou visível. Poucas alterações foram feitas.
E, como dito anteriormente, precisamos abrir mão do feed das comunidades para focar nos objetivos de aprendizagem e no prazo estimado para entrega.
Todas as telas da nossa aplicação foram prototipadas e criadas a partir do conceito Mobile First, pensando primeiramente em telas de dispositivos móveis. Mais tarde, aplicamos a responsividade para telas de desktop, tornando a S2S adaptável para ser acessada em qualquer dispositivo.
Realizamos testes de usabilidade com usuários reais para diagnosticar qualquer dificuldade ou erro que pudesse ser encontrada em nossa aplicação. Os seguintes problemas foram percebidos:
- Ao clicar no menu hamburguer, abre-se uma barra lateral. Porém, esta só se fecha ao clicar em um botão de fechar, mas não fecha quando clicamos em outros locais da tela.
- O header das telas de feed, FAQ e About Us não estão fixos. Assim, o usuário precisa rolar até o topo da tela para ter acesso ao menu.
- Os links do GitHub e LinkedIn não abrem em nova página, sendo necessário retornar ao site.
- Apesar da notificação de erro quando as senhas não são iguais, o cadastro é criado normalmente. O mesmo acontece com o erro de username caso o valor inserido não tenha a quantidade de caracteres estabelecida.
- Ao redefinir senha pelo link enviado por email, o usuário não é redirecionado para a rede social.
- Não há opção de visualização da senha que está sendo inserida.
Para este projeto, deveríamos construir os testes unitários necessários, que deveriam cobrir um mínimo de 70% dos statements, branches, lines e functions. Nossos testes ultrapassaram essa porcentagem, porém não atingiram 100%, conforme visto na imagem abaixo:
Com este projeto, os seguintes objetivos de aprendizagem foram atingidos:
-
Uso de HTML semântico
-
Uso de seletores de CSS
-
Modelo de caixa (box model): borda, margem, preenchimento
-
Uso de flexbox em CSS
-
Uso de CSS Grid Layout
-
Uso de seletores de DOM
-
Manipulação de eventos de DOM (listeners, propagação, delegação)
-
Manipulação dinâmica de DOM
-
Routing (History API, evento hashchange, window.location)
-
Arrays (arranjos)
-
Objetos (key, value)
-
Diferenciar entre tipos de dados primitivos e não primitivos
-
Variáveis (declaração, atribuição, escopo)
-
Uso de condicionais (if-else, switch, operador ternário, lógica booleana)
-
Uso de laços (while, for, for..of)
-
Funções (params, args, return)
-
Testes unitários (unit tests)
-
Testes assíncronos
-
Uso de mocks e espiões
-
Módulos de ECMAScript (ES modules)
-
Uso de linter (ESLINT)
-
Uso de identificadores descritivos (Nomenclatura e Semântica)
-
Diferença entre expressões (expressions) e declarações (statements)
-
Callbacks
-
Promessas
-
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
-
GitHub: Colaboração pelo Github (branches | forks | pull requests | code review | tags)
-
GitHub: Organização pelo Github (projects | issues | labels | milestones | releases)
- Desenhar e desenvolver um produto ou serviço colocando as usuárias no centro
-
Criar protótipos para obter feedback e iterar
-
Aplicar os princípios de desenho visual (contraste, alinhamento, hierarquia)
- Planejar e executar testes de usabilidade
-
Firebase Auth
-
Firestore
-
Este projeto foi desenvolvido em trios.
-
A lógica do projeto deve está implementada completamente em JavaScript (ES6+), HTML e CSS 😃. Não foi feito uso de frameworks ou bibliotecas de CSS e JS.
Para este projeto, definimos a estrutura de pastas e escrevemos nossos próprios testes unitários (tests). Para isso, nos guiamos por meio de projetos anteriores.
Neste projeto utilizamos 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 fazemos 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. Tivemos um
cuidado especial para não ter nenhuma dependência circular no 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.)
- Login com Firebase:
- Para o login e postagens na timeline, usamos o Firebase
- O usuário pode 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 háusuários repetidos.
- O que o usuário digita no campo de senha (input) é secreto.
- Comportamento:
- Quando o formulário de registro é enviado, ele é validado.
- Quando ocorrem erros, mensagens descritivas são exibidas para ajudar o usuário.
- Validações:
- Ao publicar, é validado se há conteúdo no input.
- Comportamento:
- Ao recarregar o aplicativo, é verificado se o usuário está logado antes de exibir o conteúdo,
- É possível publicar um post.
- É possível dar e remover likes em uma publicação. Máximo de um por usuário.
- Visualizar contagem de likes.
- Pode excluir uma postagem específica.
- Solicita confirmação antes de excluir um post.
- Ao clicar em editar um post, o texto é alterado para um input que permite editar o texto e salvar as alterações.
- Ao salvar as alterações, volta ao texto normal, mas com a informação editada.
- Ao recarregar a página, pode-se ver os textos editados.
- A manipulação do DOM está separada da lógica (separação de responsabilidades).
- Há várias telas. Para isso, nosso aplicativo é um Single Page Application (SPA)
- Alterar e persistir dados. Os dados que você adiciona ou modifica persistem por todo o aplicativo. Utilizamos o Firebase para isso também.