Red social creada para amantes de la gastronomía que desean hacer comunidad y compartir sus secretos culinarios, recetas y recomendaciones. Permite a los usuarios crearse una cuenta con su correo y contraseña o utilizando una cuenta de google e ingresar a la aplicación. El usuario puede crear, editar, borrar y dar me gusta a publicaciones.
- Adultos desde jóvenes de entre 20 a 40 años que son aficionados a la cocina y gastronomía que desean formar una comunidad e interactuar con personas entusiastas como ellos mediante sus publicaciones y dando me gusta a las publicaciones de otros usuarios.
-
Mobile
-
Desktop
1. Como amante de la gastronomía Quiero relacionarme con otras personas con los mismos intereses Para compartir recetas, secretos culinarios, recomendaciones de restaurantes, etc.
Criterios de aceptación
- Crear red social para amantes de la gastronomía
- Que usuario pueda ir a de una vista a otra haciendo click
Definición de terminado
- Prototipo de Baja fidelidad
- Prototipo de alta fidelidad
- Html con secciones que pasen de una vista a otra usando url
- Que el código sea subido al repositorio
2. Como usuario Quiero poder registrarme con correo y contraseña o con google Para pertenecer a la The Social Food
Criterios de aceptación
- Interfaz con campos de texto para que el usuario ingrese sus datos: nombre, correo y contraseña
- El correo debe ser una cuenta válida
- Si el correo no es válido, mostrar un mensaje indicándolo
- Que la contraseña tenga 6 o más caracteres
- Solo se puede crear un usuario por correo y si el correo ya existe debe mostrar un mensaje
- Los campos no deben estar vacíos, si no debe mostrar un mensaje
- Bbotón para registrarse
- El usuario puede registrarse por autenticación de Google
- Una vez registrado, el usuario debe verificar su correo a través del email que se le envió.
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
3. Como usuario Quiero poder loguearme con correo y contraseña o con google Para ingresar a la aplicación
Criterios de aceptación
- Interfaz con campos de texto para que el usuario ingrese sus datos: correo y contraseña
- El correo debe estar registrado y ser una cuenta verificada
- Si el correo no está registrado y verificado, debe mostrar un mensaje indicándolo
- Si la contraseña es incorrecta debe mostrar un mensaje indicandolo
- Los campos no deben estar vacíos, sino debe mostrar un mensaje indicandolo
- Debe haber un botón para el logueo
- El usuario puede iniciar sesión por autenticación de google
- Si los datos del usuario son válidos se debe redireccionar a la vista home
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
4. Como usuario Quiero visualizar una página principal Para poder publicar y ver publicaciones de otros usuarios
Criterios de aceptación
- Que haya una barra de navegación
- Que haya un área donde pueda escribir mis post
- Que pueda ver mi información de usuario: nombre, foto
- Quiero por ver un area con todos los post en general ya publicados
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
Criterios de aceptación
- Que haya un campo de texto para ingresar mi opinión
- Que haya un botón para publicar mi post
- Que se observe el post nuevo sin recargar la página
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
Criterios de aceptación
- Que haya una opción de eliminar con un ícono
- Que solo se puedan ver en mis publicaciones
- Que se elimine al dar click
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
Criterios de aceptación
- Que haya una opción de editar con un ícono
- Que solo se puedan ver en mis publicaciones
- Al dar click en editar que pareza el botón guardar
- Que se habilite el área para poder escribir, al dar click en el ícono de editar
- Que luego de editar mi publicación y guarde, que se actualice sin recargar la página
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
8. Como usuario Quiero poder dar y quitar me gusta a las publicaciones Para mostrar que me gustó o no la publicación
Criterios de aceptación
- Que haya un ícono de me gusta
- Que se pueda dar me gusta a las publicaciones
- Al dar click a ícono que se aumente el número de me gusta
- Que se pueda quitar el me gusta a las publicaciones
- Al quitar el me gusta que disminuya el número de me gusta
Definición de terminado
- Debe ser una SPA
- Debe ser responsive
- Code review
- Que el código sea subido al repositorio
- Que pase test unitario
- 1. Preámbulo
- 2. Resumen del proyecto
- 3. Objetivos de aprendizaje
- 4. Consideraciones generales
- 5. Criterios de aceptación mínimos del proyecto
- 6. Hacker edition
- 7. Entrega
- 8. Pistas, tips y lecturas complementarias
Instagram, Snapchat, Twitter, Facebook, Twitch, Linkedin, etc. Las redes sociales han invadido nuestras vidas. Las amamos u odiamos, y muchos no podemos vivir sin ellas.
Hay redes sociales de todo tipo y para todo tipo de intereses. Por ejemplo, en una ronda de financiamiento con inversionistas, se presentó una red social para químicos en la que los usuarios podían publicar artículos sobre sus investigaciones, comentar en los artículos de sus colegas, y filtrar artículos de acuerdo a determinadas etiquetas o su popularidad, lo más reciente, o lo más comentado.
En este proyecto construirás una Red Social sobre lo que decidan tú y tu equipo. Podría ser, por ejemplo, sobre alimentación saludable, feminismo, educación, salud, energías renovables, amantes de las Empanadas o de los Tacos de Canasta, de la Feijoada, o de lo que sea.
Tu Red Social tendrá que permitir a cualquier usuario crear una cuenta de acceso y loguearse con ella; crear, editar, borrar y "likear" publicacciones.
El objetivo principal de aprendizaje de este proyecto es construir una Single-page Application (SPA) responsive (con más de una vista / página) en la que podamos leer y escribir datos.
Reflexiona y luego marca los objetivos que has llegado a entender y aplicar en tu proyecto. Piensa en eso al decidir tu estrategia de trabajo.
-
Uso de HTML semántico
-
Uso de selectores de CSS
-
Modelo de caja (box model): borde, margen, padding
-
Uso de flexbox en CSS
-
Uso de CSS Grid Layout
-
Uso de selectores del DOM
-
Manejo de eventos del DOM (listeners, propagación, delegación)
-
Manipulación dinámica del DOM
-
Ruteado (History API, evento hashchange, window.location)
-
Arrays (arreglos)
-
Objetos (key, value)
-
Diferenciar entre tipos de datos primitivos y no primitivos
-
Variables (declaración, asignación, ámbito)
-
Uso de condicionales (if-else, switch, operador ternario, lógica booleana)
-
Uso de bucles/ciclos (while, for, for..of)
-
Funciones (params, args, return)
-
Pruebas unitarias (unit tests)
-
Pruebas asíncronas
-
Uso de mocks y espías
-
Módulos de ECMAScript (ES Modules)
-
Uso de linter (ESLINT)
-
Uso de identificadores descriptivos (Nomenclatura y Semántica)
-
Diferenciar entre expresiones (expressions) y sentencias (statements)
-
Callbacks
-
Promesas
-
Git: Instalación y configuración
-
Git: Control de versiones con git (init, clone, add, commit, status, push, pull, remote)
-
Git: Integración de cambios entre ramas (branch, checkout, fetch, merge, reset, rebase, tag)
-
GitHub: Creación de cuenta y repos, configuración de llaves SSH
-
GitHub: Despliegue con GitHub Pages
-
GitHub: Colaboración en Github (branches | forks | pull requests | code review | tags)
-
GitHub: Organización en Github (projects | issues | labels | milestones | releases)
- Diseñar un producto o servicio poniendo a la usuaria en el centro
-
Crear prototipos de alta fidelidad que incluyan interacciones
-
Seguir los principios básicos de diseño visual
-
Planear y ejecutar testeos de usabilidad de prototipos en distintos niveles de fidelidad
-
Firebase Auth
-
Firestore
-
Este proyecto se debe trabajar en equipos de tres.
-
La lógica del proyecto debe estar implementada completamente en JavaScript (ES6+), HTML y CSS 😃. Para este proyecto no está permitido utilizar frameworks o librerías de CSS y JS.
-
La división y organización del trabajo debe permitir, sin excepciones, que cada integrante del equipo practique el aprendizaje de todo lo involucrado en cada historia. No se dividan el trabajo como en una fábrica.
-
¿Hasta acá has avanzado en tus proyectos con cierta fluidez y sin mayores problemas? Sé generosa con tus compañeras, permíteles aprender y practicar sin restricciones, aunque tome un poco más de tiempo. Aproveha de coachearlas, de hacer pair programming, una de las mejores maneras de aprender es explicando verbalmente.
-
¿Se te está haciendo difícil y te cuesta un poco más avanzar? No te quedes con las partes "fáciles" del proyecto, conversa, negocia, exige tu oportunidad para practicar y aprender lo que se te hace más difícil.
-
-
Solamente pueden trabajar en una única historia por vez, no pueden avanzar a la siguiente sin haber completado la anterior. La historia se completa cuando se cumplen todos sus Criterios de Aceptación + toda su Definición de Terminado.
Para comenzar tendrás que hacer un fork y clonar este repositorio.
Este proyecto no incluye un boilerplate, así es que tendrás que definir la estructura de carpetas y escribir tus propias Pruebas Unitarias (tests). Para hacerlo, puedes guiarte de los proyectos anteriores.
En el README.md cuéntanos brevemente cómo descubriste las necesidades de los
usuarios y cómo llegaste a la definición final de tu producto. Es importante
que detalles:
- Quiénes son los principales usuarios de producto.
- Qué problema resuelve el producto / para qué le servirá a estos usuarios.
Una vez que entiendas las necesidades de tus usuarixs, escribe las Historias de Usuario que representen todo lo que necesitan hacer/ver en la Red Social. Cada una de tus Historias de Usuario debe tener:
-
Criterios de Aceptación: todo lo que debe ocurrir para satisfacer las necesidades del usuario.
-
Definición de terminado: todos los aspectos técnicos que deben cumplirse para que, como equipo, sepan que esa historia está terminada y lista para publicarse. Todas tus Historias de Usuario (salvo excepciones), deben incluir estos aspectos en su Definición de Terminado (más todo lo que necesiten agregar):
- Debe ser una SPA.
- Debe ser responsive.
- Deben haber recibido code review de al menos una compañera de otro equipo.
- Hicieron los test unitarios
- Testearon manualmente buscando errores e imperfecciones simples.
- Hicieron pruebas de usabilidad e incorporaron el feedback de los usuarios como mejoras.
- Desplegaron su aplicación y etiquetaron la versión (git tag).
Debes definir cuál será el flujo que seguirá el usuario dentro de tu aplicación y, con eso, diseña la Interfaz de Usuario (UI por sus siglas en inglés) que siga este flujo.
Debe verse bien en dispositivos de pantallas grandes
(computadoras/es, laptops, etc.) y pequeñas (tablets, celulares, etc.). Te
sugerimos seguir la técnica de mobile first (más detalles sobre esta técnica
al final).
Estas consideraciones te ayudarán a escribir las Definiciones de Terminado de tus H.U.:
- Login con Firebase:
- Para el login y las publicaciones en el muro puedes utilizar Firebase
- Creación de cuenta de acceso y autenticación con cuenta de correo y contraseña, y también con una cuenta de Google.
- Validaciones:
- Solamente se permite el acceso a usuarios con cuentas válidas.
- No pueden haber usuarios repetidos.
- La cuenta de usuario debe ser un correo electrónico válido.
- Lo que se escriba en el campo (input) de contraseña debe ser secreto.
- Comportamiento:
- Al enviarse el formulario de registro o inicio de sesión, debe validarse.
- Si hay errores, se deben mostrar mensajes descriptivos para ayudar al usuario a corregirlos.
- Validaciones:
- Al publicar, se debe validar que exista contenido en el input.
- Comportamiento:
- Al recargar la aplicación, se debe verificar si el usuario está logueado antes de mostrar contenido.
- Poder publicar un post.
- Poder dar y quitar like a una publicación. Máximo uno por usuario.
- Llevar un conteo de los likes.
- Poder eliminar un post específico.
- Pedir confirmación antes de eliminar un post.
- Al dar click para editar un post, debe cambiar el texto por un input que permita editar el texto y luego guardar los cambios.
- Al guardar los cambios debe cambiar de vuelta a un texto normal pero con la información editada.
- Al recargar la página debo de poder ver los textos editados.
- Separar la manipulación del DOM de la lógica (Separación de responsabilidades).
- Contar con múltiples vistas. Para esto, tu aplicación debe ser una Single Page Application (SPA)
- Alterar y persistir datos. Los datos que agregues o modifiques deberán persistir a lo largo de la aplicación. Te recomendamos que uses Firebase para eso también.
-
Recuerda que no hay un setup de tests definido, dependerá de la estructura de tu proyecto. Algo que no debes de olvidar es pensar en éstas pruebas, te pueden ayudar a definir la estructura y nomenclatura de tu lógica.
-
Los tests unitarios deben cubrir un mínimo del 70% de statements, functions, lines, y branches.
- Hacer al menos 2 entrevistas con usuarios.
- Hacer un prototipo de baja fidelidad.
- Asegurarte de que la implementación en código siga los lineamientos del diseño.
- Hacer sesiones de testing de usabilidad con el producto en HTML.
Las secciones llamadas Hacker Edition son opcionales. Si terminaste con todo lo anterior y te queda tiempo, intenta completarlas. Así podrás profundizar y/o ejercitar más sobre los objetivos de aprendizaje del proyecto.
- Permite crear posts con imágenes.
- Permite buscar usuarios, agregar y eliminar "amigos".
- Permite definir la privacidad de los posts (público o solamente para amigos).
- Permite ver su muro de cualquier usuario "no-amigo" (solamente los posts públicos).
- Permite comentar o responder una publicación.
- Permite editar perfil.
El proyecto será entregado subiendo tu código a GitHub (commit/push) y la
interfaz será desplegada usando GitHub pages u otro servicio de hosting que
puedas haber encontrado en el camino.
El concepto de mobile first hace referencia a un proceso de diseño y desarrollo donde partimos de cómo se ve y cómo funciona la aplicación en un dispositivo móvil primero, y más adelante se ve como adaptar la aplicación a pantallas progresivamente grandes y características específicas del entorno desktop. Esto es en contraposición al modelo tradicional, donde primero se diseñaban los websites (o webapps) para desktop y después se trataba de arrugar el diseño para que entre en pantallas más chicas. La clave acá es asegurarse de que desde el principio diseñan usando la vista responsive de las herramientas de desarrollador (developer tools) del navegador. De esa forma, partimos de cómo se ve y comporta la aplicación en una pantalla y entorno móvil.
En proyectos anteriores nuestras aplicaciones habían estado compuestas de una
sola vista principal (una sóla página). En este proyecto se introduce la
necesidad de tener que dividir nuestra interfaz en varias vistas o páginas
y ofrecer una manera de navegar entre estas vistas. Este problema se puede
afrontar de muchas maneras: con archivos HTML independientes (cada uno con su
URL) y links tradicionales, manteniendo estado en memoria y rederizando
condicionalmente (sin refrescar la página), manipulando el historial del
navegador
con window.history.
En este proyecto te invitamos a explorar opciones y decidir una opción
de implementación.
En los proyectos anteriores hemos consumido (leído) datos, pero todavía no habíamos escrito datos (salvar cambios, crear datos, borrar, ...). En este proyecto tendrás que crear (salvar) nuevos datos, así como leer, actualizar y modificar datos existentes. Estos datos se podrán guardar de forma remota usando Firebase.
Otras: