Es un juego que ejercita la memoria, en donde el usuario puede destapar 2 cartas por turno y si hacen match aumenta el puntaje en 100 puntos. El usuario gana cuando ha destapado todas las cartas, además de acuerdo a su desempeño puede ganar una medalla de oro, plata o bronce.
-
Usuarios: Niños de entre 8 a 10 años que desean realizar una actividad divertida en la que también puedan aprender y ejercitar su memoria.
-
¿Cómo el producto soluciona el problema/necesidad de dicho usuario? El juego es una aplicación web que presenta una interfaz divertida y llamativa; la cual invita a los niños a desarrollar su memoria (que es una capacidad cognitiva importante que permite codificar, almacenar y recuperar de manera efectiva la información aprendida) a través de una tarjetitas con imágenes de dibujos que harán a esta actividad, nada aburrida.
-
Como niñx de primaria Quiero jugar un juego de memoria Para divertirme y aprender Criterios de aceptación
- Página de bienvenida que permita ingresar el nombre del jugador.
- Botón “vamos” que permita acceder a la siguiente vista y guardar el nombre del jugador Definición de terminado
- Esquema html y CSS de acuerdo a prototipo
- Que el código cuente con los requerimientos deseados
- Que esté validado por el equipo
-
Como jugador Quiero leer las reglas del juego Para saber cómo jugar Criterios de aceptación
- Saludar al usuario indicando su nombre
- Hacer lista de reglas del juego
- Botón “jugar” que lleve a la siguiente vista donde estará el tablero de juego Definición de terminado
- Esquema html y CSS de acuerdo a prototipo
- Que el código cuente con los requerimientos deseados
- Que esté validado por el equipo
-
Como jugador Quiero ver las cartas Para empezar a jugar y memorizar Criterios de aceptación
- Presentar las imágenes en la web en forma de tarjetas colocadas boca abajo
- Tarjetas ordenadas aleatoriamente
- Que las tarjetas se puedan voltear y mostrar la imagen, al hacerle click Definición de terminado
- Esquema html y CSS de acuerdo a prototipo
- Que el código cuente con los requerimientos deseados y funcione
- Que esté validado por el equipo
-
Como jugador Quiero destapar todas las cartas rápidamente y ver un mensaje Para saber que gané Criterios de aceptación
- Destapar tarjetas de 2 en 2 por turno
- Reconocer pares de tarjetas con imágenes iguales
- Colocar ícono de moneda y agregar puntaje de 100 puntos cada vez que 2 tarjetas hacen match
- Contar los turnos cada vez que se destapan 2 tarjetas
- Agregar un conteo regresivo, y que al terminar el tiempo se indique al jugador que vuelva a intentar Definición de terminado
- Esquema html y CSS de acuerdo a prototipo
- Que el código cuente con los requerimientos deseados y funcione
- Que esté validado por el equipo
-
Como jugador Quiero un premio al ganar el juego Para saber qué tan bien jugué y querer obtener el mejor premio Criterios de aceptación
- Agregar un sistema de medallas de oro, plata y bronce de acuerdo al número de turnos utilizados para destapar todas las cartas antes que el tiempo llegue a cero Definición de terminado
- Esquema html y CSS de acuerdo a prototipo
- Que el código cuente con los requerimientos deseados y funcione
- Que esté validado por el equipo
- 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. Consideraciones técnicas
- 8. Pistas, tips y lecturas complementarias
- 9. Checklist
El juego Memory Match, también conocido como Concentration, Match Match, Match Up, Memory, entre otros, es un juego de cartas en el que todas las cartas se ponen cara abajo sobre una superficie y se le dan la vuelta a dos cartas en cada turno. El objetivo del juego es destapar parejas de cartas que coincidan.
Imagen tomada de Wikipedia.
Ejemplos:
En este proyecto construirás una versión web del juego Memory Match, en la que una jugadora pueda jugar sola, en el navegador.
El objetivo principal de este proyecto es que aprendas a diseñar y construir una interfaz web basada en data e interacción con la usuaria.
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 selectores del DOM
-
Manejo de eventos del DOM (listeners, propagación, delegación)
-
Manipulación dinámica del DOM
-
Diferenciar entre tipos de datos primitivos y no primitivos
-
Arrays (arreglos)
-
Objetos (key, value)
-
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)
-
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)
-
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)
- 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
- Este proyecto se debe resolver en duplas.
- El proyecto será entregado subiendo tu código a GitHub (commit/push) y la interfaz será desplegada usando GitHub Pages.
- Tiempo para completarlo: Toma como referencia 4 semanas.
Los criterios para considerar que has completado este proyecto son:
Documenta brevemente tu trabajo en el archivo README.md de tu repositorio,
contándonos cómo fue tu proceso de diseño y cómo crees que el producto resuelve
el problema (o problemas) que tiene tu usuario.
Una vez que entiendas las necesidades de tus usuarios, escribe las Historias de Usuario que representen todo lo que el usuario necesita hacer/ver. Las Historias de Usuario deben ser el resultado de tu proceso de investigación o research de tus usuarios.
Asegúrate de incluir la definición de terminado (definition of done) y los Criterios de Aceptación para cada una.
En la medida de lo posible, termina una historia de usuario antes de pasar a la siguiente (Cumple con Definición de Terminado + Criterios de Aceptación).
Durante tu trabajo deberás haber hecho e iterado bocetos (sketches) de tu
solución usando papel y lápiz. Te recomendamos tomar fotos de todas las
iteraciones que hagas, que las subas a tu repositorio y las menciones en tu
README.md.
Lo siguiente es diseñar tu Interfaz de Usuario (UI por sus siglas en inglés - User Interface). Para eso debes aprender a utilizar alguna herramienta de diseño visual. Nosotros te recomendamos Figma que es una herramienta que funciona en el navegador y, además, puedes crear una cuenta gratis. Sin embargo, eres libre de utilizar otros editores gráficos como Illustrator, Photoshop, PowerPoint, Keynote, etc.
El diseño debe representar el ideal de tu solución. Digamos que es lo que desearías implementar si tuvieras tiempo ilimitado para trabajar. Además, tu diseño debe seguir los fundamentos de visual design.
Durante el reto deberás hacer tests de usabilidad con distintos usuarios, y en base a los resultados, deberás iterar tus diseños. Cuéntanos qué problemas de usabilidad detectaste a través de los tests y cómo los mejoraste en tu propuesta final.
Luego de diseñar tu interfaz de usuario deberás trabajar en su implementación. No es necesario que construyas la interfaz exactamente como la diseñaste. Tu tiempo de hacking es escaso, así que deberás priorizar
Como mínimo, tu implementación debe:
- Dado un set de cartas, barajar las cartas y mostrarlas en la interfaz.
- Permitir al usuario destapar las cartas de 2 en 2.
- Dejar destapadas las cartas que coincidan al destaparlas.
- Indicar al usuario que ganó cuando haya destapado todas las cartas.
- Ser responsive, es decir, debe visualizarse sin problemas desde distintos tamaños de pantallas: móviles, tablets y desktops.
- Que la interfaz siga los fundamentos de visual design.
El boilerplate de este proyecto incluye pruebas unitarias (unit tests) de un componente como ejemplo. A medida que vayas agregando componentes tendrás que ir agregando pruebas para mantener buena cobertura.
Tus pruebas unitarias deben tener una cobertura del 70% de statements (sentencias), functions (funciones), lines (líneas), y branches (ramas) de tus componentes.
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.
Features/características extra sugeridas:
- En lugar de consumir la data estática brindada en este repositorio, puedes
consumir la data de forma dinámica, cargando un archivo JSON por medio de
fetch. La carpetasrc/datacontiene una versión.jsy una.jsonde de cada set datos. - Agregar nuevos sets de cartas.
- Calcular puntuación basado en número de turnos.
- Agregar timer y tener cuenta en puntuación.
- 100% Coverage
La lógica del proyecto debe estar implementada completamente en JavaScript, HTML y CSS. En este proyecto NO está permitido usar librerías o frameworks, solo vanilla JavaScript.
Para iniciar un nuevo juego, siempre tendremos que barajar las cartas antes de pintarlas en la pantalla. Para eso, te invitamos a que explores algoritmos existentes para este tipo de operación (llamada shuffle en inglés), como por ejemplo el algoritmo de Fisher-Yates (aka Knuth).
En este proyecto no se espera que inventes o implementes tu propio algoritmo
para barajar las cartas, si no que googlees, veas opciones existentes,
consideres opciones y adaptes una a tu proyecto (agregando una función shuffle
que se pueda usar en tu aplicación).
El boilerplate contiene una estructura de archivos como punto de partida así como toda la configuración de dependencias:
.
├── .babelrc
├── .editorconfig
├── .eslintrc
├── .gitignore
├── package.json
├── README.md
└── src
├── components
│ ├── App.js
│ └── App.spec.js
├── data
│ ├── pokemon
│ │ ├── pokemon.js
│ │ └── pokemon.json
│ ├── README.md
│ └── webdev
│ ├── webdev.js
│ └── webdev.json
├── index.html
├── main.js
└── style.css
Como en el proyecto anterior, existe un archivo index.html. Como ya sabes,
acá va la página que se mostrará al usuario. También nos sirve para indicar
qué scripts se usarán y unir todo lo que hemos hecho.
Recomendamos usar src/main.js como punto de entrada de tu aplicación. El
boilerplate incluye este archivo para conectar o montar el componente
App en el DOM. De esta forma podremos hacer pruebas unitarias de nuestros
componentes sin necesidad de que estén conectados a un DOM global.
Esta no es la única forma de dividir tu código, puedes usar más archivos y carpetas, siempre y cuando la estructura sea clara para tus compañeras.
Este archivo contiene un componente de ejemplo que muestra cómo podemos
representar un componente como una función que retorna un HTMLElement. A la
hora de construir interfaces es útil pensar en términos de componentes o
vistas que podemos ir anidando unas dentro de otras. Te invitamos a que
pienses qué componentes o cajitas necesitas para construir tu aplicación y
que vayas agregando componentes en el directorio components para implementar
cada uno de ellos. Aunque, otra vez, la forma de organizar tu archivos depende
al final de tí y de tu equipo. Hay muchas formas de hacerlo, y el boilerplate
es solo una sugerencia 🙊.
Este archivo muestra cómo podemos crear archivos con especificaciones (expresadas como pruebas unitarias) de nuestros componentes.
En esta carpeta hay data con sets de cartas de ejemplo que puedes usar en tu
aplicación, así como información sobre cómo agregar tus propios sets.
Encontrarás una carpeta por cada set, y dentro de cada carpeta dos archivos: uno
con la extensión .js y otro .json. Ambos archivos contienen la misma data;
la diferencia es que el .js lo usaremos a través de un import, mientras que
el .json está ahí para opcionalmente cargar la data de forma asíncrona con
fetch().
Antes de empezar a escribir código, debes definir qué deberá hacer el producto en base al conocimiento que puedas obtener de tu usuario. Estas preguntas te pueden ayudar:
- ¿Quiénes son los principales usuarios de producto?
- ¿Cuáles son los objetivos de estos usuarios en relación con el producto?
- ¿Cuáles son los componentes principales de la interfaz y por qué?
- ¿Cuándo utilizan o utilizarían el producto?
- Toda tu investigación previa debe tener como resultado todas las Historias de Usuario de tu proyecto.
- No hagas los prototipos de alta fidelidad de todas tus Historias. Comienza solamente por los que se necesiten para tu Sprint 1 (semana 1 de trabajo). Más pistas en la guía de organización para el proyecto.
Cuando ya estés lista para codear, te sugerimos empezar de esta manera:
- Una de las integrantes del equipo debe realizar un 🍴
fork del repo de tu cohort,
tus coaches te compartirán un link a un repo y te darán acceso de lectura
en ese repo. La otra integrante del equipo deber hacer un fork del
repositorio de su compañera y
configurar un
remotehacia el mismo. - ⬇️ Clona tu fork a tu computadora (copia local).
- 📦 Instala las dependencias del proyecto con el comando
npm install. Esto asume que has instalado Node.js (que incluye npm). - Si todo ha ido bien, deberías poder ejecutar las 🚥
pruebas unitarias (unit tests) con el comando
npm test. - Para ver la interfaz de tu programa en el navegador, usa el comando
npm startpara arrancar el servidor web y dirígete ahttp://localhost:5000en tu navegador. - A codear se ha dicho! 🚀
- Investigación con usuarios / entrevistas
- Principios de diseño visual
- Unidad de testing en curso de JavaScript en LMS.
- Unidad de arreglos en curso de JavaScript en LMS.
- Unidad de objetos en curso de JavaScript en LMS.
- Unidad de funciones en curso de JavaScript en LMS.
- Unidad de DOM en curso de Browser JavaScript en LMS.
- Array en MDN
- Array.sort en MDN
- Array.map en MDN
- Array.filter en MDN
- Array.reduce en MDN
- Array.forEach en MDN
- Object.keys en MDN
- Object.entries en MDN
- Fetch API en MDN
- json.org
- expressions-vs-statements
- expresión vs sentencia
- datos atómicos vs datos estructurados
- Modulos: Export
- Modulos: Import
- Historias de Usuario. Ojo que Cris no diferencia Definición de terminado de Criterios de Aceptación y nosotros sí lo haremos. Más detalles en la guía.
- Cómo dividir H.U.
- Guía para Data Lovers
- Usa VanillaJS.
- Pasa linter (
npm run pretest) - Pasa tests (
npm test) - Pruebas unitarias cubren un mínimo del 70% de statements, functions y lines y branches.
- Incluye Definición del producto clara e informativa en
README.md. - Incluye historias de usuario en
README.md. - Incluye sketch de la solución (prototipo de baja fidelidad) en
README.md. - Incluye Diseño de la Interfaz de Usuario (prototipo de alta fidelidad)
en
README.md. - Incluye el listado de problemas que detectaste a través de tests de
usabilidad en el
README.md. - UI: Muestra cartas barajadas correctamente.
- UI: Permite al usuario destapar las cartas de 2 en 2.
- UI: Deja destapadas las cartas que coincidan al destaparlas.
- UI: Indica al usuario que ganó cuando sea relevante.
- UI: Es responsive.
- UI: La interfaz sigue los fundamentos de visual design.