El diseño responsive no siempre es lo mejor


Últimamente todo el mundo apuesta por el diseño responsive y tiene sentido. Con un único diseño que se adapta a los diferentes tamaños de pantalla estoy dando a mi usuario la mejor experiencia en mi web. Pero no siempre es la mejor alternativa si tenemos en cuenta las diferentes condiciones que rodean a la navegación desde diferentes dispositivos. Un smartphone puede acceder a Internet a través de WIFI o a través de la red móvil, mucho más lenta. Lo mismo pasa con las tablets aunque en este caso el porcentaje de accesos a través de WIFI es mucho mayor que a través de la red móvil. Esta sutil diferencia puede suponer que la experiencia de un usuario sea completamente diferente en función de cómo esté accediendo a Internet.

Veamos dos ejemplos diferentes:

  • etece.es
    • diseño responsive: no
    • versión web móvil: si
    • peso de la home de escritorio: 477,5 KB
    • peso de la home móvil: 140,2 KB
  • otogami.com (espero que los camaradas del metal no les importe que la coja como ejemplo)
    • diseño responsive: si
    • versión web móvil: no porque ya tienen el diseño responsive
    • peso de la home en tamaño escritorio: 478,5 KB
    • peso de la home en tamaño móvil: 473,5 KB

Como podéis ver, aunque lo esté viendo en un tamaño mucho más pequeño, el diseño responsive necesita cargar la mayoría de los elementos que existen en una versión web de escritorio y por tanto el peso de la home es prácticamente el mismo.

Si tenemos en cuenta que una conexión 3G media en España está en torno a los 1,5Mbps (fuente adslzone.net) , esto supone unos 192 KB por segundo. Es deir, la home de etece en un móvil por 3G se cargará en menos de un segundo mientras que la de otogami tardará 2,5 segundos. A lo mejor esa diferencia de tiempo no supone un cambio en la experiencia de usuario en algunos casos, aunque en algunos otros puede ser la diferencia entre que el usuario se quede en mi web y acabe convirtiendo o que el usuario abandone.

Además de las razones que tienen que ver con experiencia de usuario, hay otras razones técnicas por las cuales el diseño responsive no siempre es la mejor opción. Si consideramos que un hilo de Apache está ocupado durante todo el tiempo que dura la descarga de lo que esté subiendo, con diseño responsive estaré consumiendo 2,5 veces más tiempo que con una versión móvil específica. Eso supone recursos de mi servidor o lo que es lo mismo, podré soportar más usuarios concurrentes desde dispositivos móviles con el mismo hardware si uso una versión móvil específica frente a un diseño responsive.

Durante todo el post estoy diciendo que el diseño responsive no es siempre la mejor opción lo que quiere decir que hay veces que si que lo es. Cuando el peso de una página es bastante bajo, no merece la pena hacer una versión web y es mucho mejor tener un diseño responsive. Soy especialmente fan de los diseños responsive en webs de contenidos muy sencillas tipo wordpress y similar.

Me encantaría que este post abriera un debate y espero no quedarme solo defendiendo las versiones web móviles específicas.

Anuncios

SQA en una startup


SQA (software quality assurance) o aseguramiento (vaya palabro) de la calidad del software es un concepto con el que convivimos los que nos dedicamos, de una u otra manera, al desarrollo de software. Definir qué es el SQA es algo complicado y cada uno tendrá una versión distinta pero para mi no es más que la colección de procesos y herramientas que permite asegurar en cada nueva release que el software desarrollado tiene la calidad suficiente como para poder ser desplegado en producción. Existen metodologías muy desarrolladas en torno a este tema pero yo prefiero ir a lo práctico y sencillo y al final lo reduzco a una serie de pruebas funcionales que debe pasar el software. Estas pruebas deben cubrir todos los procesos de negocio soportados por el software, tanto el funcionamiento esperado como los errores controlados.

La gestión de la calidad del software debería formar parte de manera natural del ciclo de vida del software pero todos sabemos que no es así. En casi todos los proyectos brilla por su ausencia.

SQA en una startup

En la mayoría de los casos, unir en una misma frase startup y SQA es ciencia ficción. Casi siempre en las startups tendemos a confundir rapidez, agilidad y calidad. Pero claro, los recursos y el tiempo en una startup son muy limitados y si hay que reducir por algún sitio, normalmente suele ser a costa de suprimir el SQA. Aunque por otro lado, nuestra tolerancia a los errores es muy baja y siempre queremos que las cosas funcionen perfectamente. Estoy seguro que a muchos os ha venido a la cabeza alguna conversación con vuestro CEO en la que habéis discutido sobre la necesidad de hacer un desarrollo para ayer pero luego, cuando las cosas han fallado por hacerlas deprisa y corriendo, ha puesto el grito en el cielo.

Cuando nos movemos en el entorno de una startup, parece bastante asumido que el SQA hay que dejarlo para más adelante, para cuando la empresa deja de ser una startup y te puedes parar un poco a afianzar todo. Algunos ejemplos:

  • En BuyVIP durante el tiempo que  fui CTO no teníamos ni un plan de pruebas definido ni un proceso de pruebas exaustivo previo al paso a producción.
  • En tagUin, teníamos una guía básica de qué había que comprobar y teníamos en la cabeza el detalle de lo que había que probar pero no lo hacíamos siempre y casi siempre nos dejábamos cosas por probar.
  • En Planeo mientras yo gestioné el proyecto, nunca hubo plan de pruebas y la parte de negocio nunca se involucró lo suficiente en hacer pruebas funcionales de calidad. Así pasaba, que casi siempre había errores totalmente evitables si el negocio hubiera probado lo que le pedíamos que probara.

Qué hacíamos en etece

