W.

Wearing a wereable

Hace un mes me compré un (nuevo) smartwatch. – En realidad iba a ser un regalo, pero como siempre me pasa, acabó siendo un autoregalo y una promesa de un regalo mejor).

El modelo es el LG G Buddy en negro con Android Wear, algo muy básico que conseguí por 99€, un precio razonable para experimentar. – Sí ya sé, vaya birria de regalo, qué le vamos a hacer…

Por sus características, es un reloj que debe estar conectado por Bluetooth a mi móvil Android, y cargarse cada 3-4 días de uso. No me parece demasiado grande para mi muñeca, ni con un estilo demasiado marcado, ni pesa mucho. Creo que es cómodo como cualquier otro reloj y cumple mínimo las dos funciones básicas que debe tener:

  1. Da la hora
  2. Puedes ponértelo en la otra muñeca si quieres acordarte de algo

La experiencia de la tecnología llevable

El uso que le he dado al reloj ha sido un uso cotidiano. No me he atrevido a llevarlo mientras hacía deporte, no me parecía tan apropiado para eso a pesar de que es resistente al agua. El caso es que me resulta bastante incómodo cualquier tipo de pantalla que no tenga botones físicos. Uso un Polar, antes de eso usaba el Nike+ Sportwatch y antes de eso mi iPod de 3º generación. Cuando corro me resulta más cómodo presionar, que tocar o deslizar el dedo mientras estoy en movimiento y esperar que la interfaz reaccione.

Sin embargo, para el día a día, mientras trabajo o hago mi vida fuera de casa, lo tengo conectado con mi móvil tanto como la batería de éste me lo permite.

El reloj es un reproductor de notifcaciones el 90% del tiempo, un acceso rápido a contestar a esas notificaciones un 5% y el otro 5% es ese desconocido que te encontrarías en un ascensor que te hablaría del tiempo, del tráfico y además te chivaría lo poco o mucho que te has movido ese día.

Éste último 5% es todo mérito de Google Now (y Google Fit), que me encanta y creo que entiende muy bien el contexto y la información relativa al usuario. Fuera de bromas, creo que llevarlo en la muñeca es mucho más oportuno que en el móvil.

Sobre el exceso de notificaciones podría decirse que ‘ahorra tiempo’ si no se acumulan. Si lo hacen ya no puedes previsualizarlas en el reloj pero sí en el móvil. Es cómodo porque es discreto, puedo estar todo el día moviéndome por la casa o la oficina, dejar mi móvil en el bolso y enterarme de si alguien me está hablando por alguna red social o por mail mirando rápidamente la muñeca sin interrumpir ninguna conversación ‘en directo’.

En el coche también es útil, pero peligroso. Recibir un mensaje y poder contestarlo hablándole a tu reloj como en el coche fantástico es más seguro que intentar hacerlo manipulando el móvil. Aún así, hay que irse con cuidado.

En general este uso de receptor o canalizador de notificaciones para que resulte útil te convierte en un poco esclavo, como ya lo hace el móvil. Cuanto más quieres que te comunique, más inoportuno o estresante se convierte.

Las reacciones de la gente han sido curiosas. No se puede negar que tiene un toque moderno, techie o frikie. El diseño de cada skin para el reloj es divertida y ‘chanante’. Los smartwatch molan porque aún no está muy extendido.

Finalmente un uso curioso es mientras trabajo con el ordenador (entro 8h-10h al día), escucho música en Spotify (4-5h al día) y me da por saltar una canción desde el reloj. ¡No sirve para nada porque falla! Si bien salta la canción, parece que el móvil recibe la interacción y entiende que debe ser él el reproductor, así que paso de escuchar música por mis cascos a compartirla con quien haya en la habitación. Absurdo e incómodo porque tienes que cerrar la app en el reloj para que no te moleste.


Llevar un wereable es, en mi opinión, algo que me resulta de lo más natural y útil según qué contextos. Cuando hago deporte no puedo vivir sin mi reloj, cuando estoy en casa no me resulta interesante a no ser que pudiera verlo conectado a otros dispositivos o electrodomésticos, y en el trabajo me funciona bastante bien cuando realmente me muevo de mi puesto (en reuniones, en la mesa de algún/a compañero/a, etc.)

No descarto comprar algo mejor en el futuro, seguramente con WiFi y con mejor diseño. Pero como siempre, lo que vale de un reloj son sus aplicaciones y sus servicios. Es imprescindible que estén adaptados a contextos de uso reales y útiles. Seguro que Apple vende millones de relojes estas navidades, pero está en nosotros/as, creadores de productos digitales, aprovechar la oportunidad para construir soluciones que sirvan para algo más que para recibir notificaciones.

