- 1. Organizacion y planificaci贸n
- 2. UX
- 3. Dise帽o de displays: Html y CSS
- 4. C贸digo en Javascript
- 5. Test de usabilidad
Antes de empezar la divisi贸n del trabajo, se hizo una lectura conjunta del Readme, seguida de una discusi贸n respecto a la interpretaci贸n realizada por cada una respecto a los objetivos y alcances del desarrollo de la app.
Dada la confusi贸n que despierta la revisi贸n de un bloque de informaci贸n nuevo, decidimos realizar un esquema general que englobara los puntos m谩s relevantes de la lectura previa realizada al Readme. Este esquema fue la base inicial con la que se trabaj贸 para dividir tareas en equipo.
Para el desarrollo del usuario tipo, que ser铆a la base de toda la fase de dise帽o, trabajamos inicialmente en forma individual, desarrollando separadamente dos usuarios tipos. Posteriormmente se desarroll贸 un usuario que mostrara caracter铆sticas mixtas (un poco de cada usuario)
*ANTONIA RAMIREZ
Joven estudiante, que despu茅s de haber recibido una asignaci贸n de programaci贸n siente inter茅s al respecto, y desea ahondar en el tema, pero en una forma entretenida. Le gustan los juegos, y pasa mucho tiempo conectada en el celular.
*ANA MARIA PEREZ
Ana Maria es una joven recepcionista en una empresa tech, ella desea mejorar sus posibilidades de lograr un ascenso, y para ello desea conocer los t茅rminos b谩sicos de programaci贸n. Como ella realiza un trabajo cargado de presi贸n, necesita que la informaci贸n sea presentada en forma simple.
Bas谩ndonos en las caracter铆sticas de ambos perfiles, creados en forma individual, se crea el usuario Antonia Mar铆a, que es una mezcla de ellos. Antonia Mar铆a es una joven que reci茅n culmina sus estudios en la media, y no sabe que carrera desea cursar, por ese motivo toma un trabajo como recepcionista en una empresa tech. Luego de unos meses, comprende que necesita un trabajo que represente un mayor reto, y que, adem谩s, le permita desarrollarse en forma profesional, por eso, desea evaluar si el mundo tech, le resulta en efecto interesante, pero las obligaciones en su trabajo la dejan agotada, y no tiene las energ铆as como para iniciar tomando un curso formal.
Como respuesta a la necesidad de Antonia Mar铆a, quien es una persona joven (20 a帽os), que desea abrirse paso en el mundo de la tecnolog铆a, se propone el desarrollo de un juego de memoria, el cual, adem谩s de funcionar para fines l煤dicos, tambi茅n permita en una manera poco invasiva, que Antonia Mar铆a se vaya familiarizando con las generalidades del mundo de los desarrolladores web, ayud谩ndola as铆, a que defina el 谩rea profesional en la que desea incursionar. Siendo que ella se conecta constantemente a trav茅s de su tel茅fono, creemos que, una app tipo juego puede solventar en forma eficiente esta necesidad.
Se desarrollaron dos prototipos, en los que, cada una reflej贸 su percepci贸n de la manera en la que deb铆a desarrollarse la app. Una vez cada uno tuvo su esquema en papel, procedimos a comparar , y a plantear una manera global que incluyera las mejores ideas de ambos desarrollos.
*MODELO A
*MODELO B
Partiendo de ambos modelos desarrollados, se obtuvo el siguiente esquema, que muestra el funcionamiento de la app.
Objetivos:
-
Entender funcionamiento de la app (Facilita desarrollo del c贸digo).
-
Jerarquizar tareas, dando prioridad a los elementos primarios.
-
Tener una base com煤n para desarrollo prototipo de alta fidelidad
Leyenda
- Cuadro amarillo: display primario (elemento fundamental para el funcionamiento de la app)
- Circulo verde agua: Botones primarios
- Cuadro naranja: display secundario (elemento que enriquece el dise帽o de la app, pero cuya presencia no es vital para la funcionalidad de la app)
- Circulo azul: Botones secundarios
A fin de caracterizar la app, se dise帽贸 un logo con el nombre, y se seleccion贸 una mascosta que guiara al jugador durante el desarrollo de la partida.
Nombre: Siendo que se trata de una aplicaci贸n para personas interesadas en el mundo de la tecnolog铆a, se tomaron en consideraci贸n nombres que pudieran ser asociados con esta tem谩tica.
Logo: Tomando como referencia el nombre seleccionado (Geek麓s memory), se dise帽贸 logo:
Mascota: Se dise帽贸 un personaje que pudiera ser la imagen de la app ("Geeky")
A fin de generar un dise帽o que estuviera adaptado a las necesidades del usuario, se trabaj贸 en base a "historias de usuario", las cuales, adem谩s de ayudarnos a definir la app por etapas, tambi茅n nos permitieron ocupar la "perspectiva del usuario", pensando en la aplicaci贸n de una manera m谩s funcional que pr谩ctica.
* Soluci贸n: Crear display con instrucciones y un bot贸n que permita acceder a 茅l
* Criterios m铆nimos de aceptaci贸n: Que al hacer click en el bot贸n se muestre cuadro emergente con texto de instrucciones.
* Product Backlog:
a. Display p谩gina de inicio
b. colocar bot贸n "?" en la p谩gina de inicio.
c. dar funcionalidad al bot贸n para ir desde pagina de inicio hasta las p谩gina de instrucciones
d. Crear display de instrucciones
e. Escribir instrucciones
f. A帽adir estilo de acuerdo al dise帽o de figma
g. Dise帽ar en forma responsiva
* Soluci贸n: Barajar cartas usando algoritmo de fisher- Yates en forma correcta
* Criterios m铆nimos de aceptaci贸n: Que se genere un nuevo orden aleatorio en cada mano, que al hacer click en el lugar donde se encuentra la carta se muestre la imagen importada desde la carpeta de componentes.
* Product Backlog:
a. Dise帽ar cartas.
b. "Llamar" cartas desde carpeta de componentes.
c. Lograr que al hacer click se muestre componente: "js", "git", "html", "css"... segun corresponda.
d. Manipular elementos contenidos en un objeto en forma satisfactoria
e. Generar objeto inicial ( conteniendo 4 componentes que a su vez deben ser duplicados)
f. Implementar sobre ese objeto el algoritmo de Fisher- Yates para generar orden aleatorio
g. Usar ese objeto con orden aleatorio para mostrar juego en pantalla
Tercera historia de usuario: "Necesito saber para que sirve la herramienta descubierta en la carta (imagen en la carta webdev de memoria)"
* Soluci贸n: Cuadro de texto breve con definici贸n de la imagen que se muestra en la carta
* Criterios m铆nimos de aceptaci贸n: Que se muestre un imput type text con la informaci贸n requerida
* Product Backlog:
a. Crear objeto con las propiedades "id" e "info" (conceptos).
b. Importar objeto al archivo App.js
c. Llamar info, y ubicar en div de texto, ubicado en la parte inferior del display "gamePage".
d. Hacer que la informaci贸n mostrada sea consistente con las cartas que hacen match.
* Soluci贸n: Display que muestre carta y mensaje de victoria cuando se haga match con todas las cartas
* Criterios m铆nimos de aceptaci贸n: Que se muestre mensaje de victoria
* Product Backlog:
a. Crear display "VictoryPage"
b. Crear contador de intentos/ contador de matchs
c. Mostrar mensaje de victoria
* Soluci贸n: Incluir bot贸n "reset" que active algoritmo de fisher-yates, y retorne a la p谩gina de juego.
* Criterios m铆nimos de aceptaci贸n: Que el bot贸n reset genere un nuevo orden de cartas
* Product Backlog:
a. Crear bot贸n "reiniciar" en gamePage
b. Crear funci贸n que active mecanismo de orden aleatorio y enlazar a trav茅s de un evento a diicho bot贸n.
Como herramienta visual para desarrollar las historias, y para organizar tareas y flujo de trabajo, implementamos el uso de un tablero TRELLO, siguiendo la siguiente estructura de trabajo:
- Definimos historia de usuario
- Se escribi贸 una soluci贸n a la necesidad manifestada en la historia
- Se defini贸 un criterio m铆nimo de aceptaci贸n para dar la historia por completada
- Se desarroll贸 el Product Backlog, el cual define la historia en t茅rminos de tareas a ejecutar para garantizar su cumplimiento.
- Definimos metas bas谩ndonos en el product backlog, definiendo tareas espec铆ficas para cada una durante el sprint en curso.
- Trabajamos con tres columnas para manejar el flujo de trabajo:
*To Do: Planeado para desarrollar en el sprint/ tarea que aun no ha sido tomada por ning煤n mienbro del equipo.
* Doing: Esta es la secci贸n de las tareas que est谩n siendo trabajadas. Para llevar un orden, especificamos el miembro del equipo que la estaba desarrollando.
* Done: Ac谩 especificamos las tareas completadas de la historia de usuario en curso, cuando se hace cierre de una historia, las tareas completadas pasan a la columna historial, de esta manera evitamos que el tablero se recargue visualmente.
Se desarrollaron dos modelos, para luego someter a testeo:
*MODELO A
*MODELO B
En base a las observaciones recibidas, se realizaron modificaciones, resultando el dise帽o, en base al cual se programar铆a la app:
En el archivo Html se estructuraron en secciones todas las vistas del usuario con sus respectivas id que permite a traves de JavaScript mostrar u ocultar cada una, estas son: Home Page, Game Page, Instructions Page y Victory Page.
Algunas de las clases utilizadas se repetian en las distintas p谩ginas, lo que fue importante de detectar, ya que, en un inicio nos habiamos dividido la realizaci贸n de las p谩ginas en el equipo y luego nos dimos cuenta que eran componentes los que debiamos crear para reutilizarlos en las distintas p谩ginas. De tal manera que unificamos para hacer m谩s eficiente el codigo y darle mejor experiencia al usuario.
En la creaci贸n del CSS teniamos la tarea de crear una aplicaci贸n responsiva, esto es, que se pueda ver de buena manera en distintos tama帽os de pantallas.
Para realizarlo, utilizamos en el Html la etiqueta viewport que nos permite definir el 谩rea para renderizar las p谩ginas y desde el CSS con una consulta @media poder identificar desde que dispositivo esta viendo la p谩gina el usuario para brindarle una 贸ptima experiencia y ajuste a las resoluciones de su dispositivo.
- Movil: @media only screen and (max-width: 430px)
- Tablet: @media only screen and (min-width: 431px)
- Desktop: @media only screen and (min-width: 769px) Asignada por defecto.
As铆, en la medida que detecta el tama帽o de las pantallas se despliegan propiedades de CSS distintas que dan mejor aspecto a la aplicaci贸n.
Un elemento considerado para darle m谩s movimiento y aspecto l煤dico al Memory Match fue el dise帽o de animaciones y transiciones.
La siguiente animaci贸n permite que las cartas aparezcan en 1 segundo despues de cargar la p谩gina, llamando la animaci贸n desde la clase cards.
@keyframes appear {
from {opacity: 0;}
to {opacity: 1;}
}
.cards{
..
animation-name: appear;
animation-duration: 1s;
..}
Para poder voltear las cartas se hizo una adaptaci贸n del efecto flip, documentado aqu铆: https://codepen.io/desandro/pen/LmWoWe
Esto utiliza funciones 3D (transition: transform 1s; transform-style: preserve-3d;) y rotaci贸n en el eje Y (transform: rotateY(180deg)) para generar el efecto deseado. Lo que nos permite que cuando el usuario haga click se voltee la carta que desea y posteriormente pasa a un ciclo condicional en donde, si las cartas coinciden se quedan volteadas, sino, se ocultan nuevamente para que el usuario siga descubriendolas.
La estructura de nuestra app se basa en la ejecuci贸n de procedimientos gatillados con el evento click.
- Llamamos los datos (metodo import) desde el archivo webdev.js (obtuvimos propiedades id, imagen y background) y webdevDefinition.js (informaci贸n conceptual).
- El archivo webdevDefinition.js, fue creado ante la necesidad de a帽adir informaci贸n detallada para cumplir con la historia de usuario n煤mero 3.
-
Partiendo de la informacion base del archivo da data webDev, se obtuvo un nuevo array de objetos, usando el m茅todo "Array.from" (inputArray), de ese array se toman en forma aleatoria 4 elementos, los cuales despu茅s de ser duplicados (para obtener elementos por dupla para hacer el match), dan como resultado el sortedArray, que fue nuestro arreglo base en la ejecuci贸n del juego.
-
Este nuevo array de objetos (sortedArray), contiene la informaci贸n para las 8 cartas que forman parte del juego y cuyas propiedades son mezcladas antes de mostrarlas.
-
El orden aleatorio ofrece una sensaci贸n de azar, y aunque no existe un m茅todo que ofrezca un resultado aleatorio absoluto, existen t茅cnicas para ofrecer la sensaci贸n de "aleatoriedad".
-
En este proyecto, nos basamos en el algoritmo de fisher-Yates para alcanzar orden al azar.
-
Su ejecuci贸n se encuentra condensada dentro de la funci贸n randomArray(), la cual engloba el mecanismo de azar del juego.
-
Finalmente, a trav茅s de manipulaci贸n de delementos del DOM, se hizo la llamada respectiva de estos datos, para la creaci贸n de elementos (cartas.)
Creaci贸n de cartas:
-
La estructura b谩sica de las cartas se encuentra en HTML, y consta de una serie de "div", los cuales mediante la manipulaci贸n desde CSS y JS, se transforman en los elementos visuales y din谩micos, que constituyen las cartas.
-
En un sentido pr谩ctico, se puede decir que las cartas operan como "botones", y que a trav茅s del evento "click" desencadenan los m茅todos requeridos para dar funcionalidad al juego.
Validaci贸n de jugadas:
-
Cada juego est谩 conformado por un set de 8 jugadas, donde, cada match est谩 constitu铆do por dos jugadas que acierten cartas iguales.
-
Considerando esto, el match es almacenado en un contador "win", el cual, al llegar a la suma de 4 aciertos te lleva a la pantalla de victoria.
-
El acierto de dos jugadas muestra la definici贸n de cada elemento webdev descubierto.
-
La manipulaci贸n dinamica del DOM en el juego, permiti贸 su funcionamiento por una serie de ciclos for y condicionales if, y son estas herramientas de control de flujo, las que revisan si las cartas van coincidiendo.
-
Para ofrecer un puntaje al jugador, e incrementar el atractivo del juego, se gener贸 otro contador (tried) que se encarga de almacenar la cantidad de clicks que el jugador realiza para hacer match a todas las cartas.
Para realizar pruebas con usuarios reales, le pedimos a 3 personas que utilizaran la aplicaci贸n web, dandole como instrucci贸n "utiliza esta p谩gina". Los resultados se muestran a continuaci贸n considerando tres criterios que se habian definido previamente para la observaci贸n.
