Skip to content
/ CDMX013-data-lovers Public
forked from menamilochomil/CDMX013-data-lovers

A Harry Potter Fan club website with a database with the info for all the characters, spells, potions and more.

0 stars 53 forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

laladiaz/CDMX013-data-lovers

BranchesTags
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

268 Commits
src
src
 
 
test
test
 
 
.babelrc
.babelrc
 
 
.editorconfig
.editorconfig
 
 
.eslintignore
.eslintignore
 
 
.eslintrc
.eslintrc
 
 
.gitignore
.gitignore
 
 
EXTRA.md
EXTRA.md
 
 
FAQ.md
FAQ.md
 
 
README.md
README.md
 
 
package-lock.json
package-lock.json
 
 
package.json
package.json
 
 
thumb.png
thumb.png
 
 

Repository files navigation

Harry Potter Fan Club Website

Not resposive: desktop

The website

Harry Potter Fan Club

This website was inspired mainly by "The wizarding World" which is the official JK Rowling website, and is intended as a non commercial exercise.

In here, you can see characters, potions, spells and books displayed in a grid. In each section, you can search by name in the search bar, filter in the drop-down menu and order the characters, potions and spells as desire. The fun facts at the begining of the website change randomly with each page refresh executed.

Designingthe website

From the guidelines given, we started drawing a low-fidelity prototype to know which components would be necessary to develop.

After, we looked at the Wizarding world website and got inspire to make our high-fidelity prototype in Figma:

Figma Prototype

The difference in the size of bottoms was meant to evoke the daily prophet, where pictures, titles and writings feel missmatch and fun.

URL: https://laladiaz.github.io/CDMX013-data-lovers/

Guidelines give:

Í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 comprensible para las usuarias al lado derecho.

json-interfaz

2. Resumen del proyecto

En este proyecto aprenderás a manipular un conjunto de datos (set de datos) para hacerlos accesibles a través de una página web de utilidad para tus usuarias.

Tendrás que construir una página web que permita visualizar la data, filtrarla, ordenarla y hacer algún cálculo agregado. Con cálculo agregado nos referimos a mostrar información aún más relevante para los usuarios (promedio, el valor máximo o mínimo, etc).

Te proponemos una serie de datos de diferentes temáticas para que los explores y decidas con cuáles 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:

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

user-centricity

  • Diseñar un producto o servicio poniendo a la usuaria en el centro

product-design

  • Crear prototipos de alta fidelidad que incluyan interacciones

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

research

4. Consideraciones generales

  • 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.
  • En este proyecto aprenderás sobre "Historias de Usuario". Trabaja en una historia hasta terminarla antes de pasar a la siguiente. Trabaja hasta la historia que puedas/quieras según el tiempo que te vaya tomando.

5. Criterios de aceptación del proyecto

Llamamos "Criterios de aceptación" a todas aquellas características que debe tener un proyecto para ser "aceptado" como válido. En este caso se consideran las Historias de Usuario 1, 2 y 3.

Así mismo, cada Historia de Usuario tiene sus los suyos propios. Los CA deben ser caracerísticas obersvables, concretas, jamás generalidades del tipo "amigable con el usuario" (¿qué significa eso exactamente?).

Historias de usuario

Generalmente, las Historias de Usuario son el resultado de un proceso de investigación o research de las usuarias y de algunas necesidades específicas del producto/negocio.

Una vez que entiendas las necesidades de tus usuarias, completa las Historias de Usuario que te proveemos predefinidas para que representen exactamente todo lo que decidas implementar.

Asegúrate de completar los Criterios de Aceptación y la Definición de Terminado (definition of done) y para cada una.

Termina una historia de usuario antes de pasar a la siguiente (Cumple con Definición de Terminado + Criterios de Aceptación).

[Historia de usuario 1]

Yo como usuario [visitante del sitio] quiero poder VER todos los personajes/películas/deportistas para familiarizarme.

Criterios de Aceptación. Edita/agrega de acuerdo a tu implementación exactamente:

  • La UI es responsive (teléfonos y PC).
  • Todos los personajes/películas/deportistas aparecen en una misma vista, en forma de grilla (cuadrícula) sin ningún orden en particular.
  • La vista no tiene paginación, se hace scroll desde el primer elemento hasta el último.
  • Cada cuadrícula contiene:
  • Nombre de personaje/película/deportista.
  • [XXX]

  • Al hacer click/tap en cada cuadrícula sucede [XXX].

  • La UI es exactamente igual al prototipo de alta fidelidad (colores, tamaños de bloques,tipo de letra, tamaño de letra, imágenes, etc. )

Definición de Terminado. Edita/agrega de acuerdo a tu implementación exactamente

  • Todo el código está en la rama principal/main del repositorio.

  • La página está publicada en Github Pages y es accesible mediante un enlace/link/liga.

  • Cada estudiante del equipo ha hecho code review del código escrito por la(s) otra persona(s).

  • Se hacen pruebas de usabilidad con al menos 2 usuarias y se incorporan las mejoras identificadas en la versión.

[Historia de usuario 2]

Yo como usuario [visitante del sitio] quiero poder FILTRAR los personajes/películas/deportistas según lo que me interesa ver en particular.

Criterios de Aceptación. Edita de acuerdo a tu implementación exactamente

  • La UI es responsive (teléfonos y PC).
  • La UI contiene elementos para filtrar los datos (desplegables u otros).
  • Al seleccionar valores de los elementos para filtrar, en la parte inferior de la página aparece solamente el tipo de contenido filtrado.

Definición de Terminado. Edita/agrega de acuerdo a tu implementación exactamente

  • Hay un test unitario para la función de filtrado. Cobertura del 70%.
  • Todo el código está en la rama principal/main del repositorio.
  • La página está publicada en Github Pages y es accesible mediante un enlace/link/liga.
  • Cada estudiante del equipo ha hecho code review del código escrito por la(s) otra persona(s).
  • Se hacen pruebas de usabilidad con al menos 2 usuarias y se incorporan las mejoras identificadas en la versión.

[Historia de usuario 3]

Yo como usuario [visitante del sitio] quiero poder ORDENAR los personajes/películas/deportistas por sus nombres de manera alfabéticamente ascendente (A-Z) y descendente (Z-A).

Criterios de Aceptación. Edita de acuerdo a tu implementación exactamente:

  • La UI es responsive (teléfonos y PC)
  • La UI contiene elementos para ordenar los datos (flechas, radios, desplegables u otros).
  • Al seleccionar valores de los elementos para ordenar, en la parte inferior de la página aparece solamente el contenido ordenado según el criterio seleccionado.

Definición de Terminado. Edita/agrega de acuerdo a tu implementación exactamente:

  • Hay un test unitario para la función de ordenado. Cobertura del 70%.
  • Todo el código está en la rama principal/main del repositorio.
  • La página está publicada en Github Pages y es accesible mediante un enlace/link/liga.
  • Cada estudiante del equipo ha hecho code review del código escrito por la(s) otra persona(s).
  • Se hacen pruebas de usabilidad con al menos 2 usuarias y se incorporan las mejoras identificadas en la versión.

[Historia de usuario 4]

Yo como usuario [visitante del sitio] quiero poder BUSCAR los personajes/películas/deportistas según lo que me interesa ver en particular.

Criterios de Aceptación. Edita de acuerdo a tu implementación exactamente:

  • La UI es responsive (teléfonos y PC)
  • La UI contiene elementos para filtrar los datos (desplegables u otros).
  • Al seleccionar valores de los elementos para filtrar, en la parte inferior de la página aparece solamente el tipo de contenido filtrado.

Definición de Terminado. Edita/agrega de acuerdo a tu implementación exactamente:

  • Hay un test unitario para la función de búsqueda. Cobertura del 70%.
  • Todo el código está en la rama principal/main del repositorio.
  • La página está publicada en Github Pages y es accesible mediante un enlace/link/liga.
  • Cada estudiante del equipo ha hecho code review del código escrito por la(s) otra persona(s).
  • Se hacen pruebas de usabilidad con al menos 2 usuarias y se incorporan las mejoras identificadas en la versión.

[Historia de usuario 5]

Yo como usuario [visitante del sitio] quiero poder ver estadísticas de [XXX].

Criterios de Aceptación. Edita de acuerdo a tu implementación exactamente:

  • Escribe los criterios de aceptación

Definición de Terminado. Edita/agrega de acuerdo a tu implementación exactamente:

  • Escribe la definición de terminado

[Historia de usuario 6]

A veces queremos agregar alguna característica que no necesariamente se puede expresar como una Historia de Usuario. En esos casos se les suele llamar PBI (product Backlog Item o elemento del backlog).

Ejemplo:

js Crea un PBI que implique consumir la data de forma dinámica, cargando un archivo JSON por medio defetch. La carpetasrc/datacontiene una versión.jsy una.jsonde de cada set datos.

[Historia de usuario 7]

Escribe una historia de usuario que implique agregarle visualizaciones gráficas a tu interfaz de usuario. Para ello te recomendamos explorar librerías de gráficas como Chart.js o Google Charts.

Criterios de Aceptación. Edita de acuerdo a tu implementación exactamente:

  • Escribe los criterios de aceptación

Definición de Terminado. Edita/agrega de acuerdo a tu implementación exactamente:

  • Escribe la definición de terminado

[Historia de usuario 8]

Crea un PBI que implique 100% de Coverage.

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.

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.

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

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.

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.

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

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/data.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ón filter o filtrar recibiría la data, y nos retornaría aquellos datos que sí cumplan con la condición.

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

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

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/data.spec.js

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

7. Pistas, tips y lecturas complementarias

Primeros pasos

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

About

A Harry Potter Fan club website with a database with the info for all the characters, spells, potions and more.

Topics

javascript css git html5 figma scrum-agile

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Languages

  • JavaScript 96.5%
  • HTML 2.1%
  • CSS 1.4%