En Laboratoria, las Training Managers (TMs) hacen un gran trabajo al analizar la mayor cantidad de datos posibles respecto al progreso de las estudiantes para apoyarlas en su aprendizaje.
La principal medida de progreso de una estudiante en Laboratoria es su avance completando los proyectos de la Ruta de Aprendizaje y su desempeño en función a la Rúbrica de Niveles Esperados. Sin embargo, para completar estos proyectos las estudiantes acceden a contenidos de aprendizaje (lecturas, videos, ejercicios y quizzes) en un sistema que llamamos LMS (Learning Management System). El LMS acumula data sobre quién leyó qué, qué ejercicios se han completado, los resultados de los quizzes, etc.
A pesar de que la data de progreso del LMS (ej. lecturas leídas, ejercicios completados, nota en quizzes, etc.) no impacta directamente en la evaluación de una estudiante, sí es una pieza de información relevante que las TMs quisieran visualizar para tener un mejor entendimiento de cómo va cada estudiante en su proceso de aprendizaje.
Así, el reto de este proyecto es crear una interfaz donde las TMs puedan ver y usar la data de progreso del LMS. Para ello, proponemos crear un data dashboard (tablero de visualización de datos).
Según un estudio de IBM, el 90% de la data que existe hoy ha sido creada en los últimos dos años. Cada día generamos 2.5 trillones de bytes de datos, una cifra sin precedentes.
Sin embargo, los datos por sí solos son de poca utilidad. Para transformar datos en información necesitamos procesarlos y entenderlos. Una manera muy sencilla de hacerlo es creando visualizaciones. Las empresas líderes de hoy generan visualizaciones dinámicas de su data que les permiten entender mejor su negocio y tomar decisiones apropiadas.
En este proyecto tendrás tu primer acercamiento a transformar data en información creando tu primer data dashboard.
Si pensamos en un dashboard podemos pensar en el tablero de control de un auto o el de un avión. Un espacio desde el cual un usuario puede tener acceso a la información y controles más relevantes, en este caso, del vehículo que está utilizando. El dashboard de un auto le permite a quien conduce saber a qué velocidad está yendo, qué cambio/velocidad está utilizando, cuánto combustible tiene disponible, cuál es la temperatura del motor, cuántas revoluciones por minuto dan las ruedas, cuánta distancia ha recorrido, etc.
En el mundo de la web es muy común el uso de dashboards. De hecho, wikipedia nos dice que un dashboard puede ser un resumen gráfico de varias piezas de información importante, generalmente utilizadas para dar una visión general de una empresa o de un servicio. Así, tenemos dashboards como los de:
-
Google Analytics para visualizar la data de tráfico de sitios web.
-
Mailchimp para visualizar el desempeño de campañas de mercadeo digital por correo electrónico.
-
Quickbooks para visualizar la información financiera de una empresa.
Seguramente, a lo largo de tu carrera como diseñadora o desarrolladora, te tocará crear un data dashboard. Quizás sea para visualizar la data de un negocio de delivery de comida, o las rutas históricas de un negocio de transporte, o simplemente los indicadores clave de tu propio emprendimiento ;)
El objetivo principal de este proyecto es que aprendas a diseñar y construir una interfaz web donde podamos visualizar y manipular data.
Esperamos que puedas pensar en el usuario, entender cuál es la mejor manera de visualizar la data según sus necesidades, y plasmar todo eso en tu diseño en la web.
Además, este proyecto se debe "resolver" en parejas, por lo que un objetivo importante es ganar experiencia en trabajos colaborativos con entrega grupal.
Tendrás que familiarizarte con conceptos como: arrays,objects, dom, xhr y visual design.
Además, reforzarás lo aprendido en el proyecto anterior: valores, tipos, variables, control de flujo y tests unitarios.
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.
No se debe utilizar la pseudo-variable this.
Los tests unitarios deben cubrir un mínimo del 70% de statements, functions
y lines, y un mínimo del 50% de branches. El boilerplate ya contiene el
setup y configuración necesaria para ejecutar los tests (pruebas) usando el
comando npm test.
Para comenzar tendrás que hacer un fork y clonar este repositorio que contiene el boilerplate.
El boilerplate contiene una estructura de archivos como punto de partida así como toda la configuración de dependencias y tests de ejemplo:
./
├── .editorconfig
├── .eslintrc
├── .gitignore
├── README.md
├── data
│ └── laboratoria.json
├── package.json
├── src
│ ├── data.js
│ ├── index.html
│ ├── main.js
│ └── style.css
└── test
| ├── data.spec.js
| ├── fixtures.js
| ├── headless.js
| └── index.html
└── ux
└── README.md
La carpeta data/ dentro del boilerplate incluye un extracto de la data que
podemos usar tanto en los tests como en la interfaz en sí. Todos los datos
usados son ficticios, y su uso no afecta ni perjudica a ninguna persona o
individuo moral. Además que en este proyecto encontrarás toda la data en
español, esto pensando en que puedas entender y familiarizarte más rápido con
esta. Antes de poder visualizar o manipular la data es necesario
poder leerla, entenderla y así hacer la mejor interpretación posible de la
misma. En los siguientes proyectos estarás enfrentándote a data en inglés y
será parte de tus tareas generar estrategias para encontrar el mejor
acercamiento y entendimiento del problema.
La carpeta de ux/, incluye un README donde vas a encontrar una guía de qué hacer. Te pedimos que ahí mismo documentes ese proceso que realizaste.
Los criterios mínimos de aceptación para considerar que has completado este proyecto son:
En el README.md cuéntanos cómo pensaste y te acercaste a los usuarios al
desarrollar tu producto (Tip: entrevistas) y cuál fue tu proceso para definir
el producto final a nivel de experiencia y de interfaz. Es importante que
detalles:
- 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é. Cómo los descubriste.
- Cuándo revisan normalmente estos datos los usuarios.
- Cómo crees que el producto les está resolviendo sus problemas.
- Cómo fue tu proceso de diseño.
Debes hacer un sketch (boceto) de tu solución usando papel y lápiz, tomarle
una foto, subirla a tu repositorio y hacer mención del sketch en tu README.md.
Lo siguiente es diseñar tu Interfaz de Usuario (UI por sus siglas en inglés). 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 tu ideal de solución. Digamos que es lo que desearías implementar si tuvieras tiempo ilimitado para hackear.
Tu diseño debe seguir los fundamentos de visual design, como: contraste, alineación, jerarquía, entre otros. Tip: revisa el contenido de UX de la unidad de visual design.
Luego de diseñar tu interfaz de usuario deberás trabajar en su implementación. Como mencionamos, no es necesario que construyas la interfaz tal como la diseñaste. Tendrás un tiempo limitado para hackear, así es que deberás priorizar.
La interfaz debe permitir al usuario:
- Listar y poder seleccionar sedes
- Dentro de cada sede:
- Listar y poder seleccionar generaciones
- Para cada generación:
- Listar y poder seleccionar estudiantes mostrando porcentaje general de completitud de c/estudiante
- Seleccionar estudiantes mostrando reporte de progreso:
- Mostrar porcentaje de completitud de todos los temas
- Calcular porcentaje de tiempo completado de cada tema
- Listar subtemas de cada tema
- Poder filtrar subtemas completados y no-completados de cada tema
- Poder filtrar subtemas por tipos (ejercicios, lecturas y quizzes)
- En la vista de cada generación mostrar reporte de:
- Promedio de la generación
- Generar status para identificar estudiantes debajo del 60 en su porcentaje de completitud
- Generar status para identificar estudiantes con 90 o más en su porcentaje de completitud
- Poder filtrar estudiantes por estos dos status
- Filtrar y poder buscar estudiantes por nombre
- Poder ordenar de manera ascendente y descendente a las estudiantes según porcentaje de completitud
- Utiliza la interfaz sin problemas desde distintos tamaños de pantallas: móviles, tablets, desktops
- Realizar pruebas unitarias
Es importante que tu interfaz, a pesar de ser una versión mínima de tu ideal, igual debe seguir los fundamentos de visual design, como: contraste, alineación, jerarquía, entre otros.
data.js El corazón de este proyecto es la manipulación de datos a través de arreglos y objetos. La idea de este archivo es contener toda la funcionalidad que corresponda a obtener, procesar y manipular datos.
Parte de un buen proyecto es que esté ordenado y que otras programadoras puedan acceder a el código rápidamente. Es por esto que este orden no es casualidad y es una convención que generalmente encontrarás en internet bajo el nombre MVC o Modelo Vista Controlador. En este proyecto Controlador y Modelo estarán bajo el archivo data.js.
El boilerplate incluye tests que esperan que implementes las siguientes 4 funciones y las exportes al entorno global (window) dentro del script src/data.js, ten en cuenta que esto es solo lo básico, si necesitas más funciones puedes hacerlo:
Esta función es la responsable de "crear" la lista de estudiantes
que vamos a "pintar" en la pantalla. La idea es "recorrer" el arreglo de
estudiantes que se encuentra dentro de laboratoria.json.
La función debe devolver un nuevo arreglo de estudiantes donde cada objeto
de estudiante deberá tener una propiedad con el nombre stats y dentro,
sólo los datos requeridos.
laboratoria: Objeto obtenido de la data en bruto.
Un arreglo de objetos student con las siguientes propiedades:
name: Nombre respectivo de la estudiante.email: Correo electrónico de la estudiante.campus: Sede a la cual la estudiante pertenece.generation: Generación a la cual la estudiante pertenece.stats: Un objeto con las siguientes propiedades:status: Status para identificar si la estudiante esta por debajo del 60, en 90 o superándolo, o dentro de la media en sucompletedPercentage.completedPercentage: Número entero entre 0 y 100 que indica el porcentaje de completitud general del usuario con respecto a todos los temas asignados.topics: Un objeto que incluye como propiedades los temas del programa y cada tema tiene las siguientes propiedades:completedPercentage: Número entero entre 0 y 100 que indica el porcentaje de completitud general del usuario con respecto al tema respectivo.percentageDuration: Número entero que indica el porcentaje de tiempo invertido según la duración indicada de cada tema, si el resultado son números flotantes deberías redondearlo al entero más cercano. Ejemplo: 78.78 = 79.subtopics: Un objeto que incluye como propiedades los subtemas de ese tema en particular y cada subtema tiene las siguientes propiedades:completedPercentage: Número entero entre 0 y 100 que indica el porcentaje de completitud general del usuario con respecto al subtema.type: String que indica la modalidad del subtema.duration: Número entero que indica el tiempo necesario a invertir para completar el subtema.
Esta función es la responsable de "crear" los status de cada generación que vamos a "pintar" en la pantalla. La idea es "recorrer" el objeto que se encuentra dentro de la "data".
La función debe devolver un nuevo arreglo de generaciones donde cada objeto
generation deberá tener una propiedad con el nombre average y dentro el
promedio de completedPercentage de todas las estudiantes de la generación.
laboratoria: Objeto obtenido de la data en bruto.
Un arreglo de objetos generation con las siguientes propiedades:
campus: Sede a la cual la generación pertenece.generation: Generación a la cual pertenceaverage: Promedio del porcentajeCompletado de todas las estudiantes de la generación, si resulta un número flotante debería de ser redondeado al número entero más cercano.count: Número de estudiantes de la generación.
La función sortStudents() se encarga de ordenar la lista de estudiantes creada con
computeStudentsStats() en base a orderBy y orderDirection.
students: Arreglo de objetos creado concomputeStudentsStats().orderBy: String que indica el criterio de ordenado. Debe permitir ordenar por nombre y porcentaje de completitud.orderDirection: La dirección en la que queremos ordenar. Posibles valores:ASCyDESC(ascendente y descendente).
Arreglo de estudiantes ordenado.
students: Arreglo de objetos creado concomputeStudentsStats().search: String de búsqueda.
Nuevo arreglo de usuarios incluyendo solo aquellos que cumplan la condición de
filtrado, es decir, aquellos que contengan el string busqueda en el nombre
(name) de las estudiantes.
Ten en cuenta también que existe otro archivo main.js que no está solo por casualidad en la estructura del proyecto. En general es una buena idea ir separando la funcionalidad en varios archivos, ya que a medida que un proyecto crece, se vuelve insostenible dejar todo en un solo archivo. En este caso puedes usar main.js para todo tu código que tenga que ver con mostrar los datos en la pantalla, y data.js para todas las funciones que vimos que obtienen y manipulan los datos.
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.
Al igual que en el proyecto anterior, también existe un archivo index.html.
Como ya sabrás, acá va la página que se mostrará al usuario de este tablero de
información. También nos sirve para indicar qué scripts se usarán y unir todo lo
que hemos hecho.
En esta carpeta están los datos de prueba del proyecto, contiene información sobre las sedes, las generaciones que han pasado por cada sede, las estudiantes que han pasado por cada generación y su progreso en cada uno de los temas y subtemas que han visto. Para poder usar el archivo JSON, puedes ocupar el mismo método que usarías si es que estuvieses haciendo una llamada HTTP o a una API, pero usando una dirección relativa, ejemplo:
"../data/users.json"En esta carpeta vas a encontrar una guía para realizar el proceso de diseño de tu data dashboard, donde se explican las diferentes fases a seguir de manera muy breve, así como los pasos a desarrollar dentro de cada fase. También se deja espacios para que completes este README con tu información, pero si deseas agregar más cosas, siéntete en la libertad. Recuerda que este es un proceso creativo que responde a la data recopilada.
Tendrás también que completar las pruebas unitarias de estas funciones que se
incluyen en el boilerplate, que encontrarás en el archivo data.spec.js.
Si te fijas bien en la carpeta también encontrarás otros archivos, que
detallaremos a continuación:
No confundas este archivo con tu index.html del proyecto, este archivo es
especial para los test y es una manera de ver el resultado de tus pruebas
unitarias, pero en el navegador. Para arrancar las pruebas de esta forma,
escribe en tu consola:
npm run test-browserUna página se abrirá en tu navegador conteniendo los resultados de las pruebas.
Muy importante archivo, aunque no siempre estará (depende del proyecto). Acá es donde está el set de datos de prueba que se usarán para correr las pruebas.
Features/características extra sugeridas:
- En lugar de consumir la data estática brindada en este repositorio, puedes consumir la data del Live API de Laboratoria. Lee la documentación aquí.
- Agregarle a tu interfaz de usuario implementada visualizaciones gráficas.
- Brindar el detalle de progreso de cada estudiante por curso
- Proveer estadísticas de progreso de todo el cohort
En este proyecto deberás trabajar colaborativamente. Para ello, una de las integrantes del equipo deberá forkear el repositorio del cohort y la otra integrante deberá hacer un fork del repositorio de su compañera. Luego de esto, deberás configurar un remote hacia el repositorio del cual hiciste el fork.
Para mandar cambios desde un repositorio forkeado al original debes crear un pull request y el propietario del repositorio original recibirá una notificación para revisar el pull request y aceptar los cambios.
Aquí algunas recomendaciones para que organices mejor el trabajo con tu compañera:
-
En lugar de trabajar en una sola rama o branch, puedes organizar el flujo de trabajo con dos ramas principales:
master: rama que contiene las funcionalidades terminadas y sin errores.develop: rama dónde integrarás las funcionalidades conforme las vayas desarrollando.
-
Además de tener las dos ramas anteriores, puedes trabajar cada nueva funcionalidad en una rama individual (feature branches), estas ramas en lugar de crearse a partir de
master, tienen adevelopcomo su rama de origen. Cuando una funcionalidad es terminada se integra de nuevo adevelop. Las feature branches no se deben integrar directamente amaster. -
Por último, te sugerimos codear usando la técnica de pair programming.
¿Quieres saber más forks y pull requests?
-
Un fork es una copia de un repositorio en el que puedes experimentar sin afectar al repositorio original. Generalmente se usa para proponer cambios al proyecto de alguien más o para usar el proyecto de otra persona como punto de partida para una idea que quieras realizar.
-
Un pull request (PR) te permite solicitar la inclusión de cambios al repositorio original (tu punto de partida) en GitHub. Cuando un PR es abierto, este permite solicitar, discutir y revisar los cambios realizados con todos los colaboradores y agregar otros commits antes de que los cambios sean incluidos al repositorio original.
Recuerda revisar la rúbrica para ver la descripción detallada de cada habilidad y cada nivel. A continuación presentamos los niveles esperados para cada habilidad:
| Característica/Habilidad | Nivel esperado |
|---|---|
| Completitud | 3 |
| Investigación | 3 |
| Documentación | 2 |
| Habilidad | Nivel esperado |
|---|---|
| JavaScript | |
| Estilo | 2 |
| Nomenclatura/semántica | 3 |
| Funciones/modularidad | 2 |
| Estructuras de datos | 2 |
| Tests | 2 |
| HTML | |
| Validación | 3 |
| Estilo | 3 |
| Semántica | 2 |
| SEO | 0 |
| CSS | |
| DRY | 2 |
| Responsive | 2 |
| SCM | |
| Git | 3 |
| GitHub | 2 |
| CS | |
| Lógica | 1 |
| Arquitectura | 2 |
| Patrones/paradigmas | 0 |
| Habilidad | Nivel esperado |
|---|---|
| User Centricity | 3 |
| Entrevistas | 2 |
| Contraste | 3 |
| Alineación | 3 |
| Jerarquía | 2 |
| Tipografía | 2 |
| Color | 2 |
Esperamos que alcances al menos el nivel 2 en todas tus habilidades blandas.
| Habilidad | Nivel esperado |
|---|---|
| Planificación y organización | 2 |
| Autoaprendizaje | 2 |
| Solución de problemas | 2 |
| Dar y recibir feedback | 2 |
| Adaptabilidad | 2 |
| Trabajo en equipo (trabajo colaborativo y responsabilidad) | 2 |
| Comunicación eficaz | 2 |
| Presentaciones | 2 |
- Antes que nada, asegúrate de tener un 📝 editor de texto en condiciones, algo como Atom o Code.
- Para ejecutar los comandos a continuación necesitarás una 🐚
UNIX Shell,
que es un programita que interpreta líneas de comando (command-line
interpreter) así como tener git
instalado. Si usas un sistema operativo "UNIX-like", como GNU/Linux o MacOS,
ya tienes una shell (terminal) instalada por defecto (y probablemente
gittambién). Si usas Windows puedes usar Git bash, aunque recomendaría que consideres probar 🐧 GNU/Linux. - 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. 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. - A codear se ha dicho! 🚀
Para facilitar la lectura del JSON te recomendamos instalar algún plugin en tu navegador o visitar un JSON parser online: