Como humanos, cuando nos encontramos en situaciones de incertidumbre, nos gusta tener reglas fijas a las que poder acogernos a la hora de tomar decisiones. De ese modo, evitamos tener que pensar por nosotros mismos, dar explicaciones engorrosas o defender decisiones de diseño ante personas que tienen un credo diferente del tuyo.

Algo así está pasando con el RD. De las últimas charlas, cursos o posts que he leído, se habla de esta técnica como la medicina definitiva que cura todos los males del multidispositivo, la que se tiene que usar siempre; y si no la utilizas, algo raro te pasa.

Sin embargo, ni siquiera Luke Wroblewski, uno de sus más conocidos profetas, el padre de la criatura, la considera la panacea, sino sólo una técnica más para atacar el multidispositivo. Esto es lo que recomienda a la hora de aplicar las tres técnicas más habituales:

Responsive Design

• Quieres tener una única plantilla de diseño que se ajuste a todos los dispositivos
• Puedes vivir sin la completa optimización para cada dispositivo.
• No tienes acceso a soluciones de servidor.
• No confías en la detección del dispositivo.

Experiencia específica por dispositivo

• Quieres la mayor optimización por cada tipo de dispositivo.
• Quieres ofrecer experiencias de uso y características diferentes para cada dispositivo.
• Te sientes cómodo con la detección de dispositivo.

Responsive Design con componentes de servidor (RESS)

• Quieres ajustar diferentes plantillas de diseño a diferentes dispositivos.
• Quieres optimizar el rendimiento técnico y la experiencia de usuario.
• Confías en la detección de dispositivo del lado de servidor.

En conjunto, la toma de decisión se puede resumir en las siguientes variables:

1. Dificultad en la detección del dispositivo: Estas diferencias fueron escritas en febrero de 2012, hace casi dos años. Técnicamente se ha avanzado lo suficiente para detectar el tamaño de pantalla, navegador o dispositivo con un par de líneas de código, tanto de servidor como local. Puedes hacerlo con cualquiera las tres técnicas.
2. Dificultad al acceso a soluciones de servidor: Si no tienes control sobre los servidores, sólo te queda atacar con HTML, CSS y Javascript. Entonces el RD es tu única opción.
3. Tener una única plantilla de diseño o varias según dispositivo: El detalle es «plantilla de diseño», y no «diseño». Los diseños son diferentes para los dispositivos, la cuestión es cómo implementar técnicamente esas diferencias. Tampoco es cuestión del lenguaje en el que estés codificando, sino de si va a haber plantillas distintas para cada dispositivo, o de si vas a tunear una plantilla con diferentes trozos de código. En cualquier caso, sea cual sea la opción que elijas, vas a a tener trozos de código diferenciados por dispositivo, unas opciones lo hacen en servidor y otras en local.
4. Optimizar el rendimiento técnico: Cada mili-segundo y cada bit cuentan en la experiencia de usuario. En sitios muy pesados y con mucho tráfico, desperdiciar bits ocultando o mostrando componentes según dispositivo, sencillamente no es una opción, ni en servidor ni en local. En local es aún más doloroso, ya que la velocidad o la capacidad de procesamiento de los móviles (por muy avanzados que sean) no es la misma que un ordenador.
5. Optimizar la experiencia de uso por dispositivo : El contexto de uso y las necesidades de los usuarios de pantallas pequeñas son muy distintos de las necesidades en pantallas grandes. Cuanto más diferentes sean las necesidades, más diferente tiene que ser el diseño. No sólo a la hora de priorizar funcionalidades, sino también para poner o quitar funcionalidades dependiendo del contexto.

Como vemos, las 4 primeras pertenecen al espectro tecnológico. Si tienes completo control técnico sobre el proyecto, sólo queda la variable de la experiencia de usuario. El RD no es la opción óptima para la experiencia de usuario, sino el «apaño» para proyectos en los que no puedes o no quieres controlar la tecnología de servidor, o los recursos para el desarrollo son muy limitados.

La experiencia específica por dispositivo conlleva una serie de recursos humanos y técnicos que sólo empresas muy grandes se pueden permitir. Si no eres Google, Facebook o similar, mejor busca una solución híbrida.

El RESS tiene lo bueno (y lo malo) de la experiencia específica del dispositivo y del RD: Se acerca a la optimización técnica (no al 100% en todos los proyectos, pero sí en la mayoría) y además cubre completamente la optimización de la experiencia de usuario, que es lo que nos interesa a todos. En la parte mala, necesitas control sobre los servidores y un poquito más de organización a la hora de llevar el proyecto.

En cuanto a coste, ya he comentado que la experiencia específica por dispositivo conlleva un coste mucho mayor, aparte de estar vendido a la enorme diversidad de sistemas existentes y por venir. Desde mi experiencia, no he visto desviaciones de tiempo de desarrollo en RESS mayores que las que pueda tener un RD: el primero se tarda un poco más en programar, pero el segundo es mucho más lento de testear, prácticamente lo comido por lo servido.

Puedes engañarte a ti mismo con la facilidad de manutención de la «única» plantilla, o puedes atreverte con las otras dos técnicas si eres una persona cuidadosa con la organización del proyecto.

Como vemos, no hay una técnica mejor que otra, sino situaciones en las que conviene una técnica u otra. La próxima vez que alguien te proponga hacer algo en RD, valora las 5 variables y decide por ti mismo si es la mejor opción.