Digo “hacíamos” y no hacemos porque estamos trabajando para cambiar y mejorar el SQA. Un poco más adelante os cuento qué estamos haciendo.

Desde la primera versión de etece que vio la luz a mediados de julio de 2012, hemos tenido un documento muy sencillo donde hemos ido incorporando las pruebas que considerámos necesarias para comprobar, en cada nueva release, que todo funciona según esperamos. En esa primera versión eran alrededor de unas 80 pruebas. Ahora vamos por casi 300. Estas son algunas de nuestras pruebas:

  • Grupo: registro de cliente
  • Prueba: registro correcto de cliente
  • Pre-requisitos: ninguno
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos con un email que no haya sido registrado previamente y se completa el registro
  • Resultado esperado: 1.- Llega correctamente el email de bienvenida; 2.- El usuario está correctamente registrado en el CRM; 3.- El cliente queda correctamente suscrito a las listas usuarios y clientes tanto en la web como en MailChimp
  • Grupo: registro de cliente
  • Prueba: registro de cliente con email dado de baja
  • Pre-requisitos: disponer de un usuario registrado y dado de baja
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos usando el email de un usuario dado de baja y se intenta completar el registro
  • Resultado esperado: El registro no se completa, se muestra un mensaje genérico de error y además se marca en rojo el campo email indicando que ya existe

Al principio, hacer todas las pruebas nos llevaba un día de una persona. Ahora, con casi 300 estamos en un par de días de dos personas. Además, según vamos incorporando funcionalidad a la web, las pruebas cada vez son más complejas y requiren de más tiempo. Estaba claro que teníamos que ir un paso más allá, automatizando las pruebas.

Qué estamos haciendo ahora en etece

Desde hace un par de semanas estamos trabajando para automatizar el mayor número de pruebas que podamos. Las ventajas de automatizar las pruebas son claras:

  1. mejora del tiempo necesario para pasar el plan de pruebas.
  2. minimizar la intervención humana. No hace falta, en un procentaje grande, que intervenga ninguna persona.
  3. mejorara la calidad de las pruebas. Es casi consecuencia del punto anterior. Al eliminar el factor humano, eliminamos aquellas pruebas que se dan por buenas por error o que directamente, la persona encargada no las hace ( pasa más de lo que pensáis).
  4. hay que ser más metodológico. Todo lo nuevo que se desarrolla o que se modifica debe tener sus pruebas funcionales programadas. Es algo bueno, pero también lo incluyo como punto negativo ya que muchas veces te puede complicar de más algún desarrollo.

En cambio, hay que asumir algunos puntos negativos:

  1. aumento del tiempo de desarrollo. Ahora, además de programar la funcionalidad, hay que programar las pruebas que comprueban que todo funciona correctamente y hay que mantener operativas las pruebas ya programadas. Estimamos que el tiempo se va a aumentar entre un 10% y un 15%.
  2. hay que se más metodológico.

Para automatizar las pruebas  estamos usando Seleniun2 con JUnit4. En los próximos días publicaré un post escrito por Javier Fernandez que explica a nivel técnico cómo está montada toda la automatizacion de pruebas. Avanzando un poco de lo que él contará, para cada una de las pruebas que teníamos escritas es nuestro plan de pruebas, hemos creado un test de Selenium que hace el proceso completo de la prueba y comprueba todos los resultados esperados. Hemos hecho cada prueba independiente de la anterior de manera que una prueba empieza sin necesitar datos anteriores, se ejecuta y al terminar borra todo rastro para así poder ser ejecutada de nuevo sin problemas. Como imaginaréis, hay muchos procesos que están compartidos entre muchas pruebas (registro de usuario, registro de solucionador, encargar una tarea, etc…) por lo que la estructura de clases que hemos montado nos permite independizar del test toda esta navegación común. El plan de pruebas lo lanzamos desde nuestro servidor de integración contínua (Jenkins) lo que nos permite conocer en todo momento la salud de nuestro proyecto.

Hasta la fecha hemos conseguido automatizar alrededor de un 90% de las pruebas del plan lo que reduce a poco más de un par de horas el trabajo el tiempo humano necesario para completar las pruebas.

Espero que estas líneas os sirvan de estímulo para incluir, de manera más o menos sencilla, el SQA como parte de vuestros proyecto.

Programador: medir también es importante


Casi todos los que de una u otra manera nos dedicamos a Internet, tenemos clara la importancia de la analítica web, de medir los más posible y con el mayor detalle posible. Pero existe un colectivo que suele no entender este punto. Ese colectivo son los programadores web, entre los que me incluyo parcialmente.
Desde el punto de vista de un programador, cuando la persona que lleva la analítica web define cómo hay que marcar y etiquetar las diferentes páginas, suele entender que debe hacer cambios en la programación que normalmente ya ha terminado, sin hacer esfuerzo en entender que esos cambios que tiene que hacer suponen una mejora importante para el negocio y que van a permitir entender mucho mejor el comportamiento de los usuarios.
Todo sería mucho más fácil si los programadores entendiéramos desde el principio que la analítica web es una pieza imprescindible, irrenunciable y tan importante como una buena programación. Al igual que poco a poco los programadores incorporamos de manera natural las buenas practicas de SEO, debemos incorporar el etiquetado a nuestras web y cambiarlo tantas veces como sea necesario entendiéndolo como parte de nuestro trabajo. Medir es muy importante!!

Por otro lado, hace tiempo que creo que los equipos que se dedican al SEO deberían estar bajo el paraguas de IT. Pero en el caso de la analítica web, no lo tengo del todo claro. En mi opinión están a caballo entre IT y marketing.

En los próximos años viviremos cambios en las estructuras de los equipos. SEO, analítica e IT estarán juntos y social media estará junto con atención al cliente. Aunque eso es otro tema.