- 1. Preámbulo
- 2. Resumen del proyecto
- 3. Objetivos de aprendizaje
- 4. Consideraciones generales
- 5. Criterios de aceptación mínimos del proyecto
- 6. Entrega
- 7. 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) que se adapte al patrón modelo - vista - controlador MVC y que sea responsive (con más de una vista / página) en la que podamos leer, escribir, actualizar y eliminar datos.
- Uso de HTML semántico.
- Uso de selectores de CSS.
- Construir tu aplicación respetando el diseño realizado (maquetación).
- Uso de flexbox | Grid en CSS.
- Uso de selectores del DOM.
- Manejo de eventos del DOM (aprovecha el objeto de evento en sus handlers, uso de event delegacion.)
- Manipulación dinámica del DOM. (appendChild |createElement | createTextNode| innerHTML | textContent | etc.)
- History API.
- localStorage.
- Uso de template strings
- Uso de condicionales (if-else | switch | operador ternario)
- Uso de funciones (parámetros | argumentos | valor de retorno)
- Manipular arrays (filter | map | sort | reduce)
- Manipular objects (key | value)
- Uso ES modules (
import|export) - Diferenciar entre expression y statements.
- Diferenciar entre tipos de datos atómicos y estructurados.
- Uso de callbacks.
- Consumo de Promesas.
- Organizar y dividir el código en módulos (Modularización)
- Uso de identificadores descriptivos (Nomenclatura | Semántica)
- Uso de linter (ESLINT)
- Uso de comandos de git (add | commit | pull | status | push)
- Manejo de repositorios de GitHub (clone | fork | gh-pages)
- Colaboración en Github (branches | pull requests | code reviews |tags)
- Organización en Github (projects | issues | labels | milestones)
- Firestore.
- Firebase Auth.
- Firebase security rules.
- Observadores. (onAuthStateChanged | onSnapshot)
- Diseñar la aplicación pensando y entendiendo al usuario.
- Crear prototipos para obtener feedback e iterar.
- Aplicar los principios de diseño visual (contraste, alineación, jerarquía)
- Planear y ejecutar tests de usabilidad.
-
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.
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.
Para este proyecto vamos a entregarte las Historias de Usuario para tú junto a tu equipo puedan escribir los criterios de aceptación y definición determinado de cada una. Recuerda priorizar la implementación de tus funcionalidades, en función al esfuerzo que demandan en relación al valor que le aportan al usuario, y ejecutar en equipo todas las historias de usuario dentro del tiempo estimado para cada sprint y que finalmente se vean reflejadas en publicaciones completamentamente funcionales al final de cada sprint.
-
Como usuario nuevo debo poder crear una cuenta con email y password válidos para ingresar a la red social.
-
Como usuario registrado debo poder iniciar sesión con email y password válidos para ingresar a la red social.
-
Como usuario nuevo debo poder iniciar sesión con mi cuenta de Google o Facebook para ingresar a la red social (sin necesidad de crear una cuenta de email válido).
-
Como usuario loggeado debo poder crear, guardar, modificar en el mismo lugar (in place) y eliminar una publicación (post) privada o pública, que puede ser una frase o una imagen.
-
Como usuario loggeado debo poder ver todos los posts públicos y privados que he creado hasta ese momento, desde el más reciente hasta el más antiguo, así como la opción de poder cambiar la configuración de privacidad de mis posts para poder elegir la privacidad de mis publicaciones.
-
Yo como usuario loggeado, puedo dar like y llevar un conteo de likes en las publicaciones para poder indicar que me gusta una publicación.
-
Yo como usuario loggeado debo poder escribir, guardar, editar o eliminar un comentario en una publicación para poder compartir mi opinión o hacer preguntas.
-
Yo como usuario loggeado debo poder visualizar los datos de mi perfil creado y editarlos para actualizar mi información.
Te dejamos un ejemplo de cómo definir criterios de aceptación y definiciones de terminado para una H.U. Si se te complica definirlas o no tienes idea de que considerar para cada H.U. es de gran ayuda revisar redes sociales como facebok, twitter, instagram, tik tok o la red social que más te guste y puedas evaluar qué consideran en cada funcionalidad para darla como terminada y aceptada. De igual manera recuerda considerar tus objetivos de aprendizaje en tu planificación.
Como usuario registrado debo poder iniciar sesión con email y password válidos para ingresar a la red social.
Criterios de Aceptación: todo lo que debe ocurrir para satisfacer las necesidades del usuario.
- Si el mail o password no es válido, al momento de logearme, debo poder ver un mensaje de error.
- Debe ser visible si hay algún mensaje de error.
- Debo poder ver esta página de creación en Móviles y desktop (responsive).
- No debe necesitar recargar la página para crear una cuenta (SPA).
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):
- La funcionalidad cumple y satisface los criterios de aceptación.
- La funcionalidad tiene test unitarios.
- El diseño visual corresponde al prototipo propuesto.
- El código de esta funcionalidad recibió code review de una o dos compañeras de otro equipo.
- La funcionalidad esta desplegada y pública para ser probada.
- La funcionalidad fue probada manualmente buscando errores e imperfecciones simples..
- La página es responsive (mobile first)
- Se hicieron pruebas de usuabilidad y se implementó el feedback si se consideró necesario.
Debes definir cuál será el flujo que seguirá el usuario dentro de tu aplicación y, con eso, diseñar la Interfaz de Usuario (UI por sus siglas en inglés) que siga este flujo.
A continuación te proporcionamos un layout (diseño) de la vista mobile y desktop que puedes elegir replicar visualmente y cuyo contenido, colores y fuentes de texto, dejaremos a tu elección. En caso de elegir trabajar con este layaout (diseño) ya no deberás de crear un prototipo de baja fidelidad.
-
Vista mobile
-
Vista Desktop
- 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).
Te recomendamos revisar la Píldora de SPA que también
puedes encontrar en la sección de recursos al final del
Readme.md. De igual manera puedes revisar este repositorio donde puedes ver cómo construir un To-do MVC convanillajs. - Debe ser responsive por lo cual 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). De igual manera no está permitido el uso de frameworks de CCS (bootstrap). - 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.
- Los tests unitarios deben cubrir un mínimo del 70% de statements, functions,
lines, y branches. Te recomendamos revisar la Pildora de mock Firebase
que también puedes encontrar en la sección de recursos al final del
Readme.md.
- 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.
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.
Hasta el momento, los proyectos han sido pensados como recursos públicos, donde todos los usuarios compartían un mismo rol y la misma información.
En este proyecto tendrás que diferenciar la información a mostrar y modificar, dependiendo de la identidad del usuario. De la misma manera deberás crear reglar de autorización para el acceso a los datos.
Para esto utilizaras respectivamente
Firebase authentication y
Firestore security rules
- Píldora SPA
- Repositorio de píldora de SPA
flexbox- Pildora de mock Firebase
- Repositorio de pildora de mock Firebase
- Pildora MVC
- Modulos: Export
- Modulos: Import
- Diseño web, responsive design y la importancia del mobile first - Media Click
- Mobile First: el enfoque actual del diseño web móvil - 1and1
- Mobile First - desarrolloweb.com
- Mobile First - ZURB
- Mobile First Is NOT Mobile Only - Nielsen Norman Group