En este proyecto se construyó una página web para visualizar un conjunto de datos. Esta página web debe de permitir que se visualice la data, se filtre, se ordene y además se realice algún cálculo.
Esta página web es una propuesta de pokédex para el juego Pokemon GO, es una herramienta paralela al juego, en la que se puede encontrar información sobre los pokemons. El objetivo es que esta información sea útil para los jugadores y que los ayude a realizar las mejores estrategias para sus batallas dentro del juego, y que además sea un primer acercamiento amigable para quien quiere iniciar a jugar.
Pokémon Go es un juego de realidad aumentada para teléfonos inteligentes. En él, lxs jugadores buscan sobresalir como entrenadores de Pokemones, unas criaturas que "viven" en unas bolas especiales llamadas “Pokebolas”. De acuerdo con el concepto original, los entrenadores buscan capturar Pokemones hasta completar una colección. El otro objetivo es adiestrarlos para que ganen batallas frente a otras criaturas. Para la captura, el jugador debe literalmente lanzarse a las calles de su ciudad. Haciendo uso del GPS del teléfono, la app le avisará con una vibración y una luz intermitente cuando se encuentra cerca de un Pokémon.
Los Pokémon tienen características únicas que determinan las decisiones que toma el usuario (tipo, debilidad, peso, multiplicador, etc), con base en esto elegimos qué información de la data es que debíamos utilizar. -Nombre, número, tipo, generación, max hp, fortalezas y debilidades.
Yo cómo: nueva jugadora de Pokémon. Quiero ver imágenes y nombres de los Pokemones. Para: saber cuáles existen.
Criterios de aceptación: -Se visualizan todos los pokémons con nombre, número e imagen. -Se muestran los pokemones en filas y columnas.
Criterios de terminado: -Una tarjeta contiene nombre, número e imagen de cada pokemon. -Está en un commit en GH. -Es responsive.
Yo cómo: jugadora de pokemon Go. Quiero: conocer el tipo de cada pokemon. Para: crear una estrategia para mi batalla.
Criterios de aceptación: -Se tienen botones para filtrar cada tipo de pokémon. -Los botones tienen funcionalidad. -Los botones tienen estilo en CSS. -Se tiene test para la función. -Se muestran los pokemones filtrados en filas y columnas.
Criterios de terminado: -Está en un commit en GH. -Es responsive. -Pasa los test.
Yo cómo: jugadora de pokemon Go. Quiero: conocer la generación de cada pokemon. Para: conocer el origen de cada pokemon.
Criterios de aceptación: -Se tienen botones para filtrar las generaciones de los pokémon. -Los botones tienen funcionalidad. -Los botones tienen estilo en CSS. -Se tiene test para la función. -Se muestran los pokemones filtrados en filas y columnas.
Criterios de terminado: -Está en un commit en GH. -Es responsive. -Pasa los test.
Yo cómo: jugadora de pokemon Go. Quiero: ordenar los pokemones de manera alfabética y por número.. Para: encontrarlos más fácilmente en la pokédex
Criterios de aceptación: -Se tienen una barra selección. -La barra tiene opciones para ordenar ascendente y descendentemente, por orden alfabético y de número. -La barra tiene funcionalidad. -La barra tiene estilo en CSS. -Se tiene test para la función. -Se muestran los pokemones ordenados en filas y columnas. Criterios de terminado: -Está en un commit en GH. -Es responsive. -Pasa los test.
Yo cómo: jugadora de pokemon Go. Quiero: ingresar el HP de mi pokemon. Para: que me retorne un pokemon con más HP.
Criterios de aceptación: -Se tiene un input de tipo número. -Se tiene un botón que realice el cálculo de encontrar un pokemon con más HP, que el número que se ingresa. -El botón tiene funcionalidad. -La barra tiene estilo en CSS. -Se tiene test para la función. -Se muestran los pokemones más fuertes en filas y columnas.
Criterios de terminado: -Está en un commit en GH. -Es responsive. -Pasa los test.
Yo cómo: jugadora de pokemon Go. Quiero: conocer fortalezas, debilidades y más información sobre el pokemon. Para: crear la estrategia de batalla.
Criterios de aceptación: -Se puede dar click al número de cada pokemon (botón). -Al dar click se muestran nombre, número, imagen, fortalezas, debilidades e información general del pokemon. -El botón tiene funcionalidad. -Se tiene test para la función. -Se muestra una tarjeta más grande. Criterios de terminado: -Está en un commit en GH. -Es responsive. -Pasa los test.
Yo cómo: jugadora de pokemon Go. Quiero: buscar pokemones por sus primeras letras o su nombre Para: encontrarlos más facilmente en la pokedex.
Criterios de aceptación: -Se tiene un input. -Al ingresar texto en el input se realiza la búsqueda. -Si no se encuentran coincidencias, se da un mensaje de error. -El input tiene estilo en CSS. -Se tiene test para la función. -Se muestran los pokemones en filas y columnas.
Criterios de terminado: -Está en un commit en GH. -Es responsive. -Pasa los test.
Después de buscar información sobre pokemon GO y los pokedex, se coincidió en un diseño de página con tarjetas que contengan información de los pokemones, ordenadas por filas y columnas. Además de un menú lateral donde se encuentren los botones y barras para la funcionalidad de la página.
El primer prototipo que se realizó para el proyecto, fue con un menú lateral donde se encuentran todas las funciones.
Después se decidió por cambiar el menú de barra lateral, a dejarlo como un menú encima de las cartas de los pokemones.
Se eligió una paleta de color para utilizar en el diseño de toda la página web.
Se realizaron test para todas las funciones incluídas en nuestro archivo data.js. Estos test dieron un resultado 100% en statements, functions y lines y 85.71 en branchs.
El principal problema fue el coverage de las branch, ya que al tener todos los test para las funciones cumplía con el 100% para todo a excepción de las branch. Al investigar la razón, nos dimos cuenta que el problema era la suposición de que no se recibiera data(undefined) y esto nos diera un nuevo resultado. Así que tuvimos que incluir en tres test esta opción de undefined, con lo que aumentó el porcentaje de coverage a 85.71%. Y se tomó la decisión de dejarlo hasta ese porcentaje para no seguir al código.
-
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 y desarrollar un producto o servicio poniendo a las usuarias en el centro
-
Crear prototipos de alta fidelidad que incluyan interacciones
-
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:
- Mostrar la data en una interfaz: puede ser un card, una tabla, una lista, etc.
- 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 no incluye Pruebas Unitarias (tests), así es que tendrás que escribirlas tú para las funciones encargadas de procesar, filtrar y ordenar la data, así como calcular estadísticas.
Tus pruebas unitarias deben dar una cobertura del 70% de statements
(sentencias), functions (funciones), lines (líneas), y branches
(ramas) del archivo src/data.js que contenga tus funciones y está detallado
en la sección de Consideraciones técnicas.
- 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 lista y/o tabla con datos y/o indicadores.
- UI: Permite ordenar data por uno o más campos (asc y desc).
- UI: Permite filtrar data en base a una condición.
- UI: Es responsive.
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. - Agregarle a tu interfaz de usuario implementada visualizaciones gráficas. Para ello te recomendamos explorar librerías de gráficas como Chart.js o Google Charts.
- 100% Coverage
La lógica del proyecto debe estar implementada completamente en JavaScript (ES6), HTML y CSS. En este proyecto NO está permitido usar librerías o frameworks, solo vanilla JavaScript, con la excepción de librerías para hacer gráficas (charts); ver Parte opcional más arriba.
El boilerplate contiene una estructura de archivos como punto de partida así como toda la configuración de dependencias:
.
├── EXTRA.md
├── README.md
├── package.json
├── src
| ├── data (según con qué data trabajes)
| | ├── lol
| | | ├── lol.js
| | | ├── lol.json
| | | └── README.md
| | ├── pokemon
| | | ├── pokemon.js
| | | ├── pokemon.json
| | | └── README.md
| | └── rickandmorty
| | | ├── rickandmorty.js
| | | ├── rickandmorty.json
| | | └── README.md
| | └── athletes
| | | ├── athletes.js
| | | ├── athletes.json
| | | └── README.md
| | └── ghibli
| | | ├── ghibli.js
| | | ├── ghibli.json
| | | └── README.md
| ├── data.js
| ├── index.html
| ├── main.js
| └── style.css
└── test
└── data.spec.js
directory: 7 file: 20
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 para todo tu código que tenga que ver con
mostrar los datos en la pantalla. Con esto nos referimos básicamente a la
interacción con el DOM. Operaciones como creación de nodos, registro de
manejadores de eventos (event listeners o event handlers), ....
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.
En este archivo encontrarás una serie de imports comentados. Para cargar las diferentes fuentes de datos tendrás que descomentar la línea correspondiente.
Por ejemplo, si "descomentamos" la siguiente línea:
// import data from './data/lol/lol.js';La línea quedaría así:
import data from './data/lol/lol.js';Y ahora tendríamos la variable data disponible en el script src/main.js.
El corazón de este proyecto es la manipulación de datos a través de arreglos y objetos.
Te recomendamos que este archivo contenga toda la funcionalidad que corresponda a obtener, procesar y manipular datos (tus funciones). Por ejemplo:
-
filterData(data, condition): esta funciónfiltero filtrar recibiría la data, y nos retornaría aquellos datos que sí cumplan con la condición. -
sortData(data, sortBy, sortOrder): esta funciónsortu ordenar recibe tres parámetros. El primer parámetro,data, nos entrega los datos. El segundo parámetro,sortBy, nos dice con respecto a cuál de los campos de la data se quiere ordenar. El tercer parámetro,sortOrder, indica si se quiere ordenar de manera ascendente o descendente. -
computeStats(data): la funcióncomputeo calcular, nos permitirá hacer cálculos estadísticos básicos para ser mostrados de acuerdo a la data proporcionada.
Estos nombres de funciones y de parámetros son solamente referenciales, lo que decidas depende de tu propia implementación.
Estas funciones deben ser puras
e independientes del DOM. Estas funciones serán después usadas desde el archivo
src/main.js, al cargar la página, y cada vez que el usuario interactúe (click,
filtrado, ordenado, ...).
En esta carpeta están los datos de las diferentes fuentes. Encontrarás una
carpeta por cada fuente, 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 una etiqueta <script>,
mientras que el .json está ahí para opcionalmente cargar la data de forma
asíncrona con fetch()
(ver sección de Parte Opcional).
Tendrás también que completar las pruebas unitarias de las funciones
implementadas en el archivo data.js.
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 datos más relevantes que quieren ver en 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