No seamos como consumidores y usuarios sólo el producto de la industria, no nos convirtamos sólo en ‘donantes de datos’, seamos capaces de aprovechar la naturalidad de la tecnología llevable, vestible, ponible y portable, para ofrecer algo distinto, para percibir algo evolucionado.

Más allá de la moda y el diseño, los wereables se convertirán en la tecnología que nos ayude a ampliar nuestros sentidos de la forma más natural y menos disruptiva.

Trabajemos para conseguirlo.

I.

Insider

Me gusta la ingeniería, me gusta pensar en procesos y metodologías como forma de coordinar el esfuerzo de un equipo de gente con perfiles diferentes para sacar el mejor producto viable. Cerebro y músculo con objetivos comunes. Como me gusta, disfruto del proceso, más cuando la repercusión del beneficio al finalizarlo no está siempre clara.

Creo que pensar en procesos y metodología forma parte de cualquier ingeniero y también de cualquier persona dedicada a la Experiencia de Usuario (incluso en equipos de un sólo miembro).

De la ingeniería también me gustaba programar, sobre todo cuando era una tarea sencilla, cuando no tenía que salir del shell para hacer cosas chulas, o cuando trabajaba con entornos de desarrollo completos. Cuando el lenguaje que usaba no requería de aprender una serie de cosas inútiles porque no estaba bien pensado para el propósito o arquitectura sobre el que se desplegaría.

Me gustan las cosas sencillas, es decir no me gustan las cosas innecesariamente complicadas por complejas que sean.

Ya sea porque soy ingeniera o me he pasado la vida rodeada de frikies amantes de la tecnología, me gusta conocer las novedades en tecnología que hay en el mercado o en investigación. Me gustan los prototipos, las ideas nuevas y el impacto que ésto tiene en la sociedad.

Y me gusta formar parte de esto como creadora, pensadora, desarrolladora y diseñadora. Por eso pienso que forma parte de mi preparación fundamental mantener siempre la visión más amplia posible en la creación de productos tecnológicos.

Sin embargo, durante varias etapas de mi carrera desde que me matriculara en la factultad en 2001, me he ido encontrando con una serie de mensajes contradictorios de quienes creen estar ahí para enseñarte algo, a saber:

  1. Si no eres un amante del cacharreo no eres informático, pero si no sabes nada sobre matemáticas puedes ser lo que quieras.
  2. Aprender tecnologías frontend, desarrollo web o diseño de interfaz es algo accesorio, pero trabajar en un desarrollo y no tener dorma de que lo utilice un humano es secundario.
  3. Los diseñadores tenemos que aprender a programar, pero no podemos dar nuestra opinión sobre tecnología.
  4. En los negocios la seguridad en uno mismo es importante, pero ojo, lo que para unos es muestra de pasión para otros es muestra de cabezonería.
  5. Las habilidades sociales y emocionales son imprescindibles, a no ser que seas muy crack que se te disculpará todo y podrás tener a un equipo entero envenenado.
  6. A tus empleados, estudiantes, compañeros hay que criticarles siempre para que aprendan, eso sí, el refuerzo positivo será siempre virtual en forma de notas o sueldo, si ninguna de estas cosas llegan allá cada uno con sus frustraciones.

Como decía, me gusta mi profesión, aunque a veces te invadan las dudas, las dudas de otros.

I.

Interfaz de línea de comandos: ¿un paradigma poco popular?

Han pasado ya unas cuantas semanas desde que empecé en mi nuevo trabajo y tenía muchas ganas de hablar de unos cuántos temas que han ido surgiendo durante todo este tiempo.

Uno de los que más interés me está causando, debido a su estrecha relación con la Interacción Persona-Ordenador (HCI) es el de las Interfaces de Línea de Comandos (CLI) y lo usable (o no) de su diseño.

No es éste un tema habitual ya que, usualmente, todo lo que tiene que ver con la Usabilidad y Experiencia de Usuario se termina ligando inevitablemente a las Interfaces Gráficas de Usuario (GUI) ya sean web, móviles, de escritorio u otras superficies. Lo cierto es que, desde que la metáfora visual se utiliza como representación del modelo de comunicación entre personas y computadores, la necesidad de diseñar estas interfaces de una forma eficiente para su uso se convierte en una obligación.

¿Pero qué ocurre con las CLI? ¿Se les puede aplicar criterios cualitativos de usabilidad? Más allá de los estándares que ya existen ¿representa la línea de comandos un paradigma relegado a un modelo de uso en declive o poco popular?

Haciendo un poco de investigación me topé con algunos recursos interesantes que me sorprendieron.

El primero que recomiendo es este libro: Build Awesome Command-Line Applications in Ruby 2: Control Your Computer, Simplify Your Life

Claramente destinado a programadores de interfaces de comandos pero con un enfoque muy serio en cuanto al respeto hacia los estándares para desarrollar algo suficientemente familiar. En el libro se destacan varias ideas en su introducción y conclusión:

  • Las CLI están focalizadas a scripting.
  • Las CLI no suelen utilizarse para el trabajo final, sino como recurso.
  • Las CLI son un white canvas (con los problemas de usabilidad inherentes que eso conlleve).

Pero por el contrario

  • Las GUI son interfaces muy difíciles de automatizar.
  • Las GUI no son interfaces fácilmente portables.

Quiero referenciar también el post que encontré en Biko que, curiosamente, trata el aspecto gráfico o visual de las CLI para hablar sobre UX. Sin faltarle razón creo que es un tema en el que se puede profundizar hacia muchos más aspectos.

Otro interesantísimo recurso que encontré fue este artículo escrito por Florian Cramer y Kamen Nedev que me parece simplemente imprescindible: Poética de la línea de comandos donde ejemplifica la diferencia entre los dos paradigmas de una forma muy sencilla:

La interfaz de línea de comandos provee funciones, no aplicaciones; métodos, no soluciones, o: nada más que un montón de plug-ins para ser promiscuamente enchufados unos en otros. La aplicación puede construirse, y la solución puede ser inventanda, por los propios usuarios.

[…] O, también, el paradigma Lego de un juguete auto-definido frente al paradigma Playmobil de un juguete predefinido.

Finalmente, me gustaría incluir algunos ejemplos de interfaces que, si bien no son líneas de comandos clásicas orientadas a usuarios administradores de sistemas, sí hacen uso del lenguaje natural en formato textual para interaccionar con los usuarios.

Seguramente haya muchos más ejemplos, si conoces alguno te animo a que los compartas conmigo.

Una última reflexión que me surge es sobre la necesidad/oportunidad de evolucionar las CLI para que aprovechen mejor el factor de forma de algunos dispositivos móviles como Blackberry (que se niega a morir). A fin de cuentas aún hay millones de usuarios que se comunican y se entienden con mensajes de menos de 140 caracteres.

Google podría considerar otra interfaz más de comandos.

E.

El diseño móvil como parte de la experiencia: la importancia del contexto.

El diseño móvil como parte de la experiencia: la importancia del contexto.

G.

Google Design como recurso de aprendizaje

Si hay un recurso web que considero imprescindible tanto si deseas desarrollar algo para móviles como si sólo quieres aprender algo útil sobre diseño o programación es el portal de la plataforma Android.

Ya en el pasado enlacé alguna de sus buenas prácticas dirigidas a desarrolladores, pero no hay duda de que en este portal hay muchos más recursos útiles. Y es que, en general, las guías de estilo de las diferentes plataformas nos enseñan mucho más que directivas, sino los principios fundamentales de diseño en los que se basan los nuevos paradigmas de interacción y experiencia de usuario desde la capa visual hasta la construcción de la arquitectura.

En este caso Android, en sus secciones de Design, Development y Distribute, estructura unos contenidos valiosísimos para apreciar los detalles y los conceptos básicos con los que trabajar cuando te enfrentas a un desarrollo móvil (o casi de cualquier tipo si sabes abstraerte bien).

Si aún no has navegado por su web donde fundamentan las bases del lenguaje visual Material Design, te recomiendo que empieces por ahí ya que éste puede aplicarse a cualquier plataforma y detalla con infinidad de ejemplos múltiples principios de diseño.

Igualmente importante es la sección de estilo y patrones, la sección de training de desarrollo y los contenidos esenciales sobre la distribución de apps.

A veces me parece necesario no acumular demasiada cantidad de recursos, webs, libros, etc. para poder focalizarte en una sola cosa, sencilla, directa y bien estructurada sobre todo cuando el objetivo es aprender. La documentación de Android en este caso es un ‘gustazo’ no como la de iOS que en mi opinión sólo usa la verborrea para destacar de forma inconsistente y desestructurada algunos de sus iluminados principios de diseño. Pero quién soy yo para criticar al gran Ive o a su equipo…

Creo que mi apuesta queda bastante clara, más aún viendo cómo de bien le sientan los años a Android y lo bien que está madurando. Prueba de ello es la reciente salida de Android Studio 1.0, que pasó de la beta recientemente y se presenta como un entorno de desarrollo completo el cual espero trastear en profundidad en breve.

P.

Pencil

Herramienta de prototipado de código abierto multiplataforma

Si la austeridad también ha llegado a su ciudad, como el camión del tapicero, quizá guste de conocer esta interesante herramienta de prototipado de baja fidelidad totalmente gratuita y disponible para Linux, Windows y Mac.

Pencil no es nada nuevo ni bohemio ni cool, de hecho la última release es de Septiembre de 2013 y no da la impresión de que el proyecto siga vivo, pero no podemos negar que como herramienta es bastante útil si quieres empezar a trastear con el diseño de pantallas desde ya, además es gratis, es libre y el resto depende de tu imaginación (como siempre). 

Pencil Project nació en 2008 y se distribuye bajo términos de licencia GPL version 2, y es una herramienta muy sencilla que permite hacer cosas tan básicas como:

  • Dibujar diagramas
  • Sketchear GUIs basadas en componentes predefinidos
  • Relacionar documentos de un proyecto mediante enlaces de contenido
  • Exportar los documentos como imágenes o un documento HTML (aunque éste sea bastante precario)
  • Definir tus propia librería de componentes (muy útil para equipos de diseño)

Sobre éste último punto he publicado un pequeño artículor en el que explico cómo hacerlo.  Aquí os dejo el enlace por si os pica la curiosidad: Cómo crear una librería de recursos con Pencil.

C.

Cómo crear una librería de recursos con Pencil

Si ya conocéis Pencil y os preguntáis cómo podríais definir vuestra propia librería de componentes para crear GUI en este tutorial hacemos un repaso de los pasos a seguir.

Hay dos formas de conseguir nuestra propia librería

  1. Haciéndolo bien
  2. Haciéndolo rápido

Como para hacerlo bien ya existe una buena documentación en la web de la herramienta vamos a explicar cómo puede hacerse de forma rápida (y no tan flexible) para que resulte práctico crear conceptos visuales y compartirlos con diferentes equipos.

image

Una forma fácil de empezar

Usando la librería ‘Common shapes’ podemos empezar a dibujar elementos básicos basados en formas geométricas.

  1. Una vez que tengamos todos los elementos, los seleccionamos juntos y agrupamos (CTRL+G). Ahora se comportarán como una única forma.
  2. Sobre el nuevo componente clicamos en botón derecho “Add to my collections…”.
  3. Como este es el primer componente tendremos que crear una nueva colección a la cual añadirlo. 
  4. Si ahora comprobáis en la pestaña ‘My Stuff’ veréis que ya está creada vuestra nueva colección. 

Una característica que encuentro bastante útil es la ‘Sizing policy’ que tiene cada elemento (accesible via menú contextual). Esta política permite definir el comportamiento del elemento cuando está agrupado en un componente al que se le modifica el tamaño. Gracias a esto podrás decidir si quieres que cambie o no de tamaño o se mantenga alineado a un lado o a otro.

¿Y si quiero hacerlo bien?

Qué necesitas tener

  • Un editor de texto (para ver/editar XML)
  • Un editor de SVG (las formas están definidas como vectores)
  • Un editor de bitmpas (por si necesitas meter algún icono o imagen)

Qué necesitas saber

Una estructura típica para crear una colección tiene este aspecto

... [dir] CollectionName
      |
      |___[dir] icons       #optional
      |     |
      |     |___shape1.png
      |
      |___ Definition.xml     

y en el documento Definition.xml deberás definirlo de esta forma

<Shapes xmlns="http://www.evolus.vn/Namespace/Pencil"
        xmlns:p="http://www.evolus.vn/Namespace/Pencil"
        xmlns:svg="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"

        id="your_collection_id"
        displayName="Display name of your collection"
        description="More description about this collection"
        author="Names of the authors"
        url="Optional URL to its web page">
        
        <!-- Your shapes go here -->
        
</Shapes>

Iremos añadiendo los diferentes componentes usando las etiquetas <Shape></Shape> y dentro de ellos podremos definir Propiedades (color, dimensión, etc.), Comportamientos y Acciones además de su Aspecto (mediante el SVG).

Para ver lo que estamos haciendo, puedes cargar tu colección desde Tools » Developer Tools » Load Developer Stencil Directory… seleccionando el archivo Definition.xml (usa F5 una vez cargado para refrescar).

Cuando termines, mételo todo en un archivo ZIP asegurándote que el Definition.xml está en la carpeta raíz.

No te olvides que si quieres depurar errores puedes abrir la consola de errores desde Tools » Developer Tools » Show Error Console

A partir de aquí te recomiendo que consultes el Tutorial en el que viene explicado cada detalle sobre cómo montar la colección con directivas XML.

T.

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

I.

Interaction Design with Indigo Studio and GifCam

Interaction Design with Indigo Studio and GifCam.

Indigo first release was free forever, although it’s not available for download any longer. I’m one of the few who still have a Lite license and can take advantage of this powerful prototyping tool built in Silverlight.

Indigo has helped me to demonstrate design, simulate behaviour and communicate specifications with the development team and also with end users.

GifCam is just a cool resource that helps me to share microinteractions implemented with a prototyping tool.

And this ‘Hello World’ example is nothing but one of the design interactions in motion I’ve been working this morning 🙂