Esta vez toca unos trucos básicos para llevar a cabo un diseño adaptable con fundamento.

0.- Things aren´t always #000000 and #FFFFFF

Esto no es una ciencia, se acerca más a un arte, por lo que no hay una manera fija de hacer las cosas. Y ¿cuándo tengas dudas? Usa el sentido común.

Y aunque no sea una ciencia como tal, tenemos mil reglas, unidades,  excepciones,… y por supuesto trucos que nos facilitan la vida.

1.-Otra de unidades #emPower

Se puede o mejor dicho de debe trabajar con em en los media queries.

Queda algo como:

Aquí os dejo un artículo que habla del tema.

2.-¿62,5% dónde lo he visto antes?

Supongo que conocéis el truco de poner esta línea de código para que 1em equivalga a 10px, ¿verdad?

Es útil si no queremos estar dividiendo cada unidad en 16 para hacer la conversión de unidades.

Pero aquí viene el PERO: con los media queries no funciona esta regla del 62,5%, ya que esta hace referencia a la fuente del navegador, y no a la etiqueta html. Por lo que sacad la “calcu” y acostumbraros a hacer la siguiente división. 1px/16em.

Consejo de la abuela: /*poned el comentario con el equivalente en px*/

Os dejo el link de un conversor: riddle.pl/emcalc/

3.-Houston tenemos un problema

Si en cada 10px-50px-100px tenemos que saltar a otra media query, seguramente habrá que replantear esa parte del diseño. Intentemos optimizar y utilizar el sentido común.

4.-Una de cal y una de arena

Dicho por un profesional del responsive: ¿Crear una media query sólo por una línea de código? ¿Por qué no? No se pagan al peso, si el diseño lo pide, se pone.

Es decir, con estos dos puntos anteriores os doy argumentos para que hagais con los @media lo que os venga en gana, y cuando cuestionen vuestro código, y sabeis: “estoy optimizando” o “el diseño lo pide”.

5.-Redimensión de fuentes

Aunque nos guste ser puristas y utilizar sólo css para nuestros proyectos responsive, es evidente que hay partes que se quedan cojas y tenemos que pedir rescate a javascript. Por ejemplo, ¿qué pasa si queremos que una fuente se adecue al viewport? Todavía las unidades vw no se soportan en los navegadores. Para esto tenemos este sencillo js: fittextjs.com. Para utilizarlo en títulos o encabezados viene de cine, ni se os ocurra plantearlo en párrafos…o los de FitText te echarán la bronca.

Ejemplo de uso:

El número que está en amarillo es el número “mágico” que hay que ir modificando a “ojo de buen cubero”, ya que es distinto según la fuente.

6.-Redimensión de vídeos

Para redimensionar un vídeo externo que tenemos en un iframe, tenemos este JS que nos ayudará: fitvidsjs.com

7.- Explorer sí tiene remedio

Si alguien te quiere convencer de que el responsive no tiene soporte en ie, no le creas. respond.js viene a echarte una mano, y hará que en ie funcionen tus media queries rápido y bien.

El último punto es el mejor, siempre, si has llegado hasta el final te llevas de regalo: el respond.js, que es un must en responsive.

¿Cómo se empieza a trabajar? ¿Qué fases se pueden plantear? ¿Cómo se presenta el proyecto? ¿Cómo se presupuesta?

Esto no es un dogma, cada uno que aplique la metodología que le venga mejor, pero está bien saber cómo trabaja un profesional del tema y a qué conclusiones ha llegado después de pelear en muchos proyectos y seguro llevar más de un escarmiento.

1.-Cambio del paradigma del proceso de trabajo

Se plantea un sistema retroalimentado e interactivo para ir identificando posibles errores lo antes posible e ir dándoles solución. ¿Te suena el mundo agile? Pues eso.

Todo el equipo tiene que estar involucrado en todo el proceso de vida del proyecto y no pasar el proyecto al siguiente eslabón y olvidarse del tema, ya que algunas veces se puede dar solución mediante css a un problema de funcionalidad, o viceversa. El cliente tiene que estar presente en este proceso y tomar parte, para evitar sorpresas de última hora, algo muy frustante para las dos partes. Una metodología de este tipo hará que el proceso sea mucho más enriquecedor, consigamos un producto más redondo y que todos aprendamos más con cada proyecto.

2.-Ok, ¿por dónde empezamos? El presupuesto, por supuesto

¿Cómo presupuestamos un proyecto web que también será responsive? La recomendación es no añadirlo como un extra desglosado sino que vaya integrado en la cantidad principal, ya que sino nos arriesgamos a que el cliente lo pida a posteriori y esto nos lleve a trabajar más y peor. Lo ideal es empezar a plantear el proyecto adaptable desde el principio, para conseguir un producto óptimo. Bienvenido al “yo por defecto responsive, gracias”.

3.- Dos prototipos y punto

No es necesario presentar prototipos de cada “tamaño standar” y de cada pantalla. Con un prototipo para móvil y otro para escritorio es suficiente. El tamaño del medio seguro que lo tenemos claro en la cabeza. Con nuestro sistema de cambios retroalimentados iremos modificando hasta encontrar el layout y navegación adecuados. Si pulimos demasiado en este primer punto, puede ser que tengamos que hacer muchos cambios a wireframes que nos han llevado un montón de horas.

4.-¿Boceto? De momento con styletiles suficiente

Este es el punto que más me ha gustado, ya que no conocía este concepto y me ha parecido una idea sencilla y muy productiva.

La idea es presentar unos tres styletiles para concretar la gramática visual y así conseguir un acercamiento del estilo final. Concretar los encabezados, estilos de botones, paleta de colores,… No son propuestas finales y cerradas, y nos ayudarán a guiar al cliente en la toma de decisiones. Se terminó al típico: “dale otra vuelta”, y que te quieras suicidar porque ese boceto te ha costado sudor y lágrimas. La idea es que los styletiles se puedan realizar en una tarde (es un decir), y que nos pueda acercar a un boceto final sin propuestas de cambios dolorosos.

http://styletil.es en esta web nos podemos descargar los PSD para utilizar como plantillas. Más facil imposible.

5.-Y una vez con las ideas claras montamos el HTML y le damos estilo.

6.-¿Hemos acabado? NO

Correcciones -> desarrollo -> correcciones -> desarrollo ->… ahora sí. The end. Optimicemos tiempo con metodologías ágiles y utilicemos ese tiempo para el desarrollo.

Revelación number 1: Cambio del modelo de caja

¿Qué quebraderos de cabeza nos da que la anchura total de una caja sea el width + su borde + su padding, verdad? ¿No sería más sencillo que la anchura sea el width que le pones y si tiene padding lo añada por dentro y no se tenga que sumar? Pues a alguien le han valido sus rezos ya que tenemos solución para esto, y además sencillo y efectivo:

Este cachito de código reseteará todos elementos para cambiar el modelo de caja. ¿Magia? Lo parece. Esto nos permitirá trabajar de manera más sencilla con bloques de contenido en nuestro proyecto responsive.
Buscando documentación al respecto, he encontrado en la Biblia del CSS (css-tricks.com), un artículo (http://css-tricks.com/box-sizing/) que hace referencia a esto. ¡Es del 2010! Vergüenza me debería dar enterarme a estas alturas, jajaja

Revelación number 2: redimensión de imágenes

Tema controvertido en responsive design: las imágenes. ¿Cómo las redimensionamos? Creo que mañana veremos más soluciones, pero de momento para abrir el apetito:

También sirve para vídeo, iframe, canvas y object.

Revelación number 3: el famoso viewport, ¿para qué sirve?

Había utilizado el meta viewport en mis proyectos pero sin entender demasiado para qué. Es sencillo: Los móviles sin esta etiqueta muestran las páginas web en zoom-out por defecto para que el usuario haga zoom-in para navegar. Pero si nuestra web es responsive y no queremos que el dispositivo actue de esa manera, sino que queremos que le haga caso a nuestro css, le ponemos esta línea de código en el <head> para avisarle que somos unos ‘pros’ y tenemos el responsive trabajado.

Este meta es un mundo. Os dejo un artículo sobre sus caraterísticas.

Revelación number 4: ¿Dónde ponemos los breakpoints?

Facil: Cuando el diseño se rompa vas y lo arreglas con una media query. Ya está. Punto pelota.

Revelación number 5: la unidad em

En responsive se recomienda trabajar con la em en lugar de con px. Si no se está acostumbrado cuesta un pelín al principio, porque tienen ciertas características un poco especiales: las unidades em son relativas al padre. Es decir, 1em no es igual en todas las declaraciones que hacemos en el código, ya que dependerá del font-size que tenga su progenitor. La unidad rem viene a salvar la papeleta porque sigue teniendo lo bueno que tiene el em, que es una unidad relativa, pero nos quita la dependencia de los ‘parientes’, ya que es relativa al root, a la etiqueta html.