La semana pasada dimos nuestra opinión sobre cómo decantarnos por desarrollar una web o una APP nativa, y hoy vamos a centrarnos en ir un paso más allá del Responsive mediante el RESS.

Lo primero es tener claro que reponsive es un subconjunto de adaptive, y que por tanto quedarse tan solo en el Responsive cuando el objetivo es desarrollar una web multidispositivo puede ser un error, o más bien es quedarse en la superficie del objetivo. Porque recordemos que responsive se basa en el conjunto de técnicas de frontend (HTML + Javascript + CSS) que se encargan de modelar el HTML, darle estilos y funcionalidades. Y ahí está la clave: frontend. Por tanto con RESS vamos a ir ese paso más allá para que el responsive de nuestra web multidispositivo sea más robusta.

¿Qué es RESS?

RESS implica beneficiarse del lenguaje servidor y de los componentes del lado del servidor (Server Side components, de ahí: RESS).

Uno de los problemas, o errores más comunes cuando se desarrolla un responsive es el hiding content: Esto no es otra cosa que esconder el contenido para la versión (o versiones) más pequeñas. Cuando se desarrolla partiendo del diseño y maquetación desktop (pantallas grandes) y se va bajando de resolución de pantalla mediante media queries (CSS) se adapta el contenido para que se ajuste al ancho de pantalla, pues siguiendo este camino nos encontramos con mucho contenido que en la versión más pequeña (móvil, normalmente) no se necesita y entonces simplemente se oculta.

¿Y qué sucede? Pues que aunque se oculte ese contenido realmente está ahí: se carga. Va includo en el peso de la página. De ahí que esta estrategia (hiding content) normalmente no sea la más adecuada.

Con una estrategia mobile first se suele subsanar. Para implementar el mobile first básicamente se empieza por el diseño y maquetación de pantallas pequeñas y a medida que se incrementa el tamaño de la pantalla se efectúa el siguiente diseño y su maquetación. De este modo lo primero en cargar es la versión móvil y si el dispositivo resulta ser un móvil, ya no se sigue cargando el resto.

Pero llega un momento en que esto no es suficiente (o más bien: es mejorable), y aquí entra en juego RESS para darle más sentido a nuestra primera carga de la aplicación.

Debemos pensar en RESS como en un primer escalón al que todo usuario sube cuando entra en nuestra aplicación y en el que ya podemos obtener algo de información del visitante. Necesitamos que de algún modo, antes de devolver todo el HTML (y funcionalidades de frontend) tengamos una mínima pista de qué dispositivo nos lo está solicitando (de este modo no tenemos que recurrir al odioso hiding content ya comentado).

Posible solución: RESS. Ojo, porque en realidad esta técnica no es dejar de hacer uno para hacer el otro, es más bien apoyarse en uno para que el otro sea más robusto.

Por ejemplo, el problema con las imágenes en el RWD se puede solucionar si desde el lado servidor ya se sirve la imagen lógica (es decir, la que presuponemos que sería la óptima por el tipo de dispositivo al que se sirve el HTML). Hasta ahora si asumíamos un mobile first, lo que hacíamos era cargar las más pequeñas y mediante frontend la cambiábamos por la que tocaba en función de la pantalla del usuario. Con RESS podemos servir la que a priori nos dicta el servidor, y luego hacer los arreglos pertinentes desde frontend.

RESS nos ayuda a predefinir qué cargamos en primera instancia: Imágenes, CSS, Javascripts, contenido de texto, contenido multimedia… y luego en función del frontend dejamos de cargar, seguimos cargando, vamos algún nivel arriba o abajo (tipo de dispositivo).

Imaginemos que en nuestra versión desktop tenemos un slideshow, que en nuestra versión móvil no queremos, al igual que algún tipo de submenú. Además de las imágenes, que si el dispositivo es un móvil queremos cargar unas más pequeñas, si es tablet otras, y si es desktop otras más pesadas y con más definición.

Pues bien, RESS nos detectaría el dispositivo (teórico) y nos diría qué cargamos antes, sirviendo el que se presupone óptimo, y luego mediante frontend nos aseguraríamos aún más (por eso es más robusto) de que el dispositivo en el que se visiona todo es el adecuado. Si es coincidente dejaríamos de cargar. Si es mayor seguiríamos cargando contenido extra (por ejemplo mediante AJAX) y si es inferior, también dejaríamos de cargar el contenido extra y posiblemente podríamos corregir el que ya está servido.

Como veis de este modo tenemos un punto de partida antes de llegar al frontend y además, será más fiable la elección final.

A tener en cuenta después de implementar RESS (o mejor, mientras ;-))

  • SEO (Sí, todavía hay a quien le preocupa ;-)). Debemos vigilar qué lee realmente el spider de los buscadores, y qué no… Hay emuladores al respecto, y como comprenderéis todo se basa en el HTML que se sirve finalmente.
  • Velocidad de conexión. Obviamente no es lo mismo navegar desde 3G que desde cable.
  • No dar nada por sentado. Mosquea bastante que, porque el desarrollador de turno ha decidido que si él cree que navegas desde un móvil, no darte las funcionalidades de desktop cuando realmente no navegas desde un móvil… es decir, sea lo que sea que RESS descubra, deja la opción que mediante frontend puedas modificar la experiencia del usuario. Imagina que desde servidor, interpretas que es un móvil, pero que su pantalla es de 1200px porque desde el frontend lo estás leyendo así… Algo falla, ¿no? 😉

Anteriores posts hablando de Responsive

Comparte… ¡o no!
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *