Diseño Responsive o Locurónsive

scroll

Ayer, uno de los mejores fichajes de #camaradasdelmetal –Jimena Catalina– planteó en el foro si el diseño responsive o adaptativo era siempre la mejor opción. Me hizo gracia que planteara tal debate porque, apenas unos días antes, otro camarada del metal, Daniel Brandi -CTO de etece.es– había planteado la misma cuestión en su blog.

Daniel es un caballero de la cabeza a los pies y me escribió para preguntarme si me importaba que nombrara en su artículo a Otogami como MAL ejemplo del uso de diseño responsive.

Las razones de Jimena y Dani para no elegir el diseño responsive en sus webs son muy similares: el peso de la versión responsive respecto a una específica para móviles, el consumo de recursos que eso significa y -sobre todo- el mayor tiempo de carga en un país donde el 3G aún es un lujo en muchas zonas.

Pero el final de toda esta historia no tiene un final feliz para muchos programadores, porque lo que Jimena y Daniel proponen no es hacer un diseño no-responsive sino hacer n diseños “responsive, pero poco” para adaptarte a resoluciones de escritorio, tablet o smartphones ¿La justificación? Además del peso de la página antes mencionado, disponer de un contenido y diseño específico para cada tipo de dispositivo.

Jimena apunta una última razón que para mi es clave: domina con soltura el diseño y la maquetación, pero no cree que tenga los conocimientos suficientes de programación -en cliente o servidor- para hacer un buen responsive ¿Y si fuera al contrario?

La mejor opción de diseño para un programador es no diseñar

Otogami es una empresa ingenieril. El equipo técnico está formado por un 100% por desarrolladores y un 0% de maquetadores. Trabajamos con expertos externos que son profesionales como la copa de un pino, pero nada es igual que tener a un diseñador en plantilla. El diseño es, con mucho, nuestro mayor cuello de botella.

Los desarrolladores de Otogami son fieras que pueden crear desde cero un scraper y ponerlo en producción antes de que acabe el día, pero cuando tienen que modificar un diseño, parece que tienen morcillas en vez de dedos.

horrible-design
El último diseño propuesto por el equipo de desarrollo de Otogami

En nuestro caso, la única opción al diseño responsive sería el locurónsive porque nos volveríamos locos intentando mantenerlo. Si intentar no romper un sólo diseño ya nos hace sudar sangre, tener que trabajar con TRES sería como vivir en Mordor. Un claro ejemplo de que el equipo del que se disponga puede llegar a condicionar decisiones de negocio.

  • Aitor

    Buenas,

    primero de todo me he pasado por el blog de Daniel, a ver que explicaba y despues he dado mi opinión sobre responsive, que la gente solo hablaba de versión movil 🙂

    yo estoy contigo David, prefiero responsive. Primero porque si quieres tener escritorio, movil y tablet, o tienes 3 maquetaciones o hacer responsive. A mi me parece más comodo

    Es cierto que hay cosas que luego son complicadas de hacer, o que no siempre se ve bien como se deberia… pero tambien pasa con la maquetacion de toda la vida (nuestro odiado ie)

    Yo creo que Otogami, el problema no viene de responsive o no, viene de que soys los que soys (a mi a dias me pasa lo mismo) y no teneis nadie ni de diseño, y ningun maquetador ninja.

    Si los tuvierais, seguramente, tendriais mejor adaptada la pagina.

  • Daniel Brandi

    Gracias por la mención. Yo no defiendo las n versiones como mejor alternativa si no que creo que lo responsive por defecto tampoco es lo mejor. De hecho, apuntas una muy buena razón para tener responsive y es el equipo que tienes. Eso determina un montón de cosas y una de ellas es precisamente el tipo de diseño. Por cierto, como gamer, me encanta Otogami.

  • darumesten

    Igual estoy entendiéndolo yo mal, o me falta contexto por no haber leído el post original en el foro, pero cuando dices que:

    “domina con soltura el diseño y la maquetación, pero no cree que tenga los conocimientos suficientes de programación -en cliente o servidor- para hacer un buen responsive”

    Qué conocimientos hay que tener de programación en servidor o cliente para que lo que maquetes sea responsive? Casi al 100% se trata de media queries en los CSS.

    • Yo esa parte final o punto final tampoco lo entiendo, una web con Mobile First y luego con @media-queries 768 px y 1024px se hace con CSS y HTML. Quizás se puede referir a servir imagenes dependiendo de la resolución con scripts Javascript como Picturefill, aún asi con esto se hace todo o casi todo en el HTML y es un añadido.

    • Ok, me explico. El responsive parte del concepto “One web for ALL”, y lo pongo en mayúsculas porque eso incluye muchos más dispositivos de los que estamos acostumbrados a soportar en los proyectos del día a día. Hay incluso algunos que no soportan javascript y media-queries, por eso el responsive suele ir unido al concepto de mobile-first, se empieza con la versión más básica de la web y se añaden más funcionalidades si se detecta (mediante servidor o javascript) que el dispositivo tiene más capacidades. Sé que los móviles más tontos no importan mucho si tienes un blog, pero sí si el cliente que te pide el responsive es una administración pública que debería dar acceso a toda la población.

      Pero volviendo a mi caso, cosas que tendría que hacer en recetasderechupete.com si tuviera un diseño responsive y que no puedo por falta de conocimientos de programación:
      – Cargar los scripts de botones sociales (facebook, twitter, g+) solo para tablet o desktop. O mejor aún, solo para dispositivos conectados a wifi, porque si te casco 400kb sobre una conexión 3G y la web tarda en cargar 4 segundos, te piras. Ya me duele tener metido el jquery para hacer 2 tonterías y algún día me pondré en serio para librarme de él.
      – Cambiar los formatos de publicidad según dispositivo. Lo siento pero no me basta con recolocarlos, no te voy a mostrar un 728×90 en un móvil. Google Adsense ofrece algunas facilidades pero por ahora es el único.
      – Hay algunos módulos de contenido que directamente no quiero mostrar en móvil y no voy a poner un display:none en un media-query para gastar tiempo de descarga en algo que no se va a ver. Tendría que meterme en el fregado de los Server Side Components o simplemente detectar en servidor para no incluirlos en el tema de WordPress.

      En la mayoría de los proyectos de responsive (blogs, webs de empresas, webs promocionales…) esto no hace falta, pero imagínate el encaje de bolillos que tendría que hacer facebook si se pasara al responsive.

      • A nivel de navegadores tan solo IE8(y versiones anteriores) no aceptan @media-queries http://caniuse.com/#feat=css-mediaqueries. Si un dispositivo no acepta Javascript no lo vas a poder seguir con Analytics y con muchas mas cosas que se me ocurren. Si puedo detectar el dipositivo en función de su resolución a través de CSS me ahorro el trabajo del lado del servidor o con Javascript.

        – Jodo-co 400kb para los botones de Facebook, Twitter y Google+ es una locura pero para cualquier version, quita los botones o busca otros XDD

        – Lo de la publicidad no me meto.

        – En algo estamos de acuerdo, display:none ni con un palo. Pero si tu web fuera mobile-first, lo que no quieres mostrar en la versión móvil lo colocas en el media-querie de (min-width: 1024px) y ese contenido solo se muestra a los dispositivos que tengan una resolución superior a 1024px y te ahorras el display:none y cargar cosicas que no vas a mostrar.

        Un buen ejemplo de responsive a lo bestia http://www.bostonglobe.com

        • Como ejemplo de responsive a lo bestia y bien hecho, me gusta mucho más el de BBC News http://responsivenews.co.uk/ Precisamente porque tienen un público muy amplio, con visitas de “feature phones” desde África y Asia, y con versiones de Opera Mini y Mobile que no soportan todo el javascript. Por cierto que Analytics aún ofrece tracking mediante imagen GIF para móviles que no soportan JS, yo lo usaba hasta hace nada 😀

          – Los botones de redes sociales me ofrecen ventajas en posicionamiento y viralización del contenido (ya probé a quitarlos en todas las versiones y sus consecuencias).
          – ¿display:none ni con un palo y pasar contenido (y peso en kb) a la capa de presentación? Venga ya, eso es una ñapa y la típica cosa que se hace para tener un “responsive por huevos”

          Insisto de nuevo en que yo no soy anti-responsive, solamente que algunos clientes se han aprendido el término de moda y a veces no es la mejor solución.

  • Helios VIcente

    He estado leyendo tanto el artículo de Daniel, como la aportación al foro de Jimena. Y tu artículo, claro. Y estoy de acuerdo con Jimena en una de sus frases, que viene a decir que tiene miedo cuando alguien entra con el RESPONSIVE TATUADO. Ese yo creo que es el verdadero asunto en este caso, el hecho de dejarse llevar por una moda sin analizar convenientemente si se adapta o no a tus circunstancias, tus objetivos y tus necesidades.

    Está claro que se pueden , como en cualquier tecnología, sacar pros y contras. Pero el quid está en saber cuales son tus circunstancias para escoger la mejor tecnología que te permite utilizar sus pros sin que te afecten mucho sus contras. En vuestro caso, al igual que el de Jimena, tenéis muy claro cuales son vuestras circunstancias y la elección no ha sido porque “es lo que se lleva” sino porque es lo que os permite maximizar los beneficios de cada tecnología.

    En el ultimo proyecto que participé, la elección fue también responsive y las circunstancias muy similares a las tuyas. En neustro caso, la información que mostrábamos se adaptaba bien, el peso no era excesivo y no teníamos tiempo ni personal para andar modificando varios diseños.

    En resumen, prefiero un responsive o no responsive adaptado a las circunstancias que uno “porque es lo que se lleva”.

  • Juan Antonio Cortés

    “domina con soltura el diseño y la maquetación, pero no cree que tenga los conocimientos suficientes de programación -en cliente o servidor- para hacer un buen responsive”

    Estoy con @darumesten:disqus, no veo la relación.

  • Daniel López

    Mencionas #camaradasdelmetal y no enlazas a su web, mencionas que Jimena hizo un post… y tampoco lo enlazas, pero enlazas otros blogs, cuentas de twitter… ¿Está prohibido enlazar a camaradasdelmetal? 😛

    • Que va, lo que está prohibido es publicar a las 6 de la mañana, pero yo me lo saltó casi todos los días… y así salen los textos como salen.

  • Luis Miguel de Sancho

    Creo que RESPONSIVE SI pero con cabeza …..

    A la hora de abordar un proyecto, no podemos guiarnos SOLO por lo que en los blogs, foros o escaleras de patio se comente, se lleve o se ponga por montera.

    El gran problema de un diseño (responsive o adaptativo) no está en su peso, complejidad o demás elementos …. considero que su mayor dificultad es en la definición de sus diferentes elementos y cual es la mejor representación para ellos. Considero que ese punto es lo que marca la diferencia entre un site con éxito de uno más …

    Muchos clientes/empresas no tienen muy presentes o valoran estos primeros pasos que, desde mi modesto punto de vista, son el alma y el corazón de todo proyecto.

    Como mucho de vosotros decís, todo depende del equipo que tengas ….

  • Pues a mi me convenció el responsive de The Next Web.

  • Hola,

    Pues estoy bastante de acuerdo con lo que plantea Jimena en #camaradasdelmetal.

    Aunque mi perfil es más de desarrollo, me toca a menudo parte de diseño, y también oigo bastante lo de “y que sea responsive”, decisión que en la mayoría de los casos ni está justificada por ningún dato mínimo, como por ejemplo alguna estadística de tráfico.

    Del post de Jimena resaltaría dos puntos que creo que ya hablan por sí solos:

    – “La versión desktop se ve y se navega perfectamente en tablets. No lo arregles si no está roto.”
    Nada más que añadir 🙂

    – “Hay contenido que no creo que interese a los usuarios móviles, y la forma de navegar también difiere.”
    La decisión de enfocar la web como “mobile first” obviamente tiene tomarse por alguna razón. Y lo mismo para responsive.

    Personalmente, creo que es la palabra de moda “a exigir”, pero bueno, como muchas otras cosas, esto va por temporadas 🙂

    Un saludo,

    Alberto Gato Otero.

  • Toma! Toma! Leer este post y encontrame el mismo día con un post del mismísimo Coding Horror hablando del infierno que es desarrollar applicaciones para móviles, teniendo que desarrollar una versión por cada plataforma. ¿Casualidad? Igual no.
    Sigue con tus Fred Wilson’s David, que lo vas a petar. ¡Ánimo!

  • Ernesto Cardenas

    Por las restricciones de ancho de banda en nuestro pais (750MB mensuales de plan de datos!!) sugiero versiones separadas, que el servidor en el request capture el dispositivo y te renderice la versión que corresponda (para una misma URL). Unas cuantas visitas a un sitio responsive y zas!! adios cuota mensual.
    Así que consideraría usar algún gestor de contenidos para aliviar ese tema (mismo contenido bajo diferente plantilla bajo demanda) en cuanto el contenido vaya creciendo, para sites pequeños no es totalmente necesario pero si la lista de contenidos sigue subiendo..

  • Felicidades al equipo de Otogami por ese último diseño magistral 😀