La usabilidad no es opcional

La cruda verdad: la usabilidad no es opcional

Introducción

En el año 2007 se produjo un hecho que cambiaría radicalmente el dominio de los programadores en el desarrollo de interfaces gráficas: la aparición de IPhone.

Mas allá de todas las críticas que se puedan realizar sobre aquella primera versión, lo que es indiscutible es que transformó la experiencia de los usuarios al usar teléfonos y marcó un camino que luego todos los fabricantes trataron de seguir.

La experiencia del usuario

Hasta aquel momento los teléfonos eran muy diversos y la forma de comunicarse de esas interfaces gráficas estaban todavía dentro del dominio de los programadores

Es cierto que ya en aquel momento había personas que se dedicaban a hacer interfaces gráficas más amigables. Pero lo destacable es el papel del usuario hasta ese momento: se conformaba con lo que le daban para usar. El usuario podía comprar otras marcas y entonces tener que adaptarse a la experiencia que esa marca brindaba con el dispositivo adquirido.

En el mudo de las páginas web y las aplicaciones comerciales pasaba más o menos lo mismo. Es decir, el usuario se debía adaptar al sistema.

Tomemos por ejemplo la siguiente pantalla:

¿Es necesario tener al mismo tiempo todas esas opciones disponibles? ¿ Todos esos campos son realmente necesarios ? ¿Y cada campo a completar tiene la misma importancia?

Tomemos por ejemplo el siguiente sitio web:

¿Es necesario todo ese nivel de información en la Home del sitio?¿Cuál es el objetivo del sitio?¿Qué puedo hacer con él?

Estas pantallas reflejan el tipo de interfaz gráfica con la que el usuario interactuaba a diario.

La experiencia de los desarrolladores

Quienes estábamos en el mundo de desarrollo por aquellos años, y sobre todo si trabajábamos con tecnología .Net, estábamos fascinados por las maravillas que WebForms nos brindaba: controles auto-generados, generación de HTML, CSS y Javascript automático, programación orientada a objetos en el mundo web.

Hacer web por aquellos años con esta tecnología no era tan complejo y, de hecho, así lo propiciaba Microsoft. Teníamos que centrarnos en el código del servidor ya que la tecnología puramente Web no era estrictamente necesaria de aprender.

¿Y entonces qué cambió?

Lo que sucedió es que la web luego de la burbuja comenzó a crecer cada vez más y nuevos jugadores comenzaron a aparecer en escena: Google y Apple.

Ambas companías se focalizaron en brindar al usuario experiencias diferentes con las aplicaciones que ofrecían. Incluso la experiencia de usuario se vio afectada por la forma en que estas empresas permitían comprar, descargar y actualizar el software.

Con el correr de los años los usuarios se acostumbraron a estas nuevas características y se fue estableciendo una especie de "piso", de "mínimo" esperable para las interfaces gráficas, la manera de comprar, instalar y actualizar el software.

De esta forma la tendencia de generar una experiencia de usuario más enriquecida implicó que emergieran nuevos especialistas: los analistas de User Experience (UX).

Estos profesionales deben combinar una serie de técnicas y conocimientos que provienen de diferentes áreas: marketing, psicología, diseño, sociología, diseño industrial, comunicación y sistemas.
Pero además generan actividades y conocimientos que le son propios y no compartidos por otras áreas.

¿Cómo nos afecta en el proceso de desarrollo de software?

El cambio al incorporar un equipo de UX en el proceso de desarrollo es muy importante.

En primer lugar porque ellos deben comprender los objetivos del cliente, del producto. Deben poder definir cada paso de la interacción del usuario, flujo lógicos de información por medio la interfaz. 

Y como resultado de este trabajo ellos generan prototipos de dos tipos: alta y baja fidelidad.

Tradicionalmente este tipo de tarea fue responsabilidad del analista funcional. Y esto es sumamente interesante porque justamente es la parte donde se complementan ambas posiciones. 

Un buen analista funcional hoy en día tiene que tener conocimientos y llevar adelante prácticas de UX. Pero lo mismo resulta para los analistas de UX: tienen que incorporar algunas técnicas y metodologías que tradicionalmente usaron los analistas funcionales.

Esto se debe a que ambos tienen que comprender el producto a desarrollar/mejorar con un enfoque sistemico: entrada, procesamiento, salida y retroalimentación. La diferencia está en que los analistas funcionales se centran en el sistema y los analistas de UX se centran en el usuario

El prototipo en baja fidelidad (Sketch o Wireframe) que producen los analistas de UX es un input sumamente valioso para el desarrollo de sistemas.Con ellos se puede identificar inmediatamente los tipos de entidades y atributos que existen, sus  vinculaciones, los procesos de transformación de información, validaciones y workflows subyacentes.

¡Ah! ¿Entonces le ponemos unas horas de UX a nuestro proyecto y listo?

Esta pregunta creo que se puede responder en parte con la siguiente imagen:

Creer que UX se puede ofrecer por horas es pensar que esta actividad es un condimento que se le puede agregar a la comida que estamos elaborando.

Siguiendo con esta metáfora, no estamos viendo que UX no es un condimento sino un instrumento de cocina tan útil como un cuchillo. ¿Podemos cocinar sin cuchillo? Sí, pero seguramente algo no estará del todo bien...y nos preguntaremos por qué el cliente nunca está satisfecho...

La misión de UX es el usuario, su experiencia. Es el tipo de cuchillo que siempre hemos necesitado en desarrollo. 

En otro artículo mostraré como personalmente entiendo que interactúan las disciplinas de UX con el proceso de desarrollo de software ágil.

Hasta la próxima!

Arquitectura REST

Desafíos de una arquitectura REST

Introducción

En un artículo anterior explique desde mi punto de vista las diferencias entre SOAP y REST.

En esta ocasión vamos quiero explicar los desafíos que representa para el arquitecto de software la aplicación de este tipo de arquitectura.

Escenario

Asumiendo que lo que vamos a exponer son recursos con los cuales vamos a interactuar por medio de diferentes verbos, lo primero que tenemos que evitar es abrir nuestra capa de aplicación en métodos que ofrezcan la funcionalidad al mundo exterior. 

Supongamos el siguiente ejemplo:

Aquí tenemos un cliente HTTP que consume la capa de negocio de una aplicación por medio de una capa de servicio REST que trabaja con los verbos get, put, post, delete y search.

El resultado de esto es una aplicación cuya capa de presentación se encuentra desacoplada lo máximo posible del negocio. Así la capa de presentación puede ser diseñada, maquetada y programada por personas ajenas a cualquier tecnología propietaria de back end.

Desafíos 

Sin embargo tener una capa de servicios en formato REST no es necesario para lograr los mismos beneficios de esta arquitectura.

Esta capa podría implementarse perfectamente como WebService en formato SOAP o Json y mantendría los mismos beneficios.

La pregunta entonces es ¿ qué implicancias y desafíos tiene hacer una capa REST?

El principal cambio, desde mi punto de vista, es que lo que se expone con REST son recursos y el tipo de acción a aplicar sobre estos recursos son indicados por los verbos HTTP.

Si la capa de negocio tiene una buena arquitectura con patrones como Facade, la funcionalidad debería estar expuesta en forma de métodos que representan acciones de negocio. Y esto es muy distinto de lo que debemos hacer cuando pensamos en REST. Aquí los verbos están limitados a los estándares del protocolo HTTP (los más usados quizás son: get, put, delete, post, search) y lo que tenemos que pensar es QUÉ recurso vamos a exponer.

Por ejemplo, en una aplicación que maneja órdenes de compra y un usuario puede tener asignado para gestionar muchas órdenes de compra, es probable que todas las acciones que se puedan realizar sobre la orden sean métodos encapsulados de alguna forma por una o más fachadas (independientemente de la forma de despliegue).

Pero si queremos exponer esta fachada con una capa REST debemos pensar que el recurso en sí sería uno solo (la orden); la forma de leer las órdenes sería sobrecargas del verbo GET; las formas de buscar una orden serían sobrecargas del verbo SEARCH; y las respuestas a cada una de estas llamadas siempre debería ser un objeto de tipo orden (independientemente si se devuelve como Json o XML).

Si la orden tiene como atributo otro objeto más, como por ejemplo una sucursal, ésta debería ser en si misma otro recurso, y por lo tanto el cliente HTTP que quiera interactuar esta entidad tendría que usar los mismos verbos.

Consecuencias

Si continuamos con este análisis nos daremos cuenta que utilizar una capa de servicios REST implica centrarnos fuertemente en las entidades que vamos a compartir, porque esas entidades serían los recursos y lo que querramos hacer con ellas serán los verbos HTTP que vamos codificar y exponer.

Esto significa que si una entidad "Usuario" no tiene codificado una respuesta para el verbo SEARCH no se debería poder buscar esta entidad.

Otra aspecto que también sale a la luz es que claramente una capa de presentación cuya interacción con el back end sea por medio de servicios REST debe gestionar por si sola el renderizado y bindeo de todas estas entidades sueltas.

Por ejemplo, una sola página HTML puede que requiera disparar 4 llamadas GET, una para cada tipo de entidad que deba ser mostrada, ya sea en formato de combo, grillas o algún control combinado.

Conclusiones

A simple vista, generar una capa de servicios con WebServices parece mucho más simple y natural si es que estamos acostumbrados a la programación orientada a objetos.

REST se acerca más a la forma ideal con que fue concebida la web. Es una excelente forma de estandarizar la comunicación entre sistemas pero es posible que sea muy exigente para ser consumida directamente por una capa de presentación. 

Esta exigencia se debe a que la renderización e interacción de una página requiere utilizar múltiples llamadas con diferentes verbos.

Con REST es conceptualmente incompatible exponer como recurso ViewModels ya que por definición éstos son recortes del modelo especialmente creados para las vistas.

En síntesis, considero que utilizar REST implica un trabajo de análisis mayor por parte del arquitecto de software para no cometer errores o usos indebidos / forzados de esta maravillosa técnica.