How to use Redis with MuleSoft. A quick start presentation.
UX en proyectos de moove-it
1. UX en proyectos de moove-it
Grupo de UX
Presentación: Seba Suttner,
Martin Cabrera,
Seba Borrazás
2. Que hacemos en el grupo de UX?
Objetivos
1. Que cada integrante de este grupo aprenda más
sobre UX
2. Volcar a TODO moove-it las enseñanzas
3. Que impacte el trabajo realizado en mejoras sobre los
proyectos
4. Generar un area que mejore y audite el trabajo
realizado en el área de UX
5. Poder vender los servicios de esta área
Quienes somos por ahora ?
JP, Martin, Suttner, Moretti, Borrazás, Guzman, Fernando
y Andreas
3. Patrones a analizar
● Tablas
○ Hover de datos y titulos
○ Truncar
○ Zebra
○ Sorting
○ Valor del dato (ej. 0, 1 ... true, false)
● Links vs Botones
● Acciones
○ Primaria, secundaria, Destrucción
● Criterios
○ Estéticos
○ Funcionales
4. Tablas - Truncar
Problema:
Cuando despliego datos sobre una tabla puede pasar que un
valor tome un largo mayor al "width" de la columna.
Solución:
● Truncar el valor
● Agregar en el hover la descripción completa
5. Tablas - Largo de una columna
Problema
Está bien que el titulo exprese el significado del valor ... no
abusar con el largo!
Idealmente tener en cuenta el largo que pueden tomar los
valores en la columna.
Solución titulo:
1. Si es posible acortar el titulo sin perder el significado
2. Si no es posible poner una sigla o abreviar y con el hover
poner la descripción completa
Pique adicional
3. Ojo con los espacios. Cortan la columna. Agregar " "
en vez de espacio para que no haga el salto de linea
6. Tablas
- Trunca el dato de descripción !
- no agrega el la descripción en el hover !
- Titulo grande y valor pequeño !
7. Tablas - valor "humano"
Problema
Hay veces que el valor que visualizamos es 1 o 0 en vez de
poner Verdadero/Falso. Esto ocurre tambien con
identificadores. El usuario no tiene porque saber que 453 =
Montevideo
Solución titulo:
1. Transformar a el valor que el usuario entiende para
visualizarlo en la tabla
8. Tablas - valor "humano"
El articulo que es ? el
numero a que corresponde
? que espera el usuario ?
Group ? a que hace
referencia el valor 2222 ?
9. Tablas - Sorting
Problema:
● se desea comparar campos
● hay muchas filas
● hay paginado
● no toda la información está visible
Solución:
● agregar sorting por columna en los campos necesarios
Indicaciones:
● ser bien explícitos al indicar la existencia de la funcionalidad
● indicar qué columna está ordenada en cada momento
10. Tablas - Sorting
si bien ambas
indican qué
columna está siendo
sorteada, sólo una
muestra la
funcionalidad al
hacer hover
11. Tablas - Zebra
Problema:
● hay muchas filas
● se pierde distinción entre una fila y otra
● poca legibilidad
Solución:
● pintar alternadamente las filas con dos colores distintos
Indicaciones:
● aumentar contraste
● usar colores de similar valor, diferencia sutil
● de baja saturación para no cargar la tabla
12. Tablas - Zebra
ver diferencia de
contraste y
legibilidad entre filas
no utilizar 'inline-editing
yellow' a menos que se
pueda editar al hacer
click
13. Inline editing
Problema:
Como indicar a el usuario que determinado/s campos son para
"edit in place" o "inline editing"?
Solución:
Utilizar el color #FFFF92 en el hover del contenedor del
formulario o de la fila de la tabla. Este color debe ser mostrado
también mientras se edita el elemento para marcar que el
mismo se esta editando. De ser posible agregar un elemento
que se muestre en todo momento para indicar que esa seccion
es editable (icono lapiz).
Nota: no se recomienda utilizar
este color para otra cosa que no
sea el inline editing.
15. Camino de Migas
Problema:
● el usuario necesita saber dónde se encuentra dentro del
flujo de la página para saber cómo volver
Solución:
● utilizar labels ordenados jerárquicamente que indiquen el
camino recorrido hasta el punto actual
Indicaciones:
● todas menos la locación actual deben ser links que
permiten navegar hacia atrás
● utilizar separadores que indiquen un orden
● los separadores no deben ser links
16. Camino de Migas
está bien que el
hover tenga efecto
en todos menos el
último, pero
también hay que
mostrar
previamente una
diferencia de estilo
17. Links vs botones
Problema:
● Cuándo usar cual?
Solución:
● Links are for navigation. They are used to move between
pages in an information space.
● Buttons are for actions that cause some chance (e.g.
adding a product to shopping cart)
Un boton demuestra una mucho mayor importancia que un
link, lo que significa que debe ser reservado para las acciones
que implican un cambio o un compromiso por parte del
usuario.
19. Acciones
Problema:
Se necesita indicar un flujo claro al usuario.
Solución:
● Evitar las acciones secundarias siempre que sea posible.
"Do you really need that 'reset' button?"
● Asegurarse que exista una clara distinción entre la acción
primaria y la secundaria. Agregar peso visual a la accion
primaria y quitar peso a la secundaria (color, botón/link,
tamaño).
● Alinear la acción primaria con los campos del formulario
para generar un camino claro para completarlo.
21. Mantener Criterios Visuales
Problema:
● lograr una página web consistente
● conseguir que tenga porte
● transmitir seguridad al navegarla
Solución:
● seguir patrones de diseño UX
● mantener los criterios tomados
● no confundir al usuario con diseños distintos para
funcionalidades similares
● que el usuario encuentre lo que espera a partir de lo ya
aprendido dentro de nuestra aplicación
● principio de la menor sorpresa
● principle of least astonishment (POLA)
23. Mantener criterios funcionales
Problema
Si un componente visual realiza una acción o función en un
módulo, mantener el criterio en toda la app.
Solución:
1. Tener criterio !
