Os requerimentos técnicos para esse projeto são os seguintes:
Além disso, esse desafio tinha outra particularidade: fazê-lo com um(a) colega de classe escolhido(a) aleatoriamente, o que implicaria o uso de ferramentas colaborativas como Trello e Git.
Meu companheiro de projeto Álvaro e eu (da esquerda: 1º e 3º) junto com Juan e Mateus (da esquerda: 2º e 4º), também ganhadores desta segunda rodada, com sua plataforma colaborativa para alunos da Ironhack.
I. O processo
1) Idealização
Depois de presenciar um aumento de publicações em redes sociais sobre instituições protetoras dos animais estarem saturadas e ofertas de adoção, decidi explorar que tipos de plataformas ofereciam a Comunidade de Madri e a Prefeitura a seus cidadãos.
Ambos os portais são antiquados e, ainda que centralizem parte da oferta de animais, é complicado – para não dizer impossível – filtrar o conteúdo e realizar buscas eficientes. Por outro lado, conheço pessoas que, no passado, tentaram encontrar um pet na internet usando esses portais e todas levavam a creer que um redesign da experiência de usuário seria necessário.
Portanto, definimos as seguintes prioridades estratégicas para nosso projeto:
Objetivo: criar a ferramenta de referência em nossa comunidade para conectar pessoas e centros de adoção de animais.
Outro aspecto importante, é ter em conta para quem estamos criando. Definimos nosso público a partir de casos reais:
“Quero poder buscar um pet que se ajuste à minha situação atual e de forma ágil.”, Elena – estudo de caso.
2) Prototipagem
Antes de começarmos a construção, definimos os planos do terreno. Em um primeiro momento, fizemos no papel a partir de nossas user stories, e a continuação no Sketch.
Definir o caminho do usuário nos ajudou muito, tanto para o layout como para o desenvolvimento do back-end, na definição das rotas no ExpressJS.
Por se tratar de um Produto Mínimo Viável (MVP), decidimos limitar nossa plataforma a:
1 landing
2 categorias (pets e centros)
2 páginas de detalhe (detalhe dos pets e detalhe de centros)
1 módulo de login e signup
Por outro lado, por se tratar de uma plataforma com muita informação, optei por usar cartões para representar a unidade mínima de conteúdo (o pet). Esta opção, comparada com tabelas e listas, nos permite preparar o terreno para a versão mobile do nosso produto.
3) Interface de usuário
Finalmente, depois de ter elaborado um protótipo de cada tela e montado a arquitetura da informação – muito simples para este MVP – me pus a trabalhar em uma primeira aproximação do plano visual.
4) Back-end
O back de Madri Adota está montado com Express e NodeJS e conta com uma base de dados com MongoDB, à qual nos conectamos com Mongoose. Decidimos criar um total de 4 modelos:
Usuários: estão divididos em três tipos (usuários, admin e superadmin) e nos permite atribuir a cada um diferentes permissões.
Pets: nosso “produto”, por assim dizer, dentro da plataforma. O pet só pode ser adicionado pelo admin de um centro e vai associado a esse (um pet só pode pertencer a um centro)
Centro: é possível fazer uma solicitação de criação de novo centro a partir de um formulário. Se aprovado por um superadmin, o usuário que o solicitou recebe um upgrade a admin, cria-se o novo centro na base de dados e associa-se o status de admin a esse usuário.
Solicitação de criação de novo centro: similar a um pagamento, a solicitação possui três estados (em curso, aprovada e negada) e está associada ao usuário que a criou, além de incluir os dados do novo centro.
Um dos desafios mais interessantes na configuração do back-end foi a definição das rotas protegidas com middlewares e autenticação com PassportJS.
Sobre esse último aspecto, ao se tratar de uma página na qual a identidade do usuário não é particularmente relevante, decidimos não utilizar logins com redes sociais ou pedir dados no formulário de registro.
5) APIs e bibliotecas
Desenvolver Madri Adota foi uma excelente oportunidade para consolidar os conhecimentos sobre o uso de APIs e serviços externos. Estas são as 5 APIs e bibliotecas mais importantes para o funcionamento desse projeto:
Cloudinary: serviço de hospedagem de imagens na nuvem. Vital para que os administradores de centros subam as fotos dos pets.
Nodemailer: permite montar um sistema de envio automático de emails que nos ajuda a confirmar o endereço de um usuário, além de servir de canal de comunicação entre os usuários e as unidades protetoras dos animais.
Dog API: uma API divertida que nos ajudou a criar os seeds. Os seeds são simplesmente dados de preenchimento para povoar nossa base de dados e poder fazer testes. Nesse caso, Dog API nos permitiu obter imagens aleatórias de cães para preencher a seção de pets.
Google Maps Geocoding: permite converter um endereço postal introduzido com linguagem normal à dados que podemos usar no Google Maps ( { lat: 0.0, lng: 0,0 }). Usei essa API para incluir o mapa que aparece no perfil de cada um dos centros de adoção.
Moment.js: esta biblioteca é imprescindível para lidar com datas. No caso de Madri Adota, foi usada para converter as datas de nascimento dos pets em meses ou anos, expressando sua idade nos cartões, como pode-se ver a seguir:
Moment.js permite converter um objeto “Date” a uma linguagem natural de forma simples.
6) Front-end
Se me lembro bem, Madri Adota é o primeiro projeto em que trabalhei com SASS/SCSS. Para mim, tem sido uma descoberta, dado que sempre trabalhei com folhas de estilo CSS.
Para o layout, decidi não usar Bootstrap e outros frameworks e fazer por conta própria todo o grid e flexbox.
O verdadeiro herói dessa etapa do processo foi o HandleBars. Pessoalmente, gostei muito da sua usabilidade para escrever dados no front-end e a magia de seus partials que podem ser reutilizados como componentes. Em contrapartida, trabalhar com condicionais pode resultar em algo complicado, de modo que é preferível filtrar as informações desde o back-end (sempre é possível adicionar helpers a HandleBars para operações mais complexas).
Aproveitei minha experiência com CSS e JQuery para a interação como, por exemplo, animar os cartões em “hover” e inclusive poder filtrar os pets por sexo, raça e tamanho.
II. Lições aprendidas
Trabalhar 5 dias nessa plataforma e lançar o produto foi uma experiência muito enriquecedora. As grandes lições que levo são as seguintes:
Sempre ter claras as rotas antes de começar a trabalhar com o router do Express. As user stories ajudam a identificar quais páginas serão necessárias e quem terá acesso a elas.
Feedback é importante. Criar páginas de erro (404, por exemplo) que ofereçam rotas alternativas são de agradecer e somam à experiência de usuário.
Se você vai criar emails com Nodemailer, MJML pode ser uma opção maravilhosa para desenhar páginas.
JQuery não é uma boa opção para criar filtros. É complexo e lento. Com mais tempo, teria estudado uma forma de fazê-lo usando Axios e lançando novas consultas à base de dados.
Se você não gosta do estilo de Bootstrap, pode incluir somente seu sistema de grid. Isso ajuda a ir mais rápido na hora de desenvolver e evita criar muitas media-queries (para responsividade da plataforma).
Se quer saber mais sobre Ironhack, visite nossa página de desenvolvimento web.
Texto por Abdallah Aberouch – UX Designer & Desenvolvedor Full Stack
