Skip to content

Laboratoria/impl-data-lovers

BranchesTags

Repository files navigation

Data Lovers

Índice

1. Preámbulo

Según Forbes, el 90% de la data que existe hoy ha sido creada durante los últimos dos años. Cada día generamos 2.5 millones de terabytes de datos, una cifra sin precedentes.

No obstante, los datos por sí mismos son de poca utilidad. Para que esas grandes cantidades de datos se conviertan en información fácil de leer para los usuarios, necesitamos entender y procesar estos datos. Una manera simple de hacerlo es creando interfaces y visualizaciones.

En la siguiente imagen, podrás ver cómo con la data que que se ve en la parte izquierda se puede construir una interfaz amigable y entendible por las usuarias, al lado derecho.

pokemon-data-to-ui

2. Resumen del proyecto

En este proyecto construirás una página web para visualizar un conjunto (set) de datos que se adecúe a lo que descubras que tu usuario necesita.

Como entregable final tendrás una página web que permita visualizar la data, filtrarla, ordenarla y y calcular alguna estadística. Con estadística nos referimos a distintos cálculos que puedes hacer con la data para mostrar información aún más relevante para los usuarios (promedio, el valor máximo o mínimo, etc).

Esta vez te proponemos una serie de datos de diferentes temáticas para que explores y decidas con qué temática te interesa trabajar. Hemos elegido específicamente estos sets de datos porque creemos que se adecúan bien a esta etapa de tu aprendizaje.

Una vez que definas tu área de interés, buscar entender quién es tu usuario y qué necesita saber o ver exactamente; luego podrás construir la interfaz que le ayude a interactuar y entender mejor esos datos.

Estos son datos que te proponemos:

El objetivo principal de este proyecto es que aprendas a diseñar y construir una interfaz web donde se pueda visualizar y manipular data, entendiendo lo que el usuario necesita.

3. Funcionalidades

Como entregable final tendrás una página web que permita visualizar la data, filtrarla, ordenarla y calcular alguna estadística.

Aquí definimos en más detalle las funcionalidades mínimas que debe tener:

  • La aplicación debe permitir a la usuaria ver los items de la data en una visualización, que puede ser tipo tarjetas o cualquier otra forma que tú decidas como la adecuada (pero desde aquí referimos a los items como tarjetas). Cada "tarjeta" deben estar contenida en un elemento <li> hijo de un elemento <ul>.

  • El elemento <ul> deberá ser hijo de un elemento con atributo id de valor "root".

  • La interfaz deben mostrar los valores de las propiedades de la data que le interesaría a la usuaria ver. Por ejemplo: nombre, fecha e imagen. Si vas a filtrar u ordenar por una propiedad, la tarjeta debe mostrar este valor al usuario.

  • La interfaz debe estructurar semánticamente la data usando el estándar microdatos. Es obligatorio usar al menos los atributos itemscope, itemtype y el atributo itemprop.

    Por ejemplo, la siguiente data correspondiente pokemón Pikachu:

      {
    "num": "025",
    "name": "pikachu",
    "pokemon-rarity": "normal",
  }

    puede ser estructurada semánticamente en HTML como:

    <dl itemscope itemtype="pokemon">
  <dt>Name:</dt><dd itemprop="name">pikachu</dd>
  <dt>Number:</dt><dd itemprop="num">025</dd>
  <dt>Rarity:</dt><dd itemprop="pokemon-rarity">normal</dd>
</dl>

  • La aplicación debe calcular y visualizar una estadística de la data. Puede ser una propiedad computada de cada item, como una propiedad adicional (por ejemplo, el índice de masa corporal de cada pokemon) o unas estadísticas de la data completa. (por ejemplo, peso promedio de todos los pokemones).

  • La aplicación debe permitir a la usuaria filtrar la data. Deberás usar un elemento <select> con un atributo id de valor select-filter y un atributo name con el nombre de la propiedad por la que filtrará. (por ejemplo, si vas a filtrar por "type" seria name="type"). Los <option> de este <select> deberán tener atributo value el valor del filtro (por ejemplo, si vas a filtrar por "fire" seria <option value="fire">Fire</option>).

  • La aplicación debe permitir a la usuaria ordenar la data.

    • Tendrá al menos un control <select> para ordenar.
    • Si usas solo un control <select>, debe tener un atributo id con valor select-sort y un atributo name con el nombre de la propiedad por la que ordenará. (por ejemplo, si vas a ordenar por "num" seria name="num"). Este <select> tendrá dos <option> con atributo value asc y desc, para ordenar ascendente y descendente la data respectivamente (por ejemplo, <option value="asc">A - Z</option>).
    • Una alternativa es ofrecer la usuaria un ordenamiento mas complejo. Podrías implementar ordenar por varios propiedades. En este caso sería un <select> con un atributo id con valor select-sort, y que contiene hijos <option> con un value del nombre de la propiedad con cual vas a ordenar. (Por ejemplo, <option value="name">Nombre</option>). También, necesitarás otro control (<radio>,<select>, etc.) para decir que el ordenamiento es ascendente o descendente. Este control secundaria tendrá un atributo name con valor sort-order, y tiene value asc y desc.

  • Las funcionalidades de ordenar debe operar sobre la data filtrada. Por ejemplo, si filtro los pokemones de tipo fuego y luego los ordeno por nombre ascendentemente, la aplicación deberá mantener el filtro aplicado y ordenar los pokemones de tipo fuego.

  • La aplicación debe permitir a la usuaria reiniciar la aplicación, limpiando filtros y ordenamiento, con un <button> con id button-reset.

  • Las operaciones de filtrar, ordenar, limpiar, etc. no deben recargar la página, si no que deben agregar el contenido en una manera dinámica via javascript.

  • La aplicación será responsive, es decir, debe visualizarse sin problemas desde distintos tamaños de pantallas: móviles, tablets y desktops.

Estos wireframes son ejemplos de un interfaz que puede cumplir con esta funcionalidad:

4. Consideraciones generales

  • Este proyecto se debe resolver en duplas.
  • El rango de tiempo estimado para completar el proyecto es de 3 a 4 Sprints.
  • El proyecto será entregado subiendo tu código a GitHub (commit/push) y la interfaz será desplegada usando GitHub Pages..

5. Consideraciones técnicas

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_Hacker edition.

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
|  |  └── // otras carpetas de data
|  ├── dataFunctions.js
   ├── viewFunctions.js
|  ├── index.html
|  ├── main.js
|  └── style.css
└── test
   └── data.spec.js
└── tests-read-only

src/index.html

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.

src/main.js

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.

src/dataFunctions.js

El corazón de este proyecto es la manipulación de datos a través de arreglos y objetos.

Este archivo va a contener toda la funcionalidad que corresponda a obtener, procesar y manipular datos (tus funciones). Por ejemplo:

  • filterData(data, filterBy, value): esta función recibe tres parámetros. El primer parámetro, data, nos entrega los datos. El segundo parámetro, filterBy, nos dice con respecto a cuál de los campos de la data se quiere filtrar. El tercer parámetro, value, indica el valor de campo que queremos filtrar.

  • sortData(data, sortBy, sortOrder): esta función sort u 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ón compute o calcular, nos permitirá hacer cálculos estadísticos básicos para ser mostrados de acuerdo a la data proporcionada.

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, ...).

src/data

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).

test/dataFunctions.spec.js

Tendrás también que completar las pruebas unitarias de las funciones implementadas en el archivo dataFunctions.js.

src/viewFunctions.js

Para alcanzar mejor separación de responsabilidades en el código este archivo debe tener todas las funciones que utilizara para renderizar los elementos dinámicamente.

Al menos requerimos una función obligatoria.

  • renderItems(data): esta función recibe el arreglo de data para renderizar los elementos de cada item, y deberia volver un elemento DOM o un string de HTML.

6. Criterios de aceptación mínimos del proyecto

Criterios de código

Con cada objetivo de aprendizaje, evaluamos que el código cumpla con algunos criterios. Lo cual no excluye que puedas usar otras opciones, por ejemplo en el caso de los selectores, proponemos el uso de querySelector, no significa que no puedes usar querySelectorAll o getElementId también.

HTML

  • Uso de HTML semántico

    • Tiene un <header> con <h1>
    • Tiene un <main> con <h2>
    • Todas las etiquetas de form tienen <label>
    • <ul> esta usado para dibujar la data
    • Los hijos de <li> usan attributos de microdata itemscope e itemprop

CSS

  • Uso de selectores de CSS

    • Uso de selector class para los items
    • Uso de flexbox en sentido row y column
    • Uso de flexbox para el elemento que contiene los items
    • Uso de flexbox para el elemento que contiene los UI inputs

Web APIs

  • Uso de selectores del DOM

  • Manejo de eventos del DOM (listeners, propagación, delegación)

    • addEventListener con callback que tiene parámetro de event, lo que permite el uso del objeto event con event.target o event.currentTarget
    • La aplicación registra Event Listeners para escuchar click, change, keyup dependiendo del evento que se quiere escuchar

  • Manipulación dinámica del DOM

    • La aplicación actualiza el atributo innerHTML.
    • La aplicación usa createElement y appendChild, o template strings para crear elementos

JavaScript

Criterios de proyecto

Definición del producto

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.

Historias de 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.

Usa tus historias de usuario para planificar tus sprints diviendo cada historia en tareas.

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).

Diseño de la Interfaz de Usuario

Prototipo de baja fidelidad

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.

Recuerda pedir feedback de tu prototipo a tus compañeras y/o coaches.

Prototipo de alta fidelidad

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, 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.

Recuerda pedir feedback de tu prototipo a tus compañeras y/o coaches.

Testeos de usabilidad

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.

Implementación de la Interfaz de Usuario (HTML/CSS/JS)

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.

Revisa las funcionalidades que el proyecto pide del interfaz.

Pruebas unitarias

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. Este proyecto usa el framework Jest para ejecutar las pruebas unitarias por lo que te recomendamos consultar su documentación.

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.

7. Hacker edition

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 carpeta src/data contiene una versión .js y una .json de cada set datos.
  • Visualizar la estadística calculada mediante un gráfico. Para ello te recomendamos explorar librerías de gráficas como Chart.js o Google Charts.
  • 100% Coverage

8. Objetivos de aprendizaje

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.

HTML

CSS

Web APIs

JavaScript

  • Uso de linter (ESLINT)

  • Uso de identificadores descriptivos (Nomenclatura y Semántica)

  • Diferenciar entre expresiones (expressions) y sentencias (statements)

Control de Versiones (Git y GitHub)

  • 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

    Links

  • GitHub: Colaboración en Github (branches | forks | pull requests | code review | tags)

Centrado en el usuario

  • Diseñar y desarrollar un producto o servicio poniendo a las usuarias en el centro

Diseño de producto

  • Crear prototipos de alta fidelidad que incluyan interacciones

  • Seguir los principios básicos de diseño visual

Investigación

9. Pistas, tips y lecturas complementarias

Primeros pasos

Súmate al canal de Slack #project-data-lovers para conversar y pedir ayuda del proyecto.

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:

  1. 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 remote hacia el mismo.
  2. ⬇️ Clona tu fork a tu computadora (copia local).
  3. 📦 Instala las dependencias del proyecto con el comando npm install. Esto asume que has instalado Node.js (que incluye npm).
  4. Si todo ha ido bien, deberías poder ejecutar las 🚥 pruebas unitarias (unit tests) con el comando npm test.
  5. Para ver la interfaz de tu programa en el navegador, usa el comando npm start para arrancar el servidor web y dirígete a http://localhost:5000 en tu navegador.
  6. A codear se ha dicho! 🚀

Contenido de referencia

Diseño de experiencia de usuario (User Experience Design)

  • Investigación con usuarios / entrevistas
  • Principios de diseño visual

Desarrollo Front-end

Herramientas

Organización del Trabajo

10. Consideraciones para pedir tu Project Feedback

Antes de agendar tu Project Feedback con un coach, asegúrate que tu proyecto:

  • Cumple con todos los criterios mínimos de aceptación al ejecutar npm run test:oas
  • Cumple con todas las pruebas end to end al ejecutar npm run test:e2e
  • Cumple con todas las pruebas unitarias al ejecutar npm run test y que tienen una cobertura del 70% de statements (sentencias), functions (funciones), lines (líneas), y branches
  • Esta libre de errores de eslint al ejecutar npm run pretest
  • Está subido a GitHub y desplegado en GitHub Pages.
  • Tiene un README.md con la siguente:
    • Definición del producto clara e informativa
    • Historias de usuario
    • Un sketch de la solución (prototipo de baja fidelidad) y Diseño de la Interfaz de Usuario (prototipo de alta fidelidad)
    • El listado de problemas que detectaste a través de tests de usabilidad en el README.md
  • Tiene un UI que cumple las funcionalidades:
    • Muestra lista con datos y/o indicadores
    • Permite ordenar data por uno o más campos (asc y desc)
    • Permite filtrar data en base a una condición
    • Permite limpiar los filtros con un botón
    • Es responsive

Recuerda que debes hacer una autoevaluación de objetivos de aprendizaje y life skills desde tu dashboard de estudiante.

Si no has completado todo lo anterior, no consideramos que estás lista para tu sesión de Project Feedback.

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

3 watching

Forks

2 